It started with two LDAP servers and now there is a third one. The new LDAP server has already been added to the peer domain and its receiving updates from the other two TDS servers. Now, it is the time to make each AIX host aware of its existence – the /etc/security/ldap/ldap.cfg file needs to be modified together with the installation procedure which now will set LDAP clients with access to three (previously two) TDS LDAP servers.
Let’s call the new server axitds3. For security reasons, communications between each LDAP Server and LDAP Client communication is secured by SSL which dictates that the new LDAP servers creates its self-signed SSL certificate which will be provided to AIX clients. To create a certificate is synonymous with creation a “place” for its storage. In AIX such place is called a keys database which is a files with .kdb extension.
To create a keys (certificates) database and to manipulate its contents, AIX provides the command called gsk8capicmd_64. The next line shows what to do to create the key store called aixtds3 which will have extension .kdb. See an earlier post following this link “PassThrough Authentication ……” for more details.
# gsk8capicmd_64 -keydb -create -db aixtds3 -pw abc123 -type cms -stash
Actually the aixtds3.kdb will be one of a few files created by the last command sharing the same name but having different extensions.
Next, we create the host (the new TDS server) self-signed certificates (keys) which will be stored in the aixtds3.kdb key store.
# gsk8capicmd_64 -cert -create -db aixtds3Key.kdb -pw abc123 -label aixtds3 -dn 'cn=aixtds3.wmd.edu' -default_cert yes -expire 7000
By the way, the certificates will be valid for the next seven thousands days or about twenty years – use value which is appropriate for your environment.
Now, the certificate aka the “key” has to be extracted from the database into a file that will be copied to AIX host so it can be used to validate its request sent to this LDAP server.
# gsk8capicmd_64 -cert -extract -db aixtds3.kdb -pw abc123 -label aixtds3 -target aixtds3.arm -format binary
Now, the file containing the new server certificates (aixtds3.arm is ready to be copied to a host. By a force of a habit, I keep the key stores in /etc/security/ldap directory so the freshly created .arm file is copied to (using scp or ftp) to the same location on the client.
To add the server keys to the client key store (aka client’s *.kdb file), execute the gsk8capicmd command where the AixClientHostName.kdb defines the name of the AIX client certificates database file. In this case the client key database has been previously created and it contains the certificates of the two earlier configured TDS servers.
# gsk8capicmd_64 -cert -add -db AixClientHostName.kdb -pw abc123 -label aixtds3 -file aixtds3.arm
To list the contents of the client’s key store:
# gsk8capicmd_64 -cert -list -pw abc123 -db AixClientHostName.kdb Certificates found * default, - personal, ! trusted ! aixtds3 ! aixtds2 ! aixtds1
There might be more than just one *.kdb file in /etc/security/ldap directory. How to find which one is used by ldap daemons? Find what file is specified in the ldap.cfg file.
# grep kdb /etc/secuirty/ldap/ldap.cfg AixClientHostName.kdb
Now, the ultimate test. Let’s verify that we can “search” the new LDAP server using SSL as the transport mechanism.
# /etc/security/ldap> idsldapsearch -h aixtds3 -Z -K AixClientHostName.kdb -P abc123 -b "" -s base objectclass=*
If successful, the last command will generate a lot of output which signals that the host is ready for the next step – include the new LDAP server in the client’s /etc/security/ldap/ldap.cfg file. In this file, we have to modify the line starting with the ldapservers: by adding the new ldap server to the existing list (aixtds1, axitds2). In our case this line will look like this one:
ldapservers:aixtds1,aixtds2,aixtds3
At last, re-fresh the secldapclntd daemon.
# stop-secldapclntd; start-secldapclntd