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.

Advertisements

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.

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.

Cohabitation/Migration ODSEE->OUD: schema checking

By default, OUD schema scheck is stricter than ODSEE.  Schema checking is key for data sanity, however this might cause some trouble when “incorrect” data have to be imported into OUD or when incorrect data are replicated from ODSEE.

Generally speaking, it is not recommanded to disable schema checking and the data should be fixed whenever possible before import and on the ODSEE side when ODSEE and OU cohabit in the same replication topology. In some cases, this is not possible, so some specific checks can be disabled to accomodate with common inconsistency:

Structural object class unicity

Per LDAP standard, every LDAP entry must contain exactly one structural object class.  In many deployments, some LDAP entries contain 0 or more than 1 objectclass and several LDAP server implementations do not enforce this. By default OUD does. Such check can be relaxed w/o know adverse effect by using the command below:

dsconfig set-global-configuration-prop --set \
single-structural-objectclass-behavior:accept -n

Attribute type names containing invalid characters

A few customers defined their own attribute types, using forbidden characters, e.g undercores, or leading digit in attribute names and/or in attribute type extensions (e.g 4you;x_bad_extension). Such check can be relaxed using the command below:

dsconfig set-global-configuration-prop --set \
allow-attribute-name-exceptions:true -n

 Zero-length attribute value

Zero-length attribute values (that is, an empty string) is technically not allowed by the revised LDAPv3 specification, but some environments may require it for backward compatibility with servers that do allow it. Empty string can be explicitely allowed on a per LDAP syntax basis, using the example below for DirectoryString syntax:

dsconfig set-attribute-syntax-prop --syntax-name Directory\ String \
--set allow-zero-length-values:true -n

Oracle Unified Directory Root DSE entry and schema

The root DSE entry (empty dn) is often used by LDAP client applications to discover directory services capabilities.  For instance, attribute namingContexts gives indications about the suffixes managed by the directoy server instance. All these attributes are flagged as OPERATIONAL, so, they should not be returned to client applications unless they are explicitely specified in the search attribute list.

OUD strictly adheres to LDAP standards so these attributes are not returned by default. In Oracle Directory Server Entreprise Edition (ODSEE), these attributes are treated as standard ones and are systematically returned to client applications. Applications depending on the ODSEE behaviour might be impacted as many of them do no specify any search attribute list. To make OUD behave like ODSEE with regards to the access of rootDSEE attributes, run the following command:

dsconfig set-root-dse-backend-prop –set show-all-attributes:true

To make OUD treat schema operational attribute like user attributes, run the following too:

dsconfig set-workflow-element-prop –element-name schema –set show-all-attributes:true

Optimized Solution for Oracle Unified Directory

Oracle Optimized Solution for Oracle Unified Directory is a complete solution – Software and Hardware engineered to work together.

It implements Oracle Unified Directory software on Oracle’s SPARC T4 servers to provide highly available and extremely high performance directory services for the entire enterprise infrastructure and applications. The solution is architected, optimized, and tested to deliver simplicity, performance, security, and savings in enterprise environments.

More details available at http://www.oracle.com/us/solutions/1571310

Installing Oracle Unified Directory in silent mode

By default, the OUD installer runs in GUI mode. Alternatively, it is possible to install and setup OUD in silent mode.

First, download the OUD bits, then run the installer in silent mode. Last but not least setup/configure OUD in silent mode as well.

To run the installer in silent mode, either run it in GUI mode on your laptop or any system with a GUI and record your answers so that you can replya them on another system in silent mode. Alternatively, you can build a response file manually for OUD.

To record your answers, run the installer with the option -record, e.g

./runInstaller -record -destinationFile /tmp/OUD.rsp

To the installer with an existing response file (silent mode)

./runInstaller -silent -responseFile /tmp/OUD.rsp

A response file template is available at the end of this post. You need to change values for ORACLE_HOME and MIDDLEWARE_HOME.

After this install, you can setup oud in cli mode (oud-setup), either interactive or in batch.

oud-setup –cli –no-prompt -D “cn=directory manager” -j $PASS_FILE -p $PORT1 –adminConnectorPort $APORT1 –noPropertiesFile
More info available at http://docs.oracle.com/cd/E22289_01/html/821-1274/ds-cli-setup.html#scrolltoc

Oracle Unified Directory 11G announced.

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

The product can be downloaded from http://www.oracle.com/technetwork/middleware/downloads/oid-11g-161194.html

The OUD documentation is live on OTN, at this URL. http://download.oracle.com/docs/cd/E22289_01

For more info, have a look at the official press release.