Following the exemple of my colleague Chris, I’ve pushed a set of OpenDJ scripts and utilities for that I’ve wrote and used in the past to github.
You will find script for log statistics, converting schema, …
Feel free to use, and if you have suggested enhancements, patches, I’ll be looking for pull request !
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 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 !
Closing tabs and removing bookmarks in my browser before going on vacation, I ought to post a few links before :
ForgeRock is growing and I’m happy to count Chris Ridd as a new member of the OpenDJ team. Chris’ main focus will be support and sustaining, but he’s already started building knowledge information and posted an article on our wiki about using Eclipse for OpenDJ development; and has a new feature enhancement in progress.
Open source projects likes other open source projects. For the last few months, Silverpeas has been running demos, testing with the OpenDJ LDAP directory service. They’ve moved one step closer with integrating OpenDJ in their unit test framework, posted the JUnit module on GitHub, and documented the process. A French version of the article is also available.
Bill Nelson keeps on publishing snippets of the OpenDJ Administration, Maintenance and Tuning class, and this week posted an Architecture overview of the OpenDJ directory server.
Version 2.0 of the LDAP Synchronization Connector (LSC-Project) has been released. I need to give a try to the new version, as LSC has been proved to be helpful for migrating directory services.
Dave Koelmeyer wrote a simple article, yet very useful, describing how to enable LDAP secondary group memberships with Ubuntu 12.04 and OpenDJ.
Phil Lembo, alias ELDAPO, posted a short article to describe how to update the JVM version used by OpenDJ. There are some good reasons for enforcing some stickiness with the version of the JVM, but controlling the runtime environment for a service that can be critical is the major one.
Have I already mentioned that we’re hiring ? If you’re a developer, have some good object oriented programming experience with Java, and want to live close to the Alps, enjoying cycling, hiking or hand-gliding during summer time and skiing or snowboarding in winter, then you should apply 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.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:
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 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 !
It’s been one of these weeks, where you’re so busy that you hardly have the time to tweet, let even blog. The week started on Sunday morning with an early flight to London (after a very short night thanks to my daughter end of the year party). On Monday, I’ve been driven to Bristol, to see our new office, meet with Steve Ferris, head of ForgeRock UK, and meet with Chris Ridd who has just joined our company as a Support engineer, focusing mostly on OpenDJ, our open source LDAP directory services in Java.
After Oslo, this was my second stage of the tour of world-wide offices (*). Bristol office has opened a couple of weeks ago, and it’s really nice, located on Queen’s Square, in an old house and spread through 3 stores and a cellar.
On Tuesday, we left the Bristol office around noon to come back to London for 2 meetings with customers, both using OpenDJ.On Wednesday morning I flew back to France, to prepare our Grenoble office warming party, planed for the Thursday at 5:30pm.
On Thursday I went and picked up Lasse Andresen our CEO, at the airport. He was just back from San Francisco and making a detour on his way home for the party. We had a little time for talking about the business, hiring, and a few other things, and already our first guests started to show up for the official opening of the new office for the ForgeRock Grenoble Engineering Center. Over an hour and half, we had the visit from some of our office neighbors, some ex-colleagues from Sun, the Chief Service Officer from BonitaSoft (another great startup from Grenoble, build on open source software), our external accountants, a few leaders from the AlpesJUG (the local Java User Group), guests from other software or services companies around, and even the future new hire who signed his contract yesterday. I was so busy with welcoming everyone, making sure glasses were not empty, that I realized afterwards I had not taken a single photo of the event, despite having my camera ready on my desk.
This morning, Lasse and I had another session of work before he started to head towards the airport to fly back home, and since then, I’ve been trying to catch up on emails, documents and all… This is my last action before I call it a week and go in the living room to sip a very fresh beer and relax !
The coming weeks should allow me more time for blogging and tweeting. Until then, enjoy the week-end !
(*) I don’t plan to continue my tour until September, and should see the San Francisco office when I’m coming to speak at JavaOne.
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:
$ dsconfig create-password-policy \ --set default-password-storage-scheme:Salted\ SHA-256 \ --set password-attribute:userpassword \ --type generic \ --policy-name Custom\ PP \ --hostname lpmac.local \ --port 4444 \ --bindDN cn=Directory\ Manager \ --bindPassword ****** \ -X -n
1- Assigning the password policy through a Virtual Attribute.
$ dsconfig create-virtual-attribute \ --set attribute-type:ds-pwp-password-policy-dn \ --set enabled:true \ --set value:cn=Custom\ PP,cn=Password\ Policies,cn=config \ --set base-dn:ou=people,dc=example,dc=com \ --set filter:\(objectClass=person\) \ --type user-defined \ --name Custom\ PP\ Assignment \ --hostname lpmac.local \ --port 4444 \ --bindDN cn=Directory\ Manager \ --bindPassword ****** \ -X -n
Check that the password policy is assigned properly:
$ ldapsearch -D "cn=directory manager" -w secret12 -p 1389 -b "" 'uid=user.1' '+' userPassword
dn: uid=user.1,ou=People,dc=example,dc=com
userPassword: {SSHA}u+52Ld6iaTvFoNlQvqTHrn1BBW9IjjT2/I25hg==
numSubordinates: 0
ds-pwp-password-policy-dn: cn=Custom PP,cn=Password Policies,cn=config
structuralObjectClass: inetOrgPerson
pwdPolicySubentry: cn=Custom PP,cn=Password Policies,cn=config
subschemaSubentry: cn=schema
hasSubordinates: false
entryDN: uid=user.1,ou=people,dc=example,dc=com
entryUUID: 4e9b7847-edcb-3791-b11b-7505f4a55af4
Change the user password, the new password should be encoded with the scheme specified (SSHA-256)
$ ldappasswordmodify -p 1389 -D uid=user.1,ou=People,dc=example,dc=com -w password -A -n newPassword
The LDAP password modify operation was successful
$ ldapsearch -D "cn=directory manager" -w secret12 -p 1389 -b "" 'uid=user.1' userPassword
dn: uid=user.1,ou=People,dc=example,dc=com
userPassword: {SSHA256}vjIdZEtF1AIiM0EgY9unZUXXublwQwlOCoe4RYEIHtpzumW1hYyvNg==
2 – Assigning the password policy using Collective Attributes :
$ ldapmodify -D cn=directory\ manager -w secret12 -p 1389
dn: cn=Pwp for Users,dc=example,dc=com
changetype: add
objectclass: collectiveAttributeSubEntry
objectclass: extensibleObject
objectclass: subentry
objectclass: top
ds-pwp-password-policy-dn;collective: cn=Custom PP,cn=Password Policies,cn=config
subtreeSpecification: { base "ou=people", specificationFilter "(objectclass=person)"}
Processing ADD request for cn=Pwp for Users,dc=example,dc=com
ADD operation successful for DN cn=Pwp for Users,dc=example,dc=com
Now we can check that the password policy is well assigned, and that it’s used when changing password for example.
$ ldapsearch -D "cn=directory manager" -w secret12 -p 1389 -b "" 'uid=user.1' '+' userPassword
dn: uid=user.1,ou=People,dc=example,dc=com
userPassword: {SSHA}6tHBLHh2C25UpAsKX0eq0d6LEXYGX+Jcm4dh7g==
numSubordinates: 0
ds-pwp-password-policy-dn: cn=Custom PP,cn=Password Policies,cn=config
structuralObjectClass: inetOrgPerson
etag: 000000008211ac6a
pwdPolicySubentry: cn=Custom PP,cn=Password Policies,cn=config
subschemaSubentry: cn=schema
hasSubordinates: false
collectiveAttributeSubentries: cn=Pwp for Users,dc=example,dc=com
entryDN: uid=user.1,ou=people,dc=example,dc=com
entryUUID: 4e9b7847-edcb-3791-b11b-7505f4a55af4
$ ldappasswordmodify -p 1389 -D uid=user.1,ou=People,dc=example,dc=com -w password -A -n newPassword
The LDAP password modify operation was successful
$ ldapsearch -D "cn=directory manager" -w secret12 -p 1389 -b "" 'uid=user.1' userPassword
dn: uid=user.1,ou=People,dc=example,dc=com
userPassword: {SSHA256}WswyH9ANoKcxQWlSn/eL8h/dNk532K/e5zGlJcwiwMLsCQqw+cAX0Q==
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
And then re-run the “authrate”
$ 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
As you can see, there is not much of a difference in throughput or response time, when using the strongest algorithm to hash user password. So do not hesitate to change the default settings and make use of the strongest password hashing schemes with OpenDJ. It could save you from the embarrassment of, one day, contacting each of your users or customers to ask them to change their compromised password.
The default password hashing schemes are in 2 locations :
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
Both properties can be changed with dsconfig while the OpenDJ server is running, and the new scheme will be used for all subsequent operations.
Understanding and tuning the JVM is quite important to get the best performances out of OpenDJ. We do provide some high level guidance in our documentation and I’ve been talking about Java performances in the last few years at various Java User Groups in France and Switzerland (you can find presentations in French here or here) as well as at a major conference in Brazil : FISL in 2009. On this later occasion, I was asked to cover the presentation for 2 prestigious names in the Sun Hotspot JVM team : Charly Hunt and Tony Printezis. I’ve spent a few hours with them and have learnt a great deal about the internals of the Hotspot JVM and memory management, and all magic parameters, in order to deliver that presentation. At that time, our directory team was interacting a lot with the Hotspot team as we were testing a new and promising garbage collector: Garbage First aka G1. OpenDS was even wrapped and used in one of the largest collection of tests for the Sun JVM.
During the acquisition of Sun by Oracle, the future of G1 and the Hotspot JVM were unsure and our interactions with the Hotspot team diminished seriously.
At ForgeRock, we continued to pay attention to Garbage First and for a long time, we noticed that it wasn’t moving along. Most of the issues that were raised after tests with OpenDS and that were addressed in some development version of the JVM were not integrated in official JVM releases. It only with the Oracle JVM 1.7 update 2 that we noticed the large list of issues fixed with G1. We’ve then resumed testing OpenDJ with G1 to see that while the promise of no full GC seems to be addressed, the performance impact of G1 is still significantly high. With our limited tests of JVM under 4GB of heap size, we noticed a 10% performance degradation over CMS, corresponding with an approximate 10% increase of CPU load (on a quad core machine with hyperthreading on), but with better overall response times for OpenDJ as the maximum response time decreased from 200ms to 80ms, as illustrated below.
LDAP Modrate with Garbage First ------------------------------------------------------------------------------- Throughput Response Time (ops/second) (milliseconds) recent average recent average 99.9% 99.99% 99.999% err/sec Entries/Srch ------------------------------------------------------------------------------- 16196.7 16374.1 1.972 1.951 18.886 28.129 66.933 0.0 16468.8 16374.9 1.941 1.951 18.883 28.087 66.521 0.0 LDAP Modrate with CMS ------------------------------------------------------------------------------- Throughput Response Time (ops/second) (milliseconds) recent average recent average 99.9% 99.99% 99.999% err/sec Entries/Srch ------------------------------------------------------------------------------- 17937.1 17487.7 1.780 1.827 18.175 30.521 116.990 0.0 17783.7 17494.3 1.796 1.826 18.145 30.320 117.017 0.0
We need to run more tests with OpenDJ and G1, especially with very large heaps (from 4 to 32GB), but we’re not sure whether G1 will be able to deliver the performances it promised.
And today I noticed on LinkedIn that both Charly Hunt and Tony Printezis, the 2 main engineers behind the HotSpot JVM and Garbage First, had left Oracle for new adventures. Charly’s gone to SalesForce and Tony to Adobe. This is certainly a good move for both of them, but it leaves me worried about the future of the Hotspot JVM and its ability to deliver innovation in GCs.
[Update on May 6th]
It appears that more engineers of the Sun JVM team have actually left in the last couple of months : John Pampuch, Igor Veresov, Paul Hohensee..
I was recently pointed to a white paper published by Oracle called : Oracle Optimized Solution for Oracle Unified Directory — Implementation Guide.
Because Oracle Unified Directory and OpenDJ have a common root (both derive from the Sun initiated OpenDS project), I was curious about that optimized solution, and if there was anything that might be applicable for our customers. And after reading the 45 pages white-paper, honestly, the Oracle Optimized Solution is not something I would recommend to any of our customers (*).
The white paper describes the hardware used for the solution : 3 SPARC T4-1 systems with 128GB of RAM and 6 300GB internal disks each. A Sparc T4-1 machine is an 8 core machine with each core supporting up to 8 threads. Each T4-1 system has 10GbE add-on network card. And each T4-1 machine is attached to a Sun Storage 2500-M2 array (with 2540 controllers) through two fiber channel cards, and each storage has 12 disks.
Let’s see the average price for this solution : The SPARC T4-1 with 128 GB of RAM has an estimated public price of $24,344, but with only 2 internal disks. So add another $1,660 for the additional 4 disks. The lowest price for a 10GbE card for that system is $2,000 and the cheapest storage array with the same amount of disks roughly $27,000. A total cost per system over $55,000, not including the cost of the Operating System, and a total cost for the “Optimized Solution” of approximately $165,000 (estimated public price).
So what do we get in performance for this price ? Well the white paper will not tell you what the solution is optimized for. The only number that appears, is the time it took to import the 15 Million entries on one of the systems :
[07/Jan/2012:12:19:29 +0000] category=JEB severity=NOTICE msgID=8847569 msg=Total import time was 3790 seconds. Phase one processing completed in 2868 seconds, phase two processing completed in 922 seconds
[07/Jan/2012:12:19:29 +0000] category=JEB severity=NOTICE msgID=8847454 msg=Processed 15000001 entries, imported 15000001, skipped 0, rejected 0 and migrated 0 in 3790 seconds (average rate 3957.0/sec)
[07/Jan/2012:12:19:29 +0000] category=JEB severity=NOTICE msgID=8847536 msg=Import LDIF environment close took 0 seconds
Last week, I was in Mexico with a partner of ours, demonstrating the capabilities of OpenDJ with the customer’s data (exported from a week ago, and which also contains several hundreds of very large static groups). We used x.86 based machines, with 96GB of memory, although we only used 16GB for the instance of OpenDJ.
And here’s the output of the import command :
[25/Apr/2012:20:10:44 +0200] category=JEB severity=NOTICE msgID=8847538 msg=DN phase two processing completed. Processed 21654508 DNs
[25/Apr/2012:20:10:45 +0200] category=JEB severity=NOTICE msgID=8847569 msg=Total import time was 2002 seconds. Phase one processing completed in 1137 seconds, phase two processing completed in 865 seconds
[25/Apr/2012:20:10:45 +0200] category=JEB severity=NOTICE msgID=8847454 msg=Processed 21654508 entries, imported 21654508, skipped 0, rejected 0 and migrated 0 in 2002 seconds (average rate 10815.3/sec)
[25/Apr/2012:20:10:45 +0200] category=JEB severity=NOTICE msgID=8847536 msg=Import LDIF environment close took 0 seconds
I don’t have the price for the servers we used (but our partner can get in touch with you if you’re interested in the solution), but I doubt that it tops half of the price of the Oracle optimized solution !
So before you drink the Oracle cool-aid, think twice about what an optimized solution should be, and how much it should cost. Oh, by the way, there is no cost in license for OpenDJ, it’s open source, it’s available now and you can try it free of charge. Of course, we do appreciate if you subscribe to one of our support offering to protect your investment and ensure some Service Level Agreement.
(*) I would not recommend a directory solution on SPARC Tx machine ever. While the machines have a good capacity for load, the performance for any write activity is really bad, especially as soon as access controls are in use. Most of our partners who have been deploying directory services on these machines will agree with me. As a matter of fact, I don’t recall any recent customer mentioning SPARC nor Solaris when renewing their directory service infrastructure.
I’m just back from a week of business trip to Mexico City. This was my first time in Mexico and I’ve heard all the rumors of it being a very dangerous city. I must say that I’ve seen a very very big city, vibrant, busy, with a lot of car trafic, but at no point I had any fear of being robbed or molested.
Two things have marked me during my stay. First, the city is very green. There are lots of trees, plants, flowers everywhere. All main avenues are borded by trees. It’s like mother nature is trying to tell us that she still exists despite the concrete and buildings.
The other thing is that at any time of the day or the night, there are people in the street, trying to earn a little bit of money, selling water, tissues or balloons.
The food was amazing. I enjoyed tacos, fresh fruits, some argentinian bife, jalapeños… Spicy, but not “mucho picante”. As well as beers like Victoria, Bohemia, Dox Equis, Modelo… And tequila of course !
Other photos from my trip are on Google+
By the way, we did work this week in Mexico.
Below is a photo of the screen as we’ve finished importing the customers’ data in OpenDJ (the data includes a few hundreds of groups, each averaging 40 000 members). I like this kind of performance number ! And I will probably say more about the hardware and settings to achieve that in a future post.
I shall say a big thank you to our partner in Mexico and Latin America : NoLogin. They’ve made everything to make my stay safe and comfortable, including with jalapeños and tequila !
I hope the few companies I visited will turn into customers. I’d like to come back again in Mexico. These 5 days have just gone to0 fast. And I’ve just started to get into lutta libre 😉
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.
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.
OpenDJ, the open source LDAP directory services in Java, defines a few global resource limits to prevent client connections or operations from abusing the server’s resources. These limits are
There are default values for all of these limits in the Global configuration, but they can also be set on a per user basis. The global limits are read or set using dsconfig :
$ bin/dsconfig get-global-configuration-prop -p 4444 -X -n -h localhost \ -D cn=directory\ manager -w secret12 Property : Value(s) --------------------------------------:------------------------ bind-with-dn-requires-password : true default-password-policy : Default Password Policy disabled-privilege : - entry-cache-preload : false etime-resolution : milliseconds idle-time-limit : 0 lookthrough-limit : 5000 max-allowed-client-connections : 0 max-psearches : unlimited proxied-authorization-identity-mapper : Exact Match reject-unauthenticated-requests : false return-bind-error-messages : false save-config-on-successful-startup : true size-limit : 1000 smtp-server : - time-limit : 60 s writability-mode : enabled
The per user limits have a different LDAP attribute name and can be found or set directly in users’ entry, or through Collective Attributes. The Directory Manager entry has such specific limits set, so that everything is unlimited.
$ bin/ldapsearch -D "cn=directory manager" -w secret12 -p 1389 -X -b "cn=config" \ '(objectClass=inetOrgPerson)' ds-rlim-time-limit ds-rlim-size-limit \ ds-rlim-lookthrough-limit ds-rlim-idle-time-limit dn: cn=Directory Manager,cn=Root DNs,cn=config ds-rlim-lookthrough-limit: 0 ds-rlim-time-limit: 0 ds-rlim-idle-time-limit: 0 ds-rlim-size-limit: 0
If you decide to change the default global settings, for example the idle-time-limit, to force idle connections to be closed by the server after some time (often a smaller time than the settings of the load-balancer in between your applications and the OpenDJ servers), please remember that you might also want to change the limit for “cn=Directory Manager”, especially if your client applications are connecting with Directory Manager credentials.
Action Identity has posted a couple of articles about ForgeRock products:
Our friends at ProfiQ have posted an article describing how to use OpenDJ with Red-Hat Certificate System.
While talking about using OpenDJ with LDAP enabled applications, we try to maintain a page on OpenDJ documentation wiki with different tutorials on how to configure OpenDJ client applications.
ForgeRock will be present at the European Identity and Cloud Conference (EIC), April 17-20 in Munich.
We will also be participating to Devoxx France, April 18 to 20 in Paris. I will be co-speaking on Thursday 19, 7pm about Open Source in France, and will be available for individual meetings from Thursday morning to Friday end of afternoon. So, if you want to discuss about ForgeRock products or job opportunities, send me a mail, or leave a comment.
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:
bin/dsconfig set-entry-cache-prop --cache-name FIFO --set include-filter:\(objectclass=GroupOfNames\) --set max-entries:5 --set max-memory-percent:90 --set enabled:true -h localhost -p 4444 -D "cn=Directory Manager" -w secret12 -X -n
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 !
Ludo Sketches 
