wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
===== IBM Security Verify Directory =====

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

==== Installation ====

<cli prompt='#'>
# installp -d /dev/cd0 -gaXY idsldap.clt32bit62.rte idsldap.clt64bit62.rte idsldap.cltbase62.adt idsldap.cltbase62.rte
</cli>

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.

<cli prompt='#'>
# installp -d /dev/cd0 -gaXY idsldap.clt_max_crypto32bit62.rte
# installp -d /dev/cd0 -gaXY idsldap.clt_max_crypto64bit62.rte
</cli>

And Global Secure Toolkit:
<cli prompt='#'>
GSKit8.gskcrypt32.ppc.rte GSKit8.gskcrypt64.ppc.rte GSKit8.gskssl32.ppc.rte GSKit8.gskssl64.ppc.rte 
</cli>

==== 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:

<cli prompt='#'>
# 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
</cli>

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:
<cli prompt='#'>
# 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
</cli>
==== 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.
wiki

User Tools

Site Tools

Page Tools
