Generational Garbage Collection with IBM JVM for Oracle Unified Directory

A main difference between IBM J9 JVM and Oracle JVM is that IBM’s JVM has different heap structure than Oracle’s JVM. By default IBM JVM (java 6) does not use Generational Garbage Collector. Such setting has adverse effects on OUD as OUD allocates a huge numbers of transient objects. Using the default IBM JVM settings lead to full garbage collections that freezes the directory services.

jvm2

I recommend to use generational heap structure systematically with OUD. This can be enabled by the JVM option
Xgcpolicy:gencon

OUD provides a means of configuring the Java Virtual Machine (JVM) and Java options for each command-line utility and for the directory server itself. The Java configuration is provided in a properties file, located at instance-dir/OUD/config/java.properties. The configuration specified in this file is taken into account each time the dsjavaproperties command is run. If you do not run the dsjavaproperties command, the properties file is ignored. More about JVM param settings at http://docs.oracle.com/cd/E29407_01/install.111200/e23737/configuring_jvm.htm

To use the gencon garbage collector policy for a specific OUD instance, do the following:

Edit the java.properties file located at instance-dir/OUD/config/java.properties
Add -Xgcpolicy:gencon at the end of the line starting with start-ds
Run instance-dir/OUD/bin/dsjavaproperties
Restart the OUD instance

Migration from OID to OUD: Adapting EUS metadata

Enterprise User Security is an important component of Oracle Database Enterprise Edition. It enables you to address administrative and security challenges for a large number of enterprise database users by centralizing users and roles in a LDAP directory.

It is possible to use either Oracle Internet Directory (OID) or Oracle Unified Directory (OUD) as LDAP repository for EUS.

To migrate from OID to OUD,
– enable EUS support in OUD
– copy your user and groups in <your_context)
– copy across EUS metadata (in cn=oracleContext,<your suffix)

EUS metadata as stored in OID must be slighly adapted before being impoorted to OUD otherwise the DB won’t be able to authenticate against OUD and will raise the following error:

ORA-28043: invalid bind credentials for DB-OID connection

Migrating the DB entry from OID to OUD requires some specific steps for SASL/DIGEST-MD5 authentication. In OID, the password hash used for SASL/DIGEST-MD5 authentication is stored in authpassword;oid, with the {SASL/MD5} prefix.
In OUD, this must be stored in orclcommonrpwdattribute with the {SASL-MD5} prefix.

For instance:

In OID:
ldapsearch [conn details] -b cn=oraclecontext,dc=example,dc=com -s one “(cn=orcl11g)” authpassword
dn: cn=orcl11g,cn=oraclecontext,dc=example,dc=com
authpassword;oid: {SASL/MD5}ola+G+GFsSeiu6QcRiAh9g==
authpassword;oid: {SASL/MD5-DN}3UeqmU5Axd+XVAM9Lxf28g==
authpassword;oid: {SASL/MD5-U}BD6uyBcSiFbGtlPzq6TtUA==

In OUD:
ldapsearch [conn details] -b cn=oraclecontext,dc=example,dc=com -s one “(objectclass=orcldbserver)” orclcommonrpwdattribute
dn: cn=orcl11g,cn=OracleContext,dc=example,dc=com
orclcommonrpwdattribute: {SASL-MD5}ola+G+GFsSeiu6QcRiAh9g==

Integrating OUD in Monitoring Frameworks: Service Users

Oracle Unified Directory is an all-in-one directory solution with storage, proxy, synchronization and virtualization capabilities.

It can be monitored and integrated in various Monitoring Solutions including Oracle Enterprise Manager, via a dedicated plugin that provides performance monitoring of hundreds of directory metrics, raise alerts based on thresholds and provides rich out-of-the-box reports. By default, monitoring data are retrieved from OUD over LDAPS from the OUD administration port.

In order to use this method, it is recommended to define a dedicated directory user with read privilege on monitoring statistics and configuration. Such user can either be a so-called Root User or a Global Admin User. Root Users are local to a OUD instance and have some special privileges. Global Admin Users are quite similar to Root Users except that they are replicated across OUD servers, so this is more convenient if you want to monitor several OUD instances.

The following rights and privileges are required to access monitoring data and config:  Read access on cn=config and cn=monitor naming contexts and config-read privilege.

Root Users automatically inherit a bunch of default privileges, much more than what is strictly needed to monitor OUD, so unnecessary privileges must be removed and read access must be granted. To create a Root User called “cn=monitor” with sufficient privileges , do the following

./ldapmodify  -h <hostname> -p <adminport> \
-D "cn=Directory Manager" -w <password> -X --useSSL  <<EOF
dn : cn=monitor,cn=Root DNs,cn=config
changetype: add
objectclass: inetOrgPerson
objectclass: person
objectclass: ds-cfg-root-dn-user
objectclass: top
userPassword: <password>
ds-cfg-alternate-bind-dn: cn=monitor
cn: monitor
sn: monitor
EOF

Let’s remove unnecessary privileges (basically all but config-read)

./ldapmodify  -h <hostname> -p <adminport> \
-D "cn=Directory Manager" -w <password> -X --useSSL <<EOF
dn : cn=monitor,cn=Root DNs,cn=config
changetype: modify
add: ds-privilege-name
ds-privilege-name: -config-write
ds-privilege-name: -modify-acl
ds-privilege-name: -ldif-import
ds-privilege-name: -ldif-export
ds-privilege-name: -backend-backup
ds-privilege-name: -backend-restore
ds-privilege-name: -server-shutdown
ds-privilege-name: -server-restart
ds-privilege-name: -disconnect-client
ds-privilege-name: -cancel-request
ds-privilege-name: -unindexed-search
ds-privilege-name: -password-reset
ds-privilege-name: -update-schema
ds-privilege-name: -privilege-change
ds-privilege-name: -bypass-acl
EOF

If you prefer to use Global Admin Users, do the following:

./ldapmodify  -h <hostname> -p <adminport> \ 
-D "cn=Directory Manager" -w <password> -X --useSSL <<EOF
dn : cn=monitor,cn=Administrators,cn=admin data
changetype: add
objectclass: person
objectclass: top
userPassword: <password>
cn: monitor
sn: monitor
EOF

Let’s add config-read privilege:

./ldapmodify  -h <hostname> -p <adminport> -D "cn=Directory Manager" -w <password> -X -Z <<EOF
dn : cn=monitor,cn=Administrators,cn=admin data
changetype: modify
add: ds-privilege-name
ds-privilege-name: config-read
EOF

No matter what User type you choose to use, you need to grant read access to the config and the monitoring information using OUD global acis:
For Root Users, add the following acis using dsconfig: Start dsconfig, select Authentication and Authorization, then Access Control Handler and add the 2 following global acis:

(target="ldap:///cn=config")(targetattr="*")(version 3.0; acl "Monitor config access"; allow (read,search) \
  userdn="ldap:///cn=monitor,cn=Root DNs,cn=config";)
(target="ldap:///cn=monitor")(targetattr="*")(version 3.0; acl "Monitor access"; allow (read,search) \
  userdn="ldap:///cn=monitor,cn=Root DNs,cn=config";)

For Global Admin Users, here are the corresponding acis:

(target="ldap:///cn=config")(targetattr="*")(version 3.0; acl "Monitor config access"; allow (read,search) \
  userdn="ldap:///cn=monitor,cn=administrators,cn=admin data";) 
(target="ldap:///cn=monitor")(targetattr="*")(version 3.0; acl "Monitor access"; allow (read,search) \
  userdn="ldap:///cn=monitor,cn=administrators,cn=admin data";)

At that stage, config and monitoring stats are available from the OUD admin port to the cn=monitor user (if you choose to use Root Users) or to cn=monitor,cn=administrators,cn=admin data (for Global Admins).:

OUD Directory Server vs Replication Server: Who Cares ?

Oracle Unified Directory replication model relies on 2 logical components, Directory Servers and Replication Servers. Directory Servers contain user data, pushes changes to replication changed and get updates from replication servers. Replication Server stores replication changes, they receive changes to directory servers and forward them to the rest of the topology.

By default, you don’t need to care about Replication Servers. Replication Servers and internal components managed automatically: a Replication Server is autimatically configured in each OUD DIrectory Server process when replication is configured.

OUD Replication Server and Directory Servers are NOT equivalent to DSEE Suppliers and Consumers. By default, every replicated OUD is a Read-Write Supplier/Master.

When do you need to know about replication servers? – Primarily, when full network connectivity cannot be guarantied across every instance as every Replication Server must be able to communicate to each other. – Optionally, Replication Servers and DIrectory Servers can be separated to optimize resource usage in large OUD topologies (10’s of instances) – To enable external changelog service on a standalone OUD instance (for instance in a test environment) as a Replication Server is required is such case.

Example:

aa[1]

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