Enforcement of Separation Of Duty (SOD) rules for the enterprise is very complicated when it is done per application. For each application like SAP, Oracle eBS, Peoplesoft or JD Edwards the SOD rules would have to be defined. But there is no sight on the overall SOD rules that would prevent a person to have rights in the Peoplesoft HR as well as the SAP order management or General ledger.
Theoretically it would be possible to have a meta SOD system to enforce these kind of rules. But that would be complex to implement and use. When a user would get a role it would need to be checked in the specific systems as well as the meta system.
The solution is in the future of Service Orientation. When would would have an authorization service for the total enterprise the SOD rules could be enforced in this service. Each application like SAP, EBS or Peoplesoft would check the authorization level of the person in the authorization service.
That would mean a change in architecture for the different ERP application. Oracle is working on that in their fusion applications. The authorization server used by the authorization service they already have. They got it through the Bea systems acquisition. It is the former aqua logic server now called Entitlement server.
Sunday 28 December 2008
Saturday 6 December 2008
Application Separation Of Duty
Separation of Duty (SOD) is often enforced per application. Within a ERP application like JD Edwards, SAP or Oracle E-Business Suite the roles are checked against a list of roles that can't be shared.
The roles that can't be shared are defined by business standards for the specific market, laws like Sarbanes Oxley and company specific.
Because the SOD enforcement wasn't build in the core of the systems the SOD checks are post role assignment. On a regular basis the roles assignments to the persons, groups or department are checked against the SOD list.
Then these SOD need to be resolved. This can work but will mean extra work since the roles assignments are checked after the fact. When an SOD is found these need to be resolved by assigning the role to another person or group of persons.
Off course when the roles were defined they needed to be checked that they only have SOD conflicts within the role.
The roles that can't be shared are defined by business standards for the specific market, laws like Sarbanes Oxley and company specific.
Because the SOD enforcement wasn't build in the core of the systems the SOD checks are post role assignment. On a regular basis the roles assignments to the persons, groups or department are checked against the SOD list.
Then these SOD need to be resolved. This can work but will mean extra work since the roles assignments are checked after the fact. When an SOD is found these need to be resolved by assigning the role to another person or group of persons.
Off course when the roles were defined they needed to be checked that they only have SOD conflicts within the role.
Wednesday 29 October 2008
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.
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.
Tuesday 28 October 2008
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.
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.
Tuesday 7 October 2008
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.
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.
Wednesday 1 October 2008
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.
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.
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.
Tuesday 16 September 2008
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.
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.
Monday 18 August 2008
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.
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.
Tuesday 8 July 2008
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:
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
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
Tuesday 1 July 2008
High Available setup of Oracle Authentication Services for Operating Systems
Oracle Authentication Services for Operating Systems (OASfOS) is the way to use the Oracle Internet Directory (OID) LDAP server for user management of the users on a Unix or Linux system.
This works fine and is explained in the manuals that come with the download from Oracle Technology Network: http://www.oracle.com/technology/products/oid/oracleauthenticationservices.html
But the scripts that come with this OASfOS download assume that a single instance OID ldap server is used. The script that should be run on the OID server get the host name of that server and creates the script that should be run on the Linux or Unix servers that will be using the OID as there user base.
But the strength of the OID is that it can be setup with a cluster database in the back-end. Using a hardware load balancer in from of the OID processes can mitigate against all kinds of hardware and software failures. The hardware load balancer will be setup with a Virtual DNS name which will direct the ldap requests to either of the OID processes in the cluster. The back-end of the OID processes a Real Application Cluster (RAC) database is used.
The procedure for setting up OASfOS in a cluster is slightly different from setting it up for a single instance.
The server script is that run on the first instance should be adjusted. Instead of getting the hostname of the machine on which this OID is running, it should use the LDAP Virtual Address that is used in the load balancer.
That adjusted script will create a client script that will the use the virtual address of the load balancer instead of one of the host addresses.
In the following text the bit that is changed in the server script is shown in red:
if [ "X$dmName" = "X(none)" -o "X$dmName" = "X" ]
then
dmName=""
# rootDN="cn=`hostname`,${realm}"
# hostName="`hostname`"
rootDN="cn=oid-virtualaddress.nl.oracle.com,${realm}"
hostName="oid-virtualaddress.nl.oracle.com"
else
# rootDN="cn=`hostname`.${dmName},${realm}"
# hostName="`hostname`.${dmName}"
rootDN="cn=oid-virtualaddress.nl.oracle.com,${realm}"
hostName="oid-virtualaddress.nl.oracle.com"
fi
On the other instance the only change that is made is that the Wallet for SSL traffic that is created on the first instance is copied to the same place on the second instance. The same instructions as described in the documentation for changing the standard certificate can be used.
The server script should not be run on the second instance, since it also changes the contents of the OID, but since RAC is used that is already changed when the script is run on the first instance.
This works fine and is explained in the manuals that come with the download from Oracle Technology Network: http://www.oracle.com/technology/products/oid/oracleauthenticationservices.html
But the scripts that come with this OASfOS download assume that a single instance OID ldap server is used. The script that should be run on the OID server get the host name of that server and creates the script that should be run on the Linux or Unix servers that will be using the OID as there user base.
But the strength of the OID is that it can be setup with a cluster database in the back-end. Using a hardware load balancer in from of the OID processes can mitigate against all kinds of hardware and software failures. The hardware load balancer will be setup with a Virtual DNS name which will direct the ldap requests to either of the OID processes in the cluster. The back-end of the OID processes a Real Application Cluster (RAC) database is used.
The procedure for setting up OASfOS in a cluster is slightly different from setting it up for a single instance.
The server script is that run on the first instance should be adjusted. Instead of getting the hostname of the machine on which this OID is running, it should use the LDAP Virtual Address that is used in the load balancer.
That adjusted script will create a client script that will the use the virtual address of the load balancer instead of one of the host addresses.
In the following text the bit that is changed in the server script is shown in red:
if [ "X$dmName" = "X(none)" -o "X$dmName" = "X" ]
then
dmName=""
# rootDN="cn=`hostname`,${realm}"
# hostName="`hostname`"
rootDN="cn=oid-virtualaddress.nl.oracle.com,${realm}"
hostName="oid-virtualaddress.nl.oracle.com"
else
# rootDN="cn=`hostname`.${dmName},${realm}"
# hostName="`hostname`.${dmName}"
rootDN="cn=oid-virtualaddress.nl.oracle.com,${realm}"
hostName="oid-virtualaddress.nl.oracle.com"
fi
On the other instance the only change that is made is that the Wallet for SSL traffic that is created on the first instance is copied to the same place on the second instance. The same instructions as described in the documentation for changing the standard certificate can be used.
The server script should not be run on the second instance, since it also changes the contents of the OID, but since RAC is used that is already changed when the script is run on the first instance.
Start blogging
Start blogging my manager said, 2 years ago. That is good for your "career". But I didn't think I had anything to add that couldn't be found anywhere else.
But then lately I had to find out some stuff that wasn't written in any of the manuals. Mind you, no rocket science or brain surgery, but it would be convenient if I could have done the work using a sample.
So I can start working on my "career" from today.
On this blog you should expect stuff which isn't already written in the manual (at the time of writing is my techie addition).
It could be somebody else is writing it down in another blog at the same moment though, this is my next nerdy addition to my own rule. But the web doesn't have any tools yet to prevent this redundancy, possibly in a semantic web all is normalized.
But then lately I had to find out some stuff that wasn't written in any of the manuals. Mind you, no rocket science or brain surgery, but it would be convenient if I could have done the work using a sample.
So I can start working on my "career" from today.
On this blog you should expect stuff which isn't already written in the manual (at the time of writing is my techie addition).
It could be somebody else is writing it down in another blog at the same moment though, this is my next nerdy addition to my own rule. But the web doesn't have any tools yet to prevent this redundancy, possibly in a semantic web all is normalized.
Subscribe to:
Posts (Atom)