14.3. Checking Account Availability for Passwordless Access

Most of the time, for the Directory Server to return authentication information about a user account, a client actually binds (or attempts to bind) as that user. And a bind attempt requires some sort of user credentials, usually a password or a certificate. While the Directory Server allows unauthenticated binds and anonymous binds, neither of those binds returns any user account information.
There are some situations where a client requires information about a user account — specifically whether an account should be allowed to authenticate — in order to perform some other operation, but the client either does not have or does use any credentials for the user account in Directory Server. Essentially, the client needs to perform a credential-less yet authenticated bind operation to retrieve the user account information (including password expiration information, if the account has a password).
This can be done through an ldapsearch by passing the Account Usability Extension Control. This control acts as if it performs an authenticated bind operation for a given user and returns the account status for that user — but without actually binding to the server. This allows a client to determine whether that account can be used to log in and then to pass that account information to another application, like PAM.
For example, using the Account Usability Extension Control can allow a system to use the Directory Server as its identity back end to store user data but to employ password-less authentication methods, like smart cards or SSH keys, where the authentication operation is performed outside Directory Server.

14.3.2. Changing What Users Can Perform an Account Usability Search

By default, only the Directory Manager can use the Account Usability Extension Control. Other users can use the Account Usability Extension Control by setting the appropriate ACI on the supported control entry. The control entry is named for the Account Usability Extension Control OID,
For example:
[jsmith@server ~]$ ldapmodify -D "cn=directory manager" -W -x

dn: oid=,cn=features,cn=config
changetype: modify
add: aci
aci: (targetattr != "aci")(version 3.0; acl "Account Usable"; allow (read, search, compare, proxy)(groupdn = "ldap:///cn=Administrators,ou=groups,dc=example,dc=com");)

14.3.3. Using pam_ldap Account Management with the Account Usability Control

The pam_ldap module allows a local system to use passwordless authentication mechanisms (like SSH keys, rlogin, and rsh) while still using an LDAP directory to store user information. The pam_ldap module connects to the Directory Server to verify that an account is active, is not locked, and has a valid password (if applicable). When a user uses a passwordless authentication method, then the pam_ldap module must retrieve the account status without authenticating to the LDAP server as the actual user.
PAM can be configured first for system account management, and then to use the pam_ldap module as one of its authentication sources. On Red Hat Enterprise Linux, the PAM account management is configured in the /etc/pam.d/other file.
The default account configuration does not use PAM for account management:
account  required       pam_deny.so
This can be changed to use first system accounts and then LDAP-stored accounts for system authentication. For example:
account  requisite      pam_roles.so.1
account  binding        pam_unix_account.so.1 server_policy
account  required       pam_ldap.so.1
If a user is found in a system account, that account is used first (pam_unix_account). If the user is not found there, then PAM checks the LDAP server. The LDAP configuration is set in the /etc/pam_ldap.conf file. That configuration file needs to set only the connection information for the Directory Server instance, such as its base DN, host, and port. Because the Account Usability Plug-in is enabled by default, the Directory Server is already configured to allow Account Usability Control searches for clients.