Storing AIX RBAC databases on ISVD (IBM Ldap servers)
This is my fourth part of this blog series about AIX Advanced RBAC.
And for now the last part of this series, unless people are interested in domain RBAC.
This part will explain how to store RBAC default and custom databases on an IBM LDAP server.
Setting up and prepare your LDAP environment
All the examples that I share below are based on setting up an IBM LDAP server (ISVD IBM Security Verify Directory).
AIX Scheme upload
One of the first steps you have to do, if you not have done this in the past is loading the LDAP schema to you LDAP server. If you followed my other blog series about Trusted Execution (TE) you can skip this step. Also if you did upload the AIX scheme in the past to ldap.
The command to upload an AIX schema for a AIX7.3 LPAR to Ldap is the following:
ldapmodify -Z -K <path/place_keystore>/keystore.kdb -P <password> -p 636 -h <hostname> -D cn=admin -w <password> -c -e /tmp/ldapmodify.err –f /etc/security/ldap/sec.ldif
Note: first password in this line is for opening the keystore of the local stored password. The second password is the password for your administrator ldap account.
Create a DIT Directory tree on you LDAP server.
Second thing you need to do is create a new empty directory where you can store the RBAC databases.
Of course you can let your LDAP administrator do this, but below some examples how to create a ldif and the commands to create a tree.
Example of ldif file to create a LDAP directory structure:
cat input.ldif
dn: cn=RBACdata,cn=testdata,ou=unix,o=company.something,c=nl
cn: RBACdata
objectClass: container
objectClass: top
dn: cn=730202_rbac,cn=RBACdata,cn=testdata,ou=unix,o=company.something,c=nl
cn: cn=730202_rbac
objectClass: container
objectClass: top
Use this input.ldif file with the following example to create the structure on your ldap server:
ldapadd -Z -K <path>/keystore.kdb -P <password> -p 636 -h <hostname> -D cn=admin -w <password> -c -e /tmp/ldapmodify.err –f /path/input.ldif
Modify the /etc/security/ldap/ldap.cfg
Now that we have created on our ldap server the right empty place holder, we are ready to store our RBAC databases to it.
We can create an new ldif file that we can upload to the right structure.
But before we can do this, we also have to notify our client ldap daemon where to upload it, and even more important, for a correct created ldif It needs to know also the right place in the tree.
So in this example we add lines into /etc/security/ldap/ldap.cf like below:
authbasedn:ou=Authorizations,cn=730202_rbac,cn=RBACdata,cn=testdata,ou=unix,o=company.something,c=nl
rolebasedn:ou=Roles,cn=730202_rbac,cn=RBACdata,cn=testdata,ou=unix,o=company.something,c=nl
privcmdbasedn:ou=Privcmds,cn=730202_rbac,cn=RBACdata,cn=testdata,ou=unix,o=company.something,c=nl
privdevbasedn:ou=Privdevs,cn=730202_rbac,cn=RBACdata,cn=testdata,ou=unix,o=company.something,c=nl
privfilebasedn:ou=Privfiles,cn=730202_rbac,cn=RBACdata,cn=testdata,ou=unix,o=company.something,c=nl
domainbasedn:ou=Domains,cn=730202_rbac,cn=RBACdata,cn=testdata,ou=unix,o=company.something,c=nl
domobjbasedn:ou=Domobjs,cn=730202_rbac,cn=RBACdata,cn=testdata,ou=unix,o=company.something,c=nl
Note: use some kind of naming conventions for your databases. We use the oslevel and build data for this, as you can see in the above ldif example.
While we are changing the ldap.cfg file you maybe also like to change the setkst interval (reload kernel tables)
# Time interval (seconds) for secldapclntd daemon to invoke setkst
# command to update the kernel RBAC tables. The value must be greater
# than 60 seconds. Set to 0 to disable running of the setkst command.
# The default value is 3600.
#rbacinterval:3600
rbacinterval:86400
After saving the ldap.cfg file with the changes you now need to restart the LDAP daemon.
So execute stop-secldapclntd and start-secldapclntd commands
Now we can run the following command to generate the right ldif file
#Usage: rbactoldif -d baseDN [-s tables]
#The -s flag must be followed by at least one of the following letters,
# each representing a table name:
# a authorizations
# c privileged commands
# d privileged devices
# f privileged files
# r roles
# e domains
# o domain objects
#
# Without the -s flag, all of the above tables are exported by default.
rbactoldif -d cn=730202_rbac,cn=RBACdata,cn=testdata,ou=unix,o=company.something,c=nl -s acdfreo > rbac.ldif
Note: be aware that the -d baseDN must match the configuration you set in the ldap.cfg.
We can now use this ascii generated input file, to upload to the empty placeholders on our ldap server(s) with the command below:
I always check the content of this generated ldif file before I upload it to the LDAP server(s)
With the command below the upload is started to your Ldap server(s)
ldapadd -Z -K <path>/keystore.kdb -P <password> -p 636 -h <hostname> -D cn=admin -w <password> -c -e /tmp/ldapmodify.err –f /path/rbac.ldif
Errors during the upload will be reported in the file ldapmodify.err
/etc/nscontrol.conf
There is only one important configuration file that needs attention:
/etc/nscontrol.conf
For those who read my TE blog’s there already familiar with this configuration file.
This file is a sort of switch in were you can define the search order.
So where to look first and next to find the right RBAC database, and if it has to search on one or more places:
See below a part of this configuration file for the RBAC databases:
authorizations:
secorder = files,LDAP
roles:
secorder = files,LDAP
privcmds:
secorder = files,LDAP
privdevs:
secorder = files,LDAP
privfiles:
secorder = files,LDAP
domains:
secorder = files,LDAP
domobjs:
" secorder" determines where to search first, in this example it first search into the local RBAC databases, if it cannot find it then another attempt is made to LDAP.
If only LDAP is defined or files than it only looks into that place.
NOTE: 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.
It can be quite useful to look first local, for example if only a custom RBAC role is created for a specific application, the role only can be used on a specific LPAR. Disadvantage is that the same role cannot be shared with other LPARS.
Verify and test uploaded databases
Now you can verify if your RBAC database are stored on LDAP properly.
With a graphic ldap explorer such as the Softera the last part of the DIT should look like this:
On the ldap client you can now use the useful command lsldap (see TE Blogs) to query what is stored.
For example the command lsldap -a roles should now display the RBAC roles stored on LDAP.
And to query a more specific role you can use commands like:
lsrole -R LDAP <example role>
Note: be aware that you have to run manually setkst after the first time on a LDAP client, or you have to wait for one day before the ldap client update the kernel.
Storing custom roles, authorizations etc. on LDAP
Of course you can now also store your custom RBAC authorizations and roles on the LDAP server(s)
You only have to keep in mind that you use the -R LDAP flag.
See part3 of this blog series:
See some examples below, just simple replace the "-R file" with "-R LDAP"
mkauth -R files dfltmsg='team1' id=11001 team1
is then: mkauth -R LDAP dfltmsg='team1' id=11001 team1
and the same for:
setsecattr -R LDAP -c \
innateprivs=PV_AU_ADD,PV_AU_PROC,PV_DAC_O,PV_DAC_R,PV_DAC_W,PV_DAC_X,PV_FS_CHOWN,PV_NET_CNTL,PV_NET_PORT\
accessauths=team1.app.exec.cmd \
secflags=FSF_EPS \
/example/bin/example.script
mkrole -R LDAP and so on.
Something about maintaining RBAC database on LDAP:
If you create custom roles, authorizations, privfiles etc that you like to store on LDAP, my advise is keep it simple.
First: If you have to you apply an new service pack or TL level, start with creating a new empty entry on your LDAP server. Deploy the AIX default RBAC databases first.
Second: make scripts for your custom roles and the authorizations and file access and deploy those scripts after you upload the standard AIX RBAC roles to LDAP.
Config files to maintain on clients:
/etc/security/ldap/ldap.cfg
/etc/nscontrol.conf only if you like to change the search order.
Again use some name conventions in the databases on LDAP.
We created scripts to create the right entries, and for deploying the custom roles and authorizations.
We are now at the end of this blog series about AIX Advanced RBAC.
There is however one subject that I did not cover now: Domain RBAC.
If there are enough requests for this subject I will consider writing a blog about this subject.
Please feel free to give me feed back on this subject. I like discussions about those subjects 😊