Protected User Group

User accounts are used to verify the identity of the users on any server or client work stations. The process of verifying the user identity is known as Authentication. When a user logins on a standalone or workgroup computer his identity is verified using the local SAM account database but when a domain user logins on a domain joined computer he is authenticated by the domain controller. For authentication several authentication protocols like NTLM, Kerberos, Credential Security Support Provider (CredSSP) can be used. When a user is authenticate by a DC his credentials are cached on the local machine, using this cached credential he can login in offline manner means without contacting DC for the authentication.

Although from security point of view every user account is has the importance but some accounts can be more sensitive than others. To secure these highly sensitive user accounts we have options like Fine-Grained Password Policy and group policy to restrict interactive logon. But these options don’t restrict from using less secure authentication protocol like NTLM and CredSSP, can’t restrict from using less secure encryption protocol during the pre-authentication process.

To comply with these issues Microsoft introduces Protected User Group in Windows Server 2012 R2. Members of the protected user group don’t inherit the permissions (ACL) from the OU but from the group. This group generates non-configurable protection on devices and computers running windows server 2012 R2 and windows 8.1, and on domain controllers in domains with PDC (Primary Domain Controller) running on Windows Server 2012 R2.

Protected users are generally used for Domain and Enterprise administrator account, it doesn’t mean that they can’t be used for standard users but it will apply more restrictions over those members. So it’s recommended that before adding users to the Protected Users Group test it in a test environment.

When a member of a protected users group logins on a windows server 2012 R2 host or windows 8.1 client computer following restrictions apply:

• The Protected Users group membership cannot authenticate by using NTLM, Digest Authentication, or Credential Security Support Provider, authentication mechanism also known as CredSSP. On Windows 8.1 devices, passwords are not cached, so the device that uses any one of these Security Support Providers (SSPs) will fail to authenticate to a domain when the account is part of the Protected User group.
• The Kerberos protocol will not use the weaker Data Encryption Standard (DES) or RC4 encryption types in the pre-authentication process. Therefore, you must configure the domain to support at least the Advanced Encryption Standard cipher suite.
• The user’s account cannot be delegated with Kerberos constrained or unconstrained delegation. This can cause former connections to other systems to fail if the user is in the Protected Users group.
• The default Kerberos TGTs lifetime setting of four hours is configurable by using Authentication Policies and Silos, which you can access through the Active Directory Administrative Center. This means that the user must authenticate again after four hours.

Detecting members of Protected User Group:

To check if you have the Protected Users group in your domain, log in to Windows Server 2012 R2 as a domain administrator:

·         Open Server Manager from the Start screen

·         Select Active Directory Users and Computers from the Tools

·         In the left pane, expand your domain and click Users.

If Protected Users is present in the domain, you should see it on the right. By default it doesn’t has any member but users can be added to Protected Users, as you would add them to any AD group.

To detect the members of protected user group using powershell:

Get-ADUser -LDAPFilter "(admincount=1)" | select name

Prerequisites:

·        To gain the Protected Users Security Group, the Active Directory schema needs to be extended to Windows Server 2012 R2 .

·  To replicate the Protected Users group, the Domain Controller holding the Primary Domain Controller emulator (PDCe) Flexible Single Master Operations (FSMO) role needs to run Windows Server 2012 R2.

·   Users need to authenticate on Windows 8.1-based devices (or up) or Windows Server 2012 R2-based servers (or up) to a Domain Controller that runs at least Windows Server 2012 R2.

·    For Domain Controller protection, the Active Directory domain needs to operate on the Windows Server 2012 R2 Domain Functional Level.