Applies To:
Show VersionsBIG-IP APM
- 13.0.1, 13.0.0
About LDAP and LDAPS authentication
You can use LDAPS in place of LDAP when the authentication messages between the Access Policy Manager® and the LDAP server must be secured with encryption. However, there are instances where you will not need LDAPS and the security it provides. For example, authentication traffic happens on the internal side of Access Policy Manager, and might not be subject to observation by unauthorized users. Another example of when not to use LDAPS is when authentication is used on separate VLANs to ensure that the traffic cannot be observed by unauthorized users.
How LDAP works
LDAPS is achieved by directing LDAP traffic over a virtual server that uses server side SSL to communicate with the LDAP server. Essentially, the system creates an LDAP AAA object that has the address of the virtual server. That virtual server (with server SSL) directs its traffic to a pool, which has as a member that has the address of the LDAP server.
How LDAPS works
About how APM handles binary values in LDAP attributes
For LDAP, 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
9302eb80.session.ldap.last.attr.objectGUID 34 / 0xfef232d3039be9409a72bfc60bf2a6d0
Attribute with multiple values, both printable and unprintable (binary)
29302eb80.session.ldap.last.attr.memberOf 251 | / CN=printable group,OU=groups,OU=someco,DC=smith, / DC=labt,DC=fp,DC=somelabnet,DC=com | / 0x434e3d756e7072696e7461626c6520c2bdc2a12067726f75702c4f553d67726f7570732c4f553d66352c / 44433d73686572776f6f642c44433d6c6162742c44433d66702c44433d66356e65742c44433d636f6d |
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.
Task summary for configuring for LDAPS authentication
This task list includes all steps required to set up this configuration. If you are adding LDAPS 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 LDAPS AAA server in APM
Creating an access profile
Verifying log settings for the access profile
Configuring LDAPS authentication
Creating a virtual server for LDAPS
Testing LDAPS authentication
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 of LDAP auth and query default rules
In this example, after successful authentication, the system retrieves a user group using an LDAP query. Resources are assigned to users and users are directed to a webtop if the user group has access to the network access resources.
In this figure, the default branch rule for LDAP query was changed to check for a specific user group attribute.
Example of an access policy for LDAP auth query
Importing LDAP user groups
Assigning resources to an LDAP group
LDAP authentication session variables
When the LDAP 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 LDAP Auth access policy items and for a logon access policy item.
Session variables for LDAP authentication
Session Variable | Description |
---|---|
session.ldap.last.authresult | Provides the result of the LDAP authentication. The available values are:
|
session.ldap.last.errmsg | Useful for troubleshooting, and contains the last error message generated for LDAP, for example aad2a221.ldap.last.errmsg. |
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. |
UserDN settings in LDAP
The following is an example of a typical UserDN usage for LDAP.
Access Policy Manager® attempts to bind with the LDAP server using the supplied DN and user-entered password. If the bind succeeds, that is, authentication succeeds, the user is validated. If the bind fails, the authentication fails. This value is a fully qualified DN of the user with rights to run the query. Specify this value in lowercase and without spaces to ensure compatibility with some specific LDAP servers. The specific content of this string depends on your directory layout.
For example, in an LDAP structure, a typical UserDN for query would be similar to the following string: cn=%{session.logon.last.username}, cn=users, dc=sales, dc=com.
Access Policy Manager supports using session variables in the SearchFilter, SearchDN, and UserDN settings.
For example, if you want to use the user’s CN from the user’s SSL certificate as input in one of these fields, you can use the session variable session.ssl.cert.last.cn in place of session.logon.last.username.LDAP authentication and query troubleshooting tips
You might run into problems with LDAP authentication and query in some instances. Follow these tips to try to resolve any issues you might encounter.
LDAP auth and query troubleshooting
Possible error messages | Possible explanations and corrective actions |
---|---|
LDAP auth failed |
|
LDAP query failed |
|
Additional troubleshooting tips for LDAP 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 |
|
Confirm network connectivity |
|
Check the LDAP server configuration |
Note: A good test is to use full
administrative credentials with all rights. If that works, you can use less powerful
credentials for verification.
|
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.
|