Differences

This shows you the differences between two versions of the page.

--- aix:aix_sudo [2021/04/03 00:25]
manu
+++ aix:aix_sudo [2023/08/17 01:02] (current)
manu
@@ Line 1: / Line 1: @@
 ====== SUDO options ======
+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:
+<cli prompt='#'>
+root@SERVER1:/ # visudo -cf /etc/sudoers
+>>> sudoers file: syntax error, line 95 <<<
+parse error in /etc/sudoers near line 95
+</cli>
+<cli prompt='#'>
+root@SERVER2:/ # visudo -cf /etc/sudoers
+/etc/sudoers: parsed OK
+/etc/sudoers.d/generic: parsed OK
+/etc/sudoers.d/hosts-system: parsed OK
+</cli>
 If you want to use LDAP integrating with sudo, install sudo_ids from RPM package, add also the option into /etc/netsvc.conf
 <cli prompt='>'>
-root@SERVER:/:=>tail -3 /etc/netsvc.conf
+root@SERVER:/:=> tail -3 /etc/netsvc.conf
 hosts=local4,bind4
 sudoers=ldap
 </cli>
+Here are options from /etc/sudoers or /etc/sudoers.d/*
 <code>
 ##
@@ Line 29: / Line 49: @@
 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
+  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.
@@ Line 36: / Line 56: @@
 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"
+  Defaults secure_path="/usr/local/sbin:/usr/local/bin:/opt/freeware/bin:/usr/sbin"
 Timeout with sudo
@@ Line 42: / Line 62: @@
 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
+  Defaults:bravo timestamp_timeout=20
@@ Line 58: / Line 78: @@
 </code>
-Example to rotate mailbox
+Example to rotate sulog
 <cli>
-/var/spool/mail/*
+/var/log/sudo.log
 {
            monthly
            rotate 2
-           olddir /var/log/news/old
            missingok
 }
 </cli>
+For full debug sudo:
+Create a file **/etc/sudo.conf**
+<cli prompt='#'>
+[root@aix01]/root# cat /etc/sudo.conf
+Debug sudo /var/log/sudo_debug all@debug
+</cli>
+Create the log file **/var/log/sudo_debug**
+And test...very verbose !!!
+===== 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:
+<cli>
+# nimclient -o cust -a lpp_source="lppsource_71-04-01"  -a filesets="gskta.rte gsksa.rte" -a accept_licenses=yes
+</cli>
+In this post we will assume the packages are downloaded in /mnt/LDAP/6.4. It’s possible to install everything in one command.
+<cli>
+# installp -agcXYd /mnt/LDAP/6.4 all
+</cli>
+At the end of the installation, you should have this kind of installation summary:
+<cli>
+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
+</cli>
+The next step is to register the license:
+<cli>
+/mnt/LDAP/6.4/license/idsLicense -q
+/mnt/LDAP/6.4/license/idsLicense -t && echo OK
+</cli>
+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.
+<cli>
+ls -l /usr/bin/idsldapadd
+lrwxrwxrwx    1 root     system           33 Feb 12 15:04 /usr/bin/idsldapadd -> /opt/IBM/ldap/V6.4/bin/idsldapadd
+</cli>
+To change the version, we use the idslink binary.
+Link the 64bits LDAP binaries:
+<cli>
+/opt/IBM/ldap/6.4/bin/idslink -f -q -i -l 64
+</cli>
+Link the 32bits LDAP binaries:
+<cli>
+/opt/IBM/ldap/6.4/bin/idslink -f -q -i -l 32
+</cli>
+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:
+<cli>
+mkdir /etc/ldap/certs
+cd /etc/ldap/certs
+</cli>
+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 :) )
+<cli>
+gsk7cmd -keydb -create -db galerieslafayette.kdb -pw secretpass -type cms -stash
+</cli>
+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”.
+<cli>
+gsk7cmd -cert -add -file /etc/ldap/certs/cacert.pem -db /etc/ldap/certs/cert.kdb -pw secretpass -label "Enterprise CA" -format ascii
+</cli>
+It’s easy to check if the import worked properly by listing the certificates stored in the database:
+<cli>
+gsk7cmd -cert -list -db /etc/ldap/certs/cert.kdb -pw secretpass
+</cli>
+Certificates in database: /etc/ldap/certs/galerieslafayette.kdb
+<cli>
+ 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
+</cli>
+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:
+<cli>
+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
+</cli>
+Here a description of the differents options:
+<code>
+    -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.
+</code>
+The command mksecldap start the the ldap client process automatically.
+You can check if everything is working with the ls-secldapclntd:
+<cli>
+# 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
+</cli>
+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:
+<cli>
+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
+</cli>
+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:
+<cli>
+LDAP:
+        program = /usr/lib/security/LDAP
+        program_64 =/usr/lib/security/LDAP64
+</cli>
+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:
+<cli>
+# yum install sudo_ids
+</cli>
+You can check your sudo version:
+<cli>
+# 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.
+</cli>
+You can also check if the sudo binary were built with ldap support by running this command:
+<cli prompt='#'>
+# 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
+</cli>
+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:
+<cli>
+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
+</cli>
+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.
+<cli>
+sudoers = files, ldap
+</cli>
+Example of syntax for /etc/sudoers file
+  %wheel ALL=(ALL) NOPASSWD: ALL
+  user01 ALL=NOPASSWD:/usr/sbin/lsdev

wiki

User Tools

Site Tools

Differences

Page Tools