Kerberos Quick Setup

I used notes that I had from writing a course on Directory Services and Authentication to do this quick Kerberos setup. For a better install guide you may want to reference http://web.mit.edu/kerberos/www/krb5-1.7/krb5-1.7.1/doc/krb5-install.html.

Kerberos Packages from Fedora
Having gotten my LDAP working to provide user information, I wanted to go further to have Kerberos provide authentication. Here's the list of the packages I installed to get going:


The package krb5-libs was already on my system, but is a dependency of the other three. The pam_krb5 package wasn't a dependency, but without it, the ability to use authentication using Kerberos was disabled.

Configuring the Kerberos Library (Client and Server)
First, for either a client or a server, the krb5-libs need to be configured for the realm, which is sort of like a domain. Since I'm in the domain called fedora.test. here was my configuration in /etc/krb5.conf:

default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log

default_realm = FEDORA.TEST
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = yes

kdc = krb5.fedora.test:88
admin_server = krb5.fedora.test:749

.fedora.test = FEDORA.TEST
fedora.test = FEDORA.TEST

I made only a few changes to this file. Under the [realms] section, I changed the realm name from EXAMPLE.COM to FEDORA.TEST. Also, I changed the hostnames for the kdc and admin_server entries to the CNAME hostname of the machine that will be running the Kerberos service.

Beneath the [domain_realm] section, I changed all the example.com and EXAMPLE.COM entries to fedora.test and FEDORA.TEST. Don't forget to configure this file for all clients and servers that will be a part of your realm.

Configuring Access (Server)
If you want different users or principals to have different levels of access then the /var/kerberbos/krb5kdc/kadm5.acl can be used to do that. By default, it permits all admin users to have full access. The only change needed is to make sure that the realm name configured in the previous file /etc/krb5.conf is also configured in this file. So here's what I have in /var/kerberbos/krb5kdc/kadm5.acl:

*/admin@FEDORA.TEST *

Configuring the KDC (Server)

In configuring the /var/kerberos/krb5kdc/kdc.conf file, again you need to make sure that it agrees with the realm name and ports listed in the /etc/krb5.conf. If you are satisfied with the other settings, like the encryption to be used, this usually means a simple search and replace of the realm names (one more time!):

v4_mode = nopreauth
kdc_ports = 88,750
kdc_tcp_ports = 88

#master_key_type = aes256-cts
acl_file = /var/kerberos/krb5kdc/kadm5.acl
dict_file = /usr/share/dict/words
admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab
supported_enctypes = aes256-cts:normal aes128-cts:normal des3-hmac-sha1:normal arcfour-hmac:normal des-hmac-sha1:normal des-cbc-md5:normal des-cbc-crc:normal des-cbc-crc:v4 des-cbc-crc:afs3

Creating the Principal Database (Server)
If all the files are properly configured, then on the server create the database to store the principal accounts:

kdb5_util create -s

Configure root/admin Principal
The first principal that you should create will be one that you will be able to authenticate as in order to do administration of the Kerberos server. Use this command to do that:

kadmin.local -q "addprinc root/admin"

Configure Startup and Start Services
Kerberos runs as two separate services that need to be configured to start up at boot time, and you probably want to start them immediately to use them without rebooting:

# chkconfig krb5kdc on

# chkconfig kadmin on

# service krb5kdc start

# service kadmin start

Using either kadmin or kadmin.local you can then add additional principals for user and server accounts to authenticate. Servers are added as principals just like users, except the ktadd command is used to add to a keytab file (/etc/krb5.keytab) their secret credentials. This file will then need to be copied and included in the configuration of the Kerberized services:
kadmin.local: addprinc ldap/earth.fedora.test
WARNING: no policy specified for ldap/earth.fedora.test@FEDORA.TEST; defaulting to no policy
Enter password for principal "ldap/earth.fedora.test@FEDORA.TEST":
Re-enter password for principal "ldap/earth.fedora.test@FEDORA.TEST":
add_principal: Principal or policy already exists while creating "ldap/earth.fedora.test@FEDORA.TEST".
kadmin.local: ktadd ldap/earth.fedora.test
Entry for principal ldap/earth.fedora.test with kvno 2, encryption type DES cbc mode with RSA-MD5 added to keytab WRFILE:/etc/krb5.keytab.

LDAP with 389 Project and OpenLDAP

The last couple of days, I've been working with LDAP again. Yesterday, I worked with the 389 Project LDAP server from Fedora. It was easy to set up, and easy to integrate with my system authentication. I got it to work with my Apache web server, too. Unfortunately, either it is not supported or Apache doesn't like the self-signed certificate that I used, but I could not get LDAP over SSL to work.

Yet, LDAP over SSL works fine for authentication. In the past, I had trouble even getting that to work with the self-signed certificates, and had to resort to setting up a Certificate Authority on a separate machine to sign the certificate for the LDAP server. The key to making it work now, appears to be the TLS_REQCERT setting. Here's the contents of my /etc/openldap/ldap.conf

URI ldap://localhost.localdomain
BASE dc=fedora,dc=test
TLS_CACERTDIR /etc/openldap/cacerts
HOST localhost.localdomain

Today, I'm attempting to use the openldap-servers package for Fedora. The configuration appears to have changed significantly from what I've used in the past. The /etc/openldap/slapd.conf did not even exist after installation. Instead, there appear to be some auto-generated LDIF files in the /etc/openldap/slapd.d directory. There was a /etc/openldap/slapd.conf.bak file that contained the typical configuration items.

Copyin gthe /etc/openldap/slapd.conf.bak to /etc/openldap/slapd.conf, I searched and replaced the distinguished name for my domain in the suffix and rootdn entries. I used slappasswd to generate an encrypted password like this:

suffix "dc=fedora,dc=test"
rootdn "cn=Manager,dc=fedora,dc=test"
rootpw {SSHA}SqpHzAMFefEQIu4Saw5vZWwTqEZQMkiq

Likewise, I updated the database monitoring section:

# enable monitoring
database monitor

# allow onlu rootdn to read the monitor
access to *
by dn.exact="cn=Manager,dc=fedora,dc=test" read
by * none

Restarting slapd seemed to have no effect! I was attempting to verify unsuccessfully that I could authenticate as Manager using the following command:

[keith@earth fedora.test]$ ldapwhoami -x -D \ cn=Manager,dc=fedora,dc=test -W
Enter LDAP Password:
ldap_bind: Invalid credentials (49)

Reading the man page on slapd, it seems that if you invoke the daemon as follows, then it will convert your configuration file to LDIF in the /etc/openldap/slapd.d directory.

slapd -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d

Now, at last I could verify my ability to authenticate:

[keith@earth fedora.test]$ ldapwhoami -x -D \ cn=Manager,dc=fedora,dc=test -W
Enter LDAP Password:

While there are many GUI and WBI tools available for LDAP, I wanted to review and practice my CLI tools. Since it's been three years since I took the Redhat Directory Services and Authentication course RH423 and exam EX423, I've been reviewing the Directory Services course that I wrote following that experience to refresh my memory. To begin with, a root entry for the domain was needed in the Directory Information Tree (DIT).

[keith@earth fedora.test]$ ldapadd -x -D \
cn=Manager,dc=fedora,dc=test -W

Enter LDAP Password:
# root entry for Directory Information Tree
dn: dc=fedora,dc=test
objectclass: domain
dc: fedora

adding new entry "dc=fedora,dc=test"

Before adding entries for users or computers, I prepared a file for the needed organizational units and created them like this:

[keith@earth fedora.test]$ cat ou.ldif
# add entries for organizational units
dn: ou=People,dc=fedora,dc=test
objectclass: organizationalUnit
ou: People

dn: ou=Hosts,dc=fedora,dc=test
objectclass: organizationalUnit
ou: Hosts
[keith@earth fedora.test]$ ldapadd -x -D \
cn=Manager,dc=fedora,dc=test -W -f ou.ldif
Enter LDAP Password:
adding new entry "ou=People,dc=fedora,dc=test"

adding new entry "ou=Hosts,dc=fedora,dc=test"

Finally, we can begin to add leaf, or end node, entries to the tree:

[keith@earth fedora.test]$ cat keith.ldif
dn: uid=keith,ou=People,dc=fedora,dc=test
uid: keith
cn: Keith Wright
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: {crypt}$1$2OTQS7Fs$EFizXUzsCFISt9BANTDje/
shadowLastChange: 13363
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 500
gidNumber: 500
homeDirectory: /home/keith

[keith@earth fedora.test]$ ldapadd -x -D cn=Manager,dc=fedora,dc=test -W -f keith.ldif
Enter LDAP Password:
adding new entry "uid=keith,ou=People,dc=fedora,dc=test"

About Me - WrightRocket

My photo

I've worked with computers for over 30 years, programming, administering, using and building them from scratch.

I'm an instructor for technical computer courses, an editor and developer of training manuals, and an Android developer.