Windows Server: Protected Privileged Accounts

 

In this Ask the Admin, I’ll outline some of the security features in Windows Server that can be used to help keep sensitive accounts safe.

Windows Server contains several technologies to help keep privileged accounts secure, including the Protected Users group and Authentication Silos. Before you look at implementing any of the solutions below, be sure to check out Why You Should Use Microsoft’s Active Directory Tier Administrative Model, Managing Privileged Access to Active Directory, and Windows Server 2016: Understanding Microsoft’s Enhanced Security Administrative Environment on the Petri IT Knowledgebase.

It’s worth remembering that the technologies I’ll describe in this article don’t replace security best practices. For example, in Why You Should Use Microsoft’s Active Directory Tier Administrative Model, I explain why domain administrator accounts should never be used to log into end-user devices. The Protected Users group can help mitigate some of the risks with using privileged AD accounts on Tier 2 devices but it doesn’t remove the risks entirely.

Active Directory Protected Users

The Protected Users group first appeared in Windows Server 2012 R2 and can be used to restrict what members of Active Directory privileged groups can do in the domain. Protected Users is a global security group and its primary function is to prevent users’ credentials being abused on the devices where they log in.

Protected Users group features are supported on devices running Windows 8.1 and Windows Server 2012 (or higher). Here is the full list of restrictions:

• Cached credentials. I.e. users cannot log in offline when there is no access to a domain controller.
• The Kerberos ticket-granting ticket (TGT) must be received when users log in and cannot be reissued automatically, preventing the use of long-term keys.
• Default credential delegation (CredSSP), stopping credentials being cached in plaintext even if the Allow delegating default credentials policy is set.
• Windows Digest authentication.
• NT LanManager (NTLM) NTOWF – a function for generating keys based on user passwords.

If the domain functional level is Windows Server 2012 R2 (or higher), Protected Users can’t:

• Renew Kerberos ticket-granting tickets longer than the original 4-hour TTL
• Log in using NTLM
• Use DES or RC4 for Kerberos pre-authentication
• Be delegated using constrained or unconstrained delegation

For more information on using the Protected Users group, see Protect Privileged Credentials in Windows Server 2012 R2 using the Protected Users Group on Petri.

Authentication Policies and Silos

Authentication policies were introduced in Windows Server 2012 R2 and add to the restrictions provided by membership of the Protected Users group. Where the Protected Users group provides a set of restrictions that can’t be changed, authentication policies allow administrators to configure the restrictions applied to user accounts, services, and computers. For example, you could restrict a service account to signing into a specific server.

Authentication policy silos allow you to establish a relationship between user, computer, and managed service accounts. Accounts can only belong to one silo. Authentication policies can be applied to all members of an authentication policy silo or individual policies can be applied to different types of account in a silo.

Authentication policies and silos rely on Kerberos, claims, compound authentication, and Kerberos armoring. NTLM logons are not supported and users must be a member of the Protected Users group. For more information about how to work with authentication policies and silos, see How to Create a Windows Server 2012 R2 Authentication Policy on Petri.

Credential Guard

Virtualization-based security (VBS) features in Windows 10 and Windows Server 2016 provide the technology that drives Credential Guard. When Credential Guard is enabled, an isolated version of the Local Security Authority (LSA) process is moved to a virtual machine. Windows accesses the protected LSA using remote procedure calls (RPC).

Credential Guard can guard domain accounts against pass-the-hash or token attacks even when the logged in user has administrative or debug privileges. Because domain credentials can potentially be used to log in to more than one device or used to obtain other credentials, Microsoft recommends enabling Credential Guard on devices that support it.

For more information on Credential Guard, see Windows 10 Enterprise Feature: Credential Guard on Petri.

Multifactor Authentication

Multifactor authentication (MFA) should be used to protect privileged AD accounts. MFA is a two-step verification process that can prevent programmatic attacks against privileged accounts. In addition to a strong password, Microsoft MFA supports the following factors:

• phone calls
• text messages
• mobile-app notifications
• mobile-app verification codes
• third-party OATH tokens

MFA has been traditionally expensive and difficult to set up and maintain in an on-premises AD. But one of the benefits of extending AD to the cloud is an easier way to implement MFA for improved security. For more information on Azure MFA, see Microsoft’s website here.

Read-Only Domain Controllers (RODCs)

Not all domain controllers (DCs) need to be writable. This is especially true if they are in locations that can’t be physically secured, such as branch offices. Read-Only Domain Controllers have read-only copies of the AD database partitions, SYSVOL folder, and DNS database, so provide damage limitation if the server is compromised. RODCs need to contact a writeable DC for user authentication as account credentials are not stored locally on RODCs unless you choose to enable the feature for faster logins.

Not all applications are compatible with RODCs, so check that your applications are compatible. For more information on working with RODCs, see Deploy a Read-Only Domain Controller on Petri.

Local Administrator Password Solution (LAPS)

Local administrator accounts are often configured with the same password across all user devices, meaning that an attacker could compromise every device with just one password. To help IT randomize and regularly reset passwords, Microsoft released the Location Administrator Password Solution (LAPS) tool.

LAPS uses a Group Policy client-side extension to set the administrator password and securely store it in Active Directory. The tool requires an update to your AD schema, adding two attributes: ms-MCS-AdmPwd and ms-MCS-AdmPwdExpirationTime. The first stores the local administrator account password and the second the time when it should be reset.

See Secure Local Administrator Accounts with the Local Administrator Password Solution (LAPS) Tool on Petri for more details on how to use LAPS.

The list of features for protecting privileged accounts in this article isn’t exhaustive but the tools I’ve described can help you to enforce many of the best practices that I’ve discussed in previous articles. If you’re not sure where to start, use the best practices as a guide to implementing security in your organization.

The post Windows Server: Protected Privileged Accounts appeared first on Petri.