OpenDJ with Data at Rest Encryption Solutions Part II

I blogged about OpenDJ with Data at Rest Encryption Solutions few weeks back. The POC was carried out with OpenDJ 2.6.

OpenDJ 3.0 has recently been released and the test equipment (SafeNet Data at Rest Encryption appliance) is still in our office, why not let's run a test again OpenDJ 3.0? :)

In OpenDJ 3.0, there are 2 local DB backends to choose from: JE (Oracle Berkeley DB Java Edition - 2.5 version) and PDB.


The throughtput for search operation is faster in OpenDJ 3.0 as compared to version 2.6. The response times are also slightly faster.


Encrypted partition: 11229 (JE) & 10488 (PDB) vs 10210 (JE)   ~10% diff
Non-encrypted partition: 11305 (JE) & 11235 (PDB) vs 10410 (JE)  ~ 8.5% diff

For write operations, the difference in throughput is not big. In fact, PDB performs worse. (Hmmm... Maybe need to ask my colleague to re-run the test again) ..

Encrypted partition: 2926 (JE) & 2758 (PDB) vs 2750 (JE)   ~6.5% diff
Non-encrypted partition: 3282 (JE) & 2824 (PDB) vs 3199 (JE)  ~ 2.5% diff


The difference in response time is also not big. Again, I might want to re-run the test for PDB again. Or maybe some tuning is required. Not sure, it's something new to me. :)

Encrypted partition: 8.2 (JE) & 8.70 (PDB) vs 8.72 (JE)
Non-encrypted partition: 7.3 (JE) & 8.4 (PDB) vs 7.5 (JE)

.

OpenAM Policy Configuration - High-Availability and Load-Balancing

I realized I blogged this topic before last year - OpenAM Policy Configuration - HA Issue.

One of my customers encountered policy evaluation failure last week due to a fault with one of their OpenDJ servers.

The Policy Configuration (Access Control ++ / (Top Level Realm) ++ Services ++ Policy Configuration) is seldom in use, unless a LDAP Filter condition is configured in Policies (Access Control ++ / (Top Level Realm) ++ Policies)

I'm trying my luck again today to find out a good HA solution for Policy Configuration.


1) The following instructs all OpenAM nodes to communicate with a single OpenDJ server. This is not ideal.

2) The following will not work.

OpenAM debug log will complain with failed to get LDAP server name. If you enter more than one server name in the policy config service's Primary LDAP Server field, please make sure the ldap server name is preceded with the local server name".

3) For multi OpenAM servers, it is better to distribute the load equally to different OpenDJ servers in the backend. However, of course, this doesn't solve the original high-availability/failover issue.

I'm thinking of having 2 entries of the same local server name, each append with a different OpenDJ server. No luck!

Tested. OpenAM only takes the last entry if multiple identical local server name appear. In the above case, only "am2.cdemo.sg:3389" is mapped to "am2.cdemo.sg" (local server name).


The underlying code is such that a local server name can only return a LDAP SERVER entry.

com.sun.identity.policy.PolicyConfig

com.sun.identity.shared.datastruct.CollectionHelper 

Why isn't there a Secondary LDAP Server configuration?


For now, no choice, I think we need a LB in front of the OpenDJ servers.

.

OpenDJ with Data at Rest Encryption Solutions

We just completed a POC for a customer few weeks ago. This is a long time customer using Sun Directory Server and subsequently ported over to ForgeRock OpenDJ.

Recently, due to the strict PDPA requirement from the PDPC (Personal Data Protection Commission Singapore), we are to ensure the user profiles stored in OpenDJ are kept totally safe.

So, few weeks ago, we worked with Gemalto engineers to deploy OpenDJ local DB backend on a partition that is protected by SafeNet Data at Rest Encryption.

Worked like a charm!

I asked my colleage to run a little load-test (6 Connections / 4 Threads) using OpenDJ SDK Toolkit for comparison.

The response time for search operation looks pretty similiar. 

 Now, when it comes to write operations, then there is quite a bit difference in the response time.

Need to be careful in deployment sizing when customer decides on this solution.

.

OpenAM Security Advisory #201601

ForgeRock has just released a security advisory #201601 last night and it is quite a long list - a total of 15 vulnerabilites found in OpenAM 12.0.2, 12.0.1, 11.0.3 and 10.0.2.

I have customers using 12.0.2, 11.0.3 and 10.0.2. Not really good news to me. :(

Details can be found here. Start patching!

OpenDJ Naming Conflicts nsuniqueid=xxx

Just realized I took a long break from blogging. So, I took a long holiday in December to make a family trip to Taiwan. Nice place to be in! In fact, I visit Taiwan frequently. This time round, we went to the eastern side of Taiwan - Taitung area. 

So, we have a long time customer who is using OpenDJ as a centralized user store. Few weeks back, he emailed to notify me that he found some "weird" user entries with DN as such:

dn: nsuniqueid=85c95685-21eb11df-80d5c084-e9b4da2d+uid=stageon238,ou=members,o=XXX.sg

A similar entry was found in the same OpenDJ:

dn: uid=stageon238,ou=members,o=XXX.sg


This is a naming conflict that only happens for replayed operations in a MMR setup.

I am not able to find any documentation from OpenDJ. Here are 2 links that talk about this naming conflict:

1. Resolving Naming Conflicts
2. Solving Naming Conflicts

In short, remove the entry which is older.


.