This article is a follow on from a previous post I did that for in User Lockouts and 802.1x Lockouts
The situation is, You trace your lockout to your NPS server that handles 802.1x - but now the mission of the day is to prevent lockouts, knowing that the NPS server is responsible is a positive thought but now you need to stop the lockouts occurring, Which, as you will find on this article is a whole different kettle of fish.🐠
There are a couple of places you need to review policies and registry keys, obviously, my advice here is find the policy that matches your unique situation and apply the required policies don’t just blindly apply everything thinking it will fix the problem - To fix a problem, you need to know what’s Causing the issue and then you need to come up with a plan to fix the problem, please don’t attempt this the other way around - getting the answers without any question or being able to show your workings out it’s not very helpful
NPS Lockout Policy
This remain disabled by default and to check the registry keys for this you need to check this location:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\AccountLockout
This will show you the keys as below:
You will notice that the following is true:
MaxDenials is set to 0 (which is disabled)
ResetTime is set to 2880 minutes which is 2 days
ResetTime is set to 2880 minutes which is 2 days
This is not very helpful and when the user inputs a wrong password this will continually be sent from the NPS server to the domain controller which will eventually results in a lockout, so lets take the account lockout policy which for example could be:
That means that after 6 invalid logins you account is locked out and the reset time is defined as 30 minutes timer before it "discards" those attempts, however that can be overridden with FGPP and that policy says 2 attempts and the timer is 55 minutes but notice that the lockout is "until an administrator unlocks the account" which is good.
Note : To edit the FGPP you need to start ADAC (Active Directory Administrative Centre) however they can be viewed in ADDS in this location:
CN=Password Settings Container,CN=System,DC=bear,DC=local
In ADAC you are looking for the "Password Settings Container" as below:
You will see your password policy on the right, if you double click a policy you then to the lower right of that window you will see this section:
Right now back to NPS, you need to update some registry keys and those values to the ones below in the image, remember you need to reboot the server after the update - restarting the IAS service (it called IAS because it used to be called IAS and Microsoft have not updated the service name) does not always work!!!
Therefore the new values will be under the lockout policy and set like this:
MaxDenials is set to 2
That means that after 6 invalid logins you account is locked out and the reset time is defined as 30 minutes timer before it "discards" those attempts, however that can be overridden with FGPP and that policy says 2 attempts and the timer is 55 minutes but notice that the lockout is "until an administrator unlocks the account" which is good.
Note : To edit the FGPP you need to start ADAC (Active Directory Administrative Centre) however they can be viewed in ADDS in this location:
CN=Password Settings Container,CN=System,DC=bear,DC=local
In ADAC you are looking for the "Password Settings Container" as below:
You will see your password policy on the right, if you double click a policy you then to the lower right of that window you will see this section:
Right now back to NPS, you need to update some registry keys and those values to the ones below in the image, remember you need to reboot the server after the update - restarting the IAS service (it called IAS because it used to be called IAS and Microsoft have not updated the service name) does not always work!!!
Therefore the new values will be under the lockout policy and set like this:
MaxDenials is set to 2
ResetTime is set to 30 minutes (Hex is 1e)
Now when a user changes their password and they have the old password on their phone, NPS will now locally lock them out and this will not be passed onto ADDS to get their main account locked out as well.
Monitoring Locked out NPS accounts
If people get locked out by NPS then you will see a sub-key for the login name of the user, here you can see "Bad.Bear" has been locked out by NPS and this account in ADDS remains active:
The path to they key is:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\AccountLockout\<user lockedout>
The path to they key is:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\AccountLockout\<user lockedout>
This should then solve your lockout woes, if not you need to "bring out the big guns" and think outside the box!
NPS Policies and Mitigation
The NPS lockout is good but it will not catch the tricky lockouts, like for example, the user account is being locked out by the NPS server using 802.1x but you do not see any failure events, which will usually be a 6273 events in the Security log like this:
Therefore you seem to have a user (or users) that are not getting a invalid NPS accounting log, and no they will not get a valid accounting eventlog entry of 6273 as if that was the case they would have no lockouts occuring.
Therefore you seem to have a user (or users) that are not getting a invalid NPS accounting log, and no they will not get a valid accounting eventlog entry of 6273 as if that was the case they would have no lockouts occuring.
This means this issue is a fail but its a fail that cannot be logged, this is not helpful at all, obviously you could get the full debug logs from the NPS server, but there is another solution to get these logs to appear, that is down to a policy to catch this behaviour and prevent the lockouts.
Pre-Flight : Create ADDS Security Group
You will need to have a group created in your ADDS to support this policy, in this example I have called it Wifi-Deny
NPS Policy Creation
Well to solve that riddle, NPS can also Deny and Allow, so that is what we will do to trace the lockout origin, so from the NPS server start the "Network Policy Server"
Then from there you "Network Policies"
Then you need to right click on the Network Policies and choose New:
Then you need to give it a valid name:
Then you will get to the conditions, click the Add button, the choose User Groups as below:
Then add the name of your group you created earlier, here we used "Wifi-Deny"
You then want to Deny the request:
You then want to untick all the "less secure" authentication methods and then click Add and choose Protected EAP (or PEAP) as below
You will then see the Constraints and Settings, you can leave these as default, no updates here at all, then you will get an overview of the policy, all you can do is click finish.
Then you need to right click on the Network Policies and choose New:
Then you need to give it a valid name:
Then you will get to the conditions, click the Add button, the choose User Groups as below:
Then add the name of your group you created earlier, here we used "Wifi-Deny"
You then want to Deny the request:
You then want to untick all the "less secure" authentication methods and then click Add and choose Protected EAP (or PEAP) as below
You will then see the Constraints and Settings, you can leave these as default, no updates here at all, then you will get an overview of the policy, all you can do is click finish.
Once you click finish this will add the policy to NPS and enable it automatically, now you have some more work to do before we are done.
NPS : Policy Order
Now you have created your Deny policy you will notice it will be created as the lowest priority policy, and NPS will apply policies in the apply order, this means the allow policy's at the moment will override your Deny policy - so the problem is not fixed yet!
Therefore right click on your policy and "Move Up" as below, you need to do this twice as you have two policies above at the moment that "Allow"
You need it to look like this, with the Deny policy at the top:
Now you have this, when the erroneous users get locked out by NPS add the user to this group which will then generate the "Deny" Event ID of 6273 which will give you more clues as to where its locking out, adding people to the group you created earlier is not a resolution, this group only serves to stop the locking out so you can do an investigation as to where the lockouts are occurring from which phone or device.
Therefore right click on your policy and "Move Up" as below, you need to do this twice as you have two policies above at the moment that "Allow"
You need it to look like this, with the Deny policy at the top:
When the user is part of this group they will not be able to use the Wifi using 802.1x but you will be able to troubleshoot the issue and issued device.
Deny Event ID 6273
Now when the user or their device connects to the 802.1x WiFi you will now see the Event ID 6273 which will give you more information as to where the lockout is occurring, while the event will tell you the network device, the troubleshooting and investigative skills can then find the erroneous device
Network Policy Server denied access to a user.
Contact the Network Policy Server administrator for more information.
User:
Security ID: BEAR\Bad.Bear
Account Name: Bad.Bear
Account Domain: BEAR
Fully Qualified Account Name: BEAR\Bad.Bear
NAS:
NAS IPv4 Address: x.x.x.x
NAS IPv6 Address: -
NAS Identifier: F6-9E-22-7F-6F-1A:vap0
NAS Port-Type: Wireless - IEEE 802.11
NAS Port: 1
RADIUS Client:
Client Friendly Name: London Eero
Client IP Address: x.x.x.x
Authentication Details:
Connection Request Policy Name: Secure Wireless Connections
Network Policy Name: Deny 802.1x User Access
Authentication Provider: Windows
Authentication Server: nps.bear.local
Authentication Type: EAP
EAP Type: -
Account Session Identifier: 43334531314230443539413439343730
Logging Results: Accounting information was written to the local log file.
Reason Code: 65
Reason: The Network Access Permission setting in the dial-in properties of the user account in Active Directory is set to Deny access to the user. To change the Network Access Permission setting to either Allow access or Control access through NPS Network Policy, obtain the properties of the user account in Active Directory Users and Computers, click the Dial-in tab, and change Network Access Permission.
The above tells is that Bad.Bear has been locked out from the network device names in NPS as "London Eero" and as we have the date and time with this request
It is only a matter or asking what devices that "London Eero" could see at the time of the lockout, or more interestingly could it be that Bad.Bear is based in Solihull, but he is getting a device in London authenticate with his credentials?
Always trust the logs, they only tell the truth and sometimes facts/questions you do not want to hear/answer!!