Local AIX Authentication using LDAP and eDirectory 8.8.2

Like SUSE Linux Enterprise Server (SLES), maintaining local accounts for either system administrators or general users can be a real pain if you have more than one AIX server.

Centralized user accounts can minimize the impact of forced password changes and account administration. eDirectory and LDAP and AIX provides us with a solution to allow users to login to the AIX server using their existing eDirectory accounts, thus eliminating the need for repetitious, multi-server user administration.


AIX first implemented a LDAP security load module in version 4.3. The module worked well in a uniform AIX environment. However, administrators found it hard to configure AIX systems to work with third party LDAP servers. This shortcoming is primarily the result of the proprietary schema used by AIX.

Since AIX version 5.2, it supports the schema defined in RFC 2307, which is widely used
among IBM systems. The schema defines attributes and object classes for such entities as users, groups, networks, services, hosts, protocols, rpc, etc. The RFC 2307 schema is often referred to as the nisSchema.

Client support for the nisSchema in AIX is part of Configurable Schema Support Mechanism (CSSM), which is a bigger effort to support arbitrary schema. With CSSM, AIX systems can be configured to support LDAP directory servers using any schema. At present, CSSM is implemented for users and groups only.

Configuring AIX to do naming lookup through LDAP for other network entities, including users and groups, is also implemented in AIX version 5.2. However, this article deals only with configuring services related to user authentication through LDAP.

The process is fairly simple. The only prerequisites involve extending the eDirectory schema with files already provided by Novell in the 8.8.2 ISO. Below is a list of sections to guide you through this process.


Extending the Schema

eDirectory 8.8.2 provides for the additional schema extensions as defined in RFC 2307, that are required for AIX version 5.2 and later.

There are two files located in the RPM /setup/novell-NDSserv-8.8.2-7.i586.rpm:


Note:Due to variations in the file versions, the above RPM name might not be exact.

Extract these two files using “File Roller” or your preferred extractor. Remember where you extracted them so you can retrieve them later in iManager.

Open iManager and login to the server that holds the Master of the Root Partition.

Expand Schema and select Extend Schema

Select “Add Schema from File”

Select Schema File and browse to the .sch file.

Specify your Server, port and admin account.

Click Finish on the Summary screen to start the process.

From the progress screen you can click Done or Download the log file to see the detail and troubleshoot any errors, if any occurred.

Repeat the process for BOTH Schema files.

Verify the extensions by selecting Attribute Information and scrolling down to one of the new extensions to see it's information.

If the process did not work to extend the schema, check your certificates, if used, and security equivalences for the account you used to extend the schema. Verify that the LDAP server is listening on the secure port (636) and has a certificate defined.

If all of these item check out, go back and try your extensions again. Remember to do BOTH files.

At this point, you can log out of iManager.

Note: The remaining part of this article pertains exclusively to AIX. If you are unfamiliar with AIX, contact your AIX Administrator and always use a test environment before attempting this in a production environment.

Creating the LDAP Client on AIX

There are several components that encompass the LDAP client on AIX. These components are configured individually and most require a simple edit.

  1. ldap.client

    This is the fileset for IBM Directory client. This fileset has to be installed for LDAP authentication to work. The ldap.client fileset is included in the AIX version 5.2.

  • /usr/lib/security/LDAP

    This is the LDAP load module. The 64-bit version of it is /usr/lib/security/LDAP64. When a library call is routed to LDAP, the LDAP load module is loaded. Both modules are installed by default as part of base operating system.

  • /usr/sbin/mksecldap

    This is the script to configure an AIX LDAP client. It is owned by user root and group security, with permission set to 500.

  • /usr/lib/security/methods.cfg

    This is the configuration file for the authentication module. mksecldap adds the following setting to enable the LDAP module during client setup:


    program = /usr/lib/security/LDAP

    program_64 = /usr/lib/security/LDAP64

  • /etc/security/ldap/ldap.cfg

    This is the configuration file for the secldapclntd client daemon. It contains information for secldapclntd to function correctly, e.g., host names of LDAP servers, bindDN and password, server port, SSL key location, etc. The file is updated by mksecldap command during the LDAP client setup. The default ldap.cfg file is included at the end of this article.

  • /usr/sbin/secldapclntd

    This is the client daemon that communicates with the LDAP server. It is owned by user root and group security, with permission set to 500. It can only be started by the root user or a privileged process like init. mksecldap starts this daemon after a successful client setup.

Client Configuration

The mksecldap command
mksecldap is an AIX command for IBM Directory server and client setup. The syntax for client setup is:

mksecldap -c -h server -a bindDN -p bindpwd [ -d baseDN ] [ -n serverport ] [ -k SSLkeypath ] [ -w SSLkeypasswd ] [ -t cacheTTL ] [ -C cachesize ] [ -P numberOfThread ] [ -T heartBeatInt ] [ -u userlist ] [ -U ]

The mksecldap command performs the following tasks for client configuration:

  1. Saves the LDAP server(s)' host name

  • Saves the baseDNs for users and groups.

  • If the server contains network information data, saves the baseDNs for hosts, networks, services, protocols, netgroup, and rpc.

  • If the network information data is found to exist from the LDAP server, updates the /etc/netsvc.conf, /etc/irs.conf, and /etc/rpc.conf files with the nis_ldap resolver for naming resolution through LDAP.

  • Sets communication to SSL if the -k and -w options are supplied.

  • Saves the admin DN and password.

  • Sets the cache size limit, if supplied from command line.

  • Sets the cache TTL value, if supplied from command line.

  • Sets the number of threads used by the secldapclntd daemon, if supplied from command line.

  • Sets the list of users to use LDAP by changing value of the SYSTEM and registry attributes to LDAP and saves the value to the /etc/security/user file, if -u option is supplied from command line.

  • Updates the /usr/lib/security/methods.cfg file with the following LDAP setting:


    program = /usr/lib/security/LDAP

    program_64 = /usr/lib/security/LDAP64

  • Starts the secldapclntd client daemon.

  • Adds an entry to the /etc/inittab file so that the secldapclntd daemon will be started after reboot.

Steps 3 and 4 apply to AIX version 5.2 and later only.


-a adminDN
Specifies the LDAP server administrator DN. It must match the one used for the server setup.

-c Indicates the command is being run to setup a client.

-C cachesize
Specifies the maximum number of user entries used in the client side daemon cache. Valid values are 100-10,000 for user cache. The default value is 1,000. The group cache size is 10% of that of user cache.

-d baseDN
Specifies the suffix or base DN for the mksecldap command to search for
base DNs for users, groups, and other network information entities. If not specified from the command line, the entire database is searched.

-h serverlist
Specifies a comma separated list of LDAP server host names (server and backup servers).

-k SSLkeypath
Specifies the full path to the SSL key database.

-n serverport
Specifies the port number that the LDAP server listens to.

-p adminpasswd
Specifies the clear text password for the administrator DN of the LDAP server. It must match the one used for the server setup.

-P numberofTreads
Specifies the number of threads the client side daemon uses. Valid values are 1-1,000. The default is 10.

-t cacheTTL
Specifies the maximum time length that a cache entry expires. Valid values are 60-3,600 seconds. The default is 300 seconds. Set this value to 0 to disable caching.

-T heartBeatInt
Specifies the time interval of heartbeat between this client and the LDAP server. Valid values are 60-3,600 seconds. Default is 300.

-u userlist
Specifies the comma separated list of usernames. Specify ALL to enable all users on the client.

-w SSLkeypasswd Specifies the password for the SSL key.

-U Specifies to undo the previous server setup to the /etc/security/ldap/ldap.cfg configuration file. All setup information is saved to the /etc/security/ldap/ldap.cfg file.

Client Setup Examples

The examples shown are for reference only

Example 1:

# mksecldap -c -h ldapserver1.mycompany.com -a cn=admin,o=org -p password

This sets up the local host as a client of the LDAP server running on host ldapserver1.mycompany.com.
cn=admin,o=org and password are the LDAP server administrator DN and password respectively.

Example 2:

# mksecldap -c -h myserver2.yourdomain.com -a cn=admin,o=novell -p password -n 1636

This sets up the local host as a client of the LDAP server running on host myserver2.yourdomain.com.
The -n 1636 indicates that the server is listening on port 1636.

Example 3:

# mksecldap -c -h anotherserver -a cn=admin,o=org -p password -k /usr/ldap/key.kdb -w

This sets up the local host as a client of the LDAP server running on host anotherserver using SSL secure communication. The SSL key is /usr/ldap/key.kdb and the password to the key is letmein. To run this command, you will have to install the GSKit package on the AIX server, and create the client key using the key generation tool from the package. For more information on generating the SSL key, see the Enabling SSL for Secure Communication section, below.

Example 4:

# mksecldap -c -h ldapserver1 -a cn=admin,o=novell -p password -u tjames,rking

This sets up the client and enables tjames and rking to login using LDAP.
mksecldap sets SYSTEM and registry attributes to LDAP for tjames and rking. The SYSTEM attribute controls the login authentication path, and the registry attribute indicates where a user is administered. If -u ALL is used in place of -u tjames,rking, then all locally defined users will have their SYSTEM and registry attributes set to LDAP. These users have to be defined in the LDAP server to login to the local system, otherwise, they will get the following message when they try to login:

3004-007 You entered an invalid login name or password.

Examples 1 - 3 set up the local host to be a client of a LDAP server(s), but do not enable LDAP authentication mechanism for users. To enable LDAP login, either use the -u option shown in example 4 above

Another option is to configure the client manually.

Client Configuration – Manual

  1. Configuring the secldapclntd Daemon

    The default /etc/security/ldap/ldap.cfg client configuration file has all the entries commented out. The default configuration file has all the necessary entries and description for each entry to help with the manual configuration process.
    The minimum set of attributes that has to be set:




    Comma separated list of LDAP servers


    LDAP server administrator DN or privileged bindDN


    Administrator bind password


    Path to user attribute map


    Path to group attribute map


    Path to id attribute map


    Parent DN where user entries are stored


    Parent DN where group entries are stored


    Parent DN where id entry is stored


    LDAP server listening port

  • Enabling LDAP Loadmodule

    Edit the /usr/lib/security/methods.cfg file, and append the following setting to it:


    program = /usr/lib/security/LDAP

    program_64 = /usr/lib/security/LDAP64

  • Start secldapclntd Daemon

    Simply enter secldapclntd at command line to start the daemon:

    # /usr/sbin/secldapclntd

    Once secldapclntd daemon is running, try to test the configuration by running the lsuser command:

    # /usr/sbin/lsuser -R LDAP tjames

    Where tjames is an example of a user name of an account defined in LDAP. If the user is listed, the configuration is successful. Otherwise, if you are sure tjames exists in LDAP and lsuser fails to list the user, configuration is not correctly done. Edit the /etc/security/ldap/ldap.cfg file and make corrections, restart the secldapclntd daemon and try the command again.

  • Update /etc/inittab

    Run the following command to add secldapclntd daemon to /etc/inittab file. This makes the init process start secldapclntd daemon automatically after reboot.

    # /usr/sbin/mkitab "ldapclntd:2:once: /usr/sbin/secldapclntd >dev/console 2>&1"

    LDAP User Enable

    1. The SYSTEM Attribute

      After configuring an AIX system using mksecldap, one more step is needed to enable user login through LDAP. User authentication is controlled by the SYSTEM variable of the /etc/security/user file. The AIX administrator has to set a LDAP user's SYSTEM attribute to LDAP for the user to login to the local system. For example, to enable LDAP user tjames to login to the system, run:

      # chuser SYSTEM=LDAP registry=LDAP tjames

      To allow all LDAP users to login to the system, you can set each LDAP user's SYSTEM attribute to LDAP, or simply set the default setting's SYSTEM attribute to LDAP (you has be do this manually to the /etc/security/user file). However, the implication of the two is different. By setting each user's SYSTEM attribute to LDAP, an administrator explicitly sets that these users to login through LDAP, with the implication that any newly defined local users whose SYSTEM is not set can continue to login through compat mechanism (or whatever the default SYSTEM attribute is set to). By setting the default SYSTEM to LDAP, an administrator implicitly defines that all users whose SYSTEM is not set to any value will login through LDAP. At the login time, the login process checks for the user's SYSTEM attribute to authenticate the user accordingly. If a user's SYSTEM is not defined, the default SYSTEM value is used.

  • The registry Attribute

    AIX user management is controlled by the registry attribute, which specifies where the user is administered. If a user account exists both locally and in LDAP, AIX requires both the SYSTEM and registry be set to the same value to work correctly. The only exception to this rule is that each LDAP account is unique, i.e., no corresponding local account exists. The registry determines which user database to use when managing users and it also determines the location where login activity is logged. By setting the SYSTEM and registry differently, you will run into the risk that the user is defined to login through one mechanism, but the user's account activity is logged to a different user database. It may also result in root managing the wrong account when changing password, locking the account, etc.

    A safe way of avoiding such problems is to set the SYSTEM and registry to the same value, e.g.,

    # chuser SYSTEM=LDAP registry=LDAP tjames

    NOTE: This is especially important for the default setting of the /etc/security/user file. You have to remember to add "registry = files" to the root setting if the default registry is set to LDAP, otherwise root may not be able to login to the system.

    Although multiple authentication mechanisms can be configured (through the SYSTEM and registry attributes), it is highly recommended that each system only enable one mechanism to simplify user management and minimize related security issues.
    If you need both local and LDAP login, do the following to minimize any side effect:

    Synchronize locally defined users with LDAP users, or Create unique LDAP users with no corresponding local users - no sharing of same id between local and LDAP users.

  • Security

    To prevent unauthorized access to resources that you should not normally be allowed to, it is highly recommended that a system be configured to use a single authentication mechanism. Currently there are few tools to synchronize users/groups across multiple user registries. Under most cases users and groups are out of sync between registries. Allowing multiple authentication mechanisms can result in a user having unauthorized access to resources.

    Such unauthorized access to resources is due to user id "conflict" between two user registries – two user accounts defined in two different registries but they "share" the same numeric user id. When a user login to one of the accounts, he will be able to access the files that are really owned by another user defined in a different registry. An administrator has to take steps to avoid such conflict when enabling a system for multiple authentication mechanisms.

  • Host Login Control

    As described in #3, above, an easy way to enable LDAP authentication is to set the default SYSTEM attribute to LDAP. However, this potentially enables login of all users defined remotely in LDAP. To prevent such from happening, AIX has enforced a host login control mechanism.

    Since AIX version 5.2, two new attributes, hostsallowedlogin and hostsdeniedlogin, are introduced for this purpose. These two new attributes are user attributes and therefore host login control can be defined on a per user bases. Existing high level commands, e.g., mkuser, chuser, and lsuser, support these two new attributes.
    Here are some examples of setting which hosts a user can or cannot login to:

    # mkuser -R LDAP hostsallowedlogin=ldapserver tjames

    This creates a new user account tjames, and sets so the user tjames is allowed to login only to host ldapserver.

    # chuser -R LDAP hostsdeniedlogin=ldapserver rking

    This sets the user rking is denied login to host ldapserver, but is allowed to login to any other hosts.

    # chuser -R LDAP hostsallowedlogin=192.168.0/24 rking

    This sets the user rking is allowed login to any hosts in the network 192.168.0/24

    A few other notes when using the host login control mechanism:

    hostsallowedlogin and hostsdeniedlogin can be used jointly.

    In case of conflict, hostsdeniedlogin takes precedence.

    If neither is defined, the default values will be checked and login decision made.

    If neither the user's or the defaults get set, user is allowed to login to any system. This is for backward compatibility.

    To set default behavior for host login control in LDAP, find the default entry from the LDAP user database, and add the hostsallowedlogin and/or hostsdeniedlogin attributes with appropriate values.

    This can be done by running the ldapmodify command.

    AIX systems earlier than version 5.2 are not aware of the hostsallowedlogin and hostsdeniedlogin attributes and are not controlled by this mechanism.

  • Default Entry in LDAP

    Each LDAP user database has a default entry, just as the local default setting of /etc/security/user. The LDAP default entry is stored together with all other user entries under the same user base DN. The default entry's RDN is "uid=default" if the server is RFC 2307 compliant The default entry is for internal use only, no one is allowed to login or bind using that entry.

    The function of the default entry is exactly the same as the local default setting of the /etc/security/user file, with the default entry being used only in the LDAP environment and the local default setting being used in compat (local NIS) mode. The only difference is that the SYSTEM and registry attributes are always stored/retrieved from the local default setting. These two attributes determine the local system authentication and user management behavior, and do not mean anything if stored in the LDAP database.

    Unlike a regular LDAP user account, the default entry is not treated as a user account by AIX, and AIX high level commands do not work on the default entry. To add/delete/set an attribute of the default entry, you have to use the ldapmodify command.

    Enabling SSL for Secure Communication

    Follow these steps to generate the client key database, import the server certificate, and configure a client to use SSL:

    Use iManager to export a server certificate.

    Install GSKit on each client system.

    Run gsk5ikm to generate the key database on each client

    Copy the server certificate to each of the clients.

    On each client system, run gsk5ikm to import the server certificate to the key database:

    1. Enter gsk5ikm at the command line.

  • Click Key Database File menu bar and select Open.

  • Enter the path and name of the existing key database file then click OK.

  • Enter the password.

  • Ensure Signer Certificates is chosen and Click on Add.

  • Enter the name and location of the server's certificate file

  • Enter a label for the server certificate entry in the client's key database file, for example, 'LDAP Server' then click OK.

  • Click View/Edit, mark Set the certificate as a trusted root, then click OK.

Enable SSL for each client:

# mksecldap -c -h servername -a adminFDN -p pwd -k /usr/ldap/etc/mykey.kdb -p password

where /usr/ldap/etc/mykey.kdb is full path to the key database, password is the password to the key.

  1. Enter gsk5ikm

  • Click Key Database File menu bar and select Open.

  • Enter the path and name of the existing key database file; then click OK.

  • Enter the password.

  • Ensure Personal Certificates is chosen and Click on New Self-Signed Certificate.

  • Enter Key Label, Common Name, Organization, select Version and Key Size; then click OK.

  • Select the new certificate you just created, click Extract Certificate.

  • Select the Data Type, enter the Certificate file name and Location; then click OK.


Test your setup by initiating a Secure Shell connection, SSH, to the AIX server. Enter your eDirectory credentials and your AIX welcome text should appear. If not, double check your ldap.cfg file to be sure there are no stray characters AND that any of your parameters are not still commented out.


Although Novell's Identity Management would also centralize account management for AIX through a driver, this solution provides a different avenue to local AIX account access and simplifies management through eDirectory. Enjoy.


# Comma separated list of ldap servers this client talks to

# LDAP server bindDN

# LDAP server bindDN password

# Whether to use SSL to communicate with the LDAP server. Valid value
# is either "yes" or "no". Default is "no".
# Note: you need a SSL key and a password to the key to enable this.
#useSSL: no

# SSL key file path and key password

# AIX-LDAP attribute map path.

# Base DN where the user and group data are stored in the LDAP server.
# e.g., if user foo's DN is: username=foo,ou=aixuser,cn=aixsecdb
# then the user base DN is: ou=aixuser,cn=aixsecdb

# LDAP class definitions.

# LDAP server version. Valid values are 2 and 3. Default is 3.

# LDAP server port. Default to 389 for non-SSL connection and
# 636 for SSL connection

# Follow aliases. Valid values are NEVER, SEARCHING, FINDING, and
# ALWAYS. Default is NEVER.

# Number of user cache entries. Valid value is 100 - 10000 entries.
# Default is 1000.
#usercachesize: 1000

# Number of group cache entries. Valid value is 10 - 1000 entries.
# Default is 100.
#groupcachesize: 100

# Cache timeout value in seconds. Valid value is 60 - 60*60 seconds.
# Default is 300. Set to 0 to disable caching
#cachetimeout: 300

# Time interval in seconds that the secldapclntd daemon contact the
# LDAP server for server status. Valid value is 60 - 60*60 seconds.
# Default is 300.
#heartbeatinterval: 300

# Number of threads the secldapclntd daemon uses to to process jobs.
#Valid value is 1 - 1000. Default is 10
#numberofthread: 10

Comment List
  • Mike,
    Ran into this issue on AIX, and the AIX guy kept coming up with this doc. (Hey Duane!) Just to call it out, but this one line, solved our issue:

    userattrmappath Path to user attribute map

    I was watching in Dstrace +LDAP and seeing all these AD style attributes being requested, and I tried to map them one by one. I kept noting that somehow we were thinking we were pointing at AD, not LDAP/eDir.

    Reading your article pointed me right at that key file, and lo and behold there it was, wrong map file. Awesome, now we can fix it.

    Now what is shadowLastChanged (mandatory) meant to store? Hmm... I can make it have whatever we need via IDM or map it to whatever we need it to be. But that is an 'easy' one to resolve I think.
  • In addition to this tutorial I wrote one for AIX 5.3 with some extra functionality.

    First, the ldap.client fileset is officially not available anymore for AIX 5.3 It will probably work but chances are it's not supported anymore.

    I also added some documentation so home directories get automatically created when using SSH to login, and showed how to use LDAP groups for your sudo config.

    You also assume you're in an eDirectory environment on which user objecten are already linux-enabled, which was not the case in my test environment so I added some notes about that as well.

    This is the link:
  • If you can't see the new attributes. A browser refresh did the trick. Took me a little time to figure out what went wrong, but turns out it was nothing other than not finding anything new in cached data. ;-)