I noticed that this blog series is read, and received some good comments on part 1 and 2, that triggers me to write this part-3.
In this part I try to explain that the databases can be stored on a Ldap server(s), instead of store them local on the Lpar. You can also choose to do both! In the last case you can also control the search order.
But first why should you store the TE database to Ldap at all?
Whell many good reasons to choose for this, but main reason is easy control and switching between pre uploaded databases and extra security.
Extra security that can be achieved when using Ldap servers are:
- Only reading the databases from Ldap, instead of local or both.
- Make databases read-only through Ldap bind users and ACL’s
If you have a Lpar landscape with that is deployed via NIM or PowerVC, you most likely have Lpars that are deployed via a templates, in other words that have the same build level, and patch level.
Maybe you remember that the tsd.dat and the lib.tsd.dat is built during installation time and during upgrades of TL’s and SP’s so in other words it’s important to know that you can share the tds.dat and lib.tsd.dat ONLY if the Lpars are exact the same (same filesets and oslevel patch level).
Another approach is to create for groups or Lpar’s that serve the same application’s or have the same functionality for example database servers. Those can be grouped, and share the same TE-ldap databases.
Even if you have a lot of different Lpar’s storing the databases on Ldap has its benefits, because you can very easily switch between several versions.
In the following paragraphs I will explain how to upload, store and use TE in combination with Ldap servers. My examples are based on IBM version of Ldap ISVD (IBM Security® Verify Directory). I have no experience with other Ldap servers, in combination with TE, this might also work if you are allowed to do a schema upload. Please also read Andrey Klyachkin series about central user management. His blog describes excellent how to deploy ISVD with ansible:
https://open.substack.com/pub/powerdevops/p/lets-take-the-next-step-and-install?r=3h3gf4&utm_campaign=post&utm_medium=web
I will not describe further how to setup an Ldap environment (that’s a bit beyond this scope) but my examples leans on the IBM product ISVD, or the older name SDS6.4.
Preparations that has to be done.
In this part I will not describe how to install and make AIX client connections to an ISVD Ldap server. I make here the assumption that you have already an ldap server(s) in place.
Prepare your Ldap environment and client Ldap.
Schema upload:
It is always good (if you are allowed) to upload the last schema that belongs to your current os. This can be done by the following command:
/opt/IBM/ldap/V6.4/bin/ldapmodify -Z -K /etc/security/ldap/client.kdb -P password -p 636 -h <ldapserver1> -D cn=admin -w password -c -e /tmp/ldapmodify.err –f /etc/security/ldap/sec.ldif
In this example (please read the man pages for ldapmodify), we use a keystore (client.kdb) for secure ssl 636 Ldap connections, most important part is /etc/security/ldap/sec.ldif.
This can be done on a AIX client (preferable on a 7.3 client with the highest level).
Creating new DIT (directory information tree) on Ldap servers for storing the databases:
Before we can upload anything to Ldap we have to create DIT entries (placeholders) for the 3 TE databases, TSD.dat LIBTSD.dat and the TEpolicies. See figure below.
On an Ldap server it is common to use ldif files for this and use those files for creating / modify something on a ldap server. It depends on your organization if have a separate department for maintaining this Ldap environment. But if you have sufficient rights to do this you can follow the steps below. If you Ldap server is protected with ACL’s (access control lists) you may have to ask your ldap admin to create it for you or you have to bind the AIX client with an other bind user that has the right permissions.
See below an example and the contend of an ldif file
dn: cn=TEtest,cn=aixdata,ou=unix,o=example.local,c=nl
cn: TEtest
objectClass: container
objectClass: top
description: place for all TE database on ldap
dn: ou=TSDdat,cn=TEtest,cn=aixdata,ou=unix,o=example.local,c=nl
objectclass: top
objectclass: organizationalUnit
ou: TSDdat
description: place for storing binary tsd.dat files
dn: ou=LIBTSDdat,cn=TEtest,cn=aixdata,ou=unix,o=example.local,c=nl
objectclass: top
objectclass: organizationalUnit
ou: LIBTSDdat
description: place for storing binary libtsd.dat files
dn: ou=TEpolicies,cn=TEtest,cn=aixdata,ou=unix,o=example.local,c=nl
objectclass: top
objectclass: organizationalUnit
ou: TEpolicies
description: place for storing binary te policies settings
Use the following (example) command to create the new cn TEdata on your ldap server(s)
/opt/IBM/ldap/V6.4/bin/ldapadd -Z -K /etc/security/ldap/client.kdb -P <keystore-passwd> -p 636 -h ldapserver -D cn=admin -w <cn-passwd> -c -e /tmp/addte.err -f /tmp/add-TEdata-cn.ldif
Just modify the ldif file to your own environment, and trees that is convenient for your organisation.
TIP: To check and verify your tree and sub trees you can use a tool like Softerra LDAP Browser:
Softerra LDAP Browser (ldapadministrator.com)
Big advantage using this tool, it makes visual what you modify. For testing it saves you a lot work checking the right entries and or modify and delete mistakes.
Once all the empty trees are created, we can setup and modify some config files on the clients, this can be scripted but I will show you the steps needed to be done.
First you have to modify a small part of the /etc/security/ldap/ldap.cfg
See lines below:
# Base DN where the TSD and TE Policy data are stored in the LDAP server.
tsddatbasedn:ou=TSDdat,cn=TEtest,cn=aixdata,ou=unix,o=example.local,c=nl
tepoliciesbasedn:ou=TEpolicies,cn=TEtest,cn=aixdata,ou=unix,o=example.local,c=nl
libtsdbasedn:ou=LIBTSDdat,cn=TEtest,cn=aixdata,ou=unix,o=example.local,c=nl
After this we have to modify a very important file for TE named the /etc/nscontrol.conf
Via this file you can control the databases on ldap that should be used, also if the database should be stored local on ldap or both. See the contend of this file below (part that is used for TE):
/etc/nscontrol.conf
tsddat:
secorder = LDAP
databasename = 720002_72000507_tsd_v2346_v8
tepolicies:
secorder = LDAP
# V8 has the fix xxyy ifix for mrt24
databasename = 720002_72000507_tepol_v2346_v8
With the command chsec the nscontrol.conf can be modified, so that you cannot make mistakes here. But also manual edits are fine as long if the right syntax is used.
The keyword secorder controls the search order for the database like the tsddat, in the above example only ldap is queried, and nothing else, but valid entries are here files,LDAP or files only or other search orders.
In our case we like to use only LDAP, because we created a special bind user for the AIX clients that have a LDAP ACL on it that makes the database read-only, read data cannot be tampered.
Let’s go and upload the tsd.dat and store it on the Ldap server(s).
The example below is a small script that’s creates again ldif files, for each database an ldif file is generated. It’s a good habit to first inspect the created ldif file before uploading it to the Ldap servers.
#!/bin/ksh93
# set -x
# Syntax
# Usage: tetoldif -d baseDN [-s [filename] ] [-p [filename] ] [-l [filename] ]
# -s For signature database
# -p For TE policy database
# -l For library signature database
tetoldif -d cn=TEdata,cn=aixdata,ou=unix,o=example.local,c=nl -s > /home/user/TE/te.ldif
tetoldif -d cn=TEdata,cn=aixdata,ou=unix,o=example.local,c=nl -l > /home/user/TE/libtsd.ldif
tetoldif -d cn=TEdata,cn=aixdata,ou=unix,o=example.local,c=nl -p > /home/user/TE/tepol.ldif
check the content of the generated ldif files with:
-bash-5.1# cat te.ldif
dn: ou=TSDdat,cn=TEtest,cn=aixdata,ou=unix,o=example.local,c=nl
objectclass: organizationalUnit
ou: Tsddat
dn: cn=720002_72000507_tsd_v2346_v8,ou=TSDdat,cn=TEtest,cn=aixdata,ou=unix,o=example.local,c=nl
objectclass: ibm-aixTSDatabase
cn: 720002_72000507_tsd_v2346_v8
ibm-aixTSDEntry: /etc/security/tsd/tsd.dat
dn: ou=TEpolicies,cn=TEtest,cn=aixdata,ou=unix,o=example.local,c=nl
objectclass: organizationalUnit
ou: Tepolicies
dn: cn=720002_72000507_tepol_v2346_v8,ou=TEpolicies,cn=TEtest,cn=aixdata,ou=unix,o=example.local,c=nl
objectclass: ibm-aixTEPolicy
cn: 720002_72000507_tepol_v2346_v8
ibm-aixTEPDefinition: /etc/security/tsd/tepolicies.dat
Repeat this for the libtst.ldif and the tepol.ldif files
Uploading the databases files:
Upload the generated ldif files to the ldap server(s). See examples below:
/opt/IBM/ldap/V6.4/bin/ldapadd -Z -K /etc/security/ldap/client.kdb -P passwd -p 636 -h ldaphost -D cn=admin -w passwd -b -c -e /home/user/TE_error.txt -f /home/user/te.ldif
/opt/IBM/ldap/V6.4/bin/ldapadd -Z -K /etc/security/ldap/client.kdb -P passwd -p 636 -h ldaphost -D cn=admin -w passwd -b -c -e /home/user/LIBTE_error.txt -f /home/user/libtsd.ldif
/opt/IBM/ldap/V6.4/bin/ldapadd -Z -K /etc/security/ldap/client.kdb -P passwd -p 636 -h ldaphost -D cn=admin -w passwd -b -c -e /home/user/tepol_error.txt -f /home/user/tepol.ldif
Please check the error.txt files if the upload was successful!
If the error files are empty and no error’s to standard output than we can proceed with verification for every database that is stored on Ldap. Also you will like to know if the client can access it. A very useful command for this is lsldap.
See below the example how to check and verify if the upload was successful and the ldap databases are accessible.
Note: You may noticed that tsd.dat and lib.tsd.dat files are stored on the Ldap server(s) als binary format, therefore you cannot “see” the content of those files, with a ldap tool such as softterra. But on the client there is another way to see the cached content which I explain later.
You can verify on the ldap client with the command lsdap if your client can query the right TE Ldap databases with the lsldap command see examples below:
lsldap
dn: ou=Tsddat,cn=TEdata,cn=aixdata,ou=unix,o=example.local,c=nl
dn: ou=Tepolicies,cn=TEdata,cn=aixdata,ou=unix,o=example.local,c=nl
dn: ou=libtsddat,cn=TEdata,cn=aixdata,ou=unix,o=example.local,c=nl
And with more specified (the database name in nscontrol.conf should match)
lsldap -a tsddat cn=720002_72000507_tsd_v2346_v8
dn: cn=720002_72000507_tsd_v2346_v9,ou=Tsddat,cn=TEdata,cn=aixdata,ou=unix,o=example.local,c=nl
objectclass: ibm-aixTSDatabase
objectclass: top
cn: 720002_72000507_tsd_v2346_v8
ibm-aixTSDEntry: NOT ASCII
Tip: do not forget to restart the Ldap client deamon if you change something into the ldap.cfg file. (stop-secclntd start-secclntd) restart-secclntd wil NOT help you it does not re-read the ldap.cfg.
An other way to check is with ldapsearch:
/opt/IBM/ldap/V6.4/bin/ldapsearch -Z -K /ldapfs/clientkey/client.kdb -P <wachtwoord> -p 636 -L -b \ ou=TSDdat,cn=TEtest,cn=aixdata,ou=unix,o=example.local,c=nl -h <servername> -D cn=admin -w <passwd> '(objectClass=*)' |more
If you like to verify the content stored on the ldap server(s) you can use the cache file for the tsd.dat and the lib.tsd.dat. The client will download those files and store them into the following directory: /etc/security/tsd/ldap
-bash-5.1# ls -altr
total 14592
--w------- 1 root system 0 May 21 2021 .lock
drwxr-x--- 2 root security 256 Apr 14 2023 .
drwxr-x--- 4 root security 4096 Apr 21 2023 ..
-rw------- 1 root system 448 Mar 20 17:24 tepolicies.dat
-rw------- 1 root system 5411522 Mar 20 17:30 tsd.dat
-rw------- 1 root system 2046278 Mar 20 17:30 lib.tsd.dat
Be careful with those files do NOT edit them! Use view instead of vi if you like to see the content.
There is however one reason to emty this directory, and that is if you locked yourself out, and you have to reboot the Lpar, just before the reboot edit the /etc/nscontrol.conf or use chsec to switch to local files instead of Ldap and remove the .lock file and the at least the tepolicies.dat
For now we have a working TE – Ldap environment. And the next thing to check is to validate the executables libraries and scripts. So lets run…
trustchk -R LDAP -n ALL
If there is no output after a while then you have successfully stored the TE databases on a Ldap server.
Note: there will be sometimes one or more executables such as rlogin that give some errors, most likely that they are symlinks with the same names and or duplicates. Always do a trustchk -R files -n to see if those errors do not occur locally, then check the tsd.dat or lib.dst.dat to see is something is duplicated.
Last resort to fix this is to remove those files from the Ldap database with:
trustchk -R LDAP -d /complete/path/name
This is the end of part-3.
If I get again feedback about this blog series, I will post a finally part-4. In this part I will explain how to maintain, and can show some examples how to deal with efixes and or TL’s and SP’s and why is storing on Ldap is therefore a good idea.
#IBMChampion