I have several sites, each with their own CP server and AD server.  I've created a service for each site and added their local AD server as the first authentication source.  As a second authentication source for each site, I've selected our AD servers at our DR facility in case the local AD server fails.  I believe this will acomplish fail-through of authentication sources if the first authentication source (local AD servers) are unavailable.  However, I'm wondering what happens for authentications that fail on the first AD server, if someone uses incorrect credentials. Does the authentication fail-through to the next authentication source?   If so, this may be undesirable since the AD servers all contain the same records, and I'd be querying the second authentication source for no reason.  I'd like to know in which cases secondary or tertiary authentication sources would be used.

Compnerd,

You need to add backup servers into the backup parameter for redundancy of each authentication source to accomplish that.

Here's what I did:

Authentication source 1: Primary Site AD Servers

Primary: AD Server 1

Backup: AD Server 2

Authentication source 2: DR AD servers

Primary: AD Server 1

Backup: AD Server 2 

If the primary AD server in authentication source 1 goes down, we fail to the backup AD server at Site 1.  I added authentication source 2 in case both AD servers at site 1 are inaccessible.  Will authentication not fail through to authentication source 2 if authentication source 1 is inaccessible?

Since my understanding was incorrect, can you please explain in what use case multiple authentication sources would be setup?

Thanks.

If you look at the context-specific help when you are editing the service it will detail all of this.  I am going to copy and paste it below.  In multiple authentication sources CPPM will look to see if the user exists in the authentication source.  If it does not exist, it will move onto the next one.  If the user exists and the password is rejected, a reject is sent back to the NAS device and everything stops there.  If you have the same database you should use the backup tab in the authentication source to list servers that you want to be tried in case the the first server is unresponsive:

Authentication and Authorization

As the first step in Service-based processing, Policy Manager uses an Authentication Method to authenticate the user or device against an Authentication Source. Once the user or device is authenticated, Policy Manager fetches attributes for role mapping policies from the Authorization Sources associated with this Authentication Source.

Architecture and Flow

Policy Manager divides the architecture of authentication and authorization into three components:

To add to that, you don't even have to put a list of ip address for primary or backup servers in particular.  You can just put in the domain for the hostname and CPPM will enumerate AD and find an available AD server.  Those servers do NOT have to be setup as Radius Devices or anything.  They just need to be a domain controller to service an authentication:

You're right.  I missed those tidbits of info in the help.  Scrolled right past them!  Thank you for pointing that information out.

Your second reply, brings up something that I've been trying to find out, but keep getting different answers from Aruba employees.  I've been creating a separate service with authentication sources for each site so that we don't have authentications going across the WAN.  Based on what you're saying, it sounds like I don't need to setup site specific services and authentication sources.  I need to test this!

I was able to test AD authentication using the domain name rather than a server FQDN.  I setup a packet capture in CP and generated an authentication.  I can confirm that the CP servers are using their local server AD server for authentication.  This is a great find since I understood this was not possible!

This leads me to my next question.  If I use the domain name as the primary server, should I setup a backup server with an actual AD FQDN?  I want to be sure that in case of a failure of the primary AD server occurs, CP will use another server.  I can't properly test this in my environment since I can't take an AD server out of service.

I just want to make some clarification. The screen shot that is being shown is for LDAP lookups and attribute fetching. Not for authentication.

Authentication is handled by samba/winbind and DNS.

So if you have AD sites and services configured, DNS will return the AD servers that are in charge of those subnets.
Otherwise we will send to any of the AD servers that DNS returns.

In 6.1.1 (which came out on monday); we added a new CLI option to specify the 'password server' which is the server or list of servers that we will send the authentcation request to.
This allows you to sepficy the FQDN or IP of the DC's local to that CPPM server. Or in your case, 1 or 2 local and 1 remote.

It is however a good idea to shorten the LDAP timeout if you are using the domain in the authenticaiton profile. Otherwise there is the possibility that the RADIUS session will timeout waiting for a LDAP responce.

Hope this helps.

Not sure I follow, Gary.

These are authentication sources that we're configuring, are they not?  My understanding is that authentication sources are used for authentication as well as authorization (attribute fetching).

We do have AD Site and Services configured.  So I assumed that since I changed the primary server  to the domain name in my authentication source that I'm now leveraging AD S&S to determine the local AD server for authentication and authorization.  A local AD server is returned, the result of resolving the primary server domain name in the authentication source, should be used to authenticate the credentials (using samba/winbind) and then perform an LDAP lookup to retrieve attributes for those credentials, right?

thecompnerd,

<From Gary>

That field is ONLY used for LDAP lookups and attribute fetching.  It is also done to lookup a user to see if it exists, BEFORE AUTHENTICATON.  Authentication is sent through Winbind, and transmitted to an available Domain Controller..."Which DC is actually determined by AD sites and Services, where the end user specifies what subnets go to what DC's."

In that case, how does ClearPass know that the credentials in the RADIUS response need to be authenticated by an AD server?  My ClearPass servers are joined to the domain, is that how?

When you add an AD server as an Authentication Source, that is what it authenticates to.

When you create an AD server it uses the domain joined to do 802.1x

That was a confusing statement.....

When you add a authentication source profile in a AD environment, It uses that for only LDAP; ie Username lookup, attribute lookup.

When you join CPPM to 'a' domain; It uses the domain configuration for authentication; The settings in the authentication source profile is not what is used for the actual handling of Authentication. For that we rely on winbind to fetch the domain configuration (domain name, netbios name, and trusted domain);

We then use DNS to resolve the local ad server and set that as the password server.

The settings in the authentication profile do not over ride this.

This is why when you configure an authentication source with out joining to AD you get error messages about mschapv2 responces being incorrect. 

The only way to over ride this is to use the password server configuration in the SMB_<domain>.conf; which we didn't expose to end users until 6.1.1 with the password server CLI configuration command. 

This is the ONLY way to override the settings we got from the domain lookups during the initial joining of CPPM to the domain. 

Hope this clarifies a bit. 

Yes, thank you very much for your clarification on this topic. Glad to finally have an understanding of this.