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.

Enterprise User Security (EUS)

The past weeks we have been working on Enterprise User Security. In this solution the Oracle database users are stored in the Oracle Internet Directory (OID) .
Together with the solution described in the previous blog entries in, which the Linux users are stored in the OID too, this makes the OID the central point of the user management.
So the databases as wel as the Linux user are refering to the same OID user.
More details in coming blogs.

Script doesn't work for double line version

It is not like I'm working ful time on OID Authentication for Operating Systems. Just part time for a certain customer. For other customers I do IDM and security architecting. But some how these nitty gritty details seem more blog material.
We are roling this out for multiple linux servers and it turned out taht for some servers the client script of OA4OS wasn't working. After debugging and tracing it turned out that the /etc/redhat-release version file of these two servers was different.
Instead of
cat /etc/redhat-release
Enterprise Linux Enterprise Linux AS release 4 (October Update 5)
Like on the other servers the response was:
cat /etc/redhat-release
Red Hat Enterprise Linux AS release 4
Enterprise Linux Enterprise Linux AS release 4 (October Update 5)

Which lets the awk scrip collect a 4 newline 4 in stead of just 4:

cat /etc/redhat-release awk '{print $7}'
4
4

Then the /usr/bin/authconfig isnot executed because the if statement that needs to be true before this statement checks for a version equal to 4 of 5 and not for equal to 4 newline 4.

We solved this issue by removing the first line in the version file. Somehow at the installation of OEL the line was added instead of updated. This was just for two machines, the OID cluster, in the whole infrastructure of 20 machines.

You would ask, why would there be the double line in the version file ? That is because the Oracle Internet Directory (OID) doesn't install on Enterprise Linux yet. But does install on "Red Hat Enterprise Linux AS release 4".
The test we have done was on the same machine(s) we installed the OID on. The other machines didn't have the version file change and therefore didn't have the install problem.

Wrong password ?

Implementing the Oracle Authentication for Operating System (OAfOS) for a certain Oracle Enterprise Linux (OEL) server we got a Access Denied error when we tried to login the server using the credentials from the Oracle Internet Directory (OID) ldap server. When we looked in the /var/log/secure messages file we saw the error
sshd[22791]: Failed password for invalid user xander

This even though the same account xander worked fine for other OEL servers.
When we used the su xander from the root account on the OEL server we were able to create the directory:

$ su xander

Creating directory '/home/xander'.

Creating directory '/home/xander/.kde'.

Creating directory '/home/xander/.kde/Autostart'.

It turned out that this specific machine had an extra access policy in the /etc/security/access.conf file. This policy only let users access the machine through SSH when they were member of a group.
When we added the same group to the OID and added the username to the group, the password error was gone and we were able login using SSH