Use sudo -l to list your privileges

Use visudo instead of vi to edit a sudoers file

# visudo -f /etc/sudoers.d/oracle_priv

Check syntax on a file:

root@SERVER1:/ # visudo -cf /etc/sudoers
>>> sudoers file: syntax error, line 95 <<<
parse error in /etc/sudoers near line 95

root@SERVER2:/ # visudo -cf /etc/sudoers
/etc/sudoers: parsed OK
/etc/sudoers.d/generic: parsed OK
/etc/sudoers.d/hosts-system: parsed OK

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 

Here are options from /etc/sudoers or /etc/sudoers.d/*

##
# 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 sulog

/var/log/sudo.log 
{
           monthly
           rotate 2
           missingok
}

For full debug sudo: Create a file /etc/sudo.conf

[root@aix01]/root# cat /etc/sudo.conf
Debug sudo /var/log/sudo_debug all@debug

Create the log file /var/log/sudo_debug

And test…very verbose !!!

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

Example of syntax for /etc/sudoers file

%wheel ALL=(ALL) NOPASSWD: ALL
user01 ALL=NOPASSWD:/usr/sbin/lsdev