No Directory Manager - Protect Your LDAP Server
By arnaud on Jun 23, 2009
Many institutions, companies and organizations have security policies in place to keep security under control with an homogeneous environment. One of those guidelines mandates that no credentials be shared between any two employees. When that is the case, cn=Directory Manager lays as what seems like a gaping hole in violation of such policies.
The other fact that bothers regulators with this user is that it is not subjected to Access Controls. It can therefore, by design, by-pass any carefully-designed access restriction policy. While this can sometimes be useful for performance reasons, this is incompatible with a quest of absolute security.
There are institutions where this is not tolerable.
Here is a painless way to stay compliant.
The idea behind this tip is to disable "cn=Directory Manager" knowing that a number of things are perfectible about this use, the main one being that one could run a brute force attack on it. Knowing the user name, which remains to its default more often than not, only makes things worse. So the number 1 thing would be to change the user name to some other value. But that would still allow brute force attacks.
The other thing that can be done is to null the directory manager password, which, combined with a mandatory password, effectively renders "cn=Directory Manager" unusable.
1. create a random password and store it in a file protected on the
host to be readable only by root.
e.g. store pd80wu709@w87-3WQJX%mjx097hc&50 in /path/to/cryptic-directory-manager-password.
Note: Do not use echo or cat or anything of that sort as this could be sniffed. Use an editor like vi, joe or whatever is most convenient.
2. create a random user. The only constraint is that it should be a valid DN - see rfc 2253 - and even that rule can be bent a bit...
e.g. store tr-d7=9gcxf7tu in /path/to/cryptic-directory-manager-dn
Note: take the same precautions as in step 1
3. Never use the same user and password between any 2 instances of Directory Server instances
e.g. dsadm create -D `echo /path/to/cryptic-directory-manager-dn` -w /path/to/cryptic-directory-manager-password -p xyz -P zyx </path/to>/instance
4. delete the cryptic password file
5. delete the cryptic dn file
6. edit </path/to>/instance/config/dse.ldif and remove the value of the nsslapd-rootpw so that its contents are blank
7. start the instance
e.g. dsadm start </path/to>/instance
Your directory manager is effectively unusable and has little to no chance of having been compromised at any point of creating or starting the instance.[ if you really want absolute security, use a small program that will quietly output a randomly-generated password to file with 600 rights ]
Note that for an already created instance, you can simply do step 5 & 6, which is nice and easy. The only addition in that case is to check that the
require-bind-pwd-enabled property is on.
$dsconf get-server-prop require-bind-pwd-enabled
require-bind-pwd-enabled : on
Since at this point your directory manager is disabled, you will need to use an account like cn=admin,cn=Administrators,cn=config as your dsconf user.
simply export LDAP_ADMIN_USER=cn=admin,cn=Administrators,cn=config or use dsconf <command> -D cn=admin,cn=Administrators,cn=config ...
When following this procedure, you will end up with a server that only has "regular" users. This is mostly good but has a handful of shortcomings, such as not being able to repair ACIs ... since now all your users, including the administration accounts, are subjected to ACIs evaluation, you could end up in a state where all your administration accounts are locked. Care must be taken to keep an administration account with well calibered Access Controls. There also some additional troubleshooting operations that mandate (per the code) be done by directory manager.