Protected Users Group
Requirements
✔️ Windows Domain Functionality Level (DFL) 2012 R2 and Above
✔️ Windows 8.1 and Above
Protections Offered by Protected Users Group
Passwords will not be cached. This prevents attackers from copying password hashes for offline cracking.
Passwords are not stored in memory. This prevents attackers from dumping LSASS processes and capturing NTLM hashes for authentication (MimiKatz is commonly used for this purpose)
NTLM Authentication is disabled for the account. This will prevent attackers from performing pass-the-hash attacks as well as additional attacks related to dumping password hashes as mentioned above.
Kerberos authentication is forced to use modern encryption protocols. DES and RC4 authentication types are disabled as they have been deprecated and are considered weak.
Accounts cannot be delegated. This limits an attacker’s ability to move laterally in the network with stolen privileged credentials as well as further limiting the possibility of pass-the-hash attacks.
Kerberos Tickets will expire after 4 hours instead of 10 hours. TGT tickets can no longer be renewed without re-authentication, further preventing attackers from attempting to exploit idle administrator sessions on servers/endpoints.
Considerations/Limitations
❌ Do not add Service Accounts
The protected users group is meant for privileged users. Do not add any service accounts to the protected users group, or they will not be able to function as a service account. You should also not add any normal unprivileged users to the protected users group.
❌ Cannot RDP by IP Address
Remote Desktop Connections must be made with the FQDN of the endpoint. Kerberos authentication is the only supported encryption type and therefore IP addresses cannot be used. In addition, you must always specify the FQDN of the user account when connecting.
If you attempt to connect via IP address, you will be rejected with the following message.
⚠️ RDP Connecting endpoint must have connectivity to the Domain Controller
The originating computer must have network connectivity to the Domain Controller to be able to perform Kerberos Authentication. If either your computer or the server currently have no network connectivity to the DC, your authentication will be rejected.
❌ Offline authentication not possible
As no credentials are ever cached locally or stored in memory, it becomes impossible to authenticate while the server is offline. If for whatever reason the server is offline or loses connectivity to the Domain Controller, you will be unable to log in with any account that is a member of the Protected Users Group. The only option will be to log in with the local server administrator account.
⚠️ Software install restrictions
As account delegation is not permitted, some software installs will fail while using a member of the Protected Users Group. One common example includes installing Microsoft SQL Server. During install, SQL Server will attempt to create an SPN in Active Directory using the logged in account, which is a form of delegation and will fail. Be aware of this limitation and use alternative accounts during installs if necessary.
⚠️ NTLM Authentication is disabled
Kerberos is the only supported authentication method as a member of the Protected Users Group. This will prevent any member accounts from authenticating to endpoints that do not support Kerberos authentication, such as legacy Windows systems (7 and Below) or legacy network/Linux devices that only support NTLM.