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.

Shadow Group

Before I go in details, let me clear that shadow group is not a new type of group in Active Directory in addition of Domain Local Group, Global Group and Universal Group. Shadow group is a global security group whose members are the user object of a specific organizational unit (OU).

Shadow groups are generally used to apply Fine grained password policy. Fine-grained password policies are only applied to user objects (or inetOrgPerson) and global security groups. Fine-grained password policies cannot be applied to an OU, if you want to apply a fine-grained password policy to all of the users of an OU, you can use a shadow group.

The membership of a shadow group needs to be updated manually or through scripts.

The power shell script required to automate the membership of a shadow group:

1. Either open the Active Directory Module For Windows Power Shell or open the Windows Power Shell and run the following command

Import-Module ActiveDirectory

2.Set a variable $OU that defines the distinguished name of the OU which contains the user object.

$OU="OU=TheOUName,DC=yourdomain,DC=com"

3. Set a variable $ShadowGroup that defines the distinguished name of the shadow group 

$ShadowGroup="CN=ShadowGroupName,OU=TheOUName,DC=yourdomain,DC=com"

4.This section of script will verify the membership of the shadow group that the members belong to the specific OU, if not remove them from the shadow group.

Get-ADGroupMember –Identity $ShadowGroup | Where-Object {$_.distinguishedName

–NotMatch $OU} | ForEach-Object {Remove-ADPrincipalGroupMembership –Identity 

$_ –MemberOf $ShadowGroup –Confirm:$false}

5. This section will monitor the newly added user objects in the specific OU and automatically add them as a member of shadow group.

Get-ADUser –SearchBase $OU –SearchScope OneLevel –LDAPFilter 

"(!memberOf=$ShadowGroup)" | ForEach-Object {Add-ADPrincipalGroupMembership –Identity $_ –MemberOf $ShadowGroup}

Now save this script as "ShadowGroup.ps1".

After the script is ready we need to create a task scheduler to run this script automatically,for example if you want to run this script every 24 hours. To do this:

1. Open the Task scheduler from the start menu.

2. Click create task.

3. on the general tab type the name of the task.

4. Click on the action tab and new.

5. On the New Action wizard

   Action: Start a program

   program/script: 

     C:\Windows\system32\windowspowershell\v1.0\powershell.exe

      Add arguments (optional): C:\scripts\ShadowGroup.ps1

Lab Implementation:

I have a DC named Test-dc.test.com. On the DC I've created an OU named Sales, within Sales I've create two users named Dev & Sam and a global security group named Auditor which will be used as shadow group. Please go through with the images below: