IBM AIX audit on an LDAP server

Enabling AIX audit configuration on an LDAP server

This article provides an overview of configuring the IBM® AIX® audit subsystem on a Lightweight Directory Access Protocol (LDAP) server. Using this method, administrators can download the AIX audit configuration file to all LDAP clients that are configured to the LDAP server.

Share:

Uma Chandolu (uchandol@in.ibm.com), AIX Security Development, IBM

Photo of Uma ChandoluUma M. Chandolu works as a security development support specialist on AIX. He has a baccalaureate in engineering and more than nine years of IT experience with expertise in security and various subsystems on AIX environments. Chandolu is also an IBM developer Works Professional author. You can reach him at uchandol@in.ibm.com.


developerWorks Professional author
        level

09 December 2013

Also available in Russian

Overview

The audit subsystem in AIX helps to record security-related information and alert administrators about potential or actual violations of the system security policy. For example, an administrator can detect who has modified the security-sensitive files on the system; learn about the unsuccessful login or su attempts (it might be someone trying to get unauthorized root privileges).

An administrator must consider protecting the stored data (auditing-related) from intruders, or the system might be hacked, possibly without leaving a trace about what happened. Auditing is a measure for an administrator to take in conjunction with other methods to protect systems from intruders and to trace any intrusion.

The audit subsystem performs the following functions:

  • Detecting events
  • Collecting event information
  • Processing information

Enabling auditing on AIX

The following files on an AIX system are used to enable auditing.

  1. /etc/security/audit/config - It is used to specify the events and users who are to be processed by the audit subsystem
  2. /etc/security/audit/objects - It contains the information about audited objects or files. Administrator needs to define the files that need to be audited.
  3. /etc/security/audit/events - It contains the system activities (events) that can be audited.

Scope and assumptions

This feature is available from AIX 6.1 Tl09 and AIX 7.1 Tl03 release onwards. Users must have the knowledge on AIX auditing and LDAP authentication mechanism. This article covers only how to enable AIX audit configuration files on an LDAP server. This feature is currently available only with IBM Tivoli® Directory Server.

Audit configuration on LDAP

This feature provides a facility to configure or store the audit configuration files on the LDAP server. These configuration files can be downloaded to the LDAP client systems and enable auditing on the client system.

A new command, auditldap, has been introduced to convert the /etc/security/audit/config file to the LDAP Data Interchange Format (LDIF) format and upload to the LDAP server. The auditldap command uses the bind user's distinguished name (dn) and the bind user's password to connect with the LDAP server and upload the configuration file. Only the root user is allowed to run the auditldap command.

Steps to enable AIX audit configuration on LDAP

  1. The assumption is that you are already aware of configuring the LDAP server and client. If not, you can refer to LDAP Server and client configuration using mksecldap command.

    By default, when an LDAP server is configured on AIX 6.1 Tl09 or later releases, the schema for audit gets loaded to the LDAP server. If the server is configured in the previous technological levels, you need to load the audit schema (refer to the Download section) to the LDAP server using the ldapadd command.

    Example: ldapadd -h pci2.in.ibm.com -D cn=admin -w adminpwd -i audit.ldif

    After loading, verify whether the audit schema is successfully stored on the LDAP server.

    Example: ldapsearch -h pci2.in.ibm.com -D cn=admin -w adminpwd -s base -b cn=schema 
    objectclass=* | grep -i ibm-aixAuditConfig
  2. Run the auditldap command on the LDAP client systems to upload the /etc/security/audit/config file to the LDAP server.
    auditldap -a -b cn=aixdata -D cn=admin -w adminpwd

    After loading to the LDAP server, if there are any changes to the configuration file, it can be updated to the LDAP server using the auditldap command with the -u option.
    auditldap -u -b o=ibm -D cn=admin -w adminpwd -f /etc/security/audit/config
  3. After loading the audit configuration files, either reconfigure the LDAP client with the mksecldap command or manually add the auditconfdn and auditclassdn basedns entries to the /etc/security/ldap/ldap.cfg file and restart the LDAP client daemon.
    mksecldap -c -h <ldap servername> -a <bind dn> -p <bidnpwd> -S <schema> 
    or
    #Base Dn where audit config data are stored on LDAP server.
    auditconfdn:ou=auditconfig,ou=audit,cn=aixdata
    auditclassdn:ou=auditclassstanza,ou=audit,cn=aixdata
  4. Use the following command to restart the LDAP client daemon.
    /usr/sbin/restart-secldapclntd
  5. Use the lsldap command to verify the audit classes and configuration file information on the LDAP server. The following command displays the audit classes’ information that is stored on the LDAP server.
    #lsldap -a auditclass

    The following command lists the audit configuration information that is stored on the LDAP server.
    #lsldap -a auditconfig
    Note: Currently, the auditldap command allows you to load only one configuration file on the LDAP server. The default configuration file name is config.

Loading audit configuration files on the LDAP client

A new stanza has been introduced in the /etc/nscontrol.conf file to process the audit configuration file either from the LDAP or Files load module while enabling auditing. Set the secorder attribute value to LDAP under the auditconfig stanza in the /etc/nscontrol.conf file in order to download the configuration file from the LDAP server to the LDAP client. The audit start command refers the /etc/nscontrol.conf file and loads the configuration file based on the secorder attribute.

Example: 
# tail -f /etc/nscontrol.conf 
auditconfig:
secorder = LDAP,files

After defining the secorder value, run the audit start command to start the auditing on the LDAP client systems.

Table 1. Precedence order based on secorder
Secorder valueaudit startRemarks
filesCollects the information from the /etc/security/audit/config file on that system. N/A
LDAPCollects the information from the LDAP server's auditconfig stanza. Note: All configuration information is downloaded from LDAP to the LDAP client except virtual_log and wpar stanzas. That information is always taken from the /etc/security/audit/config file on that system.
LDAP, filesFirst collects all the information from the LDAP server's auditconfig stanza and the classes that do not exist on LDAP will be taken from the /etc/security/audit/config file. Note: If the audit classes with the same name say "general", are defined on LDAP and files, then the audit start command takes the audit class definition only from LDAP. It will not merge the auditclass values defined on both load modules. It loads only the first 32 classes to the kernel.
files, LDAPFirst collects all the information from the /etc/security/audit/config file. Only those classes are not defined in the files are taken from the LDAP server. It loads only the first 32 classes to the kernel.

Currently, any change to the /etc/security/audit config file requires the audit daemon to be restarted for the new changes to get effective. With this feature, it allows you to store the /etc/security/audit/config file on the LDAP server. For any changes on the LDAP server to be effective on the LDAP client, you need to restart the audit daemon. It becomes a burden for you to restart the audit demon on every LDAP client for any new change to become effective. The following attributes are introduced in the /etc/security/ldap/ldap.cfg file to resolve this.

auditpolicy

This attribute defines the action that needs to be taken when there is any change in the audit configuration on the LDAP server. This attribute is effective only when the auditinterval attribute is set. The auditpolicy attribute takes two values, WARN and RESTART.

The WARN attribute represents that whenever there is a change in the audit configuration on the LDAP server, it logs a message in the syslog file. This helps the administrator to restart the auditing on the LDAP client.

The RESTART attribute automatically restarts the auditing by restarting audit daemon on LDAP client, whenever there is a change in the audit configuration on the LDAP.

auditrefresh

This attribute defines the interval of time that the LDAP client should check for audit configuration changes on the LDAP server. The auditrefresh attribute accepts the value in seconds and '0' means that it is disabled.

When the audirefresh attribute is set, it is time for the secldapclntd daemon to take action as per auditpolicy. That is, whenever an audit configuration changes on the LDAP server on the basis of the auditpolicy attribute, it restarts the audit or just logs the message in syslog. Time can be represented in seconds or in the 24 hour format. However, if time is in the 24 hour format, then it should start with 'T'.

Note: You need to enable the auditpolicy attribute on the LDAP client. By default, it will be disabled.

Resources

Learn

Discuss

  • Get involved in the My developerWorks community. Connect with other developerWorks users while exploring the developer-driven blogs, forums, groups, and wikis.

Download

DescriptionNameSize
Audit schema fileaudit.zip1 KB

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into AIX and Unix on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=AIX and UNIX
ArticleID=955831
ArticleTitle=IBM AIX audit on an LDAP server
publish-date=12092013