OUD&EUS Take 1: DB Accounts Stored in OUD

By Sylvain Duloutre on Jul 09, 2013

This post is the first one of a serie focusing on Enterprise User Security (EUS) and Oracle Unified DIrectory (OUD).

Enterprise User Security (EUS), an Oracle Database Enterprise Edition feature, leverages the Oracle Directory Services and gives you the ability to centrally manage database users and role memberships in an LDAP directory. EUS reduces administration costs and increases security

Storing DB Accounts in OUD

OUD is specifically tailored to work seamlessly with EUS. Database user information, passwords and privileges information for a database or for a database domain can be stored in OUD.

EUS can leverage existing user and group information stored in OUD to provide single password authentication and consistent password policy across enterprise applications. User data, database meta-data, such as DB registration information, user/role Mappings, and other EUS specific meta-data are stored in OUD using a specific, supported, read-to-use LDAP schema. These meta-data are stored in a separate OUD suffix, called Oracle Context, making a clean logical separation between EUS data and user information that can be shared across applications.

In addition to providing centralized database user management, Enterprise EUS provides three different methods of user authentication: X.509 certificate authentication (introduced in DB 8i); Password-based authentication (since DB 9i); and authentication via Kerberos (since DB 10g). OUD support for Password-based authentication for EUS was introduced in OUD 11gR2. The other authentication methods were introduced in OUD 11gR2PS1.

In the password authentication scenario, the database does not perform user authentication via LDAP bind to OUD. Instead the database collects user credentials, hashes the password, and compares the password hash value retrieved from OUD. More detailed information about EUS can be found in the Enterprise User Administrator’s Guide in the Database documentation section on OTN.

eus_general[1]

Migration Stategy to Oracle Unified Directory

Developing a good strategy is a key element of a migration from third-party directories to OUD.
For sake of simplification, migration can be broken down in 5 steps as described below:

User Data Migration

Most companies defined some custom LDAP attributes and object classes. They use them  in conjunction with standard LDAP schema. LDAP provides a standard way to define schema extensions, so migration of user data is in general quite straight-forward:  Custom schema extensions need to be added to the OUD configuration, user data are exported from the existing directory to the standard LDIF format then re-imported into OUD.

By default, OUD schema checking is strict, some user entries may be rejected when they do not strictly adhere with the LDAP schema. In such case, either fix the data, fix the schema or relax the corresponding schema option in OUD configuration.

Migration of passwords may cause problems if they are encrypted with non-standard algorithms. I plan to cover that in a separate post soon.

Directory Metadata Migration

Most directories, including OUD, store meta data along with the User Data. This may  include access control information (aci), collective attributes, ldap sub entries etc. Each directory vendor uses its own model, so this aspect of the migration requires attention  and must be carefully planned.

Directory Configuration Migration

Each directory has its own configuration model, so the configuration must be ported to OUD. It includes the LDAP ports the directory listen on, the LDAP naming contexts exposed, database indexes, replication settings, security settings, performance setting, etc. This can be done using OUD graphical interface (ODSM) or using command line dsconfig. This is in general quite simple to migrate the directory configuration to OUD. Special care is needed to manage migration of SSL server certificates if certificate renewal is not an option.

Dealing with hard-wired dependencies in client applications

Some LDAP client application have hard-wired dependencies on a directory vendor and/or version. For instance, an application would query the directory service version string and would take some decision based on that. Some applications may also create/update directory-specific metadata. It is quite difficult to identify such issues upfront, but it is usually good policy to classify client applications based on their LDAP traffic patterns: traffic of provisioning applications should be review first, as the probabilities to have dependencies on vendor-specific interface is higher than for application doing simple authentication.

Oracle Virtual Directory (OVD), part of the  Oracle Directory Services Plus can be used to emulate directory-specific features.

Switching from existing directory to OUD

From an operational perspective, it is key to define how the actual switch to OUD will occur: Some customers would favor export and import w/o maintaining the 2 environments in sync. This seems very simple, but this methodology cannot ensure an highly-available deployment with up-to-date entries on both sides. When this is not acceptable, synchronization tools like DIP (Directory Integration Platform) which is a part of Oracle Directory Services Plus can be used to synchronize user data.

Additional options exist to migrate from Oracle Directory Enterprise Edition (DSEE) to OUD as described here.

Enabling support of EUS and Fusion Apps in OUD

Since the 11gR2 release, OUD supports Enterprise User Security (EUS) for database authentication and also Fusion Apps. I’ll plan to blog on that soon. Meanwhile, the R2 OUD graphical setup does not let you configure both EUS and FusionApps support at the same time.

INBOX)67103[1]

However, it can be done manually using the dsconfig command line. The simplest way to proceed is to select EUS from the setup tool, then manually add support for Fusion Apps using dsconfig using the commands below:

– create a FA workflow element with eusWfe as next element:
dsconfig create-workflow-element \
–set enabled:true \
–set next-workflow-element:Eus0 \
–type fa \
–element-name faWfe

– modify the workflow so that it starts from your FA workflow element instead of Eus:
dsconfig set-workflow-prop \
–workflow-name userRoot0 \
–set workflow-element:faWfe

Note: the configuration changes may slightly differ in case multiple databases/suffixes are configured on OUD.

Using execution context ID (ECID)

Execution context ID (ECID) is a unique identifier to correlate events or requests associated with the same transation across several components.

The ECID value for a particular request is generated at the first layer and is passed down to the subsequent layers. The ECID value is logged (and auditable) in each product involved in the transaction. ECID allows an administrator to track the end-to-end flow of a particular request across the product stack.

ECID are supported by OUD and can be used to track LDAP requests from the client down to the ultimate LDAP server processing the request (inclusing LDAP access layer/proxy if any).

When performing a LDAP operation, a client can pass a ECID using the LDAP control extension 2.16.840.1.113894.1.8.31 . This ECID is logged by OUD. The OUD server generates a ECID in case none is present in the incoming request.

ECID are logged in the “Oracle Access Logger”. By default, this logger is disabled. To enable it, run the command below:

dsconfig set-log-publisher-prop \
         –publisher-name Oracle\ Access\ Logger \
         –set enabled:true\
–hostname localhost\
–port <admin port>\
–bindDN cn=Directory\ Manager \
–bindPassword ****** \
–no-prompt

Here is a sniplet of the Oracle access log:

[2012-08-16T16:10:26.770+02:00] [OUD] [TRACE] [OUD-24641559] [PROTOCOL] [host: prehnite] [nwaddr: 10.166.70.62] [tid: 25] [userId: sduloutr] [ecid: 10.166.70.62:37126:1345126226770:39,0] [category: REQ] [conn: -1] [op: 80] [msgID: 81] [dn: o=example] [type: synchronization] MODIFY

The administrator can then search the logs using a particular ECID value. Audit logs can be queried for a given ECID through Oracle BI Publisher’s audit reports. For example, if you send an LDAP request to Oracle Virtual Directory front-ending Oracle Unified Directory, an ECID associated with the LDAP request is present in the OVD diagnostic logs and audit logs; similarly, when the query reaches OUD, OUD includes the same ECID in its diagnostic logs and audit reports.

Monitoring OUD with VisualVM

VisualVM is a visual tool integrating several command line JDK tools and lightweight profiling capabilities. Designed for both production and development time use, it further enhances the capability of monitoring and performance analysis for the Java SE platform.

Here are the steps to use VisualVM to monitor Oracle Unified Directory:

#1 Download the latest release of VisualVM from http://visualvm.java.net/

#2 Enable the MBeans plugin as described in  http://visualvm.java.net/mbeans_tab.html to take advantage of the statistics exposed by OUD

#3 Enable JMX on OUD

  1. Start the server.
  2. Enable the JMX Connection Handler and set the port number to be used with JMX.

    Choose a port that is not in use and to which the user that is running the server has access rights.

    $ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
      set-connection-handler-prop --handler-name "JMX Connection Handler" \
      --set enabled:true --set listen-port:1689
    
  3. Add the JMX read, write, and notify privileges to the root DN.
    $ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
      set-root-dn-prop \
      --add default-root-privilege-name:jmx-read \
      --add default-root-privilege-name:jmx-write \
      --add default-root-privilege-name:jmx-notify
    
  4. Restart the server.

#4 Connect to OUD from VisualVM

To connect VisualVMto a server instance, click on File/Add JMX Connection. The following fields are required:

  • JMX URL:

    service:jmx:rmi:///jndi/rmi://''host'':''port''/org.opends.server.protocols.jmx.client-unknown

    • host is a host name, an IPv4 numeric host address, or an IPv6 numeric address enclosed in square brackets.
    • port is the decimal port number of the JMX connector.

    The default JMX URL is:

    service:jmx:rmi:///jndi/rmi://198.51.100.0:1689/org.opends.server.protocols.jmx.client-unknown

  • User Name. A valid LDAP user name.

    The default Directory Manager user name is cn=Directory Manager.

  • Password. The user’s LDAP password.

#5 Browse MBeans attributes

Go to the right panel then select the MBean tab and navigate in the MBean tree. You can get access to the OUD config, monitoring information & statistics and all the convenient java metrics.
Note: You can plot those JMX numeric values in VisualVM that appear in bold. To do so, double-clicking on numeric attribute values will display a chart that plots changes in that numeric value.

New convenient Information Center about OUD in My Oracle Support

A new “Information Center” dedicated to Oracle Unified Directory is available from the Oracle Support Site. This page provides you with all the useful links and news related to the product, including technical articles, docs, licensing info and the latest patches available.

To access it, log into MOS (My Oracle Support) at http://support.oracle.com,  search for 1418884.2 doc id in the search field on the front page, then click on the “Information Center : Overview Oracle Unified Directory (OUD)” link.

Cohabitation/Migration ODSEE->OUD: privileges

OUD provides a privilege subsystem, which can be used to define capabilities that will be granted to users. The privilege subsystem works in conjunction with the access control implementation in the process of determining whether a user will be allowed to perform a certain operation.

In general, default OUD access control settings are stricter than ODSEE. Appropriate privileges must be added to achieve behavior that is equivalent to that of ODSEE. For instance, by default, OUD ACIs don’t allow users to reset another users’s password. Alternatively, it is possible to disable the privilege subsystem.

By default, normal users are not granted any of the privileges listed above. Therefore, if a user should be allowed to perform any of the associated operations, they must be granted the appropriate privileges. This can be done by adding the ds-privilege-name operational attribute to the user’s entry. ds-privilege-name is a multivalued attribute, and if a user is to be given multiple privileges, then a separate value should be used for each one. When the virtual attribute subsystem is in place, it should also be possible to grant privileges to groups of users automatically by making ds-privilege-name a virtual attribute in those user entries.

As an example, the following modification can be used to add the proxied-auth privilege to the usercn=Proxy User,dc=example,dc=com:

dn: cn=Proxy User,dc=example,dc=com
changetype: modify
add: ds-privilege-name
ds-privilege-name: proxied-auth

Granting privileges explictely to users may not be the optimal solution when OUD and ODSEE cohabit in a replication topology as the OUD-specific ds-privilege-name would be replicated by to ODSEE, so privileges can also be assign implicitely to a set of user based on group membership for example, using the notion of virtual attribute. I’ll cover Virtual attribute in a subsequent post.

Alternatively, It is possible to disable those privileges leading to aci behavioral differences between OUD and ODSEE. For instance, the  unindexed-search privilege can be disabled  so that users can perform un-indexed searches. A privilege (unindex search checking in the example below) can be disabled using the following command:

dsconfig set-global-configuration-prop  –add \
disabled-privilege: unindexed-search -n

The list of OUD privileges is available here.

Cohabitation/Migration ODSEE->OUD: dn-based search resource limits

Oracle Unified Directory 11g Release 1 (11.1.1) provides a mechanism to replicate data between Oracle Directory Server Enterprise Edition and Oracle Unified Directory. Depending on the ODSEE features used, the OUD configuration may need to be adapted to provide the same service transparently to client application.

Both ODSEE and OUD provide ways to control ressources used by a directory user. The following limits are provided by OUD at the global configuration level:

  • ds-cfg-size-limit specifies the maximum number of entries that can be returned to the client during a single search operation.
  • ds-cfg-time-limit specifies the maximum length of time that should be spent processing a single search operation
  • ds-cfg-lookthrough-limit specifies the maximum number of entries that the Directory Server should “look through” in the course of processing a search request. This includes any entry that the server must examine in the course of processing the request, regardless of whether it actually matches the search criteria.
  • ds-cfg-idle-time-limit specifies the maximum length of time that a client connection may remain established since its last completed operation

The corresponding configuration attributes in ODSEE are search-size-limit, search-time-limit, look-through-limit, idle-timeout.  Such configuration mapping is automatically provided by tools like ds2oud.

Server limits for search operations can also be controlled using special operational attribute values assoaicted with the user binding to the directory. These attributes are stored as part of the directory data, so they are replicated between ODSEE and OUD.  Attribute names (and sometimes values) vary so the OUD configuration need to be extended to deal with that:

DSEE entries may contain the following resource limit attributes: nsSizeLimit, nsTimeLimit, nsLookThroughLimit, nsIdleTimeout. Corresponding attributes on OUD are ds-rlim-size-limit, ds-rlim-time-limit, ds-rlim-lookthrough-limit,ds-rlim-idle-time-limit.In order to replicate the functionality correctly, the OUD schema (02-config.ldif) must be modified so that each DSEE attribute name related to resource limits is declared as an alias name for each corresponding OUD attribute. An alias can be declared in an attributeType declaration as below:

attributeTypes: ( 1.3.6.1.4.1.26027.1.1.244 NAME ( ‘ds-pwp-password-policy-dn’ ‘alias-for-ds-pwp-password-policy-dn’)

On DSEE, -1 is used to disable a resource limit. On OUD, 0 is used. One way to address this difference is to create a virtual attribute on OUD to override the content of the OUD attribute when the value of the DSEE attribute is equals to -1. A virtual attribute must be created for the 4 attributes mentioned, as described below:

dsconfig create-virtual-attribute –name “mapping nsSizeLimit ”
–type user-defined –set attribute-type:ds-rlim-size-limit \
–set filter:”(nsSizeLimit=-1)” \
–set conflict-behavior:virtual-overrides-real \
–set value:”0″–set enabled:true

dsconfig create-virtual-attribute –name “mapping nsTimeLimit ” –type user-defined –set attribute-type:ds-rlim-time-limit \
–set filter:”(nsTimeLimit=-1)”\
–set conflict-behavior:virtual-overrides-real \
–set value:”0″ –set enabled:true

dsconfig create-virtual-attribute –name “mapping nsLookthroughLimit” \
–type user-defined –set attribute-type:ds-rlim-lookthrough-limit \
–set filter:”(nsLookthroughLimit=-1)” \
–set conflict-behavior:virtual-overrides-real –set value:”0″ –set enabled:true

dsconfig create-virtual-attribute –name “mapping nsIdleTimeout ” \
–type user-defined –set attribute-type:ds-rlim-idle-time-limit \
–set filter:”(nsIdleTimeout=-1)”\
–set conflict-behavior:virtual-overrides-real \
–set value:”0″ –set enabled:true

More information about account-based resource limits is available here.