Discoverer 10g login and password expiry in an SSO environment

Introduction

In an E-Business Suite 11i application, one can enable Password Expiration for users created locally using the DEFINE USER form. This value is stored in the PASSWORD_LIFESPAN_DAYS column. If the 11i application is integrated with Oracle Single Sign-On (SSO), the 11i SSO login mechanism ignores this column as expected because the password policy is defined in the LDAP Directory. However, this does not seem to be the case for Discoverer 10g SSO Login functionality. The Discoverer login code seems to be explicitly checking for 'PASSWORD_LIFESPAN_DAYS' column in the FND_USER table even though it is SSO enabled. This behavior is consistent in both Discoverer Plus and Viewer components.

For example, if FND_USER.PASSWORD_DATE is 22-NOV-08,FND_USER.PASSWORD_LIFESPAN_DAYS 30 and if SYSDATE is '22-JAN-09' for user JSMITH, the Discoverer Login will fail with the above error (whenever PASSWORD_LIFESPAN_DAYS is less than SYSDATE-PASSWORD_DATE) .

Solution

Update the PASSWORD_LIFESPAN_DAYS column to NULL for all rows in the FND_USER table after the 11i application is integrated with SSO.

High Availability Architecture for SSO and OID database components

The architecture diagram contains high availability configuration details for the SSO webserver and OID database components (Metadata Repository) in an Oracle Identity Management setup.

How to create a lean Oracle Internet Directory

Introduction

A Directory Service such as Microsoft Active Directory (AD) stores a variety of information about an enterprise viz. User Accounts, Organization Units, Printer names, Computer names, Fax Machine names and other network resources. If AD is the master source of truth for Oracle Internet Directory (OID), the Oracle Directory Integration Assistant provides a default filter to retrieve only the needed resourcers i.e user accounts (objectclass=user), groups and Organization Units (objectclass=organizationalunit). Below is the default filter to retrieve information from a Microsoft Active Directory. This can be viewed by launching dipassistant -gui tool on the Oracle Internet Directory (OID) host (dipassistant -gui => ActiveChgImp => Filtering)

"searchfilter=((objectclass=group)(objectclass=organizationalunit)(&(objectclass=user)(!(objectclass=computer))))"

Custom Filter

One can add additional conditions in the searchfilter to block unwanted resources such as disabled user accounts, special user accounts, generic user accounts or even organization units if a FLAT DIT is implemented. In a huge enterprise, Active Directory can contain thousands of unwanted user account names and if a custom filter is not used, all these unwanted entries will be loaded into FND_USER table on the E-Business Suite database if "Unconditional Provisioning" is enabled.

A few advantages of a custom filter are the following

1. A lean OID (less number of rows in the ODS schema and lesser number of entries processed during the initial bootstrap operation to get data from AD to OID).
2. Less work performed by the AD to OID syncrhonziation jobs during every scheduled interval.
3. A lean FND_USER table if Unconditional Provisioning is turned on.

How to write a custom filter

Conditions written in boolean operators are usually in the form of (condition_1 and condition_2), (condition_1 and (condition_2 or condition_3)) etc.

But an LDAP searchfilter is written differently. Note the position where the boolean operators are placed in the below examples.

Example 1 : (condition_1 and condition_2) is written as and(condition_1)(condition_2)

Example 2 : (condition_1 and (condition_2 or condition_3)) is written as and(condition_1)or((condition_2)(condition_3))

In our enterprise's Active Directory, special account names have a . (DOT) in them such as ADMIN.PAYROLL, Inactive users are stored in the attribute Org-UserStatus with an "I". The custom search filter for our case is

searchfilter=(&(objectclass=user)(!((cn=*.*)(sAMAccountName=*.*)(Org-UserStatus=I)(objectclass=computer))))

If one wants to write a custom filter, one should work with the AD administrator to obtain the conditions and attribute names that can be used in the filtering process. Now follow the rules mentioned above to place the boolean operators in the right positions to get the filter working.

FLATTENED Directory Information Tree

Introduction

By default, Oracle creates the Directory Information Tree (DIT) in an identical structure during the initial data load (bootstrap) and subsequent data syncrhonization from an external LDAP directory (such as MS Active Directory) to the Oracle LDAP Directory (Oracle Internet Directory). However, several entries failed to get loaded into OID when we tried with this default method. Our bootstrap.log file contained the below errors for the entries that failed to get processed in OID.

LDAP: error code 32 - Parent entry not found in the directory
Error occurred while loading - cn=emp_2,ou=aurora,ou=IL,dc=oid_srv,dc=mycompany,dc=com

DN in Active Directory (AD)

cn=emp_2,ou=aurora,ou=IL,dc=ad_srv,dc=mycompany,dc=com

DN in Oracle Internet Directory (Identical to the DN in AD)

cn=emp_2,ou=aurora,ou=IL,dc=oid_srv,dc=mycompany,dc=com

Solution

This error is at best misleading because the parent entry (ou=aurora) did get created in OID. We could not get a solution for this error and hence altered the design of our DIT on the target OID. We have FLATTENED the DIT. A FLAT DIT does not have any sub tree such as OUs etc. and all the entries are loaded under a single sub tree (FLATTENed). To create a FLAT DIT, the Domain Mapping Rule has to be configured in the AD->OID syncrhonization profile.

DN in Active Directory (AD)

cn=emp_2,ou=aurora,ou=IL,dc=ad_srv,dc=mycompany,dc=com

DN in Oracle Internet Directory (FLATTENED without any OUs)

cn=emp_2,dc=oid_srv,dc=mycompany,dc=com




Conclusion

Oracle supports both regular DITs and flat DITs. If one wants to check the source directory's DN value, one can use use the orclsourceobjectdn attribute returned by the ldapsearch command in OID.Furthermore, a flat DIT is simple in design and easy to search for entries in OID using the oidadmin utility. All the LDAP syncrhonization functions such as ADD, MODIFY and DELETE are supported in a FLAT DIT. We have designed a flat DIT and we are happy with it.

OCA CA Root certificate warning in the browser

Introduction

We went LIVE with Single Sign-On integration for Oracle Applications during the Thanks Giving weekend. For the real time system, we configured SSL for network encryption. For the E-Business Suite SSL configuration, we purchased the security certificate from Verisign (A third-party certificate authority). But this time we wanted to try Oracle Certificate Authority (OCA) for the Single Sign-On web server.

Some of the advantages of OCA are

1. Stronger encryption algorithms.
2. Cost effective. Since OCA is Oracle's own certificate issuing system, it eliminates the need for IT administrators to purchase certificates from third-party authorities such as Verisign etc.
3. Automatic storage of the certificate in OID because OCA is tightly integrated with the latter. Policies can be configured in OID for renewal alerts and expiration dates of the security certificates.

However, popular browsers such as Internet Explorer, Mozilla FireFox etc. trust certificates only from a few well established authorities and Oracle is not one of them yet. Because of this limitation, websites configured with SSL certificates issued by OCA show a warning.

Solution

One procedure to avoid such a warning is to request the system administrators to push the CA Root Certificate to all browsers in the enterprise.

Conclusion

To save a few $$, Oracle Certificate Authority is a good alternative to Verisign for securing Oracle resources provided your system administrator agrees to push the CA Root Certificate to the trusted list of certificates of the standard browsers. We saved this hassle for our administrator and purchased a certificate from Verisign (its already trusted by Internet Explorer). However OCA is a good bet for test and UAT systems. By the way, OCA is part of the Identity Management Software. Following is the warning message shown by Internet Explorer when the certificate issued by OCA is not yet trusted by the browser.

How to fix BULKDELETE performance problem

Due to several reasons, one may have to delete all the bootstrapped 3rd party user data from Oracle Internet Directory (OID). For example, thousands of entries may have got loaded from MS Active Directory into OID during the initial bootstrap process. If one wants to bulkdelete all these entries from OID, one can notice a performance problem during the delete operation. This problem currently exists in 10.1.4.2 Oracle Identity Management software. When i tried the bulkdelete operation with 60,000 entries, it took almost 20 hours to finish the execution.

The fix for this performance problem is to create a custom index on one of the OID tables.

1. Login as ods/***@ssodb
2. CREATE INDEX TEMP_UBS_CT_HRCH_QUERY_IDX on CT_HRCH_QUERY(ENTRYID);
3. exit
4. $ORACLE_HOME/ldap/bin/bulkdelete connect="ssodb" basedn="cn=Users,dc=oid_srv,dc=mycompany,dc=com"
5. Login as ods/***@ssodb
6. Drop index TEMP_UBS_CT_HRCH_QUERY_IDX

This index is only for fixing the performance problem and can be dropped after the bulkdelete operation completes successfully. I could complete the bulkdelete operation in less than 20 minutes with the custom index in place to delete the 60,000 entries from OID. Compare that with the 20 hours that i got without the index !

Restriction on Automatic User Provisioning

Introduction

I have explained about the different methods of user provisioning in the previous article here. If one were to go with 'Unconditional Provisioning' (automatic provisioning) of new users from OID to FND_USER table, then one has to consider an important restriction on how such users be placed in the Directory Information Tree in OID.

New User entries that are created in OID and have to be automatically provisioned (created) in FND_USER table must be either placed in the default USERS container or any container that is a sub-tree of the USERS container. If the user entries are in a sub-tree that is at the same level as the default USERS container, then such entries will not be automatically created in FND_USER table even if the 'Applications SSO Enable OID Identity Add Event' system profile option is ENABLED.

Conclusion

This restriction should go away in future releases of Oracle Identity Management, but as of now, the latest 10.1.4.2 does have it. One can load all users in OID in the default USERs container, however for better management and administration purposes, it is always recommended to create normal users in a sub-tree container.