Kerberos and LDAP Network Authentication

132

4. Kerberos and LDAP

Most people will not use Kerberos by itself; once an user is authenticated Kerberos, we need to figure out what this user can do authorization. And that would be the job of programs such as LDAP. Replicating a Kerberos principal database between two servers can be complicated, and adds an additional user database to your network. Fortunately, MIT Kerberos can be configured to use an LDAP directory as a principal database. This section covers configuring a primary and secondary kerberos server to use OpenLDAP for the principal database. The examples presented here assume MIT Kerberos and OpenLDAP. 4.1. Configuring OpenLDAP 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 Section 1, “OpenLDAP Server” [p. 91]. It is also required to configure OpenLDAP for TLS and SSL connections, so that traffic between the KDC and LDAP server is encrypted. See Section 1.8, “TLS” [p. 105] for details. cn=admin,cn=config is a user we created with rights to edit the ldap database. Many times it is the RootDN. Change its value to reflect your setup. • To load the schema into LDAP, on the LDAP server install the krb5-kdc-ldap package. From a terminal enter: sudo apt-get install krb5-kdc-ldap • Next, extract the kerberos.schema.gz file: sudo gzip -d usrsharedockrb5-kdc-ldapkerberos.schema.gz sudo cp usrsharedockrb5-kdc-ldapkerberos.schema etcldapschema • The kerberos schema needs to be added to the cn=config tree. The procedure to add a new schema to slapd is also detailed in Section 1.4, “Modifying the slapd Configuration Database” [p. 96]. 1. First, create a configuration file named schema_convert.conf , or a similar descriptive name, containing the following lines: include etcldapschemacore.schema include etcldapschemacollective.schema include etcldapschemacorba.schema include etcldapschemacosine.schema 133 include etcldapschemaduaconf.schema include etcldapschemadyngroup.schema include etcldapschemainetorgperson.schema include etcldapschemajava.schema include etcldapschemamisc.schema include etcldapschemanis.schema include etcldapschemaopenldap.schema include etcldapschemappolicy.schema include etcldapschemakerberos.schema 2. Create a temporary directory to hold the LDIF files: mkdir tmpldif_output 3. Now use slapcat to convert the schema files: slapcat -f schema_convert.conf -F tmpldif_output -n0 -s \ cn={12}kerberos,cn=schema,cn=config tmpcn=kerberos.ldif Change the above file and path names to match your own if they are different. 4. Edit the generated tmpcn\=kerberos.ldif file, changing the following attributes: dn: cn=kerberos,cn=schema,cn=config ... cn: kerberos And remove the following lines from the end of the file: structuralObjectClass: olcSchemaConfig entryUUID: 18ccd010-746b-102d-9fbe-3760cca765dc creatorsName: cn=config createTimestamp: 20090111203515Z entryCSN: 20090111203515.326445Z000000000000000 modifiersName: cn=config modifyTimestamp: 20090111203515Z The attribute values will vary, just be sure the attributes are removed. 5. Load the new schema with ldapadd: ldapadd -x -D cn=admin,cn=config -W -f tmpcn\=kerberos.ldif 6. Add an index for the krb5principalname attribute: ldapmodify -x -D cn=admin,cn=config -W Enter LDAP Password: dn: olcDatabase={1}hdb,cn=config add: olcDbIndex olcDbIndex: krbPrincipalName eq,pres,sub 134 modifying entry olcDatabase={1}hdb,cn=config 7. Finally, update the Access Control Lists ACL: ldapmodify -x -D cn=admin,cn=config -W Enter LDAP Password: dn: olcDatabase={1}hdb,cn=config replace: olcAccess olcAccess: to attrs=userPassword,shadowLastChange,krbPrincipalKey by dn=cn=admin,dc=example,dc=com write by anonymous auth by self write by none - add: olcAccess olcAccess: to dn.base= by read - add: olcAccess olcAccess: to by dn=cn=admin,dc=example,dc=com write by read modifying entry olcDatabase={1}hdb,cn=config Thats it, your LDAP directory is now ready to serve as a Kerberos principal database. 4.2. Primary KDC Configuration With OpenLDAP configured it is time to configure the KDC. • First, install the necessary packages, from a terminal enter: sudo apt-get install krb5-kdc krb5-admin-server krb5-kdc-ldap • Now edit etckrb5.conf adding the following options to under the appropriate sections: [libdefaults] default_realm = EXAMPLE.COM ... [realms] EXAMPLE.COM = { kdc = kdc01.example.com kdc = kdc02.example.com admin_server = kdc01.example.com admin_server = kdc02.example.com default_domain = example.com database_module = openldap_ldapconf } ... [domain_realm] .example.com = EXAMPLE.COM 135 ... [dbdefaults] ldap_kerberos_container_dn = dc=example,dc=com [dbmodules] openldap_ldapconf = { db_library = kldap ldap_kdc_dn = cn=admin,dc=example,dc=com this object needs to have read rights on the realm container, principal container and realm sub-trees ldap_kadmind_dn = cn=admin,dc=example,dc=com this object needs to have read and write rights on the realm container, principal container and realm sub-trees ldap_service_password_file = etckrb5kdcservice.keyfile ldap_servers = ldaps:ldap01.example.com ldaps:ldap02.example.com ldap_conns_per_server = 5 } Change example.com, dc=example,dc=com, cn=admin,dc=example,dc=com, and ldap01.example.com to the appropriate domain, LDAP object, and LDAP server for your network. • Next, use the kdb5_ldap_util utility to create the realm: sudo kdb5_ldap_util -D cn=admin,dc=example,dc=com create -subtrees \ dc=example,dc=com -r EXAMPLE.COM -s -H ldap:ldap01.example.com • Create a stash of the password used to bind to the LDAP server. This password is used by the ldap_kdc_dn and ldap_kadmin_dn options in etckrb5.conf : sudo kdb5_ldap_util -D cn=admin,dc=example,dc=com stashsrvpw -f \ etckrb5kdcservice.keyfile cn=admin,dc=example,dc=com • Copy the CA certificate from the LDAP server: scp ldap01:etcsslcertscacert.pem . sudo cp cacert.pem etcsslcerts And edit etcldapldap.conf to use the certificate: TLS_CACERT etcsslcertscacert.pem The certificate will also need to be copied to the Secondary KDC, to allow the connection to the LDAP servers using LDAPS. 136 You can now add Kerberos principals to the LDAP database, and they will be copied to any other LDAP servers configured for replication. To add a principal using the kadmin.local utility enter: sudo kadmin.local Authenticating as principal rootadminEXAMPLE.COM with password. kadmin.local: addprinc -x dn=uid=steve,ou=people,dc=example,dc=com steve WARNING: no policy specified for steveEXAMPLE.COM; defaulting to no policy Enter password for principal steveEXAMPLE.COM: Re-enter password for principal steveEXAMPLE.COM: Principal steveEXAMPLE.COM created. There should now be krbPrincipalName, krbPrincipalKey, krbLastPwdChange, and krbExtraData attributes added to the uid=steve,ou=people,dc=example,dc=com user object. Use the kinit and klist utilities to test that the user is indeed issued a ticket. If the user object is already created the -x dn=... option is needed to add the Kerberos attributes. Otherwise a new principal object will be created in the realm subtree. 4.3. Secondary KDC Configuration Configuring a Secondary KDC using the LDAP backend is similar to configuring one using the normal Kerberos database. 1. First, install the necessary packages. In a terminal enter: sudo apt-get install krb5-kdc krb5-admin-server krb5-kdc-ldap 2. Next, edit etckrb5.conf to use the LDAP backend: [libdefaults] default_realm = EXAMPLE.COM ... [realms] EXAMPLE.COM = { kdc = kdc01.example.com kdc = kdc02.example.com admin_server = kdc01.example.com admin_server = kdc02.example.com default_domain = example.com database_module = openldap_ldapconf } ... [domain_realm] .example.com = EXAMPLE.COM 137 ... [dbdefaults] ldap_kerberos_container_dn = dc=example,dc=com [dbmodules] openldap_ldapconf = { db_library = kldap ldap_kdc_dn = cn=admin,dc=example,dc=com this object needs to have read rights on the realm container, principal container and realm sub-trees ldap_kadmind_dn = cn=admin,dc=example,dc=com this object needs to have read and write rights on the realm container, principal container and realm sub-trees ldap_service_password_file = etckrb5kdcservice.keyfile ldap_servers = ldaps:ldap01.example.com ldaps:ldap02.example.com ldap_conns_per_server = 5 } 3. Create the stash for the LDAP bind password: sudo kdb5_ldap_util -D cn=admin,dc=example,dc=com stashsrvpw -f \ etckrb5kdcservice.keyfile cn=admin,dc=example,dc=com 4. Now, on the Primary KDC copy the etckrb5kdc.k5.EXAMPLE.COM Master Key stash to the Secondary KDC. Be sure to copy the file over an encrypted connection such as scp, or on physical media. sudo scp etckrb5kdc.k5.EXAMPLE.COM stevekdc02.example.com:~ sudo mv .k5.EXAMPLE.COM etckrb5kdc Again, replace EXAMPLE.COM with your actual realm. 5. Back on the Secondary KDC, restart the ldap server only, sudo service slapd restart 6. Finally, start the krb5-kdc daemon: sudo etcinit.dkrb5-kdc start 7. Verify the two ldap servers and kerberos by extension are in sync. You now have redundant KDCs on your network, and with redundant LDAP servers you should be able to continue to authenticate users if one LDAP server, one Kerberos server, or one LDAP and one Kerberos server become unavailable. 138 4.4. Resources • The Kerberos Admin Guide 57 has some additional details. • For more information on kdb5_ldap_util see Section 5.6 58 and the kdb5_ldap_util man page 59 . • Another useful link is the krb5.conf man page 60 . • Also, see the Kerberos and LDAP 61 Ubuntu wiki page. 57 http:web.mit.eduKerberoskrb5-1.6krb5-1.6.3dockrb5-admin.htmlConfiguring-Kerberos-with-OpenLDAP-back_002dend 58 http:web.mit.eduKerberoskrb5-1.6krb5-1.6.3dockrb5-admin.htmlGlobal-Operations-on-the-Kerberos-LDAP-Database 59 http:manpages.ubuntu.commanpagespreciseenman8kdb5_ldap_util.8.html 60 http:manpages.ubuntu.commanpagespreciseenman5krb5.conf.5.html 61 https:help.ubuntu.comcommunityKerberoskerberos-ldap 139

Chapter 8. Domain Name Service DNS