Cyril's Identity Management Blog

Did you know that OpenDJ, one of the major open source directory server, features a powerful logging interface ? For each need and use case, the OpenDJ logging system brings a solution to debug, finely tune and optimize or just filter out what you want or don't want to see in your logs.

For example, let's have a look at a few commands below...

Use this one to enable nanoseconds accuracy for LDAP operations execution time:

dsconfig -j mypasswordfile -Xn set-global-configuration-prop --set etime-resolution:nanoseconds

Use this one to enable the debug log with a somewhat talkative log level:

dsconfig -j mypasswordfile -Xn set-log-publisher-prop --publisher-name File-Based Debug Logger --set default-debug-level:verbose --set enabled:true

The last one below is a bit more complicated:

dsconfig -j mypasswordfile -Xn set-log-publisher-prop --publisher-name "File-Based Access Logger" --set connection-client-address-not-equal-to:10.0.0.1 --set log-record-type:extended --set response-etime-less-than:500 --set log-format:combined --set log-control-oids:true --set suppress-internal-operations:true --set buffer-size:512kb --set filtering-policy:exclusive --set queue-size:100000

It would have the following effects:

- it would exclude (from the access log) access requests issued by the 10.0.0.1 IP address, which can be very useful for example to prevent load balancers health-check requests from being logged, making the access log grow large unusefully if not excluded.
- it would also exclude LDAP extended operations like the replication trafic for example
- it would also exclude requests that took less than half a millisecond (500 ns) to be served. In such a case, it's recommended to log both requests and results on the same line, for the same operation. That's exactly what the "log-format:combined" parameter does.
- it would log LDAP controls OIDs, as well as the server internal LDAP operations like the ones executed by some enabled plugins
- finally, to limit disks I/O and improve the overall throughput, it would increase the default asynchronous access logger queue size as well as the log buffer size.

It's been a while since my previous post, so let's push 2 articles today. OpenDJ brings some nice features in comparison with Sun DSEE, but may also give you some headaches if you don't closely read the documentation (I did !).

Among the good things, it's possible to have a very fine grained directory administration with OpenDJ, thanks to privileges. Privileges define administrative rights one must gain in order to perform some specific operations. It can be administrative operations, but also operations on data. For example, in order to be able to modify the access control rules (stored as aci attributes in the LDAP entries), defining the right acis is not enough, one needs the modify-acl privilege. Among other privileges, any user can be assigned the right to bypass the whole acis, thanks to the bypass-acl privilege, or to execute unindexed searches, which is forbidden by default.

Among some other features that require special care, OpenDJ now distinguishes between user and operational attributes in acis, in such a way that when specifying "all" in an aci, it means all user attributes, implicitly excluding the operational attributes. To target them in acis, they now have to be explicitly mentioned. Or you can alternatively use the special keyword "+" to target all operational attributes.So, beware !

If you plan to migrate from Sun Directory Server (Sun DS v5 to Sun DSEE v7, including ODSEE 11gR1) to OpenLDAP 2.4 or later, here're a few non exhaustive tips to keep in mind:

- Sun directory server versions up to 6.x don't enforce any attribute value checking, as opposed to OpenLDAP. So, expect some work on your data before being able to import them in OpenLDAP. Typically, if you had mail attribute values containing forbidden characters (like "ç" for example) in Sun DS, you'll have to modify your Sun DS LDIF export file and replace "ç" by "c" in each mail attribute value, before being able to import it in OpenLDAP. In the same manner, if you have illegal DN values for attributes like "manager" or "uniquemember", OpenLDAP will refuse them and they must be fixed before you try to import your data in OpenLDAP.

- Sun legacy attributes such like nsaccountlock don't exist in a standard OpenLDAP schema. When nsaccountlock is FALSE, it just means the account is not locked out, so you can just safely remove such attributes in the corresponding LDIF entries of the OpenLDAP database. On the contrary, Sun directory server locked accounts have a value of TRUE for the nsaccountlock attribute. In such a case, if you want to keep the account locked in OpenLDAP, this should be replace by: "pwdAccountLockedTime;pwd-userpassword: 000001010000Z"

And of course, you first need to include the password policy overlay and schema in OpenLDAP to be able to use that kind of feature.

- Empty valued attributes are forbidden in OpenLDAP, and thus, the corresponding attributes must be removed before being imported in OpenLDAP.

- "passwordexpirationtime: 19700101000000Z" should be replaced by "pwdChangedTime: 19700101000000Z"

- If passwordexpirationtime is different from 19700101000000Z, the corresponding value for pwdChangedTime must be set accordingly with your password policy. Those attribute names are self explanatory to understand how the value must be computed for each LDIF entry.

- The real nightmare comes with ACI's since there's no standard implementation of LDAP access rights. Each directory vendor uses its own syntax, its own implementation, and its own evaluation algorithm. So, there may be different ways to translate the access rights for a a Sun directory server to OpenLDAP. One could simply try to reproduce the same rules, which limits the risks but may not be optimized, since OpenLDAP works differently. Another way would be to rethink the access rights globally, understand what was done and how OpenLDAP works to achieve the same result, in a possibly more efficient way. At least, I would recommand to use (and include in the main OpenLDAP config file) several files to clarify the access rights, and ease their management. Also, I would think of using the OpenLDAP "break" directive, which can help to mimic the Sun DS ACI's evaluation process.

Former Sun Identity Synchronization for Windows (IDSync) can help you to migrate your users' password from Sun DS 5.2 to Windows AD, and also has some nice features. It's also a simple solution to a common problem, in comparison with IDM software (from any vendors) which will also do the job but that you probably don't want to deploy just for AD to/from Sun DS synchronization, since ROI would be discouraging.

So, basically, if you don't want to upgrade or migrate your Sun DS 5.2 directory, you can safely use choose IDSync, it will often be one of the cheapest Sun DS 5.2 to/from AD password synchronization solution (including services and licence costs), and also probably one of the best ROI, but beware of:

- the vendor proposed support, if any (probably quite expensive now that Sun belongs to Oracle)

- high availability: IDSync is designed for high availability, in some use cases at least, so carefully check your requirements and what ID Sync can or can not do from that perspective.

IDSync is also bundled with Sun DS since v 6 (=Sun DSEE 6) and still exists in DSEE v7.0. As far as I know, Oracle Directory Server Enterprise Edition 11 g Release 1 (11.1.1), which corresponds to DSEE 7.0 update 1 is still bundled with that synchronization solution.

Please note that ODSEE 11gR1 is different from Oracle's virtual directory which probably also contains a synchronization solution from/to AD, but it's of course designed to synchronize with Oracle's directory solution.

To answer the primary question of initial password synchronization from Sun DS 5.2 to AD without password reset, IDSync won't do the job, without resetting those passwords, or without forcing users to change it. Basically, with IDSync, your passwords can be synchronized on the fly once they've been synchronized once, but IDSync won't help you for that first time. As described above, you need to capture your users' passwords (so you need them to type it in a Web interface for example) and then you can push them to AD through LDAPS. For example, if you've got a webmail interface that authenticate your users to Sun DS, you can possibly hack the webmail system to do the job. Careful planning must also be decided, between the initial password synchronization and the real time synchronization solution taking then place.

Oracle recently published the first release of ODSEE, Oracle Directory Server Enterprise Edition 11g Release 1 (11.1.1), formerly known as Sun Directory Server Enterprise Edition 7.0 (DSEE 7). ODSEE 11.1.1 simply corresponds to the first patch for DSEE 7, so one can see it as DSEE 7.0P1 or DSEE 7.1, as you want !
This is only a "bug fix" release, there's no new feature.

Read the complete release notes here.

Likewise solves the user management nightmare in heterogeneous environment mixing Unix, Linux and Windows desktops or servers, making it possible for administrators to manage their internal users from a single point: the corporate Active Directory environment. Recently, the open source version, "Likewise Open 6" was released, as well as its "legacy" counterpart: Likewise Enterprise.
So, I thought it was an opportunity for another article in this blog, since I think it's a nice software. The former open source version may fit for most customers just interested in a simple solution to a simple problem. For those requiring rich features like advanced reporting or group policy management, the latter solution may be a better choice.
Shed a light on the latest improvments.

One of my team mate delivered our first OpenDS training last week.
Just contact us if you're interested in it.

Here's the agenda:

Day 1
LDAP protocol overview
Introduction to OpenDS
OpenDS Prerequisites
Installing OpenDS
Starting with a fresh directory

Day 2
OpenDS Concepts
OpenDS Tools
OpenDS monitoring
OpenDS backup
Java considerations
H/A considerations

Day 3
OpenDS vs. DSEE
OpenDS fine tuning
Replication concepts
Data import and exchange
OpenDS security aspects
OpenDS performance testing by slamd (short overview, transfer of knowledge )

Day 4
OpenDS's Virtual Attributes
Using Virtual Attributes
Replacing COSes with Virtual Attributes
OpenDS plugins / extended features
Build instructions from OpenDS source code
Practical Exercises

The Kantara initiative workgroup recently unveiled his plans and threw the bases for a more secure and wider adoption of federation technologies: Check this !

Back from a beautiful scenery, it looks like things are moving and happening at Forgerock's: former Sun execs join and intend to keep the IDM/IAM suite alive, and open source !