Security

We have a new Clearpass deployment where we are trying to setup an AD server as an authentication source.

We have added the AD Server under Authentication Sources, as well as joining CPPM to the domain under Server Settings.

However when we try to perform a test authentication against the CPPM server all of our attempts fail. Looking in the Request Details under alerts we see "Bind failed because of invalid credentials" however when you browse to the Primary tab on the Authentication source and do 'Search base DN' it returns the list with no problem.

Any hint would be greatly appreciated.

-ELiasz

Have you tried more than one user to test authentications?  Any chance the password is wrong?   Try to uncheck the "Allow bind using user password" on your connection details page under the Authentication Source and try your attempt again; this will force the bind to use the Bind DN you have specified.  Do you get the same failed message?  

Description of this function:

Enable to authenticate users by performing a bind operation on the directory using the credentials (user name and password) obtained during authentication.

If the attempt from the user has bad credentials, the bind will fail.

It turned out to not be working correctly for some reason when using a FQDN to do the bind. When we switched the user to admin@domain.com we were able to successfully authenticate users. The odd part is that with both names we were still able to bind and browse the tree.

Thanks for the tips.

-Eliasz

In the AD settings when you look at the filter query "(&(userPrincipalName=%{Authentication:Username})(objectClass=user))", this "userPrincipalName" is what it looks at for user authentication. I can't remember what the initial value is but "userPrincipalName" is what we had to change it to. So depending on what you want to use for the user to authenticate is what you would change that initial value to. 

Hope that made sense

I'm getting the same problem where I can search the DN fine, but cannot authenticate users. I changed the default filter for authentication to what is below, but still the same problem.

1. (&(userPrincipalName=%Authentication:Username})(objectClass=user))
2. (distinguishedName=%{memberOf})
3. (&(sAMAccountName=%{Host:Name}$)(objectClass=computer))
4. (&(sAMAccountName=%{Onboard:Owner})(objectClass=user))
5. (distinguishedName=%{Onboard memberOf})

Are there any specific attributes I need to authenticate users to AD?

Bob

The defaults typically work fine.  If you need to you can add/edit and use the UPN name rather than SAM Acccount Name.   If you don't need to, leave the defaults.  

Can you send me the entire export of the Access Tracker as shown below?  I feel like we are missing something here.

Also, have you tried:

- authenticating as any other users?

- authenticating using the AAA diagnostics from the controller?   You may need to create another service with MSCHAPv2 or PAP and remove the ESSID condition in the service.

I've only been using my account to test with, but I know there are no problems with my account. 

The AAA diagnostics from the controller also fails. I did try removing the ESSID condition in this service and it still failed. If I need to add a MSCHAPv2 service. What type should I choose? 

Attachment(s)

DashboardDetails.zip   16 KB 1 version

I notice that the Bind user you have set in the Auth Source  varies from the Bind attempt during authentication (using the allow bind using user password setting).  Can you verify which DN is correct below?  Notice the \ before the comma (used as an escape character preceding a comma in a DN).   When the authentication is attempted, it is trying to Bind as the DN without the "\" which I believe is causing a problem (as that DN technically doesn't exist).

Bind user defined in auth source:  CN=Garlin\, Robert,OU=Users,OU=..........,DC=edu  (Omitted portions of the DN)

Authentication Bind as:  CN=Garlin, Robert,OU=Users,OU=.............DC=edu   (Omitted portions of the DN)

Can you try the following (not at the same time); testing after each.

1) Change the Bind username to user@domain.com format (UPN), making sure the NetBIOS name stays TUFTS

2) Remove the check for allow bind using user password

3) Try to bind as a different username (UPN format)

It's working. I tried those options in the past and they didn't work, but with the UPN format I was using admin@domian.com. This time I removed the ,com. admin@domin, and I was able to browse the tree and authenticate a client. More testing to be done, but that seems to have fixed my problem.