Installation
We will describe a fresh install in a generic case, adding distribution specific notes where required. We have three different systems for test purposes : Debian 4.0 ( etch ) , RHAS 4.6 (
Nahant ), Centos 5.3 (
), Fedora 8 (
Werewolf ) and Ubuntu 8.04 (
Hardy ).
The very first step is to install the base software : ldap & kerberos server. The package names change from distribution to distribution:
# apt-get install slapd heimdal-kdc libsasl2-modules-gssapi-mit
# up2date -i openldap-servers krb5-server
# yum install openldap-servers krb5-server openldap-clients cyrus-sasl-gssapi
# yum install openldap-servers krb5-server-ldap
NOTE
: The RHEL and Centos releases used for test don't support LDAP backend for kerberos, so in this case actually there is no single data backend. Anyway, the describe procedure and utilities do also work, as they just hide the details of the underlying software.
NOTE
: There is a specific and automatic method to install on a debian system, which is as easy as patch control files and reconfigure.
The procedure to setup a KAD server is sligthly different from one distribution to another. We will outline below the steps for a centos server as example for RedHat derived distros, because there is an automated way for debian based distributions.
Initialize servers
Although the ldap and kerberos servers could be initialized during the package installation, they are not valid just out of the box, so they must be specially initialized.
LDAP
Server configuration
In the case of LDAP server, we must modify slapd.conf (at /etc/openldap) to load two additional schemas, the one for the kerberos-ldap backend, and the one specific for KAD.
include /etc/openldap/schema/hdb.schema include /etc/openldap/schema/kad.schema
The highly privileged access for the LDAP server will be done by using LDAPI from the root account, so we must properly configure the slapd.conf file
# Give total access for root user through ldapi protocol sasl-regexp "gidNumber=0\\\+uidNumber=0,cn=peercred,cn=external,cn=auth" "cn=administrator,dc=domain,dc=com" [...] suffix "dc=domain,dc=com" rootdn "cn=administrator,dc=domain,dc=com"
Note that this administrator is the LDAP server administrator, which dont need (and should not) be the same than the KAD administrator that we will see later, that will be a Kerberos principal and will have wide privileges, but not so much as the LDAP administrator.
This LDAPI interface must be explicitly enabled on server startup, by modifying /etc/sysconfig/ldap
SLAPD_LDAPI=yes
Once restarted, we have two different things to verify: that the LDAPI protocol works, and that the root user maps to the proper DN
# ldapwhoami -H ldapi:/// -Y EXTERNAL SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn:cn=administrator,dc=domain,dc=com Result: Success (0) # ldapsearch -H ldapi:/// -Y EXTERNAL SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 # extended LDIF # # LDAPv3 # base <> with scope subtree # filter: (objectclass=*) # requesting: ALL # # search result search: 2 result: 32 No such object # numResponses: 1
We see an empty response because the LDAP tree has not been actually populated even with the bare minimal content.
Tree population
Either if LDAP server is already populated or not, some attributes must be modified, and we also need to add some KAD specifics, as the tree skeleton and basic principals: Administrator and LDAP server.
To create an LDIF file with this structure, we must use the kadBaseLdif utility, which outputs it to stdout, and also creates a configuration file for KAD, that will be used by the other utilities. This utility requires a domain name, that will be used to construct the realm name, and the root DN for the ldap tree. There is only an optional argument (--rhel), that enables the actual creation of the root DN in the produced LDIF
# ./kadBaseLdif --rootdn domain.com > kad.ldif # ldapmodify -H ldapi:/// -Y EXTERNAL < kad.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "dc=domain,dc=com" modifying entry "dc=domain,dc=com" [...] adding new entry "serviceName=ldap,host=node0.domain.com,ou=Computers,dc=domain,dc=com" modifying entry "serviceName=ldap,host=node0.domain.com,ou=Computers,dc=domain,dc=com"
Optional configuration
NOTE : Describe also any other changes to slapd configuration such as the default base dn
Kerberos
Configuration
Although not strictly required, life will be much easier if we properly configure kerberos. First, we need to set the default_realm of /etc/krb5.conf, that must match our desired realm name (the one on /etc/kad.conf). Unless we haver properly configured DNS entries for our realm, we need to add entries on realms section in the main configuration file.
Initialization
Even if we are using the LDAP backend for kerberos, we need also to initialize the principals database
# kdb5_util -r DOMAIN.COM create -s # /etc/init.d/krb5kdc start # kadmin.local -q getprincs Authenticating as principal root/admin@DOMAIN.COM with password. K/M@DOMAIN.COM kadmin/admin@DOMAIN.COM kadmin/changepw@DOMAIN.COM kadmin/history@DOMAIN.COM kadmin/node0.domain.com@DOMAIN.COM krbtgt/DOMAIN.COM@DOMAIN.COM
And we need to finishing setting up the basic principals. If we are using a LDAP backend for kerberos, it is enough to set the passwords, but if that is not the case the principal must be just created
# kadmin.local -q 'add_principal Administrator' # kadmin.local -q 'add_principal -randkey ldap/node0.domain.com'
KAD initialization
Setting up the KAD administrator user
As the first step, we give the principal whole access to the kerberos database by editing /var/kerberos/krb5kdc/kadm5.acl
Administrator@DOMAIN.COM * *
And from now on, we can use this admin principal for any kerberos administration task, including the creation of the keytab for the LDAP server
# /etc/init.d/kadmind start # kadmin -p Administrator -q 'ktadd -k /etc/openldap/slapd.keytab ldap/node0.domain.com' # chown ldap:ldap /etc/openldap/slapd.keytab
Giving similar privileges respect to LDAP server involves two different steps. The first is to enable GSSAPI authentication on the slapd server by giving a proper keytab during startup, modifying /etc/sysconfig/ldap
export KRB5_KTNAME=/etc/openldap/slapd.keytab
The second step is to enable the mapping for GSSAPI users, giving them an distinguished name
# Map for GSSAPI users sasl-regexp "uid=([^,]*),cn=gssapi,cn=auth" "ldap:///ou=People,dc=domain,dc=com??sub?uid=$1"
and this second step has another task to be performed, which is our actual target: give administrative permission to the KAD administrator. This will be done not for the specific user, but using group membership for that purpose. And in the way, we will give some permission to modify KAD attributes to its owner.
# We want to grant write access to some objectclasses, but sensitive
# attributes must be protected in advance
access to attrs=entry,cn,kadId,gidNumber,homeDirectory
by group="cn=Administrators,ou=Groups,dc=domain,dc=com" write
by users read
access to attrs=@kadPerson,@kadUnixUser
by group="cn=Administrators,ou=Groups,dc=domain,dc=com" write
by self write
by users read
access to *
by group="cn=Administrators,ou=Groups,dc=domain,dc=com" write
by self write
by users read
by anonymous auth
And now, we have a single principal able to manage both the kerberos and LDAP server, thanks to the access rules that we have already setup for the members of the Administrators group
# /etc/init.d/ldap restart # kinit Administrator # ldapwhoami SASL/GSSAPI authentication started SASL username: Administrator@DOMAIN.COM SASL SSF: 56 SASL installing layers dn:cn=administrator,ou=people,dc=domain,dc=com Result: Success (0)
NOTE : Check about domain_realm section and hostname & principal being FQDN
