Configuring Kerberos master-slave KDC with LDAP master-replica topology on AIX
http://www.ibm.com/developerworks/aix/library/au-ldap_master_replica/index.html
Introduction
In a Kerberos production environment, it is a best practice to use an LDAP (Lightweight Directory Access Protocol) directory to store the Kerberos principal and policy information. This allows the Kerberos administrator to centrally manage and monitor the Kerberos data.
In the Kerberos setup, along with the master KDC (Key Distribution Center), it is always advisable to have more than one slave KDC, which will support the master KDC to render round-the-clock availability and constant support for the authentication service and other kerberized services (for example, AIX® NFS v4, SSH, telnet, and more).
When using the LDAP directory, it is very common to have one master LDAP server and a few other LDAP replica servers, so as to achieve the load-balancing and high availability of the directory data.
A typical Kerberos production environment usually has both of the above configurations together, which means it may have a Kerberos master-slave KDC setup along with the LDAP master-replica setup. And it takes an expert Kerberos administrator to set up this type of configuration. This article deals with configuring one such environment.
Example setup
This article will use IBM® Network Authentication Service (IBM NAS) for the Kerberos and IBM Tivoli® Directory Server 6.1 (ITDS) for the LDAP directory server on the AIX platform.
The configuration of LDAP master and replica servers is out of the scope of this article. Please refer to your LDAP documentation for that specific information. This article references the following LDAP setup:
Figure 1. Example setup for LDAP master-replica topology
The following information pertains to the Kerberos setup.
Kerberos Administrator Name:
admin/admin
Kerberos Realm Name:
TEST
IBM NAS 1.4.0.7 Master KDC:
Hostname: master.in.ibm.com Port: 88
IBM NAS 1.4.0.7 Administration Server:
Hostname: master.in.ibm.com Port: 749
IBM NAS 1.4.0.7 Slave KDC:
Hostname: slave.in.ibm.com Port: 88
IBM NAS 1.4.0.7 client configured to the Master KDC:
Hostname: client.in.ibm.com
IBM Tivoli Directory Server v6.1 (LDAP master servers):
Hostname: lmaster1.in.ibm.com Port: 389
Hostname: lmaster2.in.ibm.com Port: 389
IBM Tivoli Directory Server v6.1 (LDAP replica servers):
Hostname: replica1.in.ibm.com Port: 389
Hostname: replica2.in.ibm.com Port: 389
Hostname: replica3.in.ibm.com Port: 389
All of these machines use IBM NAS version 1.4.0.7. You can get it either from the AIX Expansion Pack CDs or from the IBM AIX Web Download Pack Programs. (see Resources).
Figure 2 shows the Kerberos setup that will be achieved at the end of this article.
Figure 2. Example setup for Kerberos master-slave KDC configuration
Configuration steps
This section covers the necessary steps that an administrator needs to carry out to set up the above Kerberos configuration.
Since the master KDC and administration servers need the read-write copy of the principal database to make the required changes, you are going to configure the master KDC with the LDAP masters. If one LDAP master server is down, there needs to be a backup LDAP master server (with the latest updated copy of the principal database), which will take charge immediately. For this reason, you will use two LDAP master servers with peer-to-peer replication configuration, so that the changes made to one master server will be immediately reflected to the other.
On the other hand, the slave KDCs can work with the read-write and read-only copies of the Kerberos principal database. Since the slave KDC is meant for backing up the master KDC in an emergency, the slave KDC might need to use the read-write copy. That is the reason that you will configure the slave KDC primarily with the master LDAP servers and with the LDAP replica as a fallback mechanism. So even if both the LDAP master servers are down, the slave KDC should continue its service by using the LDAP replicas.
Preparing the LDAP servers for Kerberos
In order to make use of any LDAP server to store Kerberos data, there are few preparations that need to be done on the LDAP server.
- Adding the proper suffix. In the LDAP directory, a suffix is a top-level entry in LDAP directory hierarchy, under which all the logically related information is stored. So, even for the Kerberos information, you will use a suffix. For example, "ou=india, o=ibm, c=in" is the suffix that is used in this article. The LDAP server can have multiple suffixes, with each suffix denoting a specific directory hierarchy.
- Loading Kerberos schema. In order to store the Kerberos data in any LDAP server (master or replica), the adequate Kerberos schema definitions should be loaded first in the LDAP directory. Only after doing this will the Kerberos data be understood and properly stored by the LDAP server. IBM NAS 1.4 ships the Kerberos schema definitions as LDIF (LDAP Data Interchange Format) file. These files are:
/usr/krb5/ldif/IBM.KRB.schema.ldiffor IBM Directory Server 5.1 and 5.2/usr/krb5/ldif/NS5.KRB.schema.ldiffor SunONE Directory Server 5.1 and 5.2You can use the ldapadd or ldapmodify commands to load the schema definition in the LDAP server. Please consult your LDAP documentation for more options and a detailed description of these commands.
- Loading realm entry. The IBM NAS principal database is represented by a realm entry. This realm entry acts as the base for storing the Kerberos principal and policy information. This realm entry is comprised of the realm name and the suffix. In the example setup, you will add the realm entry
krbrealmName-V2=TEST,ou=india,o=ibm,c=in. IBM NAS ships a template realm entry LDIF file, which can be edited to reflect the actual realm information. This file is installed by the name/usr/krb5/ldif/realm_add.ldif.
Since this article emphasizes the Kerberos configuration, it assumes that the LDAP setup is already present as shown in the example setup. For now, the article will concentrate on the Kerberos configuration steps.
The whole Kerberos configuration process can be logically divided into the following major steps:
- Configuration of master KDC with the LDAP master servers
- Configuration of slave KDC with the LDAP master and replica servers
- Configuration and use of the IBM NAS client to test the setup and test the fail-safe mechanism when the master KDC or LDAP master servers are down
Configuration of master KDC with the LDAP master servers
As stated earlier, you will configure the master KDC with two LDAP master servers and with no LDAP replica servers.
- To configure the master KDC, you can use either the IBM NAS command
/usr/krb5/sbin/config.krb5or the AIX command wrappermkkrb5srv. Use themkkrb5srvcommand to configure the master KDC with the master LDAP server. On the master KDC machine, run themkkrb5ksrv, as shown below:bash-2.05b# mkkrb5srv -r TEST -d in.ibm.com -a admin/admin -l lmaster1.in.ibm.com -u cn=admin -p adminpwd Fileset Level State Description ---------------------------------------------------------------------------- Path: /usr/lib/objrepos krb5.server.rte 1.4.0.7 COMMITTED Network Authentication Service Server Path: /etc/objrepos krb5.server.rte 1.4.0.7 COMMITTED Network Authentication Service Server The -s option is not supported. The administration server will be the local host. Initializing configuration... Creating /etc/krb5/krb5_cfg_type... Creating /etc/krb5/krb5.conf... Creating /var/krb5/krb5kdc/kdc.conf... Creating database files... Initializing database 'LDAP' for realm 'TEST' master key name 'K/M@TEST' Attempting to bind to one or more LDAP servers. This may take a while... You are prompted for the database Master Password. It is important that you DO NOT FORGET this password. Enter database Master Password: Re-enter database Master Password to verify: Attempting to bind to one or more LDAP servers. This may take a while... WARNING: no policy specified for admin/admin@TEST; defaulting to no policy. Note that policy may be overridden by ACL restrictions. Enter password for principal "admin/admin@TEST": Re-enter password for principal "admin/admin@TEST": Principal "admin/admin@TEST" created. Creating keytable... Attempting to bind to one or more LDAP servers. This may take a while... Creating /var/krb5/krb5kdc/kadm5.acl... Starting krb5kdc... Attempting to bind to one or more LDAP servers. This may take a while... krb5kdc was started successfully. Starting kadmind... Attempting to bind to one or more LDAP servers. This may take a while... kadmind was started successfully. The command completed successfully. Restarting kadmind and krb5kdc Attempting to bind to one or more LDAP servers. This may take a while... Attempting to bind to one or more LDAP servers. This may take a while... bash-2.05b#
Now the master KDC is up and running, but only this master KDC to one LDAP master server. In order to configure with another LDAP master server, you need to manually edit the KDC LDAP configuration file
/var/krb5/krb5kdc/.kdc_ldap_data. - To add another LDAP master server, edit the
/var/krb5/krb5kdc/.kdc_ldap_datafile as shown below (the highlighted text is being added now).bash-2.05b# cat /var/krb5/krb5kdc/.kdc_ldap_data [ldapdefaults] realm = TEST bind_dn = cn=admin bind_dn_pw = adminpwd ldapserver = lmaster1.in.ibm.com ldapserver = lmaster2.in.ibm.com bind_type = simple #LDAP_OPT_REFERRALS = 1 #LDAP_OPT_DEBUG = 0 #LDAP_OPT_DEREF = 0 #LDAP_OPT_TIMELIMIT = 300 #LDAP_OPT_SIZELIMIT = 0 #LDAP_OPT_SSL_TIMEOUT = 43200 #LDAP_OPT_REFHOPLIMIT = 10 [servers] lmaster1.in.ibm.com = { port = 389 replica_type = readwrite preference = 9 } lmaster2.in.ibm.com = { port = 389 replica_type = readwrite preference = 4 } bash-2.05b#
The
preferencerelation in the above box shows the priority number while connecting to any LDAP server. The higher the value, the higher the priority. If the preference value is same for two servers, then the load balancing is used to determine which server to read and search from. - Once you have finished editing the file, you must restart both the Kerberos daemons:
bash-2.05b# /usr/krb5/sbin/stop.krb5; /usr/krb5/sbin/start.krb5 Stopping /usr/krb5/sbin/krb5kdc... /usr/krb5/sbin/krb5kdc was stopped successfully. Stopping /usr/krb5/sbin/kadmind... /usr/krb5/sbin/kadmind was stopped successfully. The command completed successfully. Starting krb5kdc... krb5kdc was started successfully. Starting kadmind... kadmind was started successfully. The command completed successfully. bash-2.05b#
- The master KDC is now configured with the two LDAP master servers. To test this configuration, stop one master LDAP server and try performing some Kerberos requests (like kinit, klist, or kadmin). The master KDC should never panic in this case and transmission from one LDAP server to another should be seamless from the end-users' point of view.
Configuration of slave KDC with the LDAP master and replica servers
Now configure the slave KDC with the two LDAP master servers and three LDAP replica servers.
- Use the
/usr/krb5/sbin/config.krb5command to configure the slave KDC.bash-2.05b# /usr/krb5/sbin/config.krb5 -E -d in.ibm.com -r TEST -s master.in.ibm.com -l lmaster1.in.ibm.com -u admin -p admin_pswd -R replica1.in.ibm.com replica2.in.ibm.com replica3.in.ibm.com Initializing configuration... Creating /etc/krb5/krb5_cfg_type... Creating /etc/krb5/krb5.conf... Creating /var/krb5/krb5kdc/kdc.conf... Password for admin/admin@TEST: Starting krb5kdc... Attempting to bind to one or more LDAP servers. This may take a while... krb5kdc was started successfully. The command completed successfully. bash-2.05b#
A few things to note in the command are:
- Only a krb5kdc daemon will be running at the slave machine, because a slave KDC never runs an administration server (kadmind).
- There is no database propagation. Since you are storing the Kerberos data in the LDAP directory, there is no need to propagate data from the master KDC to the slave KDC.
- Please note that right now the slave KDC is configured to one LDAP master server and three replicas with the default preference values. You need to add another LDAP master server manually. For this, edit the
/var/krb5/krb5kdc/.kdc_ldap_datafile and insert the highlighted entries below.bash-2.05b# cat /var/krb5/krb5kdc/.kdc_ldap_data [ldapdefaults] realm = TEST bind_dn = cn=admin bind_dn_pw = adminpwd ldapserver = replica1.in.ibm.com ldapserver = replica2.in.ibm.com ldapserver = replica2.in.ibm.com ldapserver = lmaster1.in.ibm.com ldapserver = lmaster2.in.ibm.com bind_type = simple #LDAP_OPT_REFERRALS = 1 #LDAP_OPT_DEBUG = 0 #LDAP_OPT_DEREF = 0 #LDAP_OPT_TIMELIMIT = 300 #LDAP_OPT_SIZELIMIT = 0 #LDAP_OPT_SSL_TIMEOUT = 43200 #LDAP_OPT_REFHOPLIMIT = 10 [servers] replica1.in.ibm.com = { port = 389 replica_type = readonly preference = 5 } replica2.in.ibm.com = { port = 389 replica_type = readonly preference = 5 } replica3.in.ibm.com = { port = 389 replica_type = readonly preference = 5 } lmaster1.in.ibm.com = { port = 389 replica_type = readwrite preference = 4 } lmaster2.in.ibm.com = { port = 389 replica_type = readwrite preference = 4 } bash-2.05b#
- Restart the Kerberos daemon by using stop.krb5 and start.krb5:
bash-2.05b# /usr/krb5/sbin/stop.krb5 krb5kdc; /usr/krb5/sbin/start.krb5 krb5kdc Stopping /usr/krb5/sbin/krb5kdc... /usr/krb5/sbin/krb5kdc was stopped successfully. The command completed successfully. Starting krb5kdc... krb5kdc was started successfully. The command completed successfully. bash-2.05b#
- The slave KDC is all set to assist the master KDC to handle the client requests. Check the configuration by configuring a client to this slave KDC and running the IBM NAS commands like kinit, klist, and kadmin.
Configure and use IBM NAS client to test the setup
Now you are going to set up a Kerberos client to the above master-slave KDC setup that you have successfully configured. To configure a client, you can use either config.krb5 (an IBM NAS command) or mkkrb5clnt (an AIX wrapper). By using mkkrb5clnt, you can also configure an integrated Kerberized login for the AIX machine along with the IBM NAS client in a single command. But, executing mkkrb5clnt requires more understanding of a few things. For now, use config.krb5 to configure a simple IBM NAS client to the above configuration of master-slave KDCs.
- Run
/usr/krb5/sbin/config.krb5as shown below to configure the client:bash-2.05b# /usr/krb5/sbin/config.krb5 -c -d in.ibm.com -r TEST -c master.in.ibm.com -s master.in.ibm.com Initializing configuration... Creating /etc/krb5/krb5_cfg_type... Creating /etc/krb5/krb5.conf... The command completed successfully. bash-2.05b#
- You only have one KDC (master.in.ibm.com) listed in the /etc/krb5/krb5.conf file. Edit this file and make another KDC entry for the slave KDC (slave.in.ibm.com) as shown below:
-bash-2.05b# cat /etc/krb5/krb5.conf [libdefaults] default_realm = TEST default_keytab_name = FILE:/etc/krb5/krb5.keytab default_tkt_enctypes = des3-cbc-sha1 arcfour-hmac aes256-cts des-cbc-md5 des-cbc-crc default_tgs_enctypes = des3-cbc-sha1 arcfour-hmac aes256-cts des-cbc-md5 des-cbc-crc [realms] TEST = { kdc = master.in.ibm.com:88 kdc = slave.in.ibm.com:88 admin_server = master.in.ibm.com:749 default_domain = in.ibm.com } [domain_realm] .in.ibm.com = TEST master.in.ibm.com = TEST slave.in.ibm.com = TEST [logging] kdc = FILE:/var/krb5/log/krb5kdc.log admin_server = FILE:/var/krb5/log/kadmin.log default = FILE:/var/krb5/log/krb5lib.log -bash-2.05b#
- Now you are all set to test the configuration. Use the
/usr/krb5/bin/kinitand/usr/krb5/bin/klistcommands to test whether the client can contact KDC or not.bash-2.05b# /usr/krb5/bin/kinit admin/admin Password for admin/admin@TEST: bash-2.05b# /usr/krb5/bin/klist Ticket cache: FILE:/var/krb5/security/creds/krb5cc_0 Default principal: admin/admin@TEST Valid starting Expires Service principal 05/09/08 07:08:53 05/10/08 07:08:51 krbtgt/TEST@TEST bash-2.05b#
- You can also test the connection to kadmind by running the
/usr/krb5/sbin/kadmincommand.bash-2.05b# /usr/krb5/sbin/kadmin -p admin/admin Authenticating as principal admin/admin with password. Password for admin/admin@TEST: kadmin: getprincs K/M@TEST admin/admin@TEST kadmin/admin@TEST kadmin/changepw@TEST kadmin/history@TEST krbtgt/TEST@TEST kadmin: q bash-2.05b#
To test the fail-safe machanism, you can try shutting down either the slave / master KDC or LDAP servers. The above configured client can follow these fail-over paths in case of failure of any server:
Figure 3. Possible fail-over paths for IBM NAS client
Finally, you are able to successfully configure IBM NAS master-slave KDC with LDAP master-replica topology.
Conclusion
This article shows you the configuration of the Kerberos master-slave KDC duo with the LDAP master-replica setup. Though not an easy task, this article provides a step-by-step guide along with the adequate examples to make ensure that everything runs smoohtly.
Resources
Learn
- Configuring AIX 5L for Kerberos Based Authentication Using IBM Network Authentication Service: Read this white paper to learn about using Kerberos as an alternative authentication mechanism to AIX.
- A Kerberos Primer (developerWorks, Nov 2001): This article introduces Kerberos technology and Distributed Computing Environment-based applications.
- AIX and UNIX : Want more? The developerWorks AIX and UNIX zone hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials.
- developerWorks technical events and webcasts: Stay current with developerWorks technical events and webcasts.
Get products and technologies
- IBM Network Authentication Service for AIX: Download the IBM Network Authentication Service for AIX from IBM AIX Web Download Pack Programs.
- IBM Network Authentication Service for Linux,Solaris: Download the IBM Network Authentication Service for Linux,Solaris from here.
- IBM GUI-based Administration Tool for Network Authentication Service: Experience the GUI to perform the IBM NAS related administration tasks. Download from the IBM alphaWorks today.
- AIX 5L Expansion Pack and Web Download Pack: Start downloading now.
About the author
Vipin Rathor has been with IBM India System and Technology Lab for three years. He works for IBM Network Authentication Service Development and Support activities. His areas of interest include network security, particularly Kerberos and other authentication protocols
=========
https://help.ubuntu.com/10.04/serverguide/kerberos-ldap.html
Kerberos and 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.
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 the section called “OpenLDAP Server”.
It is also required to configure OpenLDAP for TLS and SSL connections, so that traffic between the KDC and LDAP server is encrypted. See the section called “TLS and SSL” for details.
-
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.gzfile:sudo gzip -d /usr/share/doc/krb5-kdc-ldap/kerberos.schema.gz sudo cp /usr/share/doc/krb5-kdc-ldap/kerberos.schema /etc/ldap/schema/
-
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 the section called “Further Configuration”.
-
First, create a configuration file named
schema_convert.conf, or a similar descriptive name, containing the following lines:include /etc/ldap/schema/core.schema include /etc/ldap/schema/collective.schema include /etc/ldap/schema/corba.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/duaconf.schema include /etc/ldap/schema/dyngroup.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/java.schema include /etc/ldap/schema/misc.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/openldap.schema include /etc/ldap/schema/ppolicy.schema include /etc/ldap/schema/kerberos.schema
-
Create a temporary directory to hold the LDIF files:
mkdir /tmp/ldif_output -
Now use slapcat to convert the schema files:
slapcat -f schema_convert.conf -F /tmp/ldif_output -n0 -s "cn={12}kerberos,cn=schema,cn=config" > /tmp/cn=kerberos.ldifChange the above file and path names to match your own if they are different.
-
Edit the generated
/tmp/cn\=kerberos.ldiffile, 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.326445Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20090111203515Z
![[Note]](http://img.e-com-net.com/image/info8/397c233e570249f7bd59eda3f3a35bbe.jpg)
The attribute values will vary, just be sure the attributes are removed.
-
Load the new schema with ldapadd:
ldapadd -x -D cn=admin,cn=config -W -f /tmp/cn\=kerberos.ldif -
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,submodifying entry "olcDatabase={1}hdb,cn=config" -
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=exampl e,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 * readmodifying entry "olcDatabase={1}hdb,cn=config"
-
That's it, your LDAP directory is now ready to serve as a Kerberos principal database.
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
/etc/krb5.confadding 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 ... [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 = /etc/krb5kdc/service.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
/etc/krb5.conf:sudo kdb5_ldap_util -D cn=admin,dc=example,dc=com stashsrvpw -f /etc/krb5kdc/service.keyfile cn=admin,dc=example,dc=com -
Copy the CA certificate from the LDAP server:
scp ldap01:/etc/ssl/certs/cacert.pem . sudo cp cacert.pem /etc/ssl/certs
And edit
/etc/ldap/ldap.confto use the certificate:TLS_CACERT /etc/ssl/certs/cacert.pem
The certificate will also need to be copied to the Secondary KDC, to allow the connection to the LDAP servers using LDAPS.
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 root/[email protected] with password.
kadmin.local: addprinc -x dn="uid=steve,ou=people,dc=example,dc=com" steve
WARNING: no policy specified for [email protected]; defaulting to no policy
Enter password for principal "[email protected]":
Re-enter password for principal "[email protected]":
Principal "[email protected]" 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. |
Secondary KDC Configuration
Configuring a Secondary KDC using the LDAP backend is similar to configuring one using the normal Kerberos database.
-
First, install the necessary packages. In a terminal enter:
sudo apt-get install krb5-kdc krb5-admin-server krb5-kdc-ldap -
Next, edit
/etc/krb5.confto 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 ... [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 = /etc/krb5kdc/service.keyfile ldap_servers = ldaps://ldap01.example.com ldaps://ldap02.example.com ldap_conns_per_server = 5 } -
Create the stash for the LDAP bind password:
sudo kdb5_ldap_util -D cn=admin,dc=example,dc=com stashsrvpw -f /etc/krb5kdc/service.keyfile cn=admin,dc=example,dc=com -
Now, on the Primary KDC copy the
/etc/krb5kdc/.k5.EXAMPLE.COMMaster 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 /etc/krb5kdc/.k5.EXAMPLE.COM [email protected]:~ sudo mv .k5.EXAMPLE.COM /etc/krb5kdc/
Again, replace EXAMPLE.COM with your actual realm.
-
Finally, start the krb5-kdc daemon:
sudo /etc/init.d/krb5-kdc start
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.
Resources
-
The Kerberos Admin Guide has some additional details.
-
For more information on kdb5_ldap_util see Section 5.6 and the kdb5_ldap_util man page.
-
Another useful link is the krb5.conf man page.
-
Also, see the Kerberos and LDAP Ubuntu wiki page.