EUS and Grid Control next

Yesterday I explained how to get Enterprise User Security (EUS) and Grid Control (GC) to work together. This is without integrating GC with the Oracle Single Sign On Server that would also use the Oracle Internet Directory (OID) for storage of the user credentials.
When a EUS user is logged into GC and the administrator would want to administer a database automatically the preferred credential screen is displayed. The data in this screen is already filled in with the EUS information. The administrator should also be a EUS for that database and then transparently the DBA can administer the database.
This way using an ldap server like the OID and setting up EUS for a hundreds of databases dba's can in a simple way be added and removed from databases.

EUS and Grid Control

According to the Oracle documentation Enterprise User Security (EUS) works with Oracle Enterprise Manager Grid Control. The steps in the documentation: http://download.oracle.com/docs/cd/B16240_01/doc/em.102/e10954/security2.htm#i1036425.

The steps explained there are easy to follow and correct. The repository of the Grid Control (GC) is setup for EUS and works fine. But just for sqlplus sessions to the repository and one would want to login to the Grid Control console. That unfortunately didn't work. The authentication went ago, but the user didn't have the propers authorization. But even giving the EUS user the proper GC authorization didn't make it work:

SQL> grant MGMT_USER to EMGC_EUS;

Grant succeeded.

Login still din't work, see the picture.

The work around waqs to create a regular GC user thru the GC administration console. Then drop this user from the GC repository. That means the database user droppped, but the GC user is still defined. Then the EUS user can login to the GC console.

Security Roadmap

In the entries of the first of October we showed the single account usages between Oracle Enterprise Linux Operating (OEL) system accounts and Oracle database accounts. One would say why not go for Single Sign On (SSO) using kerberos rightaway. Indeed that would simplify the usages of the accounts.
There are a number of technical and license reasons I'll get to later, but it is also a social reason.
One of the reasons is the SSO would be based on Kerberos in combination with MS Active Directory (AD) . For many companies the AD is doing the domain authentication.
For the OEL machines to be able to use keberos authentication they would have to be added to the windows domains as machines. Before large enterprises to go for this kinds of integration they need to get used to the idea. Alot of evangilizing is necessary before that can be achieved.
Using single account between OS and database is a step in getting used to that idea.
Management will start asking for SSO soon afterwards. Cross "IT Ecosphere" integration is than easier too.
Other reasons for not quickly implementing OEL Kerberos authentication:
1) Kerberized clients, like kerberized Putty for SSH, need to be used. To role these out in large Enterprise takes a lot of explaining and time.
2) MIT Kerberos for Windows DLL's needs to be implemented to integrate the Kerberos with OEL. To role this out in thousands of clients takes a lot of time and explaining.

These extra installations could be prevented when the Oracle Database administrators for whom we are implementing this solution would use the sqlplus client form the windows client prompt. Since the windows client is already authenticated to the windows domain. This windows run client could then be used for Kerberos authentication to the Oracle database. Skipping the authentication to the OEL OS.
But the Oracle DBA's are very used to there Unix prompt and can also only slowly change there attitude. Here again that will need some time.

To implemented kerberos Authentication for the oracle database is fairly simple and following the steps in the Oracle manual will get you there.But to be able to use kerberos for windows one needs to have the Advanced Security Option licensed from Oracle.
This extra costs is not always within the budget of even large Enterprises.

Al in al the roadmap to security should be taken in small steps, so to get all stakeholders used to the little bit of technical solutions to take them onto the path of the next level.

Single Sign On ?

You may ask is the previous entry Single Sign On between an OS and Oracle database. The answer is: "no". This is single account usage. Single Sign On between the OS and the database can be achieved using Kerberos authentication. We will discuss that in a later blog entry.
The advantage of this solution is that in one place the account with which a user enters the database or the OS is maintained.
This can make the solution more secure, because the user only has to remember one userid and password. The alternative would be userid's and passwords in all the machines used and in all the databases used. These would have password expiry policies. But these would only be enforced when a user would enter a machine or database. With different moments of accessing machines and database the risk would be that different passwords with then different expiry dates would be used. The maintaince of userdid and password would be made more complex and users would choose easier passwords or other kinds of workarounds.
With the single password for all the databases and all the machines it would be very simple to change the password for all those resources. This would make it easier for the user to accept that a password has to be more complex and changed in a regular interval.

EUS with OAS4OS

This is a beautifull acroniem heavy heading. We are combining Enterprise User Security, e.g. Database users from an ldap directory with Oracle Authentication for Operating System, e.g. Operating System users from an ldap server.
An OS session where sqlplus is used looks as follows:

login as: HeemskerkACW
mailto:HeemskerkACW@linuxmachine1 password:
Last login: Wed Oct 1 15:15:59 2008 from 10.100.1.172

aliases: DB1
HeemskerkACW@linuxmachine1::/home/HeemskerkACW
$ DB1
HeemskerkACW@linuxmachine1:DB1:/home/HeemskerkACW
$ sqlplus HeemskerkACW@DB1

SQL*Plus: Release 10.2.0.3.0 - Production on Wed Oct 1 15:18:27 2008

Copyright (c) 1982, 2006, Oracle. All Rights Reserved.

Enter password: ********

Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
With the Partitioning, Real Application Clusters, OLAP and Data Mining options

SQL> show user
USER is "SHARED_SCHEMA_USER"
SELECT
SYS_CONTEXT('USERENV','EXTERNAL_NAME')
,SYS_CONTEXT('SYS_LDAP_USER_DEFAULT','mail')
,SYS_CONTEXT('SYS_LDAP_USER_DEFAULT','telephoneNumber')
,SYS_CONTEXT('SYS_LDAP_USER_DEFAULT','uid')
FROM DUAL
7 /

SYS_CONTEXT('USERENV','EXTERNA
--------------------------------------------------------------------------------
SYS_CONTEXT('SYS_LDAP_USER_DEF
--------------------------------------------------------------------------------
SYS_CONTEXT('SYS_LDAP_USER_DEF
--------------------------------------------------------------------------------
SYS_CONTEXT('SYS_LDAP_USER_DEF
--------------------------------------------------------------------------------
cn=heemskerk\, acw (xander),cn=users,dc=nl,dc=oracle,dc=nl
xheemske@googlemail.nl
+31 30 6698443
HeemskerkACW

SQL>

As can be seen the same userid is used for both the OS as the database session. What can't be seen but you can take on "my blog entry" is that the same password is used.
The userid and the password came from the Oracle Internet Directory ldap server.
How to set this up will be in a next blog.