Security

Hi all,

I'm struggling with some intermittent machine authentication failures.. For the most part machine authentication has been working without any issues. I have a simple allow policy that checks for Machine Auth default role and allows all workstations on the network (with some ACLs). All workstations are set for Computer and User authentication.

During each successful attempt, I see host/[machine name].example.net in access tracker. The successful attempts generate the following logs in access tracker:

2020-02-10 18:20:08,645 [Th 41 Req 1249 SessId R00000068-01-5e420f58] INFO RadiusServer.Radius - rlm_eap_mschapv2: Received MSCHAPv2 Response from client
2020-02-10 18:20:08,645 [Th 41 Req 1249 SessId R00000068-01-5e420f58] INFO RadiusServer.Radius - rlm_mschap: MSCHAPv2 username used for challenge computation host/ws-MVdTest01.example.net
2020-02-10 18:20:08,645 [Th 41 Req 1249 SessId R00000068-01-5e420f58] INFO RadiusServer.Radius - rlm_mschap: Using domain example.net from User-Name attribute
2020-02-10 18:20:08,645 [Th 41 Req 1249 SessId R00000068-01-5e420f58] INFO RadiusServer.Radius - rlm_mschap: Domain example.net from User-Name does not match domain example from Object SID
2020-02-10 18:20:08,645 [Th 41 Req 1249 SessId R00000068-01-5e420f58] INFO RadiusServer.Radius - rlm_mschap: authenticating user WS-MVDTEST01$, domain example.net
2020-02-10 18:20:08,647 [Th 41 Req 1249 SessId R00000068-01-5e420f58] INFO RadiusServer.Radius - rlm_mschap: user WS-MVDTEST01$ authenticated successfully
2020-02-10 18:20:08,647[Th 41 Req 1249 SessId R00000068-01-5e420f58] INFO RadiusServer.Radius - MS-Chap User Authentication time = 2 ms
2020-02-10 18:20:08,647 [Th 41 Req 1249 SessId R00000068-01-5e420f58] INFO RadiusServer.Radius - rlm_eap_mschapv2: Sending MSCHAPv2 Success reply

However this will occasionally fail. When this happens I see a failure entry in access tracker indicating EXAMPLE\[hostname]$ as the username.

Detailed logs are as follows:

2020-02-10 17:56:59,827 [Th 44 Req 1220 SessId R00000065-01-5e4209eb] INFO RadiusServer.Radius - rlm_eap_mschapv2: Received MSCHAPv2 Response from client
2020-02-10 17:56:59,827 [Th 44 Req 1220 SessId R00000065-01-5e4209eb] INFO RadiusServer.Radius - rlm_mschap: MSCHAPv2 username used for challenge computation
2020-02-10 17:56:59,827 [Th 44 Req 1220 SessId R00000065-01-5e4209eb] INFO RadiusServer.Radius - rlm_mschap: Using domain EXAMPLE from User-Name attribute
2020-02-10 17:56:59,827 [Th 44 Req 1220 SessId R00000065-01-5e4209eb] INFO RadiusServer.Radius - rlm_mschap: authenticating user WS-MVDTEST01$, domain EXAMPLE
2020-02-10 17:56:59,839 [Th 44 Req 1220 SessId R00000065-01-5e4209eb] INFO RadiusServer.Radius - rlm_mschap: user WS-MVDTEST01$ authentication failed
2020-02-10 17:56:59,839 [Th 44 Req 1220 SessId R00000065-01-5e4209eb] ERROR RadiusServer.Radius - rlm_mschap: AD status:Logon failure (0xc000006d)
2020-02-10 17:56:59,839 [Th 44 Req 1220 SessId R00000065-01-5e4209eb] INFO RadiusServer.Radius - MS-Chap User Authentication time = 12 ms
2020-02-10 17:56:59,839 [Th 44 Req 1220 SessId R00000065-01-5e4209eb] ERROR RadiusServer.Radius - rlm_mschap: FAILED: MS-CHAP2-Response is incorrect

When this happens access tracker shows the following alert details:

RADIUS	MSCHAP: AD status:Logon failure (0xc000006d) 
MSCHAP: Authentication failed
EAP-MSCHAPv2: User authentication failure

I can't quite figure out what the endpoint or ClearPass is doing wrong in the failure situations. It seems like the computer lookups are failing. Has anyone else seen this before?

I've confirmed the that Machine AD search string in my auth source should be correct:

(&(sAMAccountName=%{Host:Name}$)(objectClass=computer))

Both authentication requests should pass.

The first thing I don't understand is why you have changed the authentication query. Normally this is not needed for machine authentication. 

Next to this, it looks like the LDAP lookup is fine but the mschap authentication failed. The log in indicating that the DC will reject the authentication request.

Error code 0xc000006d means: "This is either due to a bad username or authentication information"

Is the same machine working in most cases?

I haven't changed the default authentication query. I was simply providing that for verification purposes.

I also should mention that this is a new deployment on v6.8.4.

This is the same machine that passes most of the time but occasionally fails so you are correct.

It looks to my like the supplicant is occasionally presenting the wrong domain to match against its request (example.net vs EXAMPLE)

Could something be misconfigured in the AD environment?

About ready to throw these clients and APs out the window.

Interesting data point:

- The intermittent failures are isolated to Meraki APs

- Mist APs are working successfully (every time)

I'm even more confused today than I was yesterday.

Customer had two distinct issues at play here that were exhibited across various testing devices:

Domain Trust Issues

Certain AD computer objects have fallen off the domain due to yet to be identified domain trust issues. Issuing the following commands from PowerShell (as Admin) were able to identify and resolve the issue for some devices:

Test-ComputerSecureChannel -Verbose

Any issues with the AD computer's relationship with the domain will present themselves here. In our case some of our test clients reported:

PS C:\windows\system32> Test-ComputerSecureChannel -Verbose
VERBOSE: Performing the operation "Test-ComputerSecureChannel" on target "PC-5CG90158W".
False
VERBOSE: The secure channel between the local computer and the domain example.net is broken.

We were able to repair these workstations by running the following command from PowerShell, again launched as admin:

Test-ComputerSecureChannel -Repair -Credential EXAMPLE\[Domain Admin]

Wifi Profile Errors

Separately we identified anomalies in the group policy propagation of our wifi settings for different SSIDs. This is why Meraki wasn't working and Mist was. Deleting these group policy settings and recreating them with the appropriate values for User or Computer authentication resolved the rest of the issues.