Protected Users Group in Active Directory

Protected Users Security Group

  • 08/31/2016
  • 7 minutes to read

Applies To: Windows 8.1, Windows Server 2012 R2

This topic for the IT professional describes the Active Directory security group Protected Users and explains how it works. This group was introduced in Windows Server 2012 R2.

Members of this group are afforded additional protections against the compromise of credentials during authentication processes.

This security group is designed as part of a strategy to effectively protect and manage credentials within the enterprise. Members of this group automatically have non-configurable protections applied to their accounts. Membership in the Protected Users group is meant to be restrictive and proactively secure by default. The only method to modify these protections for an account is to remove the account from the security group.

 Warning

Accounts for services and computers should not be members of the Protected Users group. This group provides no local protection because the password or certificate is always available on the host. Authentication will fail with the error “the username or password is incorrect” for any service or computer that is added to the Protected Users group.

This domain-related, global group triggers non-configurable protection on devices and host computers running Windows Server 2012 R2 and Windows 8.1, and on domain controllers in domains with a primary domain controller running Windows Server 2012 R2. This greatly reduces the memory footprint of credentials when users sign into computers on the network from a non-compromised computer.

Depending on the account’s domain functional level, members of the Protected Users group are further protected due to behaviour changes in the authentication methods that are supported in Windows.

  • The member of the Protected Users group cannot authenticate by using NTLM, Digest Authentication, or CredSSP. On a device running Windows 8.1, 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 a member of the Protected User group.
  • The Kerberos protocol will not use the weaker DES or RC4 encryption types in the pre-authentication process. This means that the domain must be configured to support at least the AES cipher suite.
  • The user’s account cannot be delegated with Kerberos constrained or unconstrained delegation. This means that former connections to other systems may fail if the user is a member of the Protected Users group.
  • The default Kerberos Ticket Granting Tickets (TGTs) lifetime setting of four hours is configurable by using Authentication Policies and Silos, which can be accessed through the Active Directory Administrative Centre (ADAC). This means that when four hours has passed, the user must authenticate again.

For more information, see How the Protected Users group works in this topic.

The following table specifies the properties of the Protected Users group.

TABLE 1
AttributeValue
Well-known SID/RIDS-1-5-21-<domain>-525
TypeDomain Global
Default containerCN=Users, DC=<domain>, DC=
Default membersNone
Default member ofNone
Protected by ADMINSDHOLDER?No
Safe to move out of default container?Yes
Safe to delegate management of this group to non-service admins?No
Default user rightsNo default user rights

How the Protected Users group works

This section explains how the Protected Users group works when:

  • Windows 8.1 devices are connecting to Windows Server 2012 R2 hosts.
  • The account is located at the Windows Server 2012 R2 domain functional level.

When Windows 8.1 devices are connecting to Windows Server 2012 R2 hosts

When the Protected Users’ group account is upgraded to the Windows Server 2012 R2 domain functional level, domain controller-based protections are automatically applied. Members of the Protected Users group who authenticate to a Windows Server 2012 R2 domain can no longer authenticate by using:

  • Default credential delegation (CredSSP). Plain text credentials are not cached even when the Allow delegating default credentials Group Policy setting is enabled.
  • Windows Digest. Plain text credentials are not cached even when Windows Digest is enabled.
  • NTLM. The result of the NT one-way function, NTOWF, is not cached.
  • Kerberos long-term keys. The keys from Kerberos initial TGT requests are typically cached so the authentication requests are not interrupted. For accounts in this group, Kerberos protocol verifies authentication at each request..
  • Sign-in offline. A cached verifier is not created at sign-in.

Non-configurable settings to the TGTs expiration are established for every account in the Protected Users group. Normally, the domain controller sets the TGTs lifetime and renewal, based on the domain policies, Maximum lifetime for user ticket and Maximum lifetime for user ticket renewal. For the Protected Users group, 600 minutes is set for these domain policies.

After the user account is added to the Protected Users group, protection is already in place when the user signs into the domain.

When domain controllers other than Windows Server 2012 R2 require the Protected Users security group

The Protected Users group can be applied to domain controllers that run an operating system earlier than Windows Server 2012 R2. This allows the added security that is achieved by using the Protected Users group to be applied to all domain controllers. The Protected Users group can be created by HYPERLINK “https://technet.microsoft.com/library/cc816944(v=ws.10).aspx” transferring the primary domain controller (PDC) emulator role to a domain controller that runs Windows Server 2012 R2. After that group object is replicated to other domain controllers, the PDC emulator role can be hosted on a domain controller that runs an earlier version of Windows Server.

For more information, see How to Configure Protected Accounts.

Built in restrictions of the Protected Users security group

Accounts that are members of the Protected Users group that authenticate to a Windows Server 2012 R2 domain are unable to:

  • Authenticate with NTLM authentication.
  • Use DES or RC4 encryption types in Kerberos pre-authentication.
  • Be delegated with unconstrained or constrained delegation.
  • Renew the Kerberos TGTs beyond the initial four-hour lifetime.

 Warning

Accounts for services and computers should not be members of the Protected Users group. This group provides no local protection because the password or certificate is always available on the host.

Event log information

Two operational administrative logs are available to help troubleshoot events that are related to Protected Users. These new logs are located in Event Viewer and are disabled by default, and are located under Applications and Services Logs\Microsoft\Windows\Microsoft\Authentication.

EVENT LOG INFORMATION
Event ID and LogDescription
104 ProtectedUser-ClientReason: The security package on the client does not contain the credentials. The error is logged in the client computer when the account is a member of the Protected Users security group. This event indicates that the security package does not cache the credentials that are needed to authenticate to the server. Displays the package name, user name, domain name, and server name.
304 ProtectedUser-ClientReason: The security package does not store the Protected User’s credentials. An informational event is logged in the client to indicate that the security package does not cache the user’s sign-in credentials. It is expected that Digest (WDigest), Credential Delegation (CredSSP), and NTLM fail to have sign-on credentials for Protected Users. Applications can still succeed if they prompt for credentials. Displays the package name, user name, and domain name.
100 ProtectedUserFailures-DomainControllerReason: An NTLM sign-in failure occurs for an account that is in the Protected Users security group. An error is logged in the domain controller to indicate that NTLM authentication failed because the account was a member of the Protected Users security group. Displays the account name and device name.
104 ProtectedUserFailures-DomainControllerReason: DES or RC4 encryption types are used for Kerberos authentication and a sign-in failure occurs for a user in the Protected User security group. Kerberos preauthentication failed because DES and RC4 encryption types cannot be used when the account is a member of the Protected Users security group. (AES is acceptable.)
303 ProtectedUserSuccesses-DomainControllerReason: A Kerberos ticket-granting-ticket (TGT) was successfully issued for a member of the Protected User group.

Deployment requirements

Requirements to provide client-side protection for members of the Protected Users group include:

  • The Protected Users global security group is replicated to all domain controllers in the account domain.
  • Devices and hosts are running Windows 8.1 or Windows Server 2012 R2.

Requirements to provide domain controller protection for members of the Protected Users group include:

  • The domain functional level in the account domains is set to Windows Server 2012 R2.

To enable Windows Server 2012 R2 and Windows 8.1 protection for clients on domains with pre-Windows Server 2012 R2 domain functional levels, after the Protected Users group has replicated throughout the domain, a user signs in with an account that is a member of a Protected Users group.

Resolved–“WARNING: Unable to resolve package source ‘https://www.powershellgallery.com/api/v2’

HiTechCandy Blog – New Era of Technical Blog

I’ve been running into a similar issue today trying to get the AZ module installed.  See if running this below command first helps:

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

PowerShell Install-Module: The term ‘Install-Module’ is not recognized

PowerShell error : Install-Module: The term ‘Install-Module’ is not recognized as the name of a cmdlet.
This error Is Manly Because Of The Limitation of cmdlet and resource available on Machine.

This Gallery TechNet Will help you to resolve The Error” Install-Module: The term ‘Install-Module’ is not recognized as the name of a cmdlet.”
While Performing This Step We Need to restart the system So Request You to Save Any unsaved Document Before Following the Below Steps.
To Resolve This We Need to Update. Windows Management Framework 5.1 with the Help of Below Link

https://www.microsoft.com/en-us/download/details.aspx?id=54616
*Tested on Client Machine

Step 1 : Run the PowerShell as Administrator.

 

Step 2 : When We try the Command Install-Module msonline
PS C:\Users\Administrator>Install-Module msonline
It Givens Error
Install-Module : The term ‘Install-Module’ is not recognized as the name of a cmdlet, function, script file,or operable program.
Check the spelling of the name, or if a path was included,verify that the path is correct and try again.
At line:1 char :1
+Install-module msonline



Step 3 : To Check the Host version Type Host

PS C:\Users\Administrator>HOST

 

Step 4 :if the Host Version 4.0 or Below That Need to Download And Install the Windows Management Framework 5.1

Need to Update. Windows Management Framework 5.1 with the Help of Below Link

https://www.microsoft.com/en-us/download/details.aspx?id=54616
* Note :When We Download and install windows Management Framework 5.1. it Will restart the Machine So please Save any unsaved Document.


Step 5 : Choose the Download you want as per Your Operating System.

Step 6 : Once we Restart the Machine Than Run the PowerShell as Administrator again.

Step 7 : We can Confirm if the HOST Version is Updated to 5.1

How to Disable/Enable Internet Options Tabs in Internet Explorer

As an IT guy, I always encounter problems when untrained users tweak their Internet connection settings.  They always make a mistake somewhere and sometimes the solution is to just keep them away from the Internet Options dialog box altogether.

I have worked at many companies that hide the Internet Options tab in Internet Explorer to discourage users from changing the options, which makes sense since network admins are the only ones who are supposed to access these options.

In a controlled environment, companies usually allow only one type of browsers like Internet Explorer and those companies usually don’t allow their employees to change the Internet Options like default the homepage and proxy server.

Below is a typical Internet Options window:

There are several ways to disable the Internet Options tabs in IE and I’ll explain the different methods in this post. The first method uses Group Policy, but will only work if you have the Pro or Ultimate versions of Windows. If you are running Home or Home Premium, then skip down to the registry section.

Disable Internet Options in IE via Group Policy

To disable any tab in the Internet Options window, follow these steps below:

Step 1: Click Start RUN and type GPEDIT.MSC in the search bar and hit enter to launch the Group Policy editor window.

Step 2: In the Local Group Policy editor window expand User Configuration > Administrative Templates > Windows Components > Internet Explorer then click on Internet Control Panel.

Step 3: On the right pane of the window, double click on the item you want to disable. For example, to disable the Advanced tab, double click on Disable the Advanced page option.

Step 4: In the properties window, click on the Enabled option and click OK. The Advanced tab in the Internet Options window will now be disabled and removed.

Step 5: Follow the previous steps to disable other items in the Internet Options window. To enable items, just select the Not Configured option in the properties window and click OK.

There you have it!  For less savvy computer users who don’t know about GPEDIT, it should discourage them from changing the advanced settings in IE.

Disable IE Options via Registry Editor

The second way to disable tabs in IE options is to use the registry editor. This is a bit more complicated but is the only option if you can’t access the group policy editor.

You can open the registry editor by clicking on Start and typing in Regedit. Once there, navigate to the following key:

HKEY_CURRENT_USER\Software\Policies\Microsoft

Note that if you want to disable this option for all users on the PC, navigate to the same key, but under HKEY_LOCAL_MACHINE.

If there isn’t already a key called Internet Explorer under Microsoft, you’ll have to create it manually. Just right-click on Microsoft and choose NewKey. At this point, there are two options. If you want to disable the entire Internet Options dialog, you can create another key under Internet Explorer called Restrictions.

Lastly, you’ll create a new DWORD value in the right-pane inside Restrictions called NoBrowserOptions. Give that a value of 1 and restart Internet Explorer. If you try to go to Internet Options, it will give you an error message.

If you don’t want to disable the whole dialog, but instead just a few of the tabs, then you should create a new key called Control Panel under Microsoft instead of Restrictions. Inside of that, you’ll create DWORD entries that correspond to the tabs:

AdvancedTab

ConnectionsTab

ContentTab

GeneralTab

PrivacyTab

ProgramsTab

SecurityTab

As you can see above, I created the Control Panel key under Internet Explorer and then created a DWORD entry in the right-pane called AdvancedTab with a decimal value of 1. This removed just the advanced tab from the IE options window.

Hopefully, these methods will allow you to gain more control over Internet Explorer advanced settings in your environment. If you’re having issues, feel free to comment and I’ll try to help. Enjoy!

Troubleshooting Failed Login Attempts in Windows Active Directory Server

On Event Viewer, we should look for the following information (filter Security log):

Security log, events 4625 and 4771 (format for filtering is: 4625,4771).

We need to filter for these two events since we don’t know if the user failed to authenticate using NTLM (4625) or Kerberos (4771).

References:

4625(F): An account failed to log on

https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4625

4771(F): Kerberos pre-authentication failed

https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4771

With a view containing only events 4625 and 4771 we can then search (Find…) the user we are troubleshooting.

We should be looking for and see the following information on each of events.

4625:

You can refer to the article above for a full description on the Status and Sub-Status codes.

Log Name: Security

Source: Microsoft-Windows-Security-Auditing

Date: 5/21/2019 10:40:19 AM

Event ID: 4625

Task Category: Logon

Level: Information

Keywords: Audit Failure

User: N/A

Computer: DC2.contoso.local

Description:

An account failed to log on.

Subject:

Security ID: NULL SID

Account Name: –

Account Domain: –

Logon ID: 0x0

Logon Type: 3

Account For Which Logon Failed:

Security ID: NULL SID

Account Name: test2016 à This should be showing the account you are troubleshooting.

Account Domain: WIN2K16MEMBER

Failure Information:

Failure Reason: Unknown user name or bad password.

Status: 0xC000006D à These are the fields you should be looking also.

Sub Status : 0xC0000064 à We can have either 0xC0000064 or 0xC000006A

Process Information:

Caller Process ID: 0x0

Caller Process Name: –

Network Information:

Workstation Name: WIN2K16MEMBER à This might not show on this event but if it does this is where the bad password is coming from.

Source Network Address: 192.168.0.31 à This might not show on this event but if it does this is the IP where the bad password is coming from.

Source Port: 49735

Detailed Authentication Information:

Logon Process: NtLmSsp

Authentication Package: NTLM

Transited Services: –

Package Name (NTLM only): –

Key Length: 0

If the above event does not show the Network Information details, you will have to enable the Netlogon debug log to have more tracing and NTLM authentication information.

You can refer to the following article for the full instructions on how to enable and disable Netlogon

debugging:

Enabling debug logging for the Netlogon service

https://support.microsoft.com/en-us/help/109626/enabling-debug-logging-for-the-netlogon-service

Although, enabling and disabling Netlogon debugging is quite easy but should only be enabled for troubleshooting purposes and disabled afterwards:

Enable Netlogon debug:

From an elevated command prompt (as administrator), run the following command:

nltest /dbflag:2080ffff

Disable Netlogon debug:

From an elevated command prompt (as administrator), run the following command:

nltest /dbflag:0x0

The netlogon debug log can then be found under C:\Windows\debug\netlogon.log

On the netlogon debug log we should look for (find…) the user we are troubleshooting and should be able to find information similar to the bellow:

08/15 16:38:22 [LOGON] [608] C ONTOSO: SamLogon: Generic logon of CONTOSO.LOCAL\test2016 from ( WIN2K16MEMBER ) (via JUMPSERVER) Returns 0xC000006A

This entry tells you where the bad password came from.

4771:

You can refer to the article above for a full description on the Failure Codes.

Log Name: Security

Source: Microsoft-Windows-Security-Auditing

Date: 7/26/2019 11:47:11 AM

Event ID: 4771

Task Category: Kerberos Authentication Service

Level: Information

Keywords: Audit Failure

User: N/A

Computer: DC2.contoso.local

Description:

Kerberos pre-authentication failed.

Account Information:

Security ID: CONTOSO\Administrator

Account Name: Administrator à This should be showing the account you are troubleshooting.

Service Information:

Service Name: krbtgt/CONTOSO

Network Information:

Client Address: ::ffff: 192.168.0.4 à This might not show on this event but if it does this is the IP where the bad password is coming from.

Client Port: 49908

Additional Information:

Ticket Options: 0x40810010

Failure Code : 0x18 à This is the Failure Code we should be looking for: The wrong password was provided.

Pre-Authentication Type: 2

Certificate Information:

Certificate Issuer Name:

Certificate Serial Number:

Certificate Thumbprint:

This was the easy part!

The hard part is often to troubleshoot from the client side as we don’t have any specific procedure to understand what is sending the bad passwords.

An application? A Scheduled Task? A script?

Can be either and/or all of them and for that reason we often need to revisit the client workstation to continue searching for the culprit(s).

Sometimes it is a middle device that connects the user to Exchange, SQL or any other resource and the same steps needs to be taken on each device in the middle that will bring us back to the originating source.

More information:
You can also check the bellow articles for more information on troubleshooting information and tips regarding account lockouts:

Active Directory: Bad Passwords and Account Lockout

https://social.technet.microsoft.com/wiki/contents/articles/32490.active-directory-bad-passwords-and-account-lockout.aspx

Active Directory: Troubleshooting Frequent Account Lockout

https://social.technet.microsoft.com/wiki/contents/articles/23497.active-directory-troubleshooting-frequent-account-lockout.aspx

Troubleshooting account lockout the PSS way

https://blogs.technet.microsoft.com/instan/2009/09/01/troubleshooting-account-lockout-the-pss-way/

how-to-disable-inactive-user-accounts-using-powershell

Inactive Active Directory (AD) user accounts can pose a security risk to organizations, in situations such as when former employees still have active accounts months after leaving the company because HR failed to inform IT, or accounts might be created for a particular purpose but never deleted after the event. Whatever the reason for the existence of such accounts, Active Directory can quickly get out of control, in turn making your systems harder to audit and less secure.

Active Directory Module for PowerShell

The PowerShell module for Active Directory allows system administrators to query Active Directory and generate reports using the resulting data. The AD module for PowerShell is installed by default on Windows Server 2012 domain controllers, or alternatively you can download the Remote Server Administration Tools (RSAT) for Windows 8.1 and install the module using the command below.

Log in as a local administrator, open a PowerShell prompt, type the code below and press ENTER to install the AD module for PowerShell:

Install-WindowsFeature RSAT-AD-PowerShell

Search Active Directory for Inactive Accounts

The Search-ADAccount cmdlet provides an easy way to query Active Directory for inactive user accounts:

Search-ADAccount –UsersOnly –AccountInactive

clip_image002Figure 1

The above command returns all inactive accounts. To narrow down the results to a specific time range, you can add the –TimeSpanparameter to Search-ADAccount. In the example below, a variable defines the value for the –TimeSpan parameter, using the New-Timespan cmdlet to simplify the input:

$timespan = New-Timespan –Days 90

Search-ADAccount –UsersOnly –AccountInactive –TimeSpan $timespan

Alternatively, you can specify the –DateTime parameter to return accounts that have been inactive since a given date. In the command that follows, accounts not active since May 5th 2014 are returned:

Search-ADAccount –UsersOnly –AccountInactive -DateTime ‘5/20/2014’

To get more user-friendly information about the accounts, pipe the results to the Get-ADUser cmdlet and then choose the columns to display in the output using Select:

Search-ADAccount –UsersOnly –AccountInactive | Get-ADuser -Properties Department,Title | Select Name,Department,Title,DistinguishedName

clip_image004Figure 2

The results can also be sorted by a specified field, in this example by the LastLogOnDate attribute, which is derived from the LastLogonTimestamp and converted into a readable format:

Search-ADAccount –UsersOnly –AccountInactive | Get-ADuser -Properties Department,Title | Sort LastLogOnDate | Select Name,Department,Title,DistinguishedName

It’s worth noting that unlike the LastLogOn attribute, LastLogonTimestamp is synchronized between domain controllers, but can be 9 to 14 days out-of-date, so you should bear this in mind when processing your results.

Another way to simplify the output and count the number of inactive users is to pipe the results to the Measure cmdlet:

Search-ADAccount –UsersOnly –AccountInactive –TimeSpan $timespan | Measure

As with any other PowerShell cmdlets, the results can be piped to Out-GridView, or to a comma-delimited file so that the results can be imported into Excel.

Search-ADAccount –UsersOnly –AccountInactive –TimeSpan $timespan | Out-GridView

Disable Inactive Accounts

Once you’ve got the set of results you’re looking for, all you need to do is pipe them to the Disable-ADAccount cmdlet as shown here to disable the accounts:

Search-ADAccount –UsersOnly –AccountInactive –TimeSpan $timespan | Disable-ADAccount