I’m sure most of you have seen this already… I’m posting it here for posterity !
ForgeRock secures $7M in a series A funding from Accel Partners
Let’s pop up the volume now !!!
I’m sure most of you have seen this already… I’m posting it here for posterity !
ForgeRock secures $7M in a series A funding from Accel Partners
Let’s pop up the volume now !!!
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.4.5 is an update release of the OpenDJ project and improves reliability with SSL connections, replication meta-data indexes and Java 7. The full details about the release have been posted in the OpenDJ 2.4.5 Release Notes. Note that if you upgrade from a previous version, the ds-sync-hist index must be rebuilt, prior to restart the server.
The release is built out of revision 7743 of the b2.4 branch of the code repository.
As usual, you can find every thing on the OpenDJ Downloads page:
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 !
While taming the subject of indexes, we recently had some discussion with one of our users who complained about long response times with some language specific search filter such as (cn:fr.6:=*John*).
These extended filters rely on I18N Collation matching rules and indexes that I’ve described in an old post for OpenDS.
It turned out that he had defined the matching rule for the index, and rebuilt it, but had missed an important part: the index-type did not include “extensible”.
The proper command to create an extensible index is the following :
dsconfig set-local-db-index-prop --backend-name userRoot --index-name cn \ --set index-extensible-matching-rule:fr.6 \ --add index-type:extensible \ --hostname localhost --port 4444 \ --bindDN cn=Directory\ Manager --bindPassword ****** \ -X -n
fr.6 is the shortcut for the French substring collation matching rule which full OID is 1.3.6.1.4.1.42.2.27.9.4.76.1.
Note that if you don’t specify the extensible index-type, the server will not build the index for the extensible matching rule. The use of the index-type is consistent with the other types of index, equality or else, and allows you to disable and re-enable extensible indexes without having to re-enter all OIDs.
In a previous post I talked about analyzing search filters and indexes. Matt added in a comment that OpenDJ has another mean of understanding how indexes are used in a search. Here’s a detailed post.
The OpenDJ LDAP directory server supports a “magic” operational attribute that allows an administrator to get from the server information about the processing of indexes for a specific search query: debugsearchindex.
If the attribute is set in the requested attributes in a search operation, the server will not return all entries as expected, but a single result entry with a fixed distinguished name and a single valued attribute debugsearchindex that contains the information related to the index processing, including the number of candidate entries per filter component, the overall number of candidate, and whether any or all of the search is indexed.
$ bin/ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -b "dc=example,dc=com" "(&(mail=user.*)(cn=*Denice*))" debugsearchindex Password for user 'cn=Directory Manager': ******* dn: cn=debugsearch debugsearchindex: filter=(&(mail=user.*)[INDEX:mail.substring][COUNT:2000](cn=*Denice*)[INDEX:cn.substring][COUNT:1])[COUNT:1] final=[COUNT:1] $ bin/ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -b "dc=example,dc=com" "objectclass=*" debugsearchindex Password for user 'cn=Directory Manager': ********* dn: cn=debugsearchdebugsearchindex: filter=(objectClass=*)[NOT-INDEXED] scope=wholeSubtree[COUNT:2007] final=[COUNT:2007] $ bin/ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -b "dc=example,dc=com" "mail=user.1*" debugsearchindex Password for user 'cn=Directory Manager': ********* dn: cn=debugsearch debugsearchindex: filter=(mail=user.1*)[INDEX:mail.substring][COUNT:1111] scope=wholeSubtree[COUNT:2007] final=[COUNT:1111]
Note that sometimes, OpenDJ tries to optimize the query and use some other index than the regular one for the query. For example, it might use the equality index for an initial substring filter. The index used during the search does appear in the debugsearchindex attribute. Also, once the result set has been narrowed down to very few entries, it will stop using index and evaluate directly the entry set, as for the example below:
$ bin/ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -b "dc=example,dc=com" "(&(cn=Denice*)(mail=user.9*))" debugsearchindex Password for user 'cn=Directory Manager': dn: cn=debugsearch debugsearchindex: filter=(&(cn=Denice*)[INDEX:cn.equality][COUNT:1])[COUNT:1] final=[COUNT:1]
I’ve been traveling a little bit last week, visiting a major customer in the UK (helping with their OpenDJ based directory service that has grown from 13 Millions entries to 17 Millions in a about 6 months).
Last week was also a busy week in term of news for ForgeRock. First, we’ve announced the release of OpenIDM 2.0, a major version of our real-time identity life-cycle management, provisioning and synchronization software product. OpenIDM 2.0 is a new release, but is already running in production at a few happy customers.
ForgeRock and Qubera Solutions have announced a partnership for the delivery of Standard-based Identity Services based on ForgeRock I3 Open Platform. Qubera Solutions offers workshops and migration tools to help former Sun Microsystems customers to move away legacy software solutions.
I’ve also came across a blog post from Martin Sandren, that positions ForgeRock as one of the challengers on the Identity and Access Management market. It’s an interesting reading and it looks like the previous announcement does start to address some of his concerns.
Martin was not the only one to talk about ForgeRock. Scott Mc Nealy has been nicely advertising about us on Twitter.
And finally, we’re expanding and therefore we’ve published a few job postings on our web site. I’m pretty confident that these are just a few to start with and we will have more, including some in our Grenoble Engineering Center.
Enabling replication between multiple instances of the OpenDJ LDAP directory server is pretty simple and straightforward. You can check for yourself in the Replication chapter of the Administration Guide.
But fully disabling replication can be tricky with OpenDJ 2.4, mostly because of a known issue with the dsreplication disable –disableAll command : OPENDJ-249 : Doing dsreplication disable –disableAll is throwing a javax.naming.CommunicationException when removing contents of “cn=admin data”.
We are fixing this issue in OpenDJ 2.5, but for those who have deployed OpenDJ 2.4 and want to know how to fully remove all references to a replica in the topology, here are the steps to manually disable replication :
Note, all these steps should be done using ldapmodify, or an LDAP browser such as OpenDJ Control-Panel’s Manage Entry or Apache Directory Studio.
The OpenDJ Administration, Maintenance and Tuning (FR-462) training is taking place in Paris from Tuesday January 24th to Friday January 27th 2012.
The course is mix of lecture and labs and is designed for system administrators, integrators, consultants, architects and developers that will be installing, configuring, administering and maintaining ForgeRock OpenDJ LDAP directory server. I’ve been reviewing the course materials, and I must say I’m really excited by it. The amount of information available in the materials is huge, and the hands-on exercises are very detailed and practical.
The training is definitely a must for anyone who is or will be deploying and managing OpenDJ. And as this is the first training for OpenDJ in Europe, I will be attending it as an observer, gathering feedback on both product and course, also possibly as an assistant to the trainer Bill Nelson.
The session will be hosted in Astec training facilities, right in the heart of Paris, close to Gare Saint Lazare and Boulevard Haussmann.
There are still some slots available, so enroll quickly by email to training@forgerock.com.
Isode has just released a benchmark of their M-Vault R15.1 directory server, and has run some comparative tests against OpenLDAP and OpenDJ.
While the benchmark demonstrates that M-Vault is one of the best directory server out there (the new release has some really impressive search performance) , I paid more attention to the write performance, and I really like those results that are showing the OpenDJ is the fastest directory server for write operations, even when modifications are mixed with searches.

Captured from Isode benchmark white-paper.
Thanks Isode for running those tests, and making those numbers publicly available.
If you’re running OpenDJ with a 64bit JVM with less than 32GB of heap size, be aware of the need to explicitly set the -XX:+UseCompressedOops option (unless you want to disable it).
Compressed oops is supported and enabled by default in Java SE 6u23 and later, when running a 64bit JBM with a value of -Xmx lower than 32GB. You can find more information about Compressed Oops in Java technical notes here: http://download.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html
However, OpenDJ internal database, in order to estimate properly the occupation of the DB cache and tune the cache eviction threads, needs to take into account the compressed oops option. For this is relies on the JVM option to be set explicitly. If the option is not explicitly set, the database may consider the cache full when it’s not, and run cache eviction too early, resulting in less optimized performances.
So, with 64bit JVM, make sure you add the -XX:+UseCompressedOops option to the start-ds line in the config/java.properties file. Then run bin/dsjavaproperties and restart OpenDJ to benefit from the new settings.
A few months ago, we worked with Ziggo in Netherland, to help them transition their legacy environment to ForgeRock I3 Open Platform. Part of the transition, they’ve replaced Sun Directory Server Enterprise Edition (DSEE) with OpenDJ, running in 3 data-centers (and different sites), and over 2.5 Million entries, in a very smooth and well controlled migration process.
They’ve now been running OpenDJ and OpenAM in production for a few months and we’re really happy to be able to share the details of the story with you. Get the Ziggo Case Study (PDF).
You can find more details about OpenDJ on ForgeRock web site.
Months goes by, but the pace of releases remains. Today, 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.4.4 is an update release of the OpenDJ project and improves reliability by resolving issues found around the External Change Log, Replication, Password Policy and GSSAPI. It also resolves a memory leak that occurred with specific LDAP extended operations, such as the Password Modify Extended Operation. The full details about the release have been posted in the OpenDJ 2.4.4 Release Notes.
The release is built out of revision 7357 of the b2.4 branch of the code repository.
As usual, you can find every thing on the OpenDJ Downloads page:
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’ve been pretty busy at ForgeRock and haven’t found much time to post here. I’ll try to improve in the coming weeks. Meanwhile, I’d like to share a number of events in which I’m participating:
October 10, 11. LDAPCon in Heidelberg, Germany. I have a couple of presentations on the first day, and will be around until the end of the conference. If you want to meet and discuss, drop me a note.
October 26, 27, 28. fOSSA in Lyon, France. I will be attending the 3 days of the conference, presenting on Thursday 27th in the Development track. FOSSa is a free conference, that focuses on open source communities and projects, without any marketing spin. Register now.
November 8th, OpenIDM Summit in Darmstadt, Germany. I won’t be able to attend that summit, but it’s a great opportunity to learn more about ForgeRock open source Identity Management solutions. Registration is already open, don’t wait !
We’re also working on a one day broader ForgeRock I3 Open Platform event, some time late November. I’ll let you know when it’s finalized, but I will be presenting OpenDJ along with the other ForgeRock product managers.

LDAPCon 2011, the 3rd International Conference on LDAP, has finalized its program and the registration is open.
The program looks awesome with the participation of many active developers of open source projects, as well as directory vendors and deployment specialists. This year, I have the immense honor to open the conference with a presentation titled: “Is LDAP dead ?” which will be followed by a short general discussion. You don’t want to miss it !
I will also present where we are with the OpenDJ project which is continuing what Sun initiated with OpenDS to replace its aging Sun Directory Server Enterprise Edition product.
The conference will take place on October 10-11 2011, in Heidelberg, Germany. Don’t wait until the last minute, register NOW.
In LDAP, attributes have different syntaxes. The one used to indicate date and time is the GeneralizedTime, a string representation of the date and time, typically expressed in GMT time. For example, when an entry is modified, the server maintains the modifytimestamp attribute and sets a value like 20110825120001Z (for 2011, Aug 25, 12:00:01 GMT).
LDAP client applications often have to search for entries based on these date and time attributes, whether it is to find the entries that have been modified , or had the password changed recently… The way it is typically done, is the following: get from the system the current date, add or substract some fixed time (for example if you want to know the entries modified in the last 10 minutes), transform to a GeneralizedTime, use that string in a search filter: (modifyTimestamp >= 20110825130000Z). If the application repeats that search a minute later, it has to recompute the value again, and again…
Ideally what application writers would like is to express the filter as an expression like (modifyTimestamp>=${CurrentTime} – 10 mn). However this is not compliant with LDAP. The proper way to solve this is to use extensible matching rules, and for that purpose, we’ve added 2 “relative time” matching rules in OpenDJ, the Open source LDAP Directory services for Java: one for “lower than” and one for “greater than”.
matchingrules: ( 1.3.6.1.4.1.26027.1.4.6 NAME ( 'relativeTimeLTOrderingMatch' 'relativeTimeOrderingMatch.lt' ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) matchingrules: ( 1.3.6.1.4.1.26027.1.4.5 NAME ( 'relativeTimeGTOrderingMatch' 'relativeTimeOrderingMatch.gt' ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
The way the matching rules work is pretty simple : (attribute:MatchingRule:=Offset), where the offset is a signed integer follow by its unit, either s for seconds, m for minutes, h for hours, d for days or w for weeks.
You can translate a statement to “is Attribute greater than (or lower than) CurrentTime +/- Offset”
(lastLoginTime:1.3.6.1.4.1.26027.1.4.6:=-4w) will match all entries who have a lastLoginTime value smaller than the Current Time minus 4 weeks, i.e. all entries who have a lastLoginTime older than 4 weeks.
(pwdExpirationTime:1.3.6.1.4.1.26027.1.4.5:=5d) will match all entries that have pwdExpirationTime greater than the Current Time plus 5 days, i.e. all entries that will expire in more than 5 days.
The true benefit of those matching rules, is actually when expressing policies in the OpenDJ server, for example for granting or denying access based on some attribute with a generalizedTime syntax, such as last login time, pwdChangedTime, modifyTimeStamp …
For example, imagine an auxiliary objectClass representing a service, with some specific attributes including an expiration date : validUntil. Now, you want to allow these attributes to be read only if the expiration date is not passed.
aci: (targetattr="serviceAttr1 || serverAttr2")(targetfilter="(validUntil:1.3.6.1.4.1.26027.1.4.5:=0s)") (version 3.0; acl "Read Valid service attributes"; allow (read, search, compare) userdn="ldap:///all";)
As you can see, this is a good way to hide (deny access to) stale data in a directory server, and to simplify client applications that need to search for entries based on some generalizedTime attributes. For example, consider using these “relative time” matching rules for all your audit queries for expired or unused accounts.
Finally, remember that the OpenDJ directory server doesn’t allow unindexed searches by default. So you might also want to create an index for the “relative time” matching rules. That’s a 2 steps process :
Define the index
$ bin/dsconfig create-local-db-index --backend-name userRoot --set index-type:extensible \ --set index-extensible-matching-rule:1.3.6.1.4.1.26027.1.4.5 \ --set index-extensible-matching-rule:1.3.6.1.4.1.26027.1.4.6 \ --index-name createTimestamp -h localhost -p 4444 \ -D cn=Directory\ Manager -w secret12 -n -X
Rebuild the index
$ bin/rebuild-index -b dc=example,dc=com -i createTimestamp \ -h localhost -p 4444 -D cn=directory\ manager -w secret12 -X
Last month, just before the French national day, I was in Strasbourg to participate in the RMLL.

On the occasion, I did a presentation in the security track, about OpenAM Universal Gateway, another piece in the complex puzzle of Web Single Sign-On. The Universal Gateway solves an important problem in Access Management: allowing single sign-on for applications that are usually left out because they are based on legacy or non standard based technology.
The Universal Gateway comes from ApexIdentity, an acquisition that ForgeRock did in the spring. It’s been released in open source as part of the OpenAM source code repository.
The presentation I did was in French, and so are the slides.
You can find more about the Universal Gateway on ApexIdentity web site, and soon on OpenAM documentation.