AD DC's behind F5....

Seems simple enough...the only challenge I can think of would be what type of health checking to use.

Not sure as I have heard various different things in forums about making sure SNAT is setup or using an LDAP rule or a straight up VIP. Just want to make sure it is possible and if there are any little gotch-ya's I should watch out for.

You're simply trying to proxy the auth request, right? AD returns a yes or a no type scenario?

Basically yes. We are trying to allow applications to authenticate against the VIP rather than a single DC in case one of the DCs needs to be rebooted or fails. Figured either a round robin VIP or a Sorry server config. And then any special communications between the VIP and the domain controller that might be required like SNAT or NAT to make sure the response goes back to the correct "client" request.

 

 

Dave

Is it just LDAP? i.e. Port tcp/389? Or is it udp/389 as well? tcp/389 is easy, and easy to write a decent monitor for... Depending on how complicated you want the monitor to be you can either do it in a built-in LDAP monitor, or an external monitor.

 

 

For udp/389, you may have to use an external monitor... But that may also depend on whether the ldapsearch CLI command on the F5 can do LDAP over UDP... I'm not sure... (Sorry, don't have access to one ATM to check).

 

 

H

As far as I know, yes it is just LDAP authentication. The applications authenticate against AD but unfortunatelly can only list one server to authenticate against.

 

 

Any special VIP rule settings I should watch out for?

 

 

Thanks,

 

 

Dave

Not really. Just a VS with tcp/389, SNAT if they're not routing back via the F5, translate IP and port (Or just IP actually should be fine if VS and servers are all :389). Persistence by srcip.

 

 

The monitor can probably be just a customisation of the built-in LDAP monitor (With the caveat some versions will follow LDAP referrals and mark the server as up anyway. You have to watch for that and customise to consider LDAP referrals as being down... Although that can be masked if the clients have the ability to follow the referrals AND have connectivity).

 

 

H

Just to bolt on here...we use the LTM to load-balance AD LDAP queries and haven't had any problems - and there shouldn't be, as AD LDAP is just another service from the LTM's perspective, just like HTTP, or anything else. We have no special settings - just a VIP, Pool, and a LDAP monitor applied to the pool. We have configured the Monitor to bind with AD. This is all standard stuff. Whether or not you need SNAT depends on where the DCs reside in your IP network space relative to the LTM. Although this is not technically accurate (I'm not a network guy), they way I like to describe this is if the DC's are in an IP network which is routed by the LTM, you do not need SNAT. The LTM maintains a connection table in memory with each client TCP connection - it's this connection table in memory that ensures data is sent back to the right client connection. You can view the connection table using the "bigpipe connection", or "b conn" for short (also see "b conn help").

Cool thanks. We will be implimenting this in out test environment shortly and see how it goes.

 

 

Will post here again if I run into any issues.

 

 

Thanks again for all the help.

 

 

Dave

I am trying to get something similar working. I have setup a VIP with cert listening on port 3269 which is the secure global catalog port. The pool attached to this VIP are global catalog AD servers listening on port 3268. Is there any reason this shouldn't work? I can connect LDAP clients fine from on my company network but am so far not successful off network. My firewall group has supposedly allowed external access to port 3269 and I can telnet to it and get response but I simply can't connect/bind from the outside. Any ideas would be appreciated.