Kerberos, Active Directory and AIX

 

Kerberos, Active Directory and AIX

 

 

 

You can find a lot and often conflicting information on the subject of using Kerberos with Active Directory to authenticate AIX clients. Recently, I migrated from LDAP-based authentication to one using Kerberos and Active Directory (2012); my AIX clients have more than 150 hosts running AIX 5.3, 6.1 and 7.1. While not painless, the difficulties were short-lived and not severe. This article will describe the task in detail.

If you think Kerberos file sets are all you need for this solution, you’re wrong. It also requires LDAP client file sets because Kerberos provides only authentication service whereas LDAP delivers the authorization (group membership and other user-defining info) information. Both obtain their information from the same source – Active Directory.

Installation

To install Kerberos client, download NAS (Network Authentication Service pack) compatible with your version of AIX. The following command installs it:

# /usr/sbin/installp -agYXd /path/to/apps/NAS1.6.0.1 all

In the similar fashion, install LDAP software. If you install only the LDAP client components, you’ll most likely be left without access to the ldapsearch command so load them all.

It makes sense to verify LDAP “connectivity” before proceeding any further. Your AIX client must have the ldapsearch command. If it’s missing, you’ll want to look for it as it’s not installed in /usr/bin or /usr/sbin. You may locate it with the find command:

# find  /opt –name ldapsearch –ls
/opt/IBM/ldap/V6.3/bin/32/ldapsearch
/opt/IBM/ldap/V6.3/bin/64/ldapsearch
/opt/IBM/ldap/V6.3/bin/ldapsearch
/opt/IBM/ldap/V6.3/examples/java/com/ibm/ldap/bp/client/ldapsearch

To make your life easier, I recommend you modify the PATH variable in either your ~./profile or /etc/environment file, appending to it the /opt/IBM/ldap/V6.3/bin. Or alternatively:

# export PATH=$PATH:/opt/IBM/ldap/V6.3/bin

Verification

With both Kerberos and LDAP installed, you must verify the AIX client is capable of asking for and receiving information from the Active Directory. Ask your Active Directory administrator for the fully qualified name of an account (and password) created for this purpose and for the DNS name of the Active Directory server (ldap.wmd.edu) where this account resides. For the sake of this tutorial, my account name is cn=aixldapquery,ou=ServiceAccounts,ou=Corporate Servers,dc=wmd,dc=edu, the password is ^laska^nebeska:1954 and our hostname is ldap.wmd.edu. With this information in hand, search Active Directory for some details about a user. In this case, I’ll ask for my own information:

# ldapsearch -h ldap.wmd.edu \
-D "cn=aixldapquery,ou=ServiceAccounts,ou=Corporate Servers,dc=wmd,dc=edu”\
-w ^laska^nebeska:1954 \
-s sub \
-b "dc=,dc=edu" "(cn=duszyk)" uid unixHomeDirectory loginShell

CN=duszyk,OU=Secured,OU=Corporate Users,DC=wmd,DC=edu
uid=duszyk
unixHomeDirectory=/home/duszyk
loginShell=/bin/bash 

As this response shows, at least some of the Active Directory UNIX attributes have already been set. You must ensure UNIX attributes in Active Directory of your AIX users are set before any of your AIX hosts is transitioned to use it for authentication. This is a sometimes-overlooked detail.

First, let’s set the client to authenticate purely with LDAP, which is an opportunity to validate that the client correctly translated user information from the Active Directory into the format that AIX can understand and use. Execute the mksecldap command:

# mksecldap –c –h ldap.wmd.edu \
–a “cn=aixldapquery,ou=ServiceAccounts,ou=Corporate Servers,dc=wmd,dc=edu” \
–d “dc=wmd,dc=edu”\
–p ^laska^nebeska:1954

Next, in the file /etc/security/user, find your own stanza and change both SYSTEM and registry attributes to contain the word LDAP.

registry = LDAP
SYSTEM = “LDAP”

Now, edit the /etc/security/ldap/ldap.cfg and verify that it contains the following entries:

authtype:unix_auth
useSSL:no
userattrmappath:/etc/security/ldap/sfur2user.map
groupattrmappath:/etc/security/ldap/sfur2group.map
userclasses:user,person,organizationalperson
groupclasses:group
ldapport:389
searchmode:ALL
defaultentrylocation:LDAP
serverschematype:sfur2

The “sfur2” shown identifies the data store as Active Directory. UNIX group membership in Active Directory may be specified in one of two ways and as the result you must change the following entry in the /etc/security/ldap/sfur2group.map:

users      SEC_LIST   cn                 m       na      yes

Into either:

users      SEC_LIST    msSFU30PosixMember m      na      yes

Or:

users      SEC_LIST   member              m      na      yes

Now, restart the secldapclntd executing “restart-secldapclntd” or empty its cache executing “flush-secldapclntd”. Check that you’re able to get all your AIX data from Active Directory – in my case, I executed the “lsuser –R LDAP duszyk” which delivered data I needed to see to declare it successful.

 

Configuring Kerberos

After this test, I removed/restored my user stanza to its original shape and proceeded to Kerberos client configuration. Verify the host time service is working and starting at reboot as Kerberos is very time sensitive and it often refuses to operate if there’s just a several seconds time difference between the client (in this case, AIX host) and Kerberos server (in this case, Active Directory Kerberos Service).

To configure Kerberos takes some focus as it requires both lower and upper case letters and the case matters. Analyze the following entry:

# config.krb5 -C -r WMD.EDU -d wmd.edu –c LDAP.WMD.EDU -s ldap.wmd.edu

Where: -r realm Active Directory domain name: -d domain Domain name of the machine hosting the Active Directory service: -c LDAP.WMD.EDU The host name of the Windows 2000 server (Kerberos Domain Controller): -s server ldap.wmd.edu

The last command populates the /etc/krb5.conf file with the provided information. You may need to edit the default_tkt_enctypes entry in this file.

# cat /etc/krb5.conf
cat krb5.conf
[libdefaults]
        default_realm = WMD.EDU
        default_keytab_name = FILE:/etc/krb5/krb5.keytab
        default_tkt_enctypes = des3-cbc-sha1 arcfour-hmac aes256-cts des-cbc-md5 des-cbc-crc aes128-cts
        default_tgs_enctypes = des3-cbc-sha1 arcfour-hmac aes256-cts des-cbc-md5 des-cbc-crc aes128-cts

[realms]
        WMD.EDU = {
                kdc = LDAP.WMD.EDU:88
                admin_server = ldap.wmd.edu:749
                default_domain = wmd.edu
        }

[domain_realm]
        .wmd.edu = WMD.EDU
        ldap.wmd.edu = WMD.EDU
        DC.LDAP.EDU = WMD.EDU

[logging]
        kdc = FILE:/var/krb5/log/krb5kdc.log
        admin_server = FILE:/var/krb5/log/kadmin.log
        kadmin_local = FILE:/var/krb5/log/kadmin_local.log
        default = FILE:/var/krb5/log/krb5lib.log 

Open the /etc/methods.cfg file and if you see KRB5A replace it with KRB5. The KRB5A module, which was originally created to communicate with the Active Directory, has been depreciated and its usage is no longer recommended. Use the KRB5 modules instead. Your methods.cfg file should look like mine:

# cat /etc/methods.cfg
KRB5:
        program = /usr/lib/security/KRB5
        program_64 = /usr/lib/security/KRB5_64
        options = authonly,is_kadmind_compat=no,tgt_verify=no

LDAP:
        program = /usr/lib/security/LDAP
        program_64 =/usr/lib/security/LDAP64

KRB5LDAP:
        options = auth=KRB5,db=LDAP

Verifying Kerberos

We are almost at the finish line. It’s time to verify Kerberos configuration. Verify that a user can create “ticket” – I used my own login name.

# kinit -p duszyk
Password for duszyk@WMD.EDU:

# klist
Ticket cache:  FILE:/var/krb5/security/creds/krb5cc_0
Default principal:  duszyk@WMD.EDU

Valid starting     Expires            Service principal
10/25/13 14:07:46  10/26/13 00:07:50  krbtgt/WMD.EDU@WMD.EDU
        Renew until 10/26/13 14:07:46

I’m satisfied with the output generated by the last command; I have no need for the ticket so I’ll destroy it.

# kdestroy
# klist
Unable to get cache name (ticket cache: /var/krb5/security/creds/krb5cc_0).
        Status 0x96c73ac3 - No credentials cache found.

The Finish

In the final step, modify the “default:” stanza in the /etc/security/user file to make sure that all non-local accounts (the “flesh and bone” as I like to call them) will employ Kerberos to authenticate using the Active Directory services. We must change the registry and the SYSTEM entries so they read KRB5LDAP.

# grep KRB5 /etc/security/user
        SYSTEM = "KRB5ALDAP"
        registry = KRB5ALDAP

Refresh the “secldapclntd” daemon and login. After you login, execute the lsuser and id commands to verify that your AIX host received the complete set of information about you – all your groups, uid, shell and more.

Be aware that in this case, the LDAP delivered data (group membership, home directory, etc.) is not scrambled. If you want, you may configure SSL to do it for you – obtain the appropriate keys from your Active Directory administrator.

A final note: At the time of this writing, I noticed that ftp command fails for the Kerberos authenticated users. I have an open PMR with IBM support to resolve this issue.

 

0 (0)
Article Rating (No Votes)
Rate this article
Attachments
There are no attachments for this article.
Comments
There are no comments for this article. Be the first to post a comment.
Full Name
Email Address
Security Code Security Code
Related Articles RSS Feed
AIX, Networking↑ Adding and deleting a static network route using the command line
Viewed 2536 times since Fri, Apr 19, 2019
AIX: Configuring a network interface
Viewed 3227 times since Sat, Jun 2, 2018
A Unix Utility You Should Know About: lsof
Viewed 1859 times since Tue, Apr 16, 2019
Aix: How to assign a specific PVID
Viewed 7115 times since Fri, Feb 1, 2019
AIX boot proccess
Viewed 2856 times since Tue, Apr 16, 2019
Mirroring the rootvg Volume Group for AIX 4.1/4.2
Viewed 2964 times since Mon, May 21, 2018
Reconfigure RSCT ID to fix DLPAR issues on cloned AIX systems
Viewed 13551 times since Thu, Feb 21, 2019
Rootvg Mirroring in AIX
Viewed 2567 times since Mon, May 21, 2018
List STALE partitions across Volume Groups for each Logical Volume in AIX
Viewed 2423 times since Tue, Jul 17, 2018
Processes and Devices—It’s All About the Children
Viewed 2068 times since Wed, May 30, 2018