Moises
asked on
Active Directory Lockouts via NPS (Network Policy Server) | RADIUS on Windows Server
Here is a weird one for account lockouts.
We have a GPO (Server 2012 R2) that sets a user's SSID with RADIUS (EAP), it all works and the user connects with a W10 endpoint via a Meraki WAP (MR42). For about 10/475 endpoints/users constant lockouts happen. We have domain controller logging enabled (nltest /dbflag:0x2080ffff) on the DCs and it tells us its coming from our NPS server that handles the RADIUS authentications. I also see these EAP failures on the WAP logs for the specific workstation so I know its coming from the endpoints.
We've cleared out all the credentials on the workstations but we still find that NPS if locking it out.
We also go to the endpoint and test connecting via WiFI/SSID and it works just fine.
This happens for a few times in a row and then stops for hours.
We've even tried to turn off WiFi and still see these events happen.
I see the repeated log entry until it locks out:
The lockout event:
These log entries match-up with the DC's Event Viewer's security section.
We have a GPO (Server 2012 R2) that sets a user's SSID with RADIUS (EAP), it all works and the user connects with a W10 endpoint via a Meraki WAP (MR42). For about 10/475 endpoints/users constant lockouts happen. We have domain controller logging enabled (nltest /dbflag:0x2080ffff) on the DCs and it tells us its coming from our NPS server that handles the RADIUS authentications. I also see these EAP failures on the WAP logs for the specific workstation so I know its coming from the endpoints.
We've cleared out all the credentials on the workstations but we still find that NPS if locking it out.
We also go to the endpoint and test connecting via WiFI/SSID and it works just fine.
This happens for a few times in a row and then stops for hours.
We've even tried to turn off WiFi and still see these events happen.
I see the repeated log entry until it locks out:
11/07 14:40:32 [LOGON] [8732] -DOMAIN HERE-: SamLogon: Transitive Network logon of DOMAIN\nvega from (via NPS01) Entered
11/07 14:40:32 [CRITICAL] [8732] NlPrintRpcDebug: Couldn't get EEInfo for I_NetLogonSamLogonEx: 1761 (may be legitimate for 0xc000006a)
11/07 14:40:32 [LOGON] [8732] -DOMAIN HERE-: SamLogon: Transitive Network logon of DOMAIN\nvega from (via NPS01) Returns 0xC000006AThe lockout event:
11/07 12:51:47 [LOGON] [8388] -DOMAIN HERE-: SamLogon: Transitive Network logon of DOMAIN\nvega from (via NPS01) Entered
11/07 12:51:47 [CRITICAL] [8388] NlPrintRpcDebug: Couldn't get EEInfo for I_NetLogonSamLogonEx: 1761 (may be legitimate for 0xc0000234)
11/07 12:51:47 [LOGON] [8388] -DOMAIN HERE-: SamLogon: Transitive Network logon of DOMAIN\nvega from (via NPS01) Returns 0xC0000234These log entries match-up with the DC's Event Viewer's security section.
If EAP 801.2x is used, then as soon as the account is locked out, every attempt will fail, that you see failures from NPS/Meraki is expected when an account is locked out.
What one needs to find are the failures that cause the lockout, any failures after the lockout are fairly irrelevant. The meraki log is the symptom, not the cause.
Presuming that the account is being locked out from bad passwords, I would suggest unlocking the account and then monitoring for a bad password using altools https://www.microsoft.com/en-gb/download/details.aspx?id=18465 and use the altools output to search the appropriate DC event log to find the source of the password failure, if the source of the password failure is from NPS, then you need to correlate that with the Meraki logs to confirm the WiFi client that is causing the failure.
I would guess that it is a saved credential on another device that is causing the problem.
What one needs to find are the failures that cause the lockout, any failures after the lockout are fairly irrelevant. The meraki log is the symptom, not the cause.
Presuming that the account is being locked out from bad passwords, I would suggest unlocking the account and then monitoring for a bad password using altools https://www.microsoft.com/en-gb/download/details.aspx?id=18465 and use the altools output to search the appropriate DC event log to find the source of the password failure, if the source of the password failure is from NPS, then you need to correlate that with the Meraki logs to confirm the WiFi client that is causing the failure.
I would guess that it is a saved credential on another device that is causing the problem.
ASKER
ArneLovius, the DC logs show the ...6A wrong username or password event coming from NPS before the lockout happens, so that is the reason why I think this is coming from there first. After the lockout occurs we then see everyone reporting the ...234 lockout event.
I will try some of those tools to see if we can get further details from the device reported in the lockout event and Meraki logs.
I will try some of those tools to see if we can get further details from the device reported in the lockout event and Meraki logs.
Correlating the failures before the lockout is the critical part.
It can also be worthwhile to disable WiFi on a suspected device, then unlock the account and while leaving WiFi disabled, see if the lockouts continue, if they do, then logically the failures cannot be WiFi authentication from that device.
It can also be worthwhile to disable WiFi on a suspected device, then unlock the account and while leaving WiFi disabled, see if the lockouts continue, if they do, then logically the failures cannot be WiFi authentication from that device.
ASKER
ArenLouvis, that is one good step to take and can't remember if I did that for the ones getting locked out. Most of them are docked in anyways. I will attempt that and the MS tools to see what we get next.
This question needs an answer!
Become an EE member today
7 DAY FREE TRIALMembers can start a 7-Day Free trial then enjoy unlimited access to the platform.
View membership options
or
Learn why we charge membership fees
We get it - no one likes a content blocker. Take one extra minute and find out why we block content.
ASKER
Here is a sample of the logs on the WAP side, so I know this is coming from wireless: