AIX LDAP authentication quick&dirty howto
UrbanBiel | Dec 10 2012 | Comments (2) | Visits (3782) 1 person likes this
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
Installation
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
Setup preparation
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.
Client setup
No SSL
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.
With SSL
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}
Post tasks
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
Debugging
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.
UrbanBiel | Dec 10 2012 | Comments (2) | Visits (3782) 1 person likes this
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
Installation
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
Setup preparation
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.
Client setup
No SSL
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.
With SSL
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}
Post tasks
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
Debugging
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.