Kerberos bind to LDAP server

4.4.2 Kerberos bind to LDAP server

This section discusses steps to diagnose problems with the AIX 5L LDAP client daemon, binding to the LDAP server using Kerberos. For more information about

using the AIX Network Authorization Service (NAS) client refer to the AIX 5L Version 5.3 Security Guide or Chapter 8, “Scenario: Microsoft Windows 2003 Active Directory integration” on page 217. The Microsoft Active Directory chapter covers the NAS client configuration to authenticate against a Windows Kerberos Key Distribution Center (KDC). Figure 4-1 shows a flow chart of the suggested decision path for resolving Kerberos bind problems.

Figure 4-1 LDAP client daemon Kerberos bind problem determination AIX 5L LDAP Client Daemon

Verify time is synchronized

Whenever you have problems with Kerberos, the first thing you should always check is that the system clocks on the LDAP clients and servers and the KDC are synchronized.

In order to prevent malicious users from replaying network traffic to authenticate to the KDC as legitimate users, Kerberos servers will automatically discard all authentication requests over the allowable clock skew of 300 seconds. If your clocks are not synchronized, you can synchronize your clocks and use Network Time Protocol (NTP) to maintain clock synchronization. For more information about setting up the AIX 5L NTP client refer to “Set up time synchronization” on page 220.

Verify AIX 5L NAS client is installed and configured

In order for any Kerberos authentication to work the AIX 5L NAS client must be installed and configured. Example 4-29 shows how to use the lslpp command to verify that the AIX 5L NAS client file sets are installed. If the NAS client is not installed, then refer to the AIX 5L Security Guide for installation and configuration instructions.

Example 4-29 Verifying that the AIX 5L NAS client is installed

# lslpp -l "krb5*"

Fileset Level State Description

---Path: /usr/lib/objrepos

krb5.client.rte 1.4.0.3 COMMITTED Network Authentication Service Client

Attention: There is a known problem with the AIX 5L Version 5.3 LDAP client binding with Kerberos to an Active Directory server. IBM is aware of the problem and has released APAR IY79120 to resolve this problem. The full APAR description can be found at the following Web site:

http://www-1.ibm.com/support/docview.wss?rs=111&context=SWG10&q1=IY79120&uid

=isg1IY79120&loc=en_US&cs=utf-8&lang=en

When the fix is publicly released, it can be downloaded at the following Web site:

http://www.ibm.com/servers/eserver/support/unixservers/aixfixes.html In the meantime, if you want a subscription service to notify you by e-mail when the PTF for the APAR is available, you can do so at the following Web site:

http://www14.software.ibm.com/webapp/set2/aparsubscriptions/bjyqvcmjd

krb5.client.samples 1.4.0.3 COMMITTED Network Authentication Service

After confirming that the AIX 5L NAS client is installed, you must now make sure that the NAS client is configured and working correctly. If the NAS client is configured, the file /etc/krb5/krb5.conf will exist and the keytab for the host principal will also exist. Example 4-30 shows the krb5.conf file generated by the config.krb5 command in the MSAD scenario. This configuration file will differ slightly depending on your environment. If this file does not exist you must use the config.krb5 command to configure the NAS client.

The next step is to confirm that the Kerberos keytab file for the host principal, located in /etc/krb5/krb5.keytab by default, exists and is valid. If the keytab file is missing you must ensure that the host principal is created and a valid keytab is generated.

You should then use the ktutil command to read the keytab file and list the keys it contains. You should then be able to use the kinit command to authenticate as the host principal and then use the klist command to confirm receiving a TGT and other service tickets. If you are unable to authenticate with the keytab file, you should ensure that the password and principal name used to generate the keytab file is still valid.

Example 4-30 Verifying AIX 5L NAS client is configured and host principal created

# cat /etc/krb5/krb5.conf [libdefaults]

default_realm = EXAMPLE.COM

default_keytab_name = FILE:/etc/krb5/krb5.keytab default_tkt_enctypes = des-cbc-md5 des-cbc-crc default_tgs_enctypes = des-cbc-md5 des-cbc-crc

[realms]

EXAMPLE.COM = {

kdc = bs01b06.example.com:88

admin_server = bs01b06.example.com:749 default_domain = example.com

}

[domain_realm]

.example.com = EXAMPLE.COM bs01b06.example.com = EXAMPLE.COM

[logging]

kdc = FILE:/var/krb5/log/krb5kdc.log

admin_server = FILE:/var/krb5/log/kadmin.log default = FILE:/var/krb5/log/krb5lib.log

#

# ktutil

ktutil: rkt /etc/krb5/krb5.keytab ktutil: list

slot KVNO Principal

--- --- 1 3 host/[email protected]

ktutil: exit

#

# kinit -kt /etc/krb5/krb5.keytab

# klist

Ticket cache: FILE:/var/krb5/security/creds/krb5cc_0 Default principal: host/[email protected]

Valid starting Expires Service principal

10/23/05 11:29:48 10/23/05 21:29:48 krbtgt/[email protected] Renew until 10/24/05 11:29:48

#

Verify Kerberos bind with ldapsearch

After verifying that the AIX 5L NAS client is working properly, you must now ensure that you can bind to the LDAP server using Kerberos. The following example uses the ldapsearch command with the SASL/GSSAPI mechanism to bind to the LDAP server. The following list describes the steps involved:

1. Use the kinit command to authenticate as the host principal using /etc/krb5/krb5.keytab.

2. Use the klist command to verify that you have received a TGT from the KDC.

3. Use the ldapsearch command with the -m GSSAPI mechanism to connect to the LDAP server using the current Kerberos credentials. If you are unable to bind to the LDAP server with Kerberos, your LDAP server might not have Kerberos bind enabled.

4. After binding to the LDAP server with Kerberos, you can run the klist command again and you will have an additional LDAP service ticket. The LDAP service ticket has been highlighted for easy recognition.

Example 4-31 Testing Kerberos bind with LDAP server with the ldapsearch command

# kinit -kt /etc/krb5/krb5.keytab

# klist

Ticket cache: FILE:/var/krb5/security/creds/krb5cc_0 Default principal: host/[email protected]

Valid starting Expires Service principal

10/23/05 19:45:55 10/24/05 05:45:55 krbtgt/[email protected] Renew until 10/24/05 19:45:55

#

# ldapsearch -b dc=example,dc=com -h bs01b06 -m GSSAPI -s one objectclass=* dn CN=Builtin,DC=example,DC=com

10/23/05 19:45:55 10/24/05 05:45:55 krbtgt/[email protected] Renew until 10/24/05 19:45:55

10/23/05 19:46:12 10/24/05 05:45:55 ldap/[email protected] Renew until 10/24/05 19:45:55

#

Verify AIX 5L LDAP client has Kerberos bind enabled

You must now ensure that the AIX 5L LDAP client daemon is configured to use Kerberos to bind to the LDAP server. Example 4-32 on page 143 shows the Kerberos bind section of the LDAP client daemon configuration file

/etc/security/ldap/ldap.cfg. For more information about configuring the LDAP client daemon for Kerberos bind refer to “Kerberos bind” on page 121.

Example 4-32 Verify LDAP client daemon has Kerberos bind configured

# Whether to use Kerberos for initial bind to the server.

# useKRB5 - valid value is either "yes" or "no". Default is "no".

# krbprincipal - Kerberos principal used to bind to the server.

# krbkeypath - Path to the kerberos keytab, default to

# /etc/security/ldap/krb5.keytab

# krbcmddir - Directory that contains the Kerberos kinit command.

# Default to /usr/krb5/bin/.

useKRB5:yes

krbprincipal:host/bs01b08.example.com krbkeypath:/etc/krb5/krb5.keytab krbcmddir:/usr/krb5/bin/

Verify LDAP client daemon’s Kerberos ticket

When the LDAP client daemon starts, it will authenticate with the LDAP server using the Kerberos principal and keytab specified in the configuration file. If there are any problems authenticating, the LDAP client daemon will log errors to the syslog daemon. When the LDAP client daemon authenticates against the KDC successfully, it will store its Kerberos credentials in

/etc/security/ldap/krb5cc_secldapclntd.

Example 4-33 shows how to verify that the LDAP client daemon received a TGT and LDAP service ticket from the KDC. You must first set the KRB5CCNAME environment variable to the location of the LDAP client daemon’s credential cache and then use the klist command to list the tickets in the credential cache.

Example 4-33 Verifying LDAP client daemon’s Kerberos ticket with the klist command

# export KRB5CCNAME=/etc/security/ldap/krb5cc_secldapclntd

# klist

Ticket cache: FILE:/etc/security/ldap/krb5cc_secldapclntd Default principal: host/[email protected]

Valid starting Expires Service principal

10/17/05 17:23:05 10/18/05 03:23:05 krbtgt/[email protected] Renew until 10/18/05 17:23:05

10/17/05 17:23:05 10/18/05 03:23:05 ldap/[email protected] Renew until 10/18/05 17:23:05

#