Microsoft introduced a new security group named “Protected Users Group” with Server 2012 R2 and windows 8.1 clients to offer additional protections against the credential theft/compromise and help in your overall mitigation plan for Pass of the Hash (PtH) attack. Its highly recommended to add all your service and high privileged accounts to this group for more protection.

For more information on this Security group, please check the below link.

https://technet.microsoft.com/en-us/library/dn466518.aspx

Microsoft Published two documents (Version 1 & 2) explaining in details the Pass of Hash Attack and possible mitigation, i would highly advice downloading these documents from the below link

http://www.microsoft.com/en-eg/download/details.aspx?id=36036

Problem:

Back to our main post, we had a scenario with some companies adding their main critical service accounts and admin accounts in the Protected Users Group. Some of these accounts (not all of them) reported that they were not able to log in to their local machines or remotely to any server whether its 2008 or 2012 family. The error message the user receives is as shown below:

As soon as these users are removed from the Protected group, they just work back normally. The weird thing is that this error occurred only for few accounts in the Protected Users group and not all accounts.

The following event was logged in the Event viewer at the same time of log in failure


Solution:

Upon further investigation on this problem we were able to identify a common factor for all these accounts that were unable to log in after being added to the Protected Users group:

  1. They were old accounts, created few years ago when the domain was 2003 Domain/Forest Functional Level.
  2. These accounts have Non-Expiry passwords (Since most of them are service accounts) !
Microsoft SCOM sent alerts when one of these users tried to connect/log in to the domain controller which helped understanding and solving the problem.
As per the SCOM alert, this was the fix. Resetting and changing these specific user passwords fixed the problem and they were able to log in either locally or remotely normally.
What was the problem ?
As we mentioned before these accounts were created long time ago when the domain/Forest functional level was 2003 and at that time there were no Kerberos hash created and password didn’t change from that time.
Password hashes are kept on the domain controller with all available etypes (Encryption Types). It seems that the passwords for these accounts which were set not to expire did not have the AES hash but only got the NTLM hash. Protected Users group is only using AES and that’s why these users were not able to connect because their passwords can’t be verified since there is no AES hash.
After resetting the password all those hashes were available and the problem was fixed 🙂
For more information on Hashes and how passwords works in Windows environment please check the below articles.
Hopefully this post can help any user with the same problem and shed some light on how passwords work in Windows environment.