This is an old revision of the document!
SUDO options
If you want to use LDAP integrating with sudo, install sudo_ids from RPM package, add also the option into /etc/netsvc.conf
root@SERVER:/:=>tail -3 /etc/netsvc.conf hosts=local4,bind4 sudoers=ldap
## # Override builtin defaults ## Defaults syslog=auth Defaults logfile=/var/log/sudo.log
The other way to preserve system environment variables is to use the Defaults !env_reset directive, like in sudoers:
Defaults !env_reset
For instance, suppose sudo was stripping out the application variables DSTAGE_SUP and DSTAGE_META from one of my suodo-ised scripts. To preserve these variables, I could put the following entries in sudoers:
Defaults env_keep += "DSTAGE_SUP" Defaults env_keep += "DSTAGE_META"
Notice that I give the variable name and not the variable value. The values are already contained in my script like this:
export DSTAGE_SUP=/opt/dstage/dsengine; export DSTAGE_META=/opt/dstage/db2
Now when the sudo script is executed, the above environment variables are preserved. Securing the sudo path
A default PATH within sudoers can be imposed using the secure_path directive. This directive specifies where to look for binaries and commands when a user executes a sudo command. This option clearly tries to lock down specific areas where a user runs a sudo command, which is good practice. Use the following directive in sudoers, specifying the secure PATH with its search directories:
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/opt/freeware/bin:/usr/sbin"
Timeout with sudo
Sudo has a feature that uses time tickets to determine how long since the last sudo command was run. During this time period, the user can re-run the command without being prompted for the password (that's the user's own password). Once this time allotment has ended, the user is prompted for the password again to re-run the command. If the user gives the correct password, the command is executed, the ticket is then re-set, and the time clock starts all over again. The ticket feature will not work if you have NOPASSWD in the user's entry in sudoers. The default timeout is five minutes. If you wish to change the default value, simply put an entry in sudoers. For example, to set the timeout value for user “bravo” on any commands he runs to 20 minutes, you could use:
Defaults:bravo timestamp_timeout=20
Log it
All commands run as sudo are logged using syslog to /var/adm/messages using the entry in the /etc/syslog.conf file:
*.debug /var/adm/messages
However, I believe sudo commands should be logged to a separate file, which makes it easier to view and investigate sudo commands that have been run. Of course, this also helps with keeping an eye on failed sudo events. Create the file /var/adm/sudo.log, and then in the /etc/sudoers file, put the following entry:
Defaults logfile=/var/adm/sudo.log Defaults !syslog
Example to rotate mailbox
/var/spool/mail/* { monthly rotate 2 olddir /var/log/news/old missingok }
AIX ldap configuration
https://www.djouxtech.net/posts/aix-ldap-configuration/
This post will describe the installation and configuration of the user’s authentication with LDAP on AIX using IBM directory server client software. packages installation
To manage certificates and use SSL/TLS, you need to have gskta.rte and gsksa.rte packages installed.
If you have a NIM server, the easiest way is to install them with nimclient:
nimclient -o cust -a lpp_source=“lppsource_71-04-01” -a filesets=“gskta.rte gsksa.rte” -a accept_licenses=yes
In this post we will assume the packages are downloaded in /mnt/LDAP/6.4. It’s possible to install everything in one command.
installp -agcXYd /mnt/LDAP/6.4 all
At the end of the installation, you should have this kind of installation summary:
Installation Summary
Name Level Part Event Result
idsldap.license64.rte 6.4.0.8 USR APPLY SUCCESS idsldap.cltbase64.rte 6.4.0.8 USR APPLY SUCCESS idsldap.cltbase64.adt 6.4.0.8 USR APPLY SUCCESS idsldap.cltbase64.rte 6.4.0.8 ROOT APPLY SUCCESS idsldap.clt64bit64.rte 6.4.0.8 USR APPLY SUCCESS idsldap.clt64bit64.rte 6.4.0.8 ROOT APPLY SUCCESS idsldap.clt32bit64.rte 6.4.0.8 USR APPLY SUCCESS idsldap.clt32bit64.rte 6.4.0.8 ROOT APPLY SUCCESS idsldap.msg64.en_US 6.4.0.8 USR APPLY SUCCESS idsldap.clt_max_crypto64bit 6.4.0.8 USR APPLY SUCCESS idsldap.clt_max_crypto32bit 6.4.0.8 USR APPLY SUCCESS
The next step is to register the license:
/mnt/LDAP/6.4/license/idsLicense -q /mnt/LDAP/6.4/license/idsLicense -t && echo OK
IBM Directory Server allows multiple versions to be installed on the same system. Some links are created in /usr/bin to point on the current version.
ls -l /usr/bin/idsldapadd lrwxrwxrwx 1 root system 33 Feb 12 15:04 /usr/bin/idsldapadd → /opt/IBM/ldap/V6.4/bin/idsldapadd
To change the version, we use the idslink binary.
Link the 64bits LDAP binaries:
/opt/IBM/ldap/6.4/bin/idslink -f -q -i -l 64
Link the 32bits LDAP binaries:
/opt/IBM/ldap/6.4/bin/idslink -f -q -i -l 32
import CA certificate
To import the Certification Authority certificate, the first step is to create a key database with gsk commands.
Create the certificate directory:
mkdir /etc/ldap/certs cd /etc/ldap/certs
The next step is to create a keystore database. It will store the Certificate Authority certificate.
It’s important to select a good password(not secretpass like in the example below :) )
gsk7cmd -keydb -create -db galerieslafayette.kdb -pw secretpass -type cms -stash
After that, you need to copy your CA certificate in /etc/ldap. Here the certificate file is named /etc/ldap/cacert.pem and we label it “Enterprise CA”.
gsk7cmd -cert -add -file /etc/ldap/certs/cacert.pem -db /etc/ldap/certs/cert.kdb -pw secretpass -label “Enterprise CA” -format ascii
It’s easy to check if the import worked properly by listing the certificates stored in the database:
gsk7cmd -cert -list -db /etc/ldap/certs/cert.kdb -pw secretpass
Certificates in database: /etc/ldap/certs/galerieslafayette.kdb Enterprise CA Entrust.net Global Secure Server Certification Authority Entrust.net Global Client Certification Authority Entrust.net Client Certification Authority Entrust.net Certification Authority (2048) Entrust.net Secure Server Certification Authority VeriSign Class 3 Public Primary Certification Authority VeriSign Class 2 Public Primary Certification Authority VeriSign Class 1 Public Primary Certification Authority VeriSign Class 4 Public Primary Certification Authority - G2 VeriSign Class 3 Public Primary Certification Authority - G2 VeriSign Class 2 Public Primary Certification Authority - G2 VeriSign Class 1 Public Primary Certification Authority - G2 VeriSign Class 4 Public Primary Certification Authority - G3 VeriSign Class 3 Public Primary Certification Authority - G3 VeriSign Class 2 Public Primary Certification Authority - G3 VeriSign Class 1 Public Primary Certification Authority - G3 Thawte Personal Premium CA Thawte Personal Freemail CA Thawte Personal Basic CA Thawte Premium Server CA Thawte Server CA
Note: this step can be done only one time. You can copy the files on your others AIX systems. LDAP configuration
The initial LDAP configuration is done with the mksecldap command:
mksecldap -c -h ldap01 -a “uid=svc_ldap,ou=Service,dc=mydomain,dc=inet” -p ldappass -S rfc2307aix -k /etc/ldap/certs/cert.kdb -w secretpass -j TLS -A ldap_auth
Here a description of the differents options:
- h: the ldap server hostname
- a: the bind user
- p: the bind user’s password
- S: the ldap structure used in the LDAP directory to store users. Here it’s based on the rfc2307 with extension for AIX.
- k: the certificate database
- w: the certificate database’s password
- j: use TLS for the ldap connection
- A: Here we specify than user’s authentication is done on the LDAP server with the value ldap_auth.
The command mksecldap start the the ldap client process automatically.
You can check if everything is working with the ls-secldapclntd:
ls-secldapclntd ldapservers=ldap01 current ldapserver=ldap01 ldapport=389 active connections=1 ldapversion=3 usercachesize=1000 usercacheused=2 groupcachesize=100 groupcacheused=1 usercachetimeout=300 groupcachetimeout=300 heartbeat interval=300 numberofthread=10 connectionsperserver=10 authtype=LDAP_AUTH searchmode=ALL defaultentrylocation=LDAP ldaptimeout=60 serverschematype=RFC2307 userbasedn=ou=Accounts,dc=mydomain,dc=inet groupbasedn=ou=Groups,dc=mydomain,dc=inet userobjectclass=posixaccount,account,shadowaccount groupobjectclass=posixgroup
further configuration
This configuration is a basic one. It’s better to modify the configuration file /etc/security/ldap/ldap.cfg to better match your environment.
Here an example of a more complex configuration:
ldapservers:ldap01,ldap02 binddn:uid=svc_ldap,ou=Service,dc=mydomain,dc=inet bindpwd:{DESv2}EE71CA5D52D2 ADECB27A2B746 3 E3172D58FF85219AC 5 authtype:ldap_auth useSSL:TLS ldapsslkeyf:/etc/ldap/certs/cert.kdb ldapsslkeypwd:{DESv2}C85DE2C1DC7D4767D47ED84D5F19CAB0849E23953FD596 4 userattrmappath:/etc/security/ldap/2307user.map groupattrmappath:/etc/security/ldap/2307group.map userbasedn:ou=Accounts,dc=mydomain,dc=inet??(memberOf=cn=admin,ou=Teams,ou=Groups,dc=mydomain,dc=inet) groupbasedn:ou=Groups,dc=mydomain,dc=inet netgroupbasedn:ou=Groups,dc=mydomain,dc=inet userclasses:posixaccount,account,shadowaccount groupclasses:posixgroup ldapport:389 searchmode:ALL defaultentrylocation:LDAP serverschematype:rfc2307 nsorder: local,bind
Most of the options are self-explanatory.
userbasedn is pretty interesting because you can specify a filter after the base dn. The separator is ??. Here we added
(memberOf=cn=admin,ou=Teams,ou=Groups,dc=mydomain,dc=inet)
So, in this example, to have a user visible on this system, he needs to be part of the cn=admin,ou=Teams,ou=Groups,dc=mydomain,dc=inet group. You can build more complex filters, it only need to be a valid ldap filter expression.
After modifying the configuration file, you need to restart the LDAP client service:
restart-secldapclntd
System configuration
LDAP is configured on the system but AIX is not using it for user management by default. You need to enable it with the chsec command:
chsec -f /etc/security/user -s default -a SYSTEM=“files or LDAP”
In some environments, you will have an error saying that LDAP is not a valid SYSTEM option. It’s because the file /etc/methods.cfg doesn’t contains this entry:
LDAP:
program = /usr/lib/security/LDAP
program_64 =/usr/lib/security/LDAP64
You can add it manually.
Another nice option added in AIX 6.1 is the possibility to automatically create the home directory at user’s login time.
chsec -f /etc/security/login.cfg -s usw -a mkhomeatlogin=true
sudo configuration
Since a few months, IBM provides a sudo package with IBM Directory Server ldap + ssl support. The package is named sudo_ids. The minimum version is 1.8.20.
If you installed yum on AIX(highly recommended), the installation is really easy:
yum install sudo_ids
You can check your sudo version:
rpm -qi sudo_ids
Name : sudo_ids Version : 1.8.20p2 Release : 2 Architecture: ppc Install Date: Fri Dec 22 12:27:32 NFT 2017 Group : Applications/System Size : 5409591 License : IBM_ILA Signature : (none) Source RPM : sudo_ids-1.8.20p2-2.src.rpm Build Date : Wed Nov 15 11:35:27 NFT 2017 Build Host : aixoss2.in.ibm.com Relocations : /opt/freeware URL : http://www.sudo.ws Summary : Allows restricted root access for specified users. Description : Sudo (superuser do) allows a system administrator to give certain users (or groups of users) the ability to run some (or all) commands as root while logging all commands and arguments. Sudo operates on a per-command basis. It is not a replacement for the shell. Features include: the ability to restrict what commands a user may run on a per-host basis, copious logging of each command (providing a clear audit trail of who did what), a configurable timeout of the sudo command, and the ability to use the same configuration file (sudoers) on many different machines. This sudo is built with ibm idsldap. One has to make sure appropriate symbolic links are created in /usr/lib for idsldap libraries (through idslink command provided by idsldap filesets) followed by “updtvpkg” before installing the rpm.
You can also check if the sudo binary were built with ldap support by running this command:
sudo -V|grep ldap Configure options: –prefix=/opt/freeware –sbindir=/opt/freeware/sbin –mandir=/opt/freeware/share/man –docdir=/opt/freeware/share/doc/sudo_ids-1.8.20p2 –with-logging=syslog –with-aixauth –with-logfac=auth –without-pam –with-env-editor –with-ignore-dot –with-tty-tickets –with-ldap –with-ldap-conf-file=/etc/sudo-ldap.conf ldap.conf path: /etc/sudo-ldap.conf ldap.secret path: /etc/ldap.secret
It will also give you the place of the ldap configuration file for sudo. Here it’s /etc/sudo-ldap.conf.
This configuration file is pretty simple to understand:
host ldap01 ldap02 port 389 sudoers_base ou=sudoers,dc=mydomain,dc=inet sudoers_debug 0 tls_key /etc/ldap/certs/cert.kdb ssl start_tls binddn uid=svc_ldap,ou=Service,dc=mydomain,dc=inet bindpw secretpass ldap_version 3 bind_timelimit 3 timelimit 3
It’s important to specify the good certificate database if you want to use TLS to contact the LDAP directory. It’s specified with the parameter tls_key.
sudoers_debug is really helpful to debug configuration problems, don’t hesitate to change the value from 0 to 7 or 9 to have more informations.
In production, it’s better to store the bind dn password in the /etc/ldap.secret file.
It’s also mandatory to modify the /etc/netsvc.conf file to allow sudo to use LDAP.
sudoers = files, ldap
