Kerberos Authorization Directory

Minimum changes to SLAPD configuration

These changes are outlined following the changes performed for a debian system, but are similar for every openldap installation.

Allow full access for root user over unix socket
```
sasl-regexp "gidNumber=0\\\+uidNumber=0,cn=peercred,cn=external,cn=auth" "cn=Administrator,dc=organization,dc=com"
rootdn      "cn=Administrator,dc=organization,dc=com"
```
NOTE: The order in which uid and gid appear on the SASL-EXTERNAL identification changes from one system to another (reversed on at least RHEL 4.6), so it is advisable to check both the EXTERNAL identification and the SASL mapping issuing the command
```
ldapwhoami -H ldapi:/// -Y EXTERNAL
```

Mapping for GSSAPI user (requires uid attribute searchable by anyone)

sasl-regexp "uid=([^,]*),cn=gssapi,cn=auth" "ldap:///ou=People,dc=organization,dc=com??sub?uid=$1"

Disable anonymous access, replacing any 'by * read' with 'by users read'

Also some decisions must be taken about which privileges are required for the Administrators group and which attributes/objectclasses can be modified by the users.
As administrators group privileges I give global write access, except for the more sensitive attributes (userPassword), thus actually forcing to modify them locally by the root user. The selection of modifiable attributes is not so clear. The schema is designed in a way that all the attributes on kadPerson class can be safely modified by the owner, except the common name, which is used on the entry dn, and have strong impact on group membership. The only extra attribute that a (unix) user can modify is the login shell.

access to attrs=entry,cn
        by group="cn=Administrators,ou=Groups,dc=organization,dc=com" write
        by users read
access to attrs=@kadPerson,loginShell
        by group="cn=Administrators,ou=Groups,dc=organization,dc=com" write
        by self write
        by users read

Besides this specific changes, other architectural changes are required

Start slapd listening also on unix sockets (ldapi:///)
Add the kad schema

Other changes

Other useful changes on slapd configuration are

Setup proper mapping for any local user using the unix socket, although they must be properly defined in the LDAP directory.

sasl-regexp "gidNumber=(.*)\\\+uidNumber=(.*),cn=peercred,cn=external,cn=auth" "ldap:///ou=People,dc=organization,dc=com??sub?kadId=$2"

Simplify the access to directory, with a default search base
```
defaultsearchbase "dc=organization,dc=com"
```
Add indexes for some attributes (uid, kadId and gidNumber)

Required entries

Appart from configuration changes, we need to add some nodes to our brand new LDAP tree. They will serve as parent for different types of entities, that will be People, Groups and Computers. Another entry will be created for Applications, with just one Kerberos sub-entry that will hold the main kerberos entries. A script to create the LDIF file for these entries (and those described below) is available here

There is also a modification of our previous ldap tree useful although not included in the above script. Adding objectclass kadRootDSE to our root entry will allow us to define a kadNextId attribute that we can use later while adding users.

Extra entries

Besides the organizational units, we need to create some other entries. The first one for the Administrator user, that will be the default member of the administrators and users group (we cannot create them without members)

dn: cn=Administrator,ou=People,dc=organization,dc=com
objectClass: kadUser
objectClass: kadUnixUser
cn: Administrator
uid: Administrator
kadId: 0
gidNumber: 0
homeDirectory: /
loginShell: /bin/sh

dn: cn=Administrators,ou=Groups,dc=organization,dc=com
objectClass: groupOfNames
objectClass: kadUnixGroup
cn: Administrators
member: cn=Administrator,ou=People,dc=organization,dc=com
gidNumber: 0

dn: cn=Users,ou=Groups,dc=organization,dc=com
objectClass: groupOfNames
objectClass: kadUnixGroup
cn: Users
member: cn=Administrator,ou=People,dc=organization,dc=com
gidNumber: 2000

Another entry that will hold the principal used to query ldap server for name services

dn: serviceName=nss-proxy,ou=Kerberos,ou=Applications,dc=organization,dc=com
objectClass: kadComputerService
serviceName: nss-proxy

And finally, we define a computer entry for our server and the ldap service (remember that our KDC is named kad)

dn: host=kad,ou=Computers,dc=organization,dc=com
objectClass: kadComputer
host: kad

dn: serviceName=ldap,host=kad,ou=Computers,dc=organization,dc=com
objectClass: kadComputerService
serviceName: ldap