I had ClearPass working fine with PEAP and GTC using LDAP as the authentication source. We would like to use MSCHAPv2 and AD, but when I made the 2 following changes, GTC - MSCHAPv2 and changed the source from ldap to AD, I get the following error:
rlm_mschap: FAILED: No NT/LM-Password. Cannot perform authentication.
rlm_mschap: FAILED: MS-CHAP2-Response is incorrect
On the summary screen of the failed session, it has authentication source none. However, when I look under the authentication source for the service, I have the AD source I created selected.
Are there are other changes I need to make changing from GTC and LDAP to MSCHAPv2 and AD?
Is ClearPass joined to the domain? To do PEAP-MSCHAPv2 authentication, it must be joined.
It is part of the domain. Also, from the Authentication -> Sources -> and my AD source, I can click on the seach base dn and that works fine, so I think the DN information is correct.
Is this a single domain or multi domain? What is the message on the Alerts tab of Access Tracker? Can you post an export of the Access Tracker event?
It's just one single domain.
I uploaded the summary and alerts screen from the failed attempt. On the summary screen I'm not sure why it has none listed for Authentication Sources, when LDAP worked it had LDAP listed and when I look at the service, AD is listed as the authentication source.
Okay. Make sure the bind user that you used for the AD source works. That is all I can see now.
I have all the Bind information in there, and from the Authentication Sources -> The AD source -> primary tab, I can click on Search Base BN and can search it. Is that all I need to do to verify the Bind information is correct, or is there another verification test?
In your AD Identity Source, do you have the check box for "Allow bind using user password". This will attempt a bind using the logon attempt username/password, not the bind user. Try unchecking it.
I tried unckecking that box and it still fails. I'm working with our SE right now, but he is not sure what LDAP works but not AD. One odd thing I noticed, is even thought I'm using AD. I get ldap errors on the log for my session in access tracker.
rlm_ldap: (re)connection attempt failed
Is that normal?
Also, I tried to LDAP and MSCHAPv2, but that was also failing, should I be able to use LDAP with MSCHAPv2? From the users guide it looks like that should be possible.
Policy Manager can perform MSCHAPv2 and PAP/GTC authentication against any LDAP-compliant directory (for example, Novell eDirectory, OpenLDAP, or Sun Directory Server).
Can you try testing AD authentication via the CLI?
[appadmin@clearpass]# ad auth -u <username> -n <domain NETBIOS name>password:
Should result in:
INFO - NT_STATUS_OK: Success (0x0)
I'm not sure what to put after NETBIOS, I tried the dns name and that didn't work. I can browse the Base DN with the username and password in the GUI.
I was doing some other testing yesterday and I was able to get MSCHAPv2 to work with the local database, just not with AD or LDAP. If that's helpful information.
I don't have much AD experience, so I can't answer that question. In my environment the netbios name is different than the FQDN for the domain. It's the netbios name that must be used for testing authentication.
The reason why I mention testing AD via CLI, is that I had a similar issue a month ago. I could search the base DN, but I couldn't test authentication via CLI. The fix was to remove the CPPM servers from the domain and rejoin them.
I wasn't sure what to enter for the NETBIOS name. I tried the host name and it failed resolving, not the authentication.
Within the Authentication source, the NETBIOS name should be the NETBIOS name of your Active Directory domain. If you don't know what it is, you can ask an administrator of the domain, or just log into a machine in the domain and check what the domain name is.
type echo %userdomain% from a command prompt on a machine that logged into the domain.
I don't have AD Admin rights to our domain, but I can remove the applicance from the domain and have the Admin rejoin it, that should only take a couple minutes.
I attched the access logs, but receive the same error.
I was trying different syntaxes and this worked:
ad auth -u <username> -n <domain name>
and received the correct response.
INFO - NT_STATUS_OK: Success (0x0)
Looks like you may have cross posted, so this initial post didn't get the last updates. For anyone looking for an update on this post, see the last few posts over here:
after unchecking the bind as user box, do the failures in Access Tracker give the same message on the Alerts tab?
the rlm_ldap entries within the log is "normal"; it appears in succesful logons as well.
Can you post a copy of the exported log file for the failed attempt?
At Aruba, we believe that the most dynamic customer experiences happen at the Edge. Our mission is to deliver innovative solutions that harness data at the Edge to drive powerful business outcomes.
© Copyright 2020 Hewlett Packard Enterprise Development LPAll Rights Reserved.