ForgeRock Community Blog Syndicate

I will be at the LavaJUG (Java User Group from Clermont-Ferrand, France) this Thursday from 19:00 to 21:00, presenting our experience with the OpenDJ project with building a highly scalable and high performance server in Java. The presentation is based on what I’ve already presented in a few JUG in France (AlpesJUG, MarsJUG, PoitouCharentesJUG,…) and Switzerland (JUG Lausanne), but has been updated with regards to GarbageFirst GC and the most recent HotSpot JVM.

And next week, from  March Wednesday 27th to Friday 29th, you will find ForgeRock at the Devoxx France conference.

Come to our conference session about “Enterprise Security in a Cloudy and Mobile World” (the session is in French). The session is on Friday 29th, from 11:45 to 12:35, in Miles Davis room. Mark it on your calendar, and if you miss it, make sure you stop by our booth (B3) to say hello and talk with some of our engineers. We will also be present at the HackerGarten on Wednesday from 14:00 to 18:00, should you want to have fun with one of our open source projects : OpenAM, OpenDJ or OpenIDM.

I’m happy to announce that a new revision of OpenDJ, the open source LDAP directory server in Java has just been released. OpenDJ 2.5.0-Xpress1 is a new stable release of the main development branch of the OpenDJ project.

OpenDJ 2.5.0-Xpress1 brings you the latest features such as:

• Capability to delegate authentication to Microsoft Active Directory (pass-through authentication)
• Improved enforcement of referential integrity for groups, whereby OpenDJ can now ensure both that members’ entries exist when they are added to groups, and also that members are removed from groups when their entries are deleted
• Access log filtering, with additional output configuration to combine request and response messages, log control OIDs, and specify timestamp formats
• Optimistic concurrency control through ETag attributes
• Synchronization of Samba and OpenDJ passwords

You can find more details about the OpenDJ 2.5.0-Xpress1 release in the OpenDJ Release Notes.

The release is built out of revision 8087 of the trunk of the code repository.

As usual, you can find every thing on the OpenDJ Downloads page:

• The Java WebStart Installer
• The Zip package (the SHA signature is here).
• The DSML gateway for those who want to provide a web service access to their LDAP directory server.

The draft documentation for OpenDJ, and more specifically the Administration Guide, has been updated on the OpenDJ project site, still on the track for an accurate, reviewed version for the final release of OpenDJ 2.5.0, due by the end of this year.

Feedback is important to us and you can participate on the IRC channel, the mailing lists or join our community.

Enjoy !

As few days after an important milestone for OpenDJ, the open source LDAP directory server in Java, I’m happy to announce that a new bug fix release of  the 2.4 series has just been made available. OpenDJ 2.4.6 is an update release of the OpenDJ project and improves reliability and performances with large groups and entries, as well as very large databases. The full details about the release have been posted in the OpenDJ 2.4.6 Release Notes. Upgrading to this release is recommended for everyone running earlier versions. For additional features and bug fixes, please use OpenDJ 2.5.0-Xpress1.

The release is built out of revision 8102 of the b2.4 branch of the code repository.

As usual, you can find every thing on the OpenDJ Downloads page:

• The Java WebStart Installer
• The Zip package (the SHA signature is here).
• The SVR4 package for Solaris users. Note that the SVR4 package has only been tested with sanity tests.
• The DSML gateway for those who want to provide a web service access to their LDAP directory server.

The draft documentation for OpenDJ, and more specifically the Administration Guide, has been updated on the OpenDJ project site, still on the track for an accurate, reviewed version for OpenDJ 2.5.

Feedback is important to us and you can participate on the IRC channel, the mailing lists or join our community.

Enjoy !

As few days after an important milestone for OpenDJ, the open source LDAP directory server in Java, I’m happy to announce that a new bug fix release of  the 2.4 series has just been made available. OpenDJ 2.4.6 is an update release of the OpenDJ project and improves reliability and performances with large groups and entries, as well as very large databases. The full details about the release have been posted in the OpenDJ 2.4.6 Release Notes. Upgrading to this release is recommended for everyone running earlier versions. For additional features and bug fixes, please use OpenDJ 2.5.0-Xpress1.

The release is built out of revision 8102 of the b2.4 branch of the code repository.

As usual, you can find every thing on the OpenDJ Downloads page:

• The Java WebStart Installer
• The Zip package (the SHA signature is here).
• The SVR4 package for Solaris users. Note that the SVR4 package has only been tested with sanity tests.
• The DSML gateway for those who want to provide a web service access to their LDAP directory server.

The draft documentation for OpenDJ, and more specifically the Administration Guide, has been updated on the OpenDJ project site, still on the track for an accurate, reviewed version for OpenDJ 2.5.

Feedback is important to us and you can participate on the IRC channel, the mailing lists or join our community.

Enjoy !

I’m happy to announce that a new revision of OpenDJ, the open source LDAP directory server in Java has just been released. OpenDJ 2.5.0-Xpress1 is a new stable release of the main development branch of the OpenDJ project.

OpenDJ 2.5.0-Xpress1 brings you the latest features such as:

• Capability to delegate authentication to Microsoft Active Directory (pass-through authentication)
• Improved enforcement of referential integrity for groups, whereby OpenDJ can now ensure both that members’ entries exist when they are added to groups, and also that members are removed from groups when their entries are deleted
• Access log filtering, with additional output configuration to combine request and response messages, log control OIDs, and specify timestamp formats
• Optimistic concurrency control through ETag attributes
• Synchronization of Samba and OpenDJ passwords

You can find more details about the OpenDJ 2.5.0-Xpress1 release in the OpenDJ Release Notes.

The release is built out of revision 8087 of the trunk of the code repository.

As usual, you can find every thing on the OpenDJ Downloads page:

• The Java WebStart Installer
• The Zip package (the SHA signature is here).
• The DSML gateway for those who want to provide a web service access to their LDAP directory server.

The draft documentation for OpenDJ, and more specifically the Administration Guide, has been updated on the OpenDJ project site, still on the track for an accurate, reviewed version for the final release of OpenDJ 2.5.0, due by the end of this year.

Feedback is important to us and you can participate on the IRC channel, the mailing lists or join our community.

Enjoy !

OpenDJ supports defining password policies that are quite complete in term of security measures to reduce the risks associated with textual passwords. It also defines 2 default policies, one for the administrators such as “cn=Directory Manager”, and one for all other users : the “Default Password Policy”. But it is possible to define additional password policies and assign them to individual users or group of users. Today, we are considering how to assign a password policy to all users under a specific subtree. In the article below, I first define a new custom password policy and then I demonstrate 2 ways of assigning that password policy to all persons under the ou=people,dc=example,dc=com subtree.

Defining a custom password policy using dsconfig:

1- Assigning the password policy through a Virtual Attribute.

Check that the password policy is assigned properly:

Change the user password, the new password should be encoded with the scheme specified (SSHA-256)

2 – Assigning the password policy using Collective Attributes :

Now we can check that the password policy is well assigned, and that it’s used when changing password for example.

So which method to assign a password policy to specific users is best ?

The first method should be preferred when the password policy is defined in the configuration (as we’ve done in the example). Both configuration entries, the password policy and its assignment, are under the “cn=config” tree,  but need to be defined in all replicas.

The second method defines the assignment of a policy to users as an subentry collocated with the data, and will be replicated. It should be preferred if the password policy is also defined as a subEntry, along with its assignment. Such way of configuring a password policy is documented in the Administration Guide, Configuring Password Policies section, procedure 10.3 - To Create a Subentry Based Password Policy.

I’ve received an intriguing request from a customer last week :  he wanted to know if we’ve done benchmarks of the password hashing schemes that are available in OpenDJ, our LDAP directory service. Their fear was that with stronger schemes, they could not sustain a high authentication rate.

In light of the LinkedIn leak of several millions of passwords, hashed with a simple unsalted SHA1, I decided to run a quick and simple test.

SSHA1 is the default hashing scheme for password in OpenDJ. The salt is an 8 bytes (64-bit) random string and is used with the password to produce the 20 bytes message digest. But OpenDJ directory server supports a wide range of password hashing scheme and salted SHA512 is currently the most secure hashing algorithm we support (and the salt here is also an 8 bytes (64-bit) random octet string).

So for the test, I generated a sample directory data set with 10 000 users, and imported it in the OpenDJ directory (a 2.5 development build) with the default settings, on my laptop (MacBook Pro, 2.2 GHz intel Core i7).

$ ldapsearch -D "cn=directory manager" -w secret12 -p 1389 -b "dc=example,dc=com" 'uid=user.10' dn userPassword
dn: uid=user.10,ou=People,dc=example,dc=com
userPassword: {SSHA}cchzM+LrPCvbZdthOC8e62d4h7a4CfoNvl6d/w==

I then ran an “authrate” which is a small benchmark tool that allows to stress an LDAP server with a high number of authentications (LDAP Bind requests) and let it run to 5 minutes.

authrate -h localhost -p 1389 -g 'rand(0,10000)' -D "uid=user.%d,ou=people,dc=example,dc=com" -w password -c 32 -f
-----------------------------------------------------------------
 Throughput     Response Time
 (ops/second)   (milliseconds)
 recent average recent average 99.9% 99.99% 99.999% err/sec
 -----------------------------------------------------------------
 ...
 26558.0  26148.9   1.179    1.195  10.168  19.431  156.421      0.0

I then stopped the server, changed the import default password encryption scheme to Salted SHA512, and reimported the data.

$ ldapsearch -D "cn=directory manager" -w secret12 -p 1389 -b "dc=example,dc=com" 'uid=user.10' dn userPassword
 dn: uid=user.10,ou=People,dc=example,dc=com
 userPassword: {SSHA512}eTGiwtTM4niUKNkEBy/9t03UdbsyYTL1ZXhy6uFnw4X0T6Y9Zf5/dS7hDIdx3/UTlUQ/9JjNV9fOg2BkmVgBhWWu5WpWKPog

$ authrate -h localhost -p 1389 -g 'rand(0,10000)' -D "uid=user.,ou=people,dc=example,dc=com" -w password -c 32 -f
 -----------------------------------------------------------------
 Throughput     Response Time
 (ops/second)   (milliseconds)
 recent average recent average 99.9% 99.99% 99.999% err/sec
 -----------------------------------------------------------------
 ...
 25481.7 25377.6 1.222 1.227 10.470 15.473 158.234 0.0

dn: cn=Default Password Policy,cn=Password Policies,cn=config
ds-cfg-default-password-storage-scheme: cn=Salted SHA-512,cn=Password Storage Schemes,cn=config

dn: cn=Password Policy Import,cn=Plugins,cn=config
ds-cfg-default-user-password-storage-scheme: cn=Salted SHA-512,cn=Password Storage Schemes,cn=config

Bill Nelson,  has published the “The Most Complete History of Directory Services You Will Ever Find” (until the next one comes along), a detailed history of LDAP based directory services and products. Expect a few updates as people find about this and ask for adding new data points. But this is the most complete summary I’m aware of. I had a timeline of Sun directory products a few years ago, but Bill’s has more details.

His post includes a visual timeline of the directory service products and their heritage, linked here under, for your convenience.

Click on the picture for a full size image.

Personally, I’ve been involved with the Sun and derived lines since 1996, and now drive the ForgeRock one: OpenDJ !

Another week goes by, and it’s time for another tab sweep.

Syntegrity Networks, one of our major partners in the US, has launched a campaign to encourage their customers to migrate from Sun Directory Server to OpenDJ.

Silverpeas, a Collaborative Platform, built as open source under the GNU Affero license by the eponym company, has been supporting LDAP for authentication and authorization for some time. The documentation for setting up the LDAP domain has been updated using OpenDJ as the recommended server.

ForgeRock OpenIDM capabilities are growing. After getting OpenIDM to work with Activity to provide workflows, the team posted a experimental tutorial to integrate Jasper with OpenIDM to produce nice reports. You can find more of these tutorials in the OpenIDM How To Collection.

System administrators that are familiar with legacy LDAP directory servers know that one of the key for the best performance is caching the data. With Sun Directory Server or OpenLDAP, there are 3 levels of caching that could be done : the filesystem level, the database level and the entries level. The filesystem level cache is managed by the OS and cannot be controlled by the application. Using the filesystem cache is good when the directory server is the only process on the machine, and/or for initial performance. The database level cache allows faster read or write operations, and also includes the indexes. The later cache is the higher level cache, and usually the one that provides the best performances as it requires the least processing from the server to return entries to the applications, and it has the least contention.

OpenDJ has a different design for its database and core server, and thus the caching strategy needs to be different.

By default, OpenDJ does have a database cache enabled, and 3 different kind of entry caches, all disabled. The reason for the 3 entry caches is that they are implementing for different needs and access patterns. But all have in common a specific filter to select which entries to cache, and some settings as to how much memory to use. During our stress and performance tests, we noticed that using an entry cache for all accessed entries added a lot of pressure on the garbage collector, and also caused more garbage collection from the old generation, often leading to either fragmentation of the memory, or more frequent full GC (also known as “Stop the world GC”). This resulted in an overall lower consistent average response time and throughput.

So, we recommend that you favor the database cache, and do not setup an entry cache, except for specific needs (and do not try to activate all 3 entry caches, this may lead to some really strange behavior).

The default settings with OpenDJ 2.4 is that 10 % of the JVM heap space will be used for the database cache. With OpenDJ 2.5 (soon to be released), we have bumped the default to 50% of the heap space. If you’re tuning the heap size and make it larger than 2GB, we recommend that you keep that 50% ratio or even increase it if the heap size exceeds the 3GB.

If you do have a few very specific entries that are very often accessed, like large static groups that are constantly used for ACI or group membership by application, then the entry cache becomes handy, and then you want to set a filter so only these specific entries are cached.

For example, if you want to cache at most 5 entries, that are groupOfNames, you can use the following dsconfig command:

Otherwise, you’d better of running with no entry cache. OpenDJ read performance are such that the directory server can respond to tens of thousands if not hundred of thousands searches per second with average response time in the order of a milli-second. This should be good enough for most applications !