Security

I was recently posed a question by the systems group about strategies for load-balancing the LDAPS calls CPPM makes against our Active Directory domain controllers.

When I originally set up my authenication source in CPPM, I made DC1 the primary server via it's fully qualified domain name, and threw the other ones in as Backups. This works well, but my systems group wants to know about options for having CPPM poll the servers in a more balanced fashion, because they are seeing DC1 get all the requests. I pose these questions to you, airheads:

• Is there a way to tell CPPM to round-robin or load balance among the primary and backup AD servers? OR
• Can I simply put the domain name in as the hostname? What would CPPM's behavior be if it got back a different IP address each time it queried (this obviously depends on how often CPPM actually does the DNS query, and how it interpretes a result that several IP addresses)

Any design perspectices or technical hints regarding this subject would be helpful. Thank you in advance,

Aaron

When attaching a CPPM node to an Active-Directory (AD) domain, (note that each CPPM node must be separately attached/enrolled) this is the node that we send the Auth request to. In CPPM 6.3 we added some logic to control the processing of where CPPM sends the authentication request to when the primary-node you initially connect to fails. This is achieved via the configuration of AD Password Servers. If NO Password Servers are configured then the processing of where the Auth requests are sent is indeterminate after the primary node fails.

To better understand the processing of which server in the network could be used to process these request look at the below nslookup example. This shows you the servers in the network that can process the CPPM AD authentication requests. Knowing this you can have a discussion with the customer to discuss where these server are located and whether or not you want to add an deterministic process to which servers are used first.

Making the processing deterministic can be achieved in the CPPM CLI with the following command…. ad passwd-server set -s <server 1> <server 2> <server 3> <etc>

To see a list of the current configured servers.. ad passwd-server list -n <domain>
To load balance across DCs, different CPPM nodes in the cluster can be joined to different domain controllers.

Beyond this, if you want 'proper' SLB backend load-balancing between CPPM and the AD server would require a 'proper' load-balnacer... F5/RADWARE etc.

I did some packet captures with a test box to see how this works in our environment.

For the AD authentication source  I use a domain name (e.g ads.domain.name) that points to about a dozen domain controllers.

I logged in to a cisco switch that is using RADIUS pointing to the clearpass server (PAP request). This was the first authentication for this test CP server in over 15 hours. The packet capture shows for this PAP request:

1) DNS lookup on ads.domain.name and it returns DC#1. Then it does a LDAPbind request using the account that is setup for the AD auth source followed by a LDAP serach request on the username for the request (I think to verify username exists). Both of these requests used DC#1.

2) DNS lookup on ads.domian.name and it retuns DC#2. It does a LDAP bind on username to authenticate user. Uses DC#2 for this auth.

3) DNS lookup on ads.domain.name and it returns DC#3. Does a LDAP search request on user and retrieves attributes for authorization (if you don't have fetching of attributes for authorization set, this step is probably not done). Uses DC#3 for this step.

Then the RADIUS accept is sent. So there are three separate LDAP steps and in my case it was using three separate domain controllers based on DNS lookups.

I then did a MSCHAP auth request a few seconds after the PAP request. The difference here was in step 2 instead of doing an LDAP bind to auth the user, it did a Samba/Winbind request against the server that is specified in the password server list I had set up in the AD domain config for the CP server (Note this password server list had no impact on which servers were used for LDAP queries).  For this second request (different user) no DNS requests were made and the same DC servers were used for steps #1 and #3. IOW DC#1 was used for step #1 calls and DC#3 was used for step #3 calls. I'm sure at some point a DNS lookup will happen for each of these steps but don't know how that works.

Also if I authenticate using the same username in short order, step #3 (fetching attributes) does not happen on the subsequent auths. If I clear the cache in the auth source then it does for the first call, so the attributes for the user must get cached.

So it appears that using a domain name for the hostname in the auth source does spread the load to some degree. It certainly isn't load balancing but it is better then using a FQDN of a a single DC.