Oracle Unified Directory 11gR2 PS3 available for download

The Identity Management 11gR2 PS3 release, including OUD 11gR2 PS3 is available on eDelivery.
To download OUD, go to http://www.oracle.com/technetwork/middleware/id-mgmt/downloads/oid-11gr2-2104316.html
and select OUD 11gR2 PS3

R2PS3 documentation is available at http://docs.oracle.com/cd/E52734_01/oud/docs.htm

Certification Matrix is available at http://www.oracle.com/technetwork/middleware/id-mgmt/documentation/identity-access-111230certmatrix-2539086.xlsx

New OUD Source Code plugin examples

I’ve just published a couple of OUD plugin examples to help customers develop their own extensions.

The ZIP package includes 2 plugin examples to demonstrate the richness of OUD plugin API. The FilterDistributor can be used to route bind request to 2 different workflow elements based on a condition present on the user entry about to be used for authentication. The PasswordSchemeUpgrade  can be used to migrate passwords from one storage/encryption scheme to another.

Plugins examples are available at http://www.oracle.com/technetwork/middleware/id-mgmt/learnmore/oid-demos-182820.html

OUD Plugin API reference is available at http://docs.oracle.com/cd/E49437_01/apirefs.111220/e38583/index.html

OUD Plugin Developer Guide is available at http://docs.oracle.com/cd/E49437_01/doc.111220/e38455/toc.htm

Global Administrators with a subset of Admin Privileges

Oracle Unified Directory provides one default root DN or root user, "cn=Directory Manager". The default root DN is a user entry assigned with specialized privileges with full read and write access to all data in the server. Comparable to a Unix root user or superuser, the root DN can bypass access controls to carry out tasks on the server. The root user is defined below the "cn=Root DNs,cn=config" branch of the server atcn=Directory Manager,cn=Root DNs,cn=config. and is local to each OUD instance.  The server supports multiple root users who have their own entries and their own set of credentials on the server.

OUD also provides the notion of global administrators. Global Administrators are responsible for managing and maintaining administrative server domains in replicated environments. One Global Administrator is created when you set up replication servers using the graphical installer or the dsreplication command (you are prompted to set a user name and password for the Global Administrator) .

The Global Administrator created for the replication exists in the cn=Administrators,cn=admin data subtree, so it is replicated and can be used with every OUD instance of a replicated topology. To view the Global Administrator entry, run the following ldapsearch command:

$ ldapsearch -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file \
  --useSSL -b "cn=Administrators,cn=admin data" -s sub "(objectclass=*)"
dn: cn=Administrators,cn=admin data
objectClass: top
objectClass: groupofurls
description: Group of identities which have full access.
cn: Administrators
memberURL: ldap:///cn=Administrators,cn=admin data??one?(objectclass=*)
dn: cn=admin,cn=Administrators,cn=admin data
objectClass: person
objectClass: top
userPassword: {SSHA}+ed1wbhcWjxtv2zJ6OHEA2TuE9n1qIJGnuR94w==
description: The Administrator that can manage all the OUD instances.
cn: admin 

The Global Administrator created for the replication exists has the full set of admin privileges. In some situations, it might be useful to create additional administrators having only a subset of admin right. For instance, a Monitor Administrator would have the privilege to read the OUD configuration but he/she would not be able to modify it.

To do so, you can create your own admin container node in the cn=admin data suffix

./ldapmodify -a -p 4444 -Z -X -D "cn=directory manager"  -w ****
dn: cn= my admins,cn=admin data
objectclass: top
objectClass: ds-cfg-branch

dn: cn=monitor,cn=my admins,cn=admin data
objectClass: person
cn: monitor
sn: monitor 
userpassword: ****

At that stage, it is possible to use these credentials (cn=monitor,cn=my admins,cn=admin data) with dsconfig. dsconfig can authenticate that user, however the “admin” won’t be able to read the config as he/she does not have the privilege to do so. dsconfig reports the following error during navigation in the config:

The Administration Connector could not be modified because you do not 
have the correct authorization

Appropriate privileges must be assigned to the admin so that he/she has the right to perform the desired actions. In that example, the admin requires the config-read privilege. The bypass-acl is also required so that he/she can perform privileged actions on the configuration.

./ldapmodify -p 4444 -Z -X -D "cn=directory manager"  -w ****
dn: cn=monitor,cn=my admins,cn=admin data
changetype: modify
add: ds-privilege-name
ds-privilege-name: bypass-acl
ds-privilege-name: config-read

Now the admin can read the config via dsconfig. However, any attempt to modify it would raise the following error:

The Configuration could not be modified because you do not have 
the correct authorization 

Sudden SSLv3-related errors in OUD explained

Starting with the January 20, 2015 Critical Patch Update releases (JDK 8u31, JDK 7u75, JDK 6u91 and above) the Java Runtime Environment has SSLv3 disabled by default. More details about this change is available at http://www.oracle.com/technetwork/java/javase/documentation/cve-2014-3566-2342133.html

Any attempt to connect to OUD with SSLv3 after applying the Java update above will fail with the error message below in the access logs:

[09/Feb/2015:12:51:48 +0100] DISCONNECT conn=102 reason="I/O Error" msg="Client requested protocol SSLv3 not enabled or not supported"
[09/Feb/2015:12:51:48 +0100] CONNECT conn=102 from=****:14123 to=****:1636 protocol=LDAPS

For testing purpose only, a procedure to re-enable SSLv3 is described in http://www.oracle.com/technetwork/java/javase/documentation/cve-2014-3566-2342133.html howewer it is time to identify the LDAP client culprit and apply the appropriate security fix so that it uses TLS.

How to lock every account in a LDAP subtree with OUD

Let’s assume a customer would like to lock every LDAP account in a given LDAP subtree stored in Oracle Unified Directory.
An account can be locked by setting the ds-pwp-account-disabled operational to true in the accounts to lock. More about account lockout and password mpolicy is available at Managing password policies

It is possible to assign the ds-pwp-account-disabled attribute to a set of accounts using virtual attributes.Virtual attributes are attribues whose values do not exist in persistent storage but are dynamically generated in some way.

OUD Collective attribute is a mean to manage virtual attributes. More about collective attributes at using-collective-attributes

To lock every account in the oud=people,dc=example,dc=com subtree, create the following collective attribute:

dn: cn=myattr,dc=example,dc=com
objectclass: top
objectClass: subentry
objectClass: collectiveAttributeSubentry
objectClass: extensibleObject
ds-pwp-account-disabled;collective: true
subtreespecification: {base “ou=people”, minimum 1}
collectiveConflictBehavior: virtual-overrides-real

How to get OUD to start on Linux/UNIX boot

To simplify integration of OUD with the target OS, you can use the create-rc-script command  to generate a shell script to start, stop, and restart the directory server. You can update the resulting script to suit the needs of your directory service. This command is available for UNIX or Linux systems.

So you can use this command to create RC scripts e.g. run  sudo create-rc-script -f /etc/init.d/oud -u oud.

Then run this script when the appropriate run level change on the target distribution. For instance, on OEL, run sudo chkconfig –level 3 oud on

Make sure you use the -u userName option unless you really want to run OUD as root.

Reusing passwords encoded with custom hash in OUD

Existing user passwords can be easily migrated to OUD as long as they are hashed with an algorithm supported OOTB by Oracle Unified Directory. The list of password storage schemes supported by OUD is available athttp://docs.oracle.com/cd/E22289_01/html/821-1278/password-storage-scheme.html

In some situations, legacy passwords to be migrated are hashed with custom algorithms or old hash algorithms not supported by OUD.  The OUD Extensible Framework can be used to reuse these passwords and migrate them transparently to a new & configurable password storage scheme, without forcing users to change their password.

The proposed plugin intercepts bind requests and add pre&post processing to handle custom algorithm and migrate the password to a new scheme. Here is the high level algorithm:

§1. Plugin intercepts LDAP bind request as a pre-operation plugin

§2. Determine if the password stored in the user entry has a custom hash tag e.g{Custom}

§3a. If the entry has the custom hash, then hash the clear text password provided by the LDAP client using the custom password hash.

§3b. If the entry does not have the custom hash, the skip to step 6

§4. Compare the hashed value computed from the clear text password with the custom hash contained in the entry.

§5. If the hash compare matches, then replace the existing custom hashed password with the hash algorithm defined by the default password hash storage scheme.

§6. Then pass the bind through to OUD to bind.

§7. OUD will hash the clear text value using the default password hash storage scheme and compare with the value in the directory.

Step 6 always forwards the bind request to the OUD core server to make sure the password policy states are properly updates.

User passwords are migrated progressively over time to the new password storage scheme as users authenticate to the OUD directory. The plugin can them be desactivated when all the passwords have been migrated.

Configuring OUD to Support Multiple Enterprise User Security Domains

Configuring OUD to Support Multiple Enterprise User Security Domains

If your users and groups are stored in multiple domains, you must configure OUD to support multiple EUS domains. For example, a single OUD instance contains two EUS domains. One EUS domain stores users entries in Active Directory below cn=users,dc=ad1,dc=com. A second EUS domain stores user entries in a different Active Directory instance below cn=users,dc=ad2,dc=com. You must configure OUD to support each EUS domain.

To configure OUD to support multiple EUS domains:

  1. Configure OUD as if the primary domain is the single domain containing all your users and groups.

    In this example, the primary domain is dc=ad1,dc=com.

    Complete the tasks in 28.4 Oracle Unified Directory Used as a Proxy Server for an External LDAP Directory with Enterprise User Security

  2. Configure the secondary domain.

    In this example, the secondary domain is dc=ad2,dc=com.

    For this secondary domain, complete the steps in 28.4.1.1 User Identities in Microsoft Active Directory

  3. Create a new naming context for the EUS domain, which is dc=ad2,dc=com in this example.

    Complete the steps in 28.4.2.1.2 to configure Enterprise User Security for an existing Oracle Unified Directory Proxy Server instance.

  4. Update the Oracle context with the new naming context.
    1. Create an LDIF file.

      In the following myconfig.ldif example, make the following substitutions:

      • Replace dc=ad1,dc=com with the DN of your first domain.
      • Replace orclcommonusersearchbase with the users location in the secondary domain.
      • orclcommongroupsearchbase with the groups location in the secondary domain.
      dn: cn=Common,cn=Products,cn=OracleContext,dc=ad1,dc=com
      changetype: modify
      add: orclcommonusersearchbase
      orclcommonusersearchbase: cn=users,dc=ad2,dc=com
      orclcommongroupsearchbase: cn=groups,dc=ad2,dc=com
      
    2. Update OUD configuration using the LDIF file you created in step 4a.
      ldapmodify -h oudhost -p 1389 -D "cn=directory manager" 
      
      -w password -f myconfig.ldif