Luc de Louw's Blog

Kerberos and LDAP are today’s way of single sign on. It is platform independent and supported by a wide range of applications.

Together with the Red Hat Directory Server (also available as CentOS Directory Server and 389 Directory Server from Fedora) you can build a neat identity management infrastructure.

Setting up the Directory Server
However there are some pitfalls when installing such a integrated solution. Installing redhat-ds is quite easy, just ensure you define your planned LDAP Namespace and default LDAP Suffix before running setup-ds-admin.pl. If you plan to setup a replica, run the script with the -k parameter: setup-ds-admin.pl -k. The servers configuration will be saved as /tmp/setup*.inf and can be used to setup the replica after changing the FullMachineName and ServerIdentifier.

In my example I used the DN “cn=Directory Manager. As base I used dc=ldap,dc=example,dc=com. This is the Internet Domain Suffix style of naming an LDAP space. The older X500 style should not be used anymore.

Have a look to man openldap.conf to see how to shorten your CLI entries such as ldapsearch -x.

Setting up Kerberos
After setting the right configurations in your /etc/krb5.conf (the sample content is self-explanatory) and its distribution, you need to initialize your key store database. This is to be done with kdb_util as follows:

[root@server]# kdb5_util create -r EXAMPLE.COM -s
Loading random data
Initializing database '/var/kerberos/krb5kdc/principal' for realm 'EXAMPLE.COM',
master key name 'K/M@EXAMPLE.COM'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key:
Re-enter KDC database master key to verify:
[root@server]#

Keep in mind! Kerberos Realms are all uppercase to distinguish them from DNS names!

In the config file for the Key Distribution Center /var/kerberos/krb5kd/kdc.conf add the following in Realm Stanza: default_principal_flags =+ preauth. This will enhance security or your Kerberos Infrastructure. Also change the example Realm to what you are going to plan to use. In /var/kerberos/krb5kd/ kadm5.acl you can define the ACLs for e.g. admins or service desk employees etc. Also check the correctness of the Realm.

Feed the keystore

Now it is time to feed the database with the first principal: root. We also can create our first host principal at the same time.
Fire up kadmin.local. The kadmin.local app accesses directly the DB files on the server. Its should only be used on initial setup. Later on you will have kadmin which also works on the net, of course with Kerberos authentication.

[root@server ~]# kadmin.local
Authenticating as principal root/admin@EXAMPLE.COM with password.
kadmin.local:  addprinc root/admin
WARNING: no policy specified for root/admin@EXAMPLE.COM; defaulting to no policy
Enter password for principal "root/admin@EXAMPLE.COM":
Re-enter password for principal "root/admin@EXAMPLE.COM":
Principal "root/admin@EXAMPLE.COM" created.
kadmin.local:  addprinc -randkey host/server1.example.com
WARNING: no policy specified for host/server1.example.com@EXAMPLE.COM; defaulting to no policy
Principal "host/server1.example.com@EXAMPLE.COM" created.
kadmin.local:  q
[root@server ~]#

After starting the kadmin and kdc services you can access the admin server with the normal kamin tool.

service kadmin start
chkconfig kadmin on
service krb5kdc start
chkconfig krb5kdc on

Now we need to create a host principal for each to be kerberized host and store it in its keytab.

End of Part I

What comes in Part II?

• LDAP Service Principal
• Getting Kerberos and LDAP working together
• Migrating users from /etc/passwd to LDAP
• Playing with PAM

Have fun!