Kerberos LDAP master-slave configuration management

Sivarami R. Chaganti (sichagan@in.ibm.com), Software Engineer, IBM

Sivarami R. Chaganti is a development support specialist on AIX with two years experience in an AIX environment, and expertise in AIX system administration and bug fixing on security modules. He has experience interfacing with customers and handling critical situations. You can reach him at sichagan@in.ibm.com.

Uma Chandolu (uchandol@in.ibm.com), Software Engineer, IBM

Uma M. Chandolu works as a Development Support Specialist on AIX. He is currently the team lead of the AIX Security Development Support team at IBM Bangalore.He has three years of extensive hands-on experience in AIX environments, and demonstrated expertise in AIX system administration and other subsystems. He has experience interfacing with customers and handling customer-critical situations. You can reach him at uchandol@in.ibm.com.

Summary: Kerberos and LDAP are designed to allow for a master/slave setup. In a centralized environment, user and group management can be handled through the LDAP/KRB5LDAP (Kerberos LDAP) protocol. This article explains how to configure KRB5LDAP (Kerberos LDAP) master/slave for KRB5LDAP clients.

Tag this!

Date: 13 Jan 2009
Level: Intermediate
PDF: A4 and Letter (40KB | 11 pages)Get Adobe® Reader®
Activity: 3161 views

Overview

KRB5LDAP clients get the user and group information from the KRB5LDAP master server. If the KRB5LDAP master is unable to respond to the KRB5LDAP client due to non-availability, then the Kerberos LDAP client sends a request to the KRB5LDAP slave to get the user and group information.

KRB5LDAP client applications are designed to attempt authentication against secondary servers if the KRB5LDAP master server is down. Therefore, administrators do not need to do any extra work during a system failure to failover Kerberos authentication service to the backup server. However, the administrative features of Kerberos do not provide for automatic failover.

Figure 1. Diagram
diagram

In the event of a Kerberos master server failure, the kadmind daemon is unavailable. Therefore, administrative functions are unavailable until the primary server is restored or replaced. Specifically, principal management, key creation, and key changes cannot be done during a Kerberos master failure.

This article uses the IBM® Tivoli® directory server (LDAP) as the database server and IBM Network Authentication Services (NAS) as the Kerberos authentication server.

Configuration

LDAP configuration

LDAP was designed to allow for a master/replica configuration. First configure the LDAP master/replica servers as follows.

Use the AIX® mksecldap command to configure the LDAP server and client. This command automatically updates LDAP information to the required LDAP configuration files. See the Resources section for information on configuring the LDAP Master-Replica topology.

Configuring the Kerberos master/slave server with the LDAP database (KRB5LDAP master/slave)

The following steps define both schema definitions to the ldap database:
Add the Kerberos schema on LDAP Master/Replica servers. NAS ships an ldif file in the /usr/krb5/ldif directory. Use the ldapmodify command to export the schema to the LDAP master/replica server.
ldapmodify uses the following syntax:
ldapmodify -h <LDAP Master hostname/ LDAP replica hostname> -D <bind dn> -w <bind passwd> -f /usr/krb5/ldif/IBM.KRB.schema.ldif -v -c
For example:
ldapmodify -h server1.in.ibm.com -D cn=admin -w adminpwd -f /usr/krb5/ldif/IBM.KRB.schema.ldif -v -c

The following steps export the Kerberos realm to the LDAP server:

NAS ships with a realm_add.ldif file and it is available in the /usr/krb5/ldif directory. Update this file with the Kerberos realm and LDAP suffix information. The modification involves the replacement of the default suffix with the LDAP suffix and the realm name should be the same as the realm that will be used during Kerberos configuration.

realm_add.ldif file

dn: <ou=Austin, o=IBM, c=US>
ou: <Austin>
objectclass: organizationalUnit

dn: krbrealmName-V2=<REALM NAME>, <ou=Austin, o=IBM, c=US>
objectclass: KrbRealm-V2
objectclass: KrbRealmExt
krbrealmName-V2: <REALM NAME>
krbprincSubtree: krbrealmName-V2=<REALM NAME>, <ou=Austin, o=IBM, c=US>
krbDeleteType: 4
krbMaxFailAuth: 0
krbDisableTimeInterval: 0

dn: cn=principal, krbrealmName-V2=<REALM NAME>, <ou=Austin, o=IBM, c=US>
objectclass: container
cn: principal

dn: cn=policy, krbrealmName-V2=<REALM NAME>, <ou=Austin, o=IBM, c=US>
objectclass: container
cn: policy

Use the ldapadd command to export this file to the LDAP master/slave servers.

ldapadd syntax

 ldapadd -h <LDAP server hostname/LDAP Replica server hostname> -D <bind dn>
 -w <bind passwd> -f /usr/krb5/ldif/realm_add.ldif -v -c

For example:

 ldapadd -h server1.in.ibm.com -D cn=admin   -w adminpwd 
-f /usr/krb5/ldif/realm_add.ldif -v -c

After exporting the Kerberos schema definition to the LDAP servers, verify it using the ldapsearch command.

ldapsearch syntax

ldapsearch -h <LDAP master/Replica hostname> -D <bind dn> -w <bind
passwd>  -b <LDAP suffix> objectclass=* | more

For example:

ldapsearch -h server1.in.ibm.com -D cn=admin -w adminpwd -b " ou=People,o=sec"
objectclass=* | more

Configure the Kerberos master server with the LDAP master server

Use the mkkrb5srv command to configure the Kerberos master server with the LDAP master server.

mkkrb5srv syntax

mkkrb5srv -r <realm> -s <KDC server> -d <Domain name>  -a <Adminitstrater name> 
 -l <LDAP master server>  -u <bind dn> -p <bind passwd>

For example:

mkkrb5srv -r TEST -s server1.in.ibm.com -d in.ibm.com -a admin/admin
-l server1.in.ibm.com -u cn=admin -p adminpwd

The mkkrb5srv command starts the krb5kdc and kadmind process. Use the ps command to verify the process.

      ps -eaf|grep KRB5

Kerberos server type information is stored in the /etc/krb5/krb5_cfg_type file. This file contains the information as either the master/slave server.

Running the mkkrb5srv command with the LDAP database results in actions similar to legacy database configuration except for database creation. Since LDAP is used as back-end storage, database files are not created on the local file system. Instead a .kdc_ldap_data file is created under /var/krb5/krb5kdc to hold information about LDAP

Configure the Kerberos slave server on the LDAP replica server

Use the config.krb5 command as follows to configure the Kerberos slave server.

config.krb5 syntax

config.krb5 -E -d <domain name> -r <realm> -s <KDC server>
 -l <LDAP replica server> -u <bind dn> -p <bind passwd>

For example:

config.krb5 -E -d in.ibm.com -r TEST -s server1.in.ibm.com -l
server2.in.ibm.com   -u cn=admin -p adminpwd

The -E option specifies that it configures the slave KDC server.

The <realm> name should be the same as the Kerberos master server.

It will start the krb5kdc daemon and verify it using the ps command:

 ps -eaf|grep KRB5

Kerberos server type information is stored in the /etc/krb5/krb5_cfg_type file. This file contains the information as either the master or the slave server. Check the type of the Kerberos server using following command:

      # cat /etc/krb5/krb5_cfg_type

Check the /etc/krb5/krb5.conf file to confirm the slave server configuration.

# 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 = Server1.in.ibm.com:88
                kdc = Server2.in.ibm.com:88
                admin_server = Server1.in.ibm.com:749 
                default_domain = in.ibm.com
                vdb_plugin_lib = /usr/lib/libkrb5ldplug.a
        }

[domain_realm]
        .in.ibm.com = TEST
        Server1.in.ibm.com = TEST
        Server2.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

In an LDAP that is used as a database server, it creates a file as .kdc_ldap_data under /var/krb5/krb5kdc to maintain the information about LDAP.

In an LDAP that is used as back-end storage, database files are not created on the local file system. Instead, a .kdc_ldap_data file is created under /var/krb5/krb5kdc to hold information about LDAP. So you have to edit the .kdc_ldap_data files in the Kerberso master and slave servers accordingly to synchronize both servers.

On the Kerberos master server, add the KDC slave entry:

           [ldapdefaults]
           realm = TEST
           bind_dn = cn=admin
           bind_dn_pw = adminpwd
           ldapserver = server1.in.ibm.com
	ldapserver = server2.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]
          server1.in.ibm.com = {
                port = 389
                replica_type = readwrite
                preference = 9
        }
        server2.in.ibm.com = {
                port = 389
                replica_type = readonly
                preference = 4
        }

On the Kerberos slave server, add the KDC master entry:

         [ldapdefaults]
        realm = TEST
        bind_dn = cn=admin
        bind_dn_pw = adminpwd
        ldapserver = server2.in.ibm.com
	 ldapserver = server1.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]
        server2.in.ibm.com = {
                port = 389
                replica_type = readonly
                preference = 9
        }

       server1.in.ibm.com = {
                port = 389
                replica_type = readwrite
                preference = 4
        }

Configuring a Kerberos client

Use the mkkrb5clnt command to configure a Kerberos client with Kerberos servers.

mkkrb5clnt syntax

 mkkrb5clnt -r  <realm> -d <domain name> {-c <KDC server> -s
<server> | -l {ldapserver | ldapserver:port}  [-c <KDC> -s <server>]} 
[-a <admin>] [-A] [-i <data base>] [-K] [-T]

mkkrb5clnt -r TEST -c server1.in.ibm.com -s server1.in.ibm.com -d in.ibm.com -i LDAP -K -T

mkkrb5clnt creates the /etc/krb5/krb5.conf file with the <realm> name, KDC server, Kerberos admin server, and domain name information.

#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]
        REDDY = {
                kdc = server1.in.ibm.com:88
                admin_server = server1.in.ibm.com:749
                default_domain = in.ibm.com
        }
[domain_realm]
        .in.ibm.com = TEST
        server1.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

Kerberos server type information is stored in the /etc/krb5/krb5_cfg_type file. This file should contain the information as "Client."

Kerberos users can be created from the Kerberos client. To create the Kerberos users the root user should have the credential. The credential can be obtained from the KDC server using the kinit command.

# /usr/krb5/bin/kinit admin/admin

Password for admin/admin@TEST:

Credential files can be verified using the /usr/krb5/bin/klist command.

On the AIX Kerberos client, Kerberos users can create using the mkuser command as follows:

# mkuser -R KRB5LDAP SYSTEM= "KRB5LDAP" registry=KRB5LDAP
<user1>

Set the password for the user using the password command and verify login.

#passwd -R KRB5LDAP <user1>

Add the slave KDC server details in the Kerberos client server

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 = server1.in.ibm.com:88
          kdc = server2.in.ibm.com:88
                admin_server = server1.in.ibm.com:749
                default_domain = in.ibm.com
        }

[domain_realm]
        .in.ibm.com = TEST
        server1.in.ibm.com = TEST
   server2.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

This fail-over mechanism can be verified as follows. Stop and shut down the LDAP master server and Kerberos master server. Run kinit from the Kerberos client machine. Also, verify that the integrated login from the client machine for any Kerberos users.

Check the /var/krb5/log/ krb5kdc.log file in Kerberos Slave server to trace the event mechanism.

Resources

Learn

AIX v 5.3 Security Guide
Setting up Tivoli Directory Server replication using the command line (developerWorks, December 2006) helps administrators understand the basics of setting up Tivoli® Directory Server (TDS) replication using the command line.
LDAP configuration management and troubleshooting on AIX (developerWorks, May 2007) provides an overview of the LDAP configuration and management.
AIX 5L LDAP user management (developerWorks, December 2006) provides an overview of the LDAP-related enhancements in the AIX 5L operating system V5.3 TL5 update.
Understanding LDAP Design and implementation: This IBM Redbook helps you create a foundation of LDAP skills, as well as install and configure the IBM Directory Server.
Integrating AIX into heterogeneous LDAP environments: This IBM Redbook is a technical planning reference for IT organizations that are adding AIX 5L clients to an existing LDAP authentication and user management environment.
Browse the technology bookstore for books on these and other technical topics.

Get products and technologies

Download IBM product evaluation versions and get your hands on application development tools and middleware products from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.

Discuss

Participate in the AIX and UNIX forums:
Check out developerWorks blogs and get involved in the developerWorks community.

About the authors

Comments (Undergoing maintenance)

Trademarks | My developerWorks terms and conditions

Close [x]

Help: Update or add to My dW interests

What's this?

This little timesaver lets you update your My developerWorks profile with just one click! The general subject of this content (AIX and UNIX, Information Management, Lotus, Rational, Tivoli, WebSphere, Java, Linux, Open source, SOA and Web services, Web development, or XML) will be added to the interests section of your profile, if it's not there already. You only need to be logged in to My developerWorks.

And what's the point of adding your interests to your profile? That's how you find other users with the same interests as yours, and see what they're reading and contributing to the community. Your interests also help us recommend relevant developerWorks content to you.

View your My developerWorks profile

Return from help

Close [x]

Help: Remove from My dW interests

What's this?

Removing this interest does not alter your profile, but rather removes this piece of content from a list of all content for which you've indicated interest. In a future enhancement to My developerWorks, you'll be able to see a record of that content.

View your My developerWorks profile

Return from help

static.content.url=http://www.ibm.com/developerworks/js/artrating/

SITE_ID=1

Zone=AIX and UNIX

ArticleID=363472

ArticleTitle=Kerberos LDAP master-slave configuration management

publish-date=01132009

author1-email=sichagan@in.ibm.com

author1-email-cc=mmccrary@us.ibm.com

author2-email=uchandol@in.ibm.com

author2-email-cc=mmccrary@us.ibm.com