Show Table of Contents
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.1. Searching for Entries Using the Account Usability Extension Control
The Account Usability Extension Control is an extension for an
ldapsearch. It returns an extra line for each returned entry that gives the account status and some information about the password policy for that account. A client or application can then use that status to evaluate authentication attempts made outside Directory Server for that user account. Basically, this control signals whether a user should be allowed to authenticate without having to perform an authentication operation.
Note
The OpenLDAP tools used by Directory Server do not support the Account Usability Extension Control. Other LDAP utilities, like OpenDS, can be used or other clients which do support the control.
For example, using the OpenDS tools, the control can be specified using the
-J with the control OID (1.3.6.1.4.1.42.2.27.9.5.8) or with the accountusability:true flag:
[jsmith@server ~]$ pathToOpenDsLdapTools/bin/ldapsearch -D "cn=directory manager" -W -p 389 -h server.example.com -b "dc=example,dc=com" -s sub-J "accountusability:true""(objectclass=*)" # Account Usability Response Control# The account is usabledn: dc=example,dc=com objectClass: domain objectClass: top dc: example ...
This can also be run for a specific entry:
[jsmith@server ~]$ pathToOpenDsLdapTools/bin/ldapsearch -D "cn=directory manager" -W -p 389 -h server.example.com -b "uid=bjensen,ou=people,dc=example,dc=com" -s base-J "accountusability:true""(objectclass=*)" # Account Usability Response Control# The account is usabledn: uid=bjensen,ou=people,dc=example,dc=com ...
Note
By default, only the Directory Manager can use the Account Usability Extension Control. To allow other users to use the Account Usability Extension Control, set on ACI on the supported control entry under
cn=features. See Section 14.3.2, “Changing What Users Can Perform an Account Usability Search”.
The control returns different messages, depending on the actual status of the account and (if the user has a password) the password policy settings for the user account.
Table 14.3. Possible Account Usability Control Result Messages
| Account Status | Control Result Message |
|---|---|
| Active account with a valid password | The account is usable |
| Active account with no password set | The account is usable |
| Expired password | Password expired |
| The password policy for the account is modified | Password expired |
| The account is locked and there is no lockout duration | Password reset |
| The account is locked and there is a lockout duration | Time (in seconds) for automatic unlock of the account |
| The password for the account should be reset at the first login | Password reset |
| The password has expired and grace logins are allowed | Password expired and X grace login is allowed |
| The password has expired and the number of grace logins is exhausted | Password expired |
| The password will expire (expiration warning) | Password will expire in X number of seconds |
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, 1.3.6.1.4.1.42.2.27.9.5.8.
For example:
[jsmith@server ~]$ ldapmodify -D "cn=directory manager" -W -x
dn: oid=1.3.6.1.4.1.42.2.27.9.5.8,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.
Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.