wiki

idsldapsearch -b cn=schema -s base objectclass=* attributeTypes IBMAttributeTypes

This entry is a reference to my AIX client LDAP authentication and authorization setup. I do not tend to explain the topic, rather to show you, how it worked for me. Tested on AIX 7.1 TL1 SP5 against TDS v6.

For comprehensive and more in depth informations see:

http://www.ibm.com/developerworks/aix/library/au-aixadsupport.html http://www.ibm.com/developerworks/aix/library/au-ldapconfg/ http://www.redbooks.ibm.com/abstracts/sg247165.html

latest update: http://www-01.ibm.com/support/docview.wss?uid=swg24035827

# installp -d /dev/cd0 -gaXY idsldap.clt32bit62.rte idsldap.clt64bit62.rte idsldap.cltbase62.adt idsldap.cltbase62.rte

If you're going to use SSL (definitely yes for LDAP authentication), install the following filesets. Installation order is very important for the SSL libraries (max_crypto). LDAP SSL libraries are on the AIX Expansion Pack media.

# installp -d /dev/cd0 -gaXY idsldap.clt_max_crypto32bit62.rte
# installp -d /dev/cd0 -gaXY idsldap.clt_max_crypto64bit62.rte

And Global Secure Toolkit:

GSKit8.gskcrypt32.ppc.rte GSKit8.gskcrypt64.ppc.rte GSKit8.gskssl32.ppc.rte GSKit8.gskssl64.ppc.rte 

No matter how your final LDAP tree will look like, to set up an AIX as an LDAP client using mksecldap command, you need to have:

  People and Group branches in the same subtree.
  at least one user in People and one group in Groups.

You can configure a very complicated LDAP tree and play with ACLs a lot, but I strongly suggest to start with the simplest scenario - no SSL and a simple LDAP tree layout, RFC2307AIX schema. Let's set basic parameters:

BASEDN="dc=ibm"
BINDUSER="uid=aixbind,ou=People,${BASEDN}"
BINDPASS="topsecret123"
LDAPPORT=389
LDAPHOST="testldap.my.domain"
LDAP="${LDAPHOST}:${LDAPPORT}"

According to manual page, the LDAP port should be specified using -n switch in mksecldap command, but it only works in the form of host:port. For LDAP connection setup purposes insert one user and one group. If you have a user on your AIX that you plan to move to LDAP anyway, create an ldif using sectoldif -d dc=${BASEDN} -S RFC2307AIX -u myuser > myuser.ldif, or use the example below:

# cat fill_the_tds.ldif
dn: uid=setupuser,ou=People,dc=ibm
uid: setupuser
objectClass: aixauxaccount
objectClass: shadowaccount
objectClass: posixaccount
objectClass: account
objectClass: ibm-securityidentities
objectclass: top
cn: setupuser
passwordchar: *
uidnumber: 1000
gidnumber: 1000
homedirectory: /home/setupuser
loginshell: /usr/bin/ksh
isadministrator: false

dn: cn=setupgrp,ou=Groups,dc=ibm
cn: setupgrp
objectclass: aixauxgroup
objectclass: posixgroup
objectclass: top
gidnumber: 1000
memberuid: setupuser
isadministrator: false

You can insert them only if you have proper ACL set, otherwise ask your LDAP administrator to do so.

/opt/IBM/ldap/V6.2/bin/ldapadd -h ${LDAP} -D ${BINDUSER} -w \? -i fill_the_tds.ldif

Failing to do this, mksecldap command will return this error:

Cannot find the user base DN from the ldap server. client setup failed.

or this one:

Cannot find the group base DN from the ldap server. client setup failed.

A piece of cake:

mksecldap -c -h ${LDAP} -A ldap_auth -D ldap -d ${BASEDN} -a ${BINDUSER} -p ${BINDPASS}

If you are upset about the password in the command line, it's because mksecldap during it's verification phase performes ldapsearch many times and each time it requires a password. The command doesn't tell you “enter password”, it just waits. I gave up after 5 inserts. If you don't mind and you are more patient than I am, use -p \? command switch. I suggest to use a temporary password and change it later.

You have to have public certificates of the server in your keystore. Ask your LDAP administrator for them. There are more ways to get them, I've got them as DER files.

KDBPASSWORD=supersecretpassword
gsk8capicmd -keydb -create -db /etc/security/ldap/ldap.kdb
gsk8capicmd -cert -add -db /etc/security/ldap/ldap.kdb -file /tmp/root.der -label root_certificate
gsk8capicmd -keydb -changepw -new_pw ${KDBPASSWORD} -db /etc/security/ldap/ldap.kdb

Now here comes the big magic:

LDAPPORT=636
LDAP="${LDAPHOST}:${LDAPPORT}"
mksecldap -c -h ${LDAP} -A ldap_auth -D ldap -d ${BASEDN} -a ${BINDUSER} -p ${BINDPASS} \
 -k /etc/security/ldap/ldap.kdb -w ${KDBPASSWORD}

User related configuration tasks:

# chsec -f /etc/security/user -s default -a registry=LDAP
# chsec -f /etc/security/user -s default -a SYSTEM=LDAP
# chsec -f /etc/security/login.cfg -s usw -a mkhomeatlogin=true
# chdev -l sys0 -a max_logname=256

A lot of things can go wrong. A few troubleshooting hints:

- Try non-SSL connection first Ask your LDAP administrator to turn on audit log and watch it. In my environment I used

tail -f /dataldap/idsslapd-dbldap/logs/audit.log

- Inspect the network traffic. Capture whole packets and analyze them later using Wireshark. Even with SSL you can at least check, whether SSL has been established:

tcpdump -s1500 -w /tmp/ldap_troubles.cap host ${LDAPHOST} and port ${LDAPPORT}
  

- If you have issues with SSL, try

openssl s_client -host ${LDAPHOST} -port ${LDAPPORT} 

to check if SSL works on LDAP server.

- Perform ldapsearch, it is independend on your current LDAP client setup:

/opt/IBM/ldap/V6.2/bin/ldapsearch -h ${LDAPHOST} -D ${BINDUSER} -b ${BASEDN} -p \? 'objectclass=*'

To test SSL, do the same with -k and -w switches.