cn=Directory Manager

cn=Directory Manager
All about Directory Server

All | Personal | Sun

« Decoding LDAP commun... | Main | Forget your roots »

Saturday December 10, 2005

The role Directory Server was meant to play

As a Directory Server administrator, you've got a bit of a quandry at install time. For security reasons, you want the server to run using a restricted account that can't directly log into the system and has limited capabilities. But also for security reasons, you probably don't want to need root access to look at the log files, update the configuration, or take backups. Unfortunately, the Directory Server creates these files owned by the user specified in the nsslapd-localuser attribute with 0600 access permissions. And what's worse, changing the permissions or adding filesystem ACLs or setting your umask won't help because the files are explicitly created with those permissions rather than inheriting them, and all of them have files that will be rotated (the DB has transaction logs that are periodically created and removed, and whenever a config change is made, a new file is written and renamed rather than overwriting the existing dse.ldif) so the existing permissions won't be retained.

Fortunately, you can make nearly all configuration changes over LDAP (and the few remaining gaps should be filled in with the DS 6 release), so you don't even have to be logged into the system to do that. Similarly, the db2bak.pl and db2ldif.pl scripts can cause the server to initiate backups and LDIF exports over protocol as well, or you can use the nsslapd-mode configuration attribute to make them group-readable if you wish. But what about the log files? If you're willing to wait for Directory Server 6, then you will be happy to see that we've added a configuration option that will allow you to define the permissions used for the log files. But what can you do until then?

The best way of addressing these and other issues, at least on a Solaris system, is to make the Directory Server account a role rather than a standard user account. A role is a special type of account that works like a normal user in many ways, but with two notable differences:

A role cannot be used to directly log into the system. Rather, you must first log in as a normal user and then use su to assume the role (after providing the appropriate password). Not only does this provide a first line of defense, it can also help provide an audit trail because you can see exactly who is assuming that role and what they are doing.
Only authorized users are allowed to assume a role. If you're not a member of a given role, then you won't be allowed to assume that role even if you know the passowrd for it.

This addresses many of the security concerns of having the server run as an account that can actually be used because it can't directly log in and because the set of users that can assume it can be tightly controlled, and you can configure that role with tight restrictions. And because it is safe to assume the role and be able to use the shell as that account, you can do things like look at the log files or touch the configuration as necessary. There's no need for convoluted cron jobs that periodically change file permissions, nor do you need to beg the system administrators for root access if something out of the ordinary comes up. In fact, "role" is the "R" in "RBAC", a mechanism that can be used to grant roles certain capabilities that might normally need to be run as root (e.g., starting the server so that it can listen on privileged network ports). I won't get into the details of that in this post (although my next one will provide information on using least privilege in Solaris 10 to accomplish this and other things).

So how do you go about creating a role? If you're just getting ready to install the server and don't yet have an account on the system for it to use, then you can create a new role using the roleadd command. This command is virtually identical to the useradd command, with the exception that it creates a role instead of a normal user. For example, the command:

roleadd -d /export/home/dirsrv -m -s /usr/bin/bash dirsrv

will create a new role called "dirsrv" and create a home directory for it and configure it to use the bash shell by default.

On the other hand, if you've already got a normal user account that you're currently using to run the Directory Server, then you can convert it to a role with a single usermod command. For example:

usermod -K type=role dirsrv

will convert the "dirsrv" user account to a role.

Once you have a role, you need to assign it a password, which you can do with the passwd command just like any other user account (of course, if you converted the role from an existing user account and that user already had a password, then it will be retained). Then, you can add the users that need to be able to administer the server to that role, also via the usermod command. For example, the following will give the user "john" the ability to assume the "dirsrv" role:

usermod -R dirsrv john

After this, whenever the user "john" is logged into the system and needs to perform some administrative task with the Directory Server, he can just issue the command "su - dirsrv", type in the password for that role, and have the access he needs to manage the server.

Posted by cn_equals_directory_manager ( Dec 10 2005, 04:42:59 PM CST ) Permalink

Comments: