F5 provides a few key articles that build the basis for this summary. Found here, here and here.
Local users with the same name as an AD user cannot authenticate with local password once Remote AD authentication is enabled. However, local rights overrule ‘External Users’ configuration.
Example: I have user bsmith local and in AD. bsmith is an admin locally, but ‘External Users‘ is configured as operator only.
Once bsmith authenticates, he will be an administrator on the box.
The built-in ‘admin‘ account is the only local account that will be able to authenticate if AD is down. Make sure you have the password documented.
- Name & IP address of LDAP/AD server(s)
- Distinguished Name of domain
- Service account for binding to LDAP to monitor servers
- Optional: Two LDAP/AD servers for HA configuration
Before starting it’s important to test from the command-line of the F5 to validate network accessibility and the LDAP search string.
What is my distinguished name?
If you’re using Microsoft Active Directory, follow these steps (make sure Advanced Features is on):
1. Open Active Directory Users and Computers
2. Right click the domain name at the top of the tree and click Properties
3. Under attributes you will see ‘distinguishedName‘ the value is important for the rest of these instructions. Capture it.
Pick a test user
A user will be needed to validate during some of our testing. Pick whatever user you’d like, but take note of what OU the user is in. If you are using Microsoft AD it may be in the Users OU.
Build Search String
Merge the information from the DN and user OU to build search string for testing. Here is an example:
User OU: users
ldapsearch is the utility used by the F5 for testing. Follow these steps to validate layer-3/4 connectivity and LDAP functionality.
1. SSH to the BigIP
2. Use the following format to test a LDAP query using ldapsearch:
ldapsearch -xLLL -H 'ldap://mydc.domain.com' -b "cn=users,dc=mydomain,dc=com"
-D mydomain\\domain-user -w 'userspassword' '(samaccountname=myuser)'
Use ‘ldapsearch –help‘ to get more information about the flags.
3. Using the previous query should return a bunch of information about your user. If not, something is wrong with the syntax. Try different variations until you get it working.
If content is returned, we know that the F5 can reach our LDAP server (if it cannot, check that a self-IP exists on the same subnet as the LDAP server or a route exists) and that our DN string is correct for future configuration.
Create LDAP Monitor
A monitor is needed to probe the pool that will be created in the next step. The string created earlier can be used here.
1. Log in to the F5 UI
2. Click Local Traffic > Monitors > Create…
3. Enter a name, i.e. ldap-monitor
4. Under type select LDAP
5. Create an interval that makes sense to you, the defaults are usually fine
6. Under ‘User Name‘ put the user you created in the prerequisites. Ideally it is a service account with no interactive rights, simply used to bind to LDAP.
Important!! If you use a prefix to log on to your domain, i.e. domain\user you must enter either domain\\user WITH TWO SLASHES or myuser@domain. I’ve had the best luck with the domain\\user format.
7. In the Base field, enter the OU we want to check (bind to).
It can be anything you’d like, but basically we are making sure the LDAP server serves up a response to our LDAP request.
I simply used the cn=users,dc=mydomain,dc=com
8. Under Filter enter the object you want to check. I used cn=Domain Guests since it is a built-in object and it is not used (if I probed Domain Admins the listing could potentially be intercepted and used for nefarious purposes).
9. If your server supports SSL/TLS optionally select one under the Security field.
10. Click Finished
Create LDAP Virtual-Server
This can be done on the local BigIP or a remote device that is accessible by the device LDAP authentication is being implemented.
The purpose of this is so that if an LDAP server fails, the F5 can continue authentication. Without this configuration the F5 must rely on a single server for authentication.
1. Log in to the F5 UI
2. Click Local Traffic > Virtual Servers > Create…
3. Enter any name, IP address (ideally on the same subnet as LDAP servers), Service port is 389
4. Protocol is TCP, with TCP profile
5. Add a Default Pool as a resource with the two domain-controllers in your environment on port 389.
6. Assign the monitor created in the previous step to this pool.
7. Click Finished
8. Create a DNS record for this virtual-server local to your environment, i.e. ldapvip.domain.com
Configure LDAP Authentication
Important Tip: Make sure you have an SSH and browser session already open to your device in-case you get locked out. The default local admin user will always be a fallback in the case this happens, make sure you have those credentials handy.
1. Click System > Users > Authentication > Change
2. Under User Directory select “Remote – Active Directory” or “Remote – LDAP” (I have not experienced any functional difference between these in practice).
3. Host is the DNS record we created in step 8 above. If you skipped the HA portion, just enter the A record for your LDAP server.
4. Remote Directory Tree: This is the OU or starting point for your user container.
Above we used cn=users,dc=domain,dc=com. Also, dc=domain,dc=com could be used, but why return all that content when the Users are only in one or a few OU’s?
If yours are in an OU under that, use the format cn=F5users,cn=users,dc=domain,dc=com
Most cases will be cn=users,dc=domain,dc=com
5. Scope: This determines the level of your search.
Important Tip: I’ve never gotten Base or One to work, only Sub.
6. Bind: Even though this is blue, inferring that it is mandatory, it is not. If you created a service account (we did for our monitor) and you only want this user to be used to bind, then go ahead and enter that user here.
Important Tip: Remember how in the monitor configuration we had to use double slashes? I.e. domain\user. For some reason the same does not apply here. Use only ONE slash. i.e. domain\user
I left the Bind fields empty and used the User Template setting. If a user can’t bind to begin with, why search for that user?
7. Under User template %email@example.com will attempt to use the user authenticating to bind (the F5 inserts the username typed in the User field for the %s), if they can’t bind (non-existent user) they won’t be looked up.
8. I’m not really sure what ‘Check Member Attribute in Group‘ does functionally (doesn’t Remote Role Groups cover this?), F5’s documentation is lacking here. I leave it unchecked.
9. Under Login LDAP Attribute enter samaccountname
10. In the External Users section assign the Role you’d like for authenticated AD users. Remember that if a local user matches remote, local rights supersede this configuration. Operator is a good choice if this is designed for sys-admins to do what they need.
11. Click Finished
Test logging in from a different browser session!! If all went well, logging in will work. If not something is wrong/missing. Look over the steps above again and make sure nothing was missed.
If not, troubleshoot using tcpdump
tcpdump is your best friend for figuring out what’s going on. Luckily LDAP is clear-text so deciphering syntax issues is fairly simple. F5 also has an article covering how to troubleshoot LDAP issues.
1. SSH to the F5 performing the LDAP queries.
2. Use the following syntax to run a simple capture
tcpdump -s0 -ni 0.0:nnn -w /shared/tmp/ldapdebug.pcap 'host 10.1.1.1 or host 10.1.1.2'
Replace the 10.x addresses with the IP’s of your LDAP servers.
3. Attempt a login from a browser.
4. Once it fails, stop the capture with ctrl-c
5. SCP the capture off the F5 (will be in the /shared/tmp directory)
6. Examine with Wireshark.
Look for syntax errors after “searchRequest” or “bindRequest” queries. The “bindResponse”, “searchResEntry” or “searchResDone” response will be a good indicator of the problem.