AIX LDAP Client (secldapclntd) Enhancements 

This document lists the LDAP client enhancements included in AIX 7.3 TL4.

• Enable AIX LDAP Client (secldapclntd) for user and group management on MSAD without relying on Identity Management for Unix (IDMU Unix attributes plugin), which has been deprecated starting with Windows Server 2012 R2.
• Support strong block cipher algorithms for the bind DN password.
• Change the default password algorithm from crypt to ssha256 for Security Verify Directory Server when configured using mksecldap -s, and from crypt to system in /etc/security/ldap/ldap.cfg when configuring the client using mksecldap -c.
• Provide a method to specify the default home directory and default shell for remote LDAP users.
• The AIX secldapclntd daemon and LDAP load module must successfully recognize and interpret the timestamp format used by the FreeIPA server.

Enable AIX LDAP Client (secldapclntd) for user and group management on MSAD without relying on Identity Management for Unix (IDMU Unix attributes plugin), which has been deprecated starting with Windows Server 2012 R2.

A Unix user has attributes such as username, UID number, group ID number, primary group ID number, comment (GECOS), home directory, and login shell. These attributes allow an Active Directory user to appear as a standard Unix user. Identity Management for Unix (IDMU), a component of Microsoft’s Service for Unix (SFU) package, enabled system administrators to configure these attributes through a GUI. Until Windows Server 2012, when using Windows AD as an LDAP server, IDMU simplified the process of updating Unix attributes such as uid, uidNumber,  gidNumber, PrimaryGroupID, homedirectory, and loginshell.

Starting with Windows Server 2012 R2, Microsoft deprecated the Services for Unix (SFU) package and removed the Unix attributes plug-in from the Active Directory Users and Computers console in Windows Server 2016. Although RFC2307 attributes (such as UID and GID) remain available, they may be deprecated in future releases. To prevent authentication failures when Unix attributes are missing, secldapclntd has been enhanced to automatically generate uidNumber, gidNumber, and other required attributes for users and groups managed in MSAD.

In Microsoft Windows, every object (such as an account, group, or device) that operates within a security context is assigned a unique Security Identifier (SID) by the Windows domain controller. This SID is returned as objectSid in binary format during LDAP queries for users or groups. The AIX secldapclntd client uses the last four bytes of objectSid, known as the Relative Identifier (RID), which is unique for each object within the domain. To prevent authentication issues when Unix attributes are missing, secldapclntd now automatically generates uidNumber and gidNumber from the RID and uses LDAP filters to retrieve user and group attributes from Active Directory. Additionally, a new mksecldap client configuration flag has been introduced for ID generation and mapping, stored as a new field in /etc/security/ldap/ldap.cfg. When enabled, all authentication logic uses this implementation, while existing users or groups with preconfigured Unix attributes (such as uid, cn, uidNumber, and gidNumber) retain their original values and do not receive new IDs.

Limitations:

• As part of this feature, user and group attributes retrieved from the AD server will be mapped only to username, groupname, id, and pgrp. Attributes previously mapped in SFU versions 2 and 3 will no longer be supported.
• This new functionality, which supports the ID generation feature, can be enabled through a idgeneration configuration option and is disabled by default.
• The domain tree on the AD server must be created before configuring the secldapclntd client. Similarly, on the AIX LDAP client side, assign a dedicated domain ID number to a specific MSAD domain. Any removal of an existing domain or addition of a new one can disrupt object authentication or access rights.
• This feature supports the following user and group management commands: lsuser, chuser, rmuser, lsgroup, chgroup, rmgroup, id, and groups.
• The generated ID uses up to six digits derived from the RID value in the MS AD Security Identifier. Therefore, the maximum RID value that can be used to generate a UID or GID is 9,99,999.

AIX LDAP client ID generation workflow

A sample method of creating user or group on AD is shown below: - 

Create the LDAP AD user and group at the WINDOWS server. For an example username is "user1" and group name is "grp1". In this case for user & group uidNumber & gidNumber are not being assigned instead will generate automatically.

Below are the steps to validate the user created on the WINDOWS AD server side does not have any uidNumber assigned.

• Navigate to Active Directory Administrative Center on the Windows AD server.
• Select the “Extension” tab for user1.
• Select the “Attribute Editor” tab for user1.
• Locate the uidNumber attribute that is unset

Below are the steps to validate the group created on the WINDOWS AD server side does not have any gidNumber assigned.

• Navigate to Active Directory Administrative Center on the Windows AD server.
• Select the “Extension” tab for grp1.
• Select the “Attribute Editor” tab for grp1.
• Locate the gidNumber attribute that is unset.

Below are the steps now to be followed from the LDAP client side to validate the UID & GID of the user "user1" & group "grp1" whereas by default idgeneration & domainid flag is disabled.

•      By default, the " idgeneration"  flag is disabled.
•      By default, the " domainid " flag is disabled
•      Now run "mksecldap -c" command to enable the flags "idgeneration" and " domainid "
•      Ensure that both the " idgeneration " and " domainid " flags are enabled.
•      Execute a query on the Windows AD server for user user1 to confirm that the " uidNumber " has been automatically generated
•      Execute a query on the Windows AD server for group grp1 to confirm that the " gidNumber " has been automatically generated.

Support strong block cipher algorithms for the bind DN password.

When configuring the secldapclntd client using mksecldap -c, the bind DN password is encrypted with a block cipher algorithm (DESv2) and stored in the /etc/security/ldap/ldap.cfg file. Secldapclntd is enhanced to support a stronger algorithm.

• Initially, no bindpwd was configured.
• Execute the LDAP client command. 
• Confirm that bindpwd is configured using a stronger algorithm.

Change the default password algorithm from crypt to ssha256 for IBM Security Verify Directory server when configured through 'mksecldap -s'.

When an administrator creates any local user(s) and sets a password, the password is hashed using the password hash algorithm defined in /etc/security/login.cfg. If the system is configured as an LDAP server using mksecldap -s, all these users are migrated to the LDAP server database. Prior to AIX 7.3, the default password algorithm was set to crypt on both the client and the server. During user authentication, when the client authentication type (authtype in /etc/security/ldap/ldap.cfg) is set to ldap_auth, the client sends the plaintext password to the LDAP server. The server then hashes this password using its configured password algorithm and compares it against the stored hashed password in the database.

Starting with AIX 7.3, the default password algorithm for local users on client systems was changed to ssha256. However, if the ISVD (IBM Security Verify Directory, formally known as Security Directory Server) is configured on AIX 7.3 or later using the mksecldap -s command, the default password algorithm remains crypt. In this configuration, the default password hash algorithm for the secldapclntd client, specified in /etc/security/ldap/ldap.cfg under the pwdalgorithm parameter, and the password hash algorithm on the IBM Security Verify Directory (LDAP server), specified by ibm-slapdPwEncryption, is set to crypt. Since crypt is considered a weak algorithm, it should be replaced with a stronger one. As part of this enhancement, the default password algorithm on the ISVD/SDS server is updated to ssha256.

Prior to AIX 7.3, the pwdalgorithm option in /etc/security/ldap/ldap.cfg, used by the AIX LDAP client daemon, was set to crypt by default. Starting with AIX 7.3, the password algorithm for local users was changed to ssha256. Therefore, the pwdalgorithm option in /etc/security/ldap/ldap.cfg should be updated to system, which allows any password algorithm retrieved from the LDAP server during authentication when auth_type is set to unix_auth.This feature ensures that the default pwdalgorithm is set to system when auth_type is configured as unix_auth.

Post configuring the LDAP server, the default value of ibm-slapdPwEncryption is set as sha256

• After LDAP server configuration, the ibm-slapdPwEncryption parameter is set to ssha256.
• By default, the pwdalgorithm parameter is set to system.

Method Provide a method to specify the default home directory and default shell for remote LDAP users.

There may be situations where system users are defined remotely through ISVD or Windows Active Directory. Although it is typically possible to set a user's home directory and shell on the remote system, there may be cases where these attributes are left undefined. If one of these users logs in to AIX, they will be placed in the root directory (/) because no home directory is defined, and SSH will default to using the /usr/bin/ksh shell.

In such situations, it would be helpful to define a default home directory and shell in a configuration file. If a query to the remote server does not return a user's home directory or shell through standard attribute lookup, the system should check this file and use the specified values to create a default home directory (/home/<username>) and set the default shell (/usr/bin/ksh) for that user. To support this feature, two new fields—defaulthomedirectory and defaultloginshell—have been added to /etc/security/ldap/ldap.cfg.

• By default, the defaultloginshellattributes is disabled.
• By default, the defaulthomedirectory attributes is disabled.

Before enabling the attributes defaulthomedirectory and defaultloginshell, if we query the user user1, the user’s attributes do not include loginshell or homedirectory.