We are going to install the OpenLDAP server on the same host as the KDC, to simplify the communication between them. In such a setup, we can use theldapi:/// transport, which is via an unix socket, and don’t need to setup SSL certificates to secure the communication between the Kerberos services and OpenLDAP.
Note, however, that SSL is still needed for the OpenLDAP replication. See LDAP with TLS for details.
If you want to use an existing OpenLDAP server that you have somewhere else, that’s of course also possible, but keep in mind that you should then use SSL for the communication between the KDC and this OpenLDAP server.
First, the necessary schema needs to be loaded on an OpenLDAP server that has network connectivity to the Primary and Secondary KDCs. The rest of this section assumes that you also have LDAP replication configured between at least two servers. For information on setting up OpenLDAP see OpenLDAP Server.
Note
cn=admin,dc=example,dc=com is a default admin user that is created during the installation of the slapd package (the OpenLDAP server). The domain component will change for your server, so adjust accordingly.
• Install the necessary packages (it’s assumed that OpenLDAP is already installed):
sudo apt i n s t a l l krb5−kdc−l d a p krb5−admin−s e r v e r
• Next, extract the kerberos.schema.gz file:
sudo cp / u s r / s h a r e / doc / krb5−kdc−l d a p / k e r b e r o s . schema . gz / e t c / l d a p / schema / sudo g u n z i p / e t c / l d a p / schema / k e r b e r o s . schema . gz
• Thekerberosschema needs to be added to the cn=configtree. This schema file needs to be converted to LDIF format before it can be added. For that we will use a helper tool, called schema2ldif, provided by the package of the same name which is available in the Universe archive:
sudo apt i n s t a l l s c h e m a 2 l d i f
• To import the kerberos schema, run:
$ sudo ldap−schema−manager −i k e r b e r o s . schema SASL/EXTERNAL a u t h e n t i c a t i o n s t a r t e d
SASL username : gidNumber=0+uidNumber=0, cn=p e e r c r e d , cn=e x t e r n a l , cn=auth SASL SSF : 0
e x e c u t i n g ’ ldapadd −Y EXTERNAL −H l d a p i : / / / −f / e t c / l d a p / schema / k e r b e r o s . l d i f ’
SASL/EXTERNAL a u t h e n t i c a t i o n s t a r t e d
SASL username : gidNumber=0+uidNumber=0, cn=p e e r c r e d , cn=e x t e r n a l , cn=auth SASL SSF : 0
adding new e n t r y ” cn=k e r b e r o s , cn=schema , cn=c o n f i g ”
• With the new schema loaded, let’s index an attribute often used in searches:
$ sudo l d a p m o d i f y −Q −Y EXTERNAL−H l d a p i : / / / <<EOF dn : o l c D a t a b a s e ={1}mdb , cn=c o n f i g
add : olcDbIndex
olcDbIndex : krbPrincipalName eq , p r e s , sub EOF
m o d i f y i n g e n t r y ” o l c D a t a b a s e ={1}mdb , cn=c o n f i g ”
• Let’s create LDAP entries for the Kerberos administrative entities that will contact the OpenLDAP server to perform operations. There are two:
– ldap_kdc_dn: needs to have read rights on the realm container, principal container and realm sub-trees. If disable_last_success and disable_lockout are not set, however, then ldap_kdc_dn needs write access to the kerberos container just like the admin dn below.
– ldap_kadmind_dn: needs to have read and write rights on the realm container, principal container and realm sub-trees
Here is the command to create these entities:
$ ldapadd −x −D cn=admin , dc=example , dc=com −W <<EOF dn : u i d=kdc−s e r v i c e , dc=example , dc=com
u i d : kdc−s e r v i c e o b j e c t C l a s s : a c c o u n t
o b j e c t C l a s s : s i m p l e S e c u r i t y O b j e c t userPassword : {CRYPT}x
d e s c r i p t i o n : Account used f o r t h e Ke rbe r o s KDC dn : u i d=kadmin−s e r v i c e , dc=example , dc=com
u i d : kadmin−s e r v i c e o b j e c t C l a s s : a c c o u n t
o b j e c t C l a s s : s i m p l e S e c u r i t y O b j e c t userPassword : {CRYPT}x
d e s c r i p t i o n : Account used f o r t h e Ke rbe r o s Admin s e r v e r
EOF
Enter LDAP Password :
adding new e n t r y ” u i d=kdc−s e r v i c e , dc=example , dc=com”
adding new e n t r y ” u i d=kadmin−s e r v i c e , dc=example , dc=com”
Now let’s set a password for them. Note that first the tool asks for the password you want for the specified user dn, and then for the password of the cn=admin dn: $ ldappasswd -x -D cn=admin,dc=example,dc=com -W -S uid=kdc-service,dc=example,dc=com New password: <–
password you want for uid-kdc-service Re-enter new password: Enter LDAP Password: <– password for the dn specified with the -D option
Repeat for the uid=kadmin−service dn. These passwords will be needed later.
You can test these with ldapwhoami:
$ ldapwhoami −x −D u i d=kdc−s e r v i c e , dc=example , dc=com −W Enter LDAP Password :
dn : u i d=kdc−s e r v i c e , dc=example , dc=com
• Finally, update the Access Control Lists (ACL). These can be tricky, as it highly depends on what you have defined already. By default, the slapd package configures your database with the following ACLs:
o l c A c c e s s : {0} t o a t t r s=userPassword by s e l f w r i t e by anonymous auth by * none
o l c A c c e s s : {1} t o a t t r s=shadowLastChange by s e l f w r i t e by * r e a d o l c A c c e s s : {2} t o * by * r e a d
We need to insert new rules before the final to * by * read one, to control access to the Kerberos related entries and attributes:
$ sudo l d a p m o d i f y −Q −Y EXTERNAL−H l d a p i : / / / <<EOF dn : o l c D a t a b a s e ={1}mdb , cn=c o n f i g
add : o l c A c c e s s
o l c A c c e s s : {2} t o a t t r s=k r b P r i n c i p a l K e y by anonymous auth
by dn . e x a c t=”u i d=kdc−s e r v i c e , dc=example , dc=com” r e a d by dn . e x a c t=”u i d=kadmin−s e r v i c e , dc=example , dc=com” w r i t e by s e l f w r i t e
by * none
−
add : o l c A c c e s s
o l c A c c e s s : {3} t o dn . s u b t r e e =”cn=krbCont ainer , dc=example , dc=com”
by dn . e x a c t=”u i d=kdc−s e r v i c e , dc=example , dc=com” r e a d by dn . e x a c t=”u i d=kadmin−s e r v i c e , dc=example , dc=com” w r i t e by * none
EOF
m o d i f y i n g e n t r y ” o l c D a t a b a s e ={1}mdb , cn=c o n f i g ”
This will make the existing {2} rule become {4}. Check with sudo slapcat −b cn=config (the output below was reformatted a bit for clarity):
o l c A c c e s s : {0} t o a t t r s=userPassword by s e l f w r i t e
by anonymous auth by * none
o l c A c c e s s : {1} t o a t t r s=shadowLastChange by s e l f w r i t e
by * r e a d
o l c A c c e s s : {2} t o a t t r s=k r b P r i n c i p a l K e y by anonymous auth by dn . e x a c t=”u i d=kdc−s e r v i c e , dc=example , dc=com” r e a d by dn . e x a c t=”u i d=kadmin−s e r v i c e , dc=example , dc=com” w r i t e by s e l f w r i t e
by * none
o l c A c c e s s : {3} t o dn . s u b t r e e =”cn=krbCont ainer , dc=example , dc=com”
by dn . e x a c t=”u i d=kdc−s e r v i c e , dc=example , dc=com” r e a d by dn . e x a c t=”u i d=kadmin−s e r v i c e , dc=example , dc=com” w r i t e by * none
o l c A c c e s s : {4} t o * by * r e a d
That’s it, your LDAP directory is now ready to serve as a Kerberos principal database.