Configuring the Remote Active Directory authentication profile
    User Directory
    Host
    Port
    Remote Directory Tree
    Scope
    Bind
    User Template
    SSL
    SSL CA Certificate
    SSL Client Key
    SSL Client Certificate
Configuring the default access for remotely authenticated users
    BIG-IP version 10.x - 11.x
    BIG-IP version 9.x
Example remote Active Directory system authentication profiles
The remote authentication process
Verifying remote authentication
Verifying user search requests
Verifying user binding
Verifying the server's certificate

This document defines F5 best practice recommendations for configuring and verifying remote Active Directory Lightweight Directory Access Protocol (LDAP) authentication of administrative connections.

Note: As with all remote authentication configurations, if the configured LDAP server is unavailable to answer authentication requests, the BIG-IP system uses the local user account database for authentication, and only locally defined user accounts, such as the default admin WebUI account and the root command line account, are able to log in to the system.

Note: For more information about LDAP, refer to RFC2251: Lightweight Directory Access Protocol (v3). This link takes you to a resource outside of AskF5, and it is possible that the information may be removed without our knowledge.

Configuring the Remote Active Directory authentication profile

You must configure a number of options to enable BIG-IP Active Directory LDAP authentication of administrative traffic.

Note: To configure system authentication options, using the BIG-IP Configuration utility, navigate to the System > Users > Authentication screen. For more information about configuring system authentication, refer to the Implementation Guide for your product and version.

User Directory

The User Directory option specifies the authentication source. To configure the BIG-IP system to use a remote Active Directory server for authentication of administrative sessions, select Remote - Active Directory.

Host

The Host option specifies the remote system hosting the LDAP database that the system will use for remote authentication. Only one host may be specified. In versions 9.0 through 9.4.7, and in version 9.6.x, this should be the IP address of the Active Directory authentication server. In versions 9.4.8 and later, you may specify either a hostname or an IP address.

Note: You can use a hostname or address that refers to a highly-available virtual server. For more information, refer to SOL11199: Creating a high availability LDAP authentication configuration.

Note: F5 is currently tracking, as CR112085, a request for enhancement (RFE) to assign multiple LDAP servers in a system authentication profile.

Important: In versions 9.4.8 and later, if you have configured SSL and a Trusted CA, you must set the value of the Host option to an FQDN, such as ldap.example.com, rather than an IP address. The FQDN must match the FQDN embedded in the CN (CommonName) attribute of the X509 subject of the certificate presented by the Active Directory LDAP server. For example, an LDAP server may present a certificate that includes the following subject data:

Subject: C=US, ST=Washington, L=Seattle, O=ldap1, OU=F5 Networks, CN=ldap1.example.com/emailAddress=ldap1@example.com

If the value for the Host option does not match the FQDN embedded in the CN field, authentication fails. Specifying an IP address instead of a hostname results in such a mismatch, and authentication fails.

Port

The Port option specifies the port that the system uses for access to the remote LDAP host server. The default port is 389. If your Active Directory server uses an alternate port, specify it here.

Note: If you are using a highly-available virtual server, such as the one created in SOL11199: Creating a high availability LDAP authentication configuration, enter the virtual service port here.

Remote Directory Tree

The Remote Directory Tree option specifies the file location of the user authentication database in the remote directory tree of the Active Directory LDAP server. At minimum, you must specify a domain component.

Note: F5 recommends that you configure the most specific Base DN possible to limit the scope of the search. If using Active Directory, it is especially important to help avoid chasing referrals. For more information about the impact of chasing referrals, refer to SOL9311: Best Practices for LDAP Monitoring. 

Scope

The Scope option specifies the level of the remote LDAP directory that the system should search for the user authentication. The following three options are available:

Note: The default setting is Sub.

• Base
  
  Specifies that the system searches the remote directory based on the access permissions of the DN that you specify in the Bind setting.
• One
  
  Specifies that the system searches one level of the remote directory.
• Sub
  
  Specifies that the system searches all subdirectories of the remote directory.

F5 recommends that you configure the most specific search possible. If using the default Sub setting, F5 recommends that you specify, for the Remote Directory Tree option, the lowest common level in the tree that contains all system users.

Note: If you are using a highly-available virtual server, such as the one created in SOL11199: Creating a high availability LDAP authentication configuration, these settings should match those configured for the custom LDAP monitor.

Bind

The Bind option specifies the distinguished name for binding to the LDAP server.

• DN
   
  Specifies the distinguished name when binding to the LDAP server.
• Password
  
  Specifies a password for the user account.
  
  

  Note: If you are using local authentication and you have created a password enforcement policy, this password must meet the criteria specified in the password enforcement policy.

• Confirm
  
  Confirms the password for the user account. The Password and Confirm entries must match.

Note: The Bind and User Template options are mutually exclusive. You can define one setting or the other, but not both.

Note: If you are using a highly-available virtual server, such as the one created in SOL11199: Creating a high availability LDAP authentication configuration, these settings should match those configured for the custom LDAP monitor.

User Template

The User Template option defines which part of the supplied login credentials is used to construct the distinguished name when binding to the LDAP server. For example, you could specify a User Template value that appears similar to the following example:

'%s@siterequest.com'

or

'uid=%s,ou=people,dc=siterequest,dc=com'

When a user attempts to log in, the system replaces %s with the value that the user typed in the Basic Authentication username dialog box, and passes the resulting string as the distinguished name for the bind request, along with the password that the user typed in the Basic Authentication dialog box. The User Template value can contain only one instance of the %s formatting string, and cannot contain any other formatting strings.

Note: Although the BIG-IP system allows simultaneous configuration of the Bind and User Template options, they are mutually exclusive. You can define one value or the other, but not both.

SSL

The SSL option specifies whether the system uses an SSL port to communicate with the LDAP server. If you enable this setting, the Port number changes automatically to 636, and the screen presents additional options for specifying SSL certificate-related values.

SSL CA Certificate

The SSL CA Certificate option specifies the name of an SSL certificate from a certificate authority (CA).

Note: Always provide the full path to the CA certificate file:

/config/ssl/ssl.crt/My-Trusted-CA-Bundle.crt

Note: In versions 9.4.8 and later, if you have configured SSL and a Trusted CA, you must set the value of the Host option to a FQDN, such as ldap.example.com, rather than an IP address. For more information, refer to the Host section, previously.

SSL Client Key

The SSL Client Key option specifies the name of an SSL client key when encrypting data sent to the Active Directory sever.

Note: The key cannot be a passphrase-protected key. To remove the passphrase, use the following syntax and replace client-key-with-password.key with the original key name client.key and the name of the new key:

openssl rsa -in client-key-with-password.key -out client.key

When prompted, enter the passphrase for client-key-with-password.key. The new key passphrase-free key will be written to the specified file.

SSL Client Certificate

The SSL Client Certificate option specifies the name of an SSL client certificate when binding to the Active Directory server.

Configuring the default access for remotely authenticated users

To configure the default access for remotely authenticated users, perform the procedure appropriate for your version, as follows:

BIG-IP version 10.x - 11.x

1. If you just completed the Active Directory configuration listed previously, continue to the External Users section of the current screen (System > Users > Authentication).  Alternatively, browse to the System > Users screen and click the User Name Other External Users.
2. In the Role drop-down menu, select the default access level that will be assigned to remotely authenticated users.
3. If you select a non-administrator user role, an optional setting appears for granting partition access to the user. To grant the user access to only the Common partition, select Common from the Partition Access drop-down menu.
4. In the Terminal Access drop-down menu, select Disabled, tmsh access, or bigpipe shell access (v. 10.x only).
5. Click Update or Finished to save your changes.

Note: For more information about the accesses granted by each Role, refer to the Configuring Remote Authentication and Authorization for Administrative traffic chapter of the BIG-IP Local Traffic Manager: Implementations Guide.

BIG-IP version 9.x

1. Click the User Name Remote Access.
2. In the Web User Role drop-down menu, select the default access level that will be assigned to remotely authenticated users.
3. If you select the Administrator user role, an optional setting appears for granting console access to the user. To grant the user access to the BIG-IP system through the command-line interface, select the Allow Console Access box.
4. To save your changes, click Update.

Note: For more information about the accesses granted by each Role, refer to the Managing User Accounts chapter of the BIG-IP Network and System Management Guide.

Note: You may also use the bigpipe remoterole command to authorize access based on individual user attributes.

Example remote Active Directory system authentication profiles

A remote Active Directory system authentication profile that is constructed according to the recommendations in this Solution appears similar to one of the following three examples:

• LDAP (All versions):
  auth ldap system-auth {
     bind dn "cn=admin,dc=f5lab,dc=com"
     bind pw "password"
     login attr "uid"
     search base dn "ou=bigipusers,dc=f5lab,dc=com"
     servers "10.1.1.1"
  }

• LDAPS (version 9.0.0 - 9.4.7):
  auth ldap system-auth {
     service ldaps
     ssl enable
     ssl ca cert file "/config/ssl/ssl.crt/My-Trusted-CA-Bundle.crt"
     search base dn "ou=bigipusers,dc=f5lab,dc=com"
     bind dn "cn=binduser,dc=f5lab,dc=com"
     bind pw "password"
     login attr "uid"
     servers "10.1.1.1"
  }

• LDAPS (version 9.4.8 - 11.x):
  auth ldap system-auth {
     service ldaps
     ssl enable
     ssl ca cert file "/config/ssl/ssl.crt/My-Trusted-CA-Bundle.crt"
     search base dn "ou=bigipusers,dc=f5lab,dc=com"
     bind dn "cn=binduser,dc=f5lab,dc=com"
     bind pw "password"
     login attr "uid"
     servers "ldap.f5lab.com"  #If Trusted CA is specified, must use hostname
  }

The remote authentication process

A typical authentication process includes the following steps:

• The BIG-IP system binds anonymously or as the configured Bind User.
  
  For example:

  bindRequest
   name: cn=admin,dc=f5lab,dc=com

• If the bind is successful, the BIG-IP system sends a search request for the user seeking authentication based on the supplied UID (known as samaccountname in Active Directory parlance).
  
  For example:

  searchRequest
  Filter: (uid=user1)

• If the search is successful, the Active Directory system returns the matching record that appears similar to the following example:

  earchResEntry(2) "uid=user1,ou=people,dc=f5lab,dc=com"
     attributes: 27 items

• The system then uses the search results to construct the client's DN for binding, as in the following example:

   bindRequest
     name: uid=user1,ou=people,dc=f5lab,dc=com

  Note: The attributes returned by this search may also be used for the Remote Role Determination feature, which was added in BIG-IP version 9.4.2.

• If the bind as user is successful, the Active Directory system returns the following response, indicating that the user has been successfully authenticated:

  bindResponse 
    resultCode: success (0)

Verifying remote authentication

Logging for remote authentication is limited and may not be particularly helpful in resolving issues. If examination of the /var/log/ltm log file is not helpful, F5 recommends that you use the ldapsearch command to verify basic connectivity between the BIG-IP system and the Active Directory server(s), and to verify expected authentication results.

Note: The BIG-IP system's LDAP auth library does not utilize the same library as ldapsearch; however, the utility is useful for verifying basic LDAP connectivity and authentication functionality from the BIG-IP system.

You can specify the following options for the ldapsearch command:

Verifying user search requests

To simulate the initial search for the user in the previous authentication connection example, type the following command at the BIG-IP command line:

ldapsearch -xLLL -H 'ldap://ldapA.company.com' -b "ou=group,dc=company,dc=com" -s sub -D "cn=binduser,dc=company,dc=com" -w 'mypassword' "(cn=user1)"

The LDAP server returns an entry that appears similar to the following example:

Note: The following response has been truncated.

dn: uid=user1,ou=group,dc=company,dc=com
objectClass: inetOrgPerson

To test the same search against an LDAP server running on an alternative port, type the following command:

ldapsearch -xLLL -H 'ldap://ldapA.company.com:390' -b "ou=group,dc=company,dc=com" -s sub -D "cn=binduser,dc=company,dc=com" -w 'mypassword' "(cn=user1)"

To test the same search against an LDAPS server running on the standard port, type the following command:

ldapsearch -xLLL -H 'ldaps://ldapA.company.com' -b "ou=group,dc=company,dc=com" -s sub -D "cn=binduser,dc=company,dc=com" -w 'mypassword' "(cn=user1)"

Verifying user binding

You can use the ldapsearch -n option to simulate binding as the user DN returned from the search above. To do so, type a command similar to the following:

ldapsearch -nxLLL -H 'ldap://ldapA.company.com' -b "ou=group,dc=company,dc=com" -D "uid=user1,ou=group,dc=company,dc=com" -w 'userpassword'

If binding is successful, the command produces no output. If binding is unsuccessful, an error message that appears similar to the following example is displayed:

ldap_bind: Invalid credentials (49)

Note: For more information about the ldapsearch command, type ldapsearch -h at the BIG-IP command line or consult the ldapsearch man page.

Verifying the server's certificate

To verify that the Active Directory server's certificate will be trusted, use the following syntax:

openssl s_client -connect <hostname>:<port> -CAfile <Your Trusted-CA-Bundle here> -debug -showcerts -verify <depth here>

For example:

openssl s_client -connect ldapA.company.com:636 -CAfile /config/ssl/ssl.crt/My-Trusted-CA-Bundle.crt -debug -showcerts -verify 4

If the certificate is trusted, the command returns several lines of text ending in the following line:

Verify return code: 0 (ok)