Applies To:
Show VersionsBIG-IP APM
- 13.1.3, 13.1.1, 13.1.0
About Active Directory authentication
You can authenticate using Active Directory authentication with Access Policy Manager®. We support using Kerberos-based authentication through Active Directory.
About Active Directory password management
Access Policy Manager® (APM®) supports password management for Active Directory authentication.
How APM supports password reset
The process works in this sequence:
- Access Policy Manager uses the client's user name and password to authenticate against the Active Directory server on behalf of the client.
- If the user password on the Active Directory server has expired, Access Policy Manager returns a new logon screen back to the user, requesting that the user change the password.
- After the user submits the new password, Access Policy Manager attempts to change the password on the Active Directory server. If this is successful, the user's authentication is validated.
If the password change fails, it is likely that the Active Directory server rejected it because the password did not meet the minimum requirements such as password length.
Number of attempts APM provides for password reset
In the AD Auth action, APM provides a Max Password Reset Attempts Allowed property.
Change password option
In the Logon page action, APM provides a Checkbox property in the visual policy editor. You can add the option on the APM logon screen to change the log on password.About AAA high availability
Using AAA high availability with Access Policy Manager® (APM®), you can configure multiple authentication servers to process requests, so that if one authentication server goes down or loses connectivity, the others can resume authentication requests, and new sessions can be established, as usual.
APM supports the following AAA servers for high availability: RADIUS, Active Directory, LDAP, CRLDP, and TACACS+. APM supports high availability by providing the option to create a pool of server connections when you configure the supported type of AAA server.
About how APM handles binary values in Active Directory attributes
For Active Directory, Access Policy Manager® (APM®) converts an attribute value to hex only if the value contains unprintable characters. If the session variable contains several values, and one or more of those values is unprintable, then APM converts only those particular values to hex.
An attribute with a single unprintable value
7ecc84a2.session.ad.last.attr.objectSid 58 / 0x01050000000000051500000013fe8e97c03cd5b5ad04e2e255040000
Attributes with multiple values, both printable and unprintable (binary)
7ecc84a2.session.ad.last.attr.memberOf 460 | CN=printable group,OU=groups,OU=someco,DC=sherwood,DC=labt,DC=fp,DC=somelabnet,DC=com | 0x434e3d756e7072696e7461626c6520c2bdc2a12067726f75702c4f553d67726f7570732c4f553d66352 | / c44433d73686572776f6f642c44433d6c6162742c44433d66702c44433d66356e65742c44433d636f6d | / CN=Domain Users,CN=Users,DC=smith,DC=labt,DC=fp,DC=somlabnet,DC=com | / CN=CERTSVC_DCOM_ACCESS,CN=Users,DC=smith,DC=labt,DC=fp,DC=somelabnet,DC=com | / CN=Users,CN=Builtin,DC=smith,DC=labt,DC=fp,DC=somelabnet,DC=com |
Task summary for Active Directory authentication
This task list includes all steps required to set up this configuration. If you are adding Active Directory authentication to an existing access policy, you do not need to create another access profile, and the access policy might already include a logon page.
Task list
Configuring an Active Directory AAA server
Creating an access profile
Verifying log settings for the access profile
Configuring Active Directory authentication
Creating a virtual server
Testing AAA high availability for supported authentication servers
- Begin a tcpdump on the Access Policy Manager®, using a protocol analyzer, and scanning for packets destined for the specific port for your authentication server.
- Log in to the virtual server with both servers active.
- Using the tcpdump records, verify that the requests are being sent to the higher priority server.
- Log out of the virtual server.
- Disable the higher-priority server.
- Log in to the virtual server again.
- Verify that the request is being sent to the other server.
- Log out again, re-enabling the server, and try one more time to verify that the new requests are being sent to the high priority server.
Example access policy using Active Directory authentication and query
This is an example of an access policy with all the associated elements that are needed to authenticate and authorize your users with Active Directory authentication and Active Directory query.
Example of an access policy for AD auth and query
Importing Active Directory user groups
Assigning resources to an AD group
Active Directory authentication session variables
When the AD Auth access policy item runs, it populates session variables which are then available for use in access policy rules. The tables list the session variables for the Active Directory access policy items and for a logon access policy item.
Session variables for Active Directory authentication
Session Variable | Description |
---|---|
session.ad.last.actualdomain | AD Auth agent sets this variable to the actual user domain used for successful Active Directory authentication, whether cross-domain support is enabled or disabled. |
session.ad.last.authresult | Provides the result of the Active Directory authentication. The available values are:
|
session.ad.last.errmsg | Displays the error message for the last login. If session.ad.last.authresultis set to 0, then session.ad.last.errmsg might be useful for troubleshooting purposes. |
Common session variables
Session Variable | Description |
---|---|
session.logon.last.username | Provides user credentials. The username string is stored after encrypting, using the system's client key. |
session.logon.last.password | Provides user credentials. The password string is stored after encrypting, using the system's client key. |
Active Directory cross-domain support rules
Rules | Explanation |
---|---|
Cross-domain support and split domain from username are both enabled. | If you enable cross domain support, and enable split domain username at the login page, and then the user enters his user name, such as user@domain.com, Access Policy Manager® uses the user@domain.com as the user principal name to authenticate the user against USERNAME.COM domain. |
Cross-domain support is enabled but split domain from username is disabled | Access Policy Manager handles the user's input as a simple user name and escape "@" and "\" chars. In other words, Access Policy Manager uses user\@userdomain.com@DEFAULTREALM.COM to authenticate the user, where DEFAULTREALM.COM is the domain name that was configured on the AAA AD Server configuration page. |
If user does not specify a user's domain | Regardless of whether split domain from username option is enabled or disabled, Access Policy Manager uses user@defaultrealm.com to authenticate the user. |
Active Directory authentication and query troubleshooting tips
You might run into problems with Active Directory authentication and query processes in some instances. Follow these tips to try to resolve any issues you might encounter.
Active Directory auth authentication and query troubleshooting
Possible error messages | Possible explanations and corrective actions |
---|---|
Domain controller reply did not match expectations.(-1765328237) | This error occurs when the principal/domain name does not match the domain controller server's database. For example, if the actual domain is SALES.MYCOMPANY.COM, and the administrator specifies STRESS as the domain, then the krb5.conf file displays the following: default_realm = SALES SALES = { domain controller = (domain controller server) admin = (admin server) So, when the administrator tries to authenticate with useraccount@SALES, the krb5 library notices that the principal name SALES differs from the actual one in the server database. |
Additional troubleshooting tips for Active Directory authentication
You should | Steps to take |
---|---|
Check that your access policy is attempting to perform authentication |
Note: Make sure that your log
level is set to the appropriate level. The default log level is notice.
|
Confirm network connectivity |
|
Check the Active Directory server configuration |
Note: Since Active Directory is
sensitive to time settings, use NTP to set the correct time on the
BIG-IP
system.
|
Capture a tcpdump | Use the tcpdump utility on the BIG-IP system to record activities between Access Policy Manager® and the authentication server when authentication
attempts are made.
Important: If you decide to
escalate the issue to customer support, you must provide a capture of the tcpdump when you
encounter authentication issues that you cannot otherwise resolve on your own.
|
Overview: Using Active Directory Trusted Domains
Active Directory Trusted Domains option in BIG-IP® Access Policy Manager® (APM®) manages Active Directory AAA trusted domains. For enterprises that are service providers, their customers might have their own enterprise network infrastructure. Using APM, the service provider provides access to their customers' networks. To avoid network traffic collisions between two customer networks, the service provider separates each customer using route domains. A route domain is a configuration object that isolates network traffic for a particular application on the network. The service provider uses Active Directory to authenticate their customer users. However, each customer's Active Directory service can contain multiple trusted domains or forests. The service provider can use the Active Directory Trusted Domains option to authenticate users across all trusted domains or forests for a customer.