Protected Users

I work for a large manufacturing company. We have a large number of organizations that are highly specialized in what they do. This group of SharePoint admins, a group of Exchange admins, we have our domain admins in one group while the domain architects are in another organization and then there’s me, the Information Security guy who is the security architect for Active Directory so three organizations just for our AD.

I had a conversation the one of the AD architects around the protected users group. This guy happens to have a user account that is an Account Operator due to his work with International. I asked him why he had a production server administrator account in the account operators group and he responded with something like, I need to support the International customers and until there is a security or technical requirement to use a different account, I’m using my admin account for that work. I explained to him that if I can compromise a server that he is logged on to, I can run tools like Mimikatz and scrape his account credentials from memory and now I not only have access to all the servers he’s got access to but I am also now an Account Operator and can manage any account I want as long as it isn’t a protected account (adminCount=1). His whole attitude changed…

I tell this story because Microsoft has a way of protecting accounts like this but it does come at a cost. With a forest functional level of 2012 or higher, your AD now has a global group called “Protected Users”.

What exactly will Protected Users buy you? Well it will enforce a few things. It will not cache your plaintext creds even with Windows Digest enabled. This is important to remember because we use a VPN product that requires you to log into your laptop with cached creds, establish the VPN tunnel and off you go. If you place your daily user account into the protected users group, you can essentially say goodbye to telecommuting. We don’t allow folks to have their administrator passwords nor are they allowed to create local accounts so this could be impacting. Since this also prevents a cached verifier from being created so if you go offline, i.e. put your laptop to sleep thinking you will simply pick up where you left off from home, think again. The Cached Verifier is created at logon and when you lock your PC so without network connectivity, you won’t be able to unlock your computer.

Protected users will also not allow Kerberos to use RC4 or DES encryption, nor can you authenticate against the domain with NTLM. Your kerberos tickets will have a 4 hour lifespan. This is to protect the account from golden tickets. The accounts also will not be allowed to be delegated with either constrained or unconstrained delegation.

Because of the scope of what protected users limits for its members, you need to be very careful how you implement this. Case in point, I took a System Center Operations Manager service account (action account) and added it to the protected users group. Within a couple days, the SCOM admin called me and asked if anything had changed with the account because it can no longer push agents to servers that need monitoring. This would also break things like SharePoint and OWA which uses constrained delegation. Because of this, Microsoft does not recommend adding service accounts to the protected users group so a phased approach might be best. Start with your domain/enterprise admins, then account operators and so forth until you have all accounts with high level of privilege in the group. When you discover service accounts in your Account Operator group, work with the product team that owns that account to see what’s going to break and be aware that not everything, regardless of permissions, can be in the protected users group.



Leave a Reply