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.