Hello, Paul Bergson back again with today’s topic of preventing your Domain Administrators and other privileged identities from logging into Tier 1 and Tier 2 devices.

Credential theft protection is always an important step in protecting the enterprise. While your administrators are your most trusted employees within the IT enterprise, they may not always use good judgment when doing day to day tasks. ALL privileged users should have at least two accounts, one for daily tasks which need internet and e-mail access and one or more privileged accounts that are used to performed tasks which require elevated permissions and should have no access to internet or e-mail. In the case of Tier 0 accounts, they should only be authenticating to Tier 0 assets. Beyond the expectation that these elevated user accounts should not be used to log on to lower Tier assets, protection measures should be put in place to guard against administrators who want to take short cuts to get the job done quickly.

What are Tier’d devices you ask? Well that is a very good question. Enterprises should define “Credential” layers where controls are put in place to control authentication to devices.

• Tier 0
  • These identities have access to most if not all objects within the directory. All elevated users within this Tier should only be used to authenticate to Tier 0 devices. Access to lower Tier devices should be blocked..
• Tier 1
  • Devices within this Tier contain the Data and Intellectual property that needs to be protected. A separate account should be created for each user that needs to manage devices on this Tier. No down level or up level access should be granted identities within this Tier.
• Tier 2
  • Unprivileged access to the user’s workstation as well as PoLP read/write Tier 1 data.

The reason to create credential Tier’ing is so that privileged accounts are never exposed to untrusted devices. Any device would be considered untrusted if it has ever been exposed to Internet browsing or e-mail access. These activities could compromise the user’s device without their knowledge and credential harvesting could occur once a privileged user authenticates to this device.

Denying Access to Devices

So now that you have some background on the credential Tier model and understand why it is important to prevent privileged users from authenticating on untrusted devices, let’s look at some of the ways enterprises can control Tier 0 accounts from logging onto lower Tier devices.

• Define a policy and trust your Domain Administrator’s to follow the rules.
  • This never works. Prior to working for Microsoft and while working with customers I see this model fail. Admins always try to justify the practice of not protecting the credentials with not enough time to do the proper protection.
• Manually remove the Domain Administrator from the Local Administrators Group
  • Not only is this an unsupported configuration it doesn’t prevent the Domain Administrator from logging onto the machine. It does remove their local admin rights but it will leave their credential hashes on the device, unless you are using Credential/Remote Credential Guard.
• Define a set of Group Policies to prevent the Domain Administrator from authenticating to lower Tier devices, this includes network authentication.
  • There are 5 different Group Policies that need to be defined that will prevent Domain Administrators from authenticating on devices. These policies should be linked to both the Tier 1 and Tier 2 devices.

Just because you remove the DA from the Local Admins group, you are still NOT preventing that identity from authenticating onto the device. Looking at figure A, the domain admin has authenticated onto the device.

1. Doing a whoami, you can see the identity logged onto the Win10 device is the Domain admin for the domain
2. Opening up the Local Administrators group
3. The domain administrator is not a member of the local administrators group, yet was able to sign in

The administrator was not prevented from logging onto the machine and since the domain administrator is logged onto the machine the DA credential hash will still be cached on the device unless Credential/Remote Credential Guard is in place.  But, as can be seen in Figure B the privileges are now reduced to a standard user.

Figure A

Figure B

“Domain Admins are, by default, members of the local Administrators groups on all member servers and workstations in their respective domains. This default nesting should not be modified for supportability and disaster recovery purposes. If Domain Admins have been removed from the local Administrators groups on the member servers, the group should be added to the Administrators group on each member server and workstation in the domain.” *1

If the Deny’s as defined below for domain administrator’s were put into place, it will prevent the identity from logging on.

Deny Domain and Enterprise Administrators from authenticating to Tier 1 and Tier 2 assets via GPO:

• Deny logon via RDP
  • https://technet.microsoft.com/en-us/library/dn221959(v=ws.11).aspx
• Deny logon as a batch job
  • https://technet.microsoft.com/en-us/library/cc976547.aspx
• Deny logon as a service
  • https://technet.microsoft.com/en-us/library/cc957038.aspx
• Deny access to the computer from the network
  • https://technet.microsoft.com/en-us/library/dn221954(v=ws.11).aspx
• Deny logon locally
  • https://technet.microsoft.com/en-us/library/cc957048.aspx

When the deny measures above are put into place, this will also prevent the administrator from opening a cmd prompt via “RunAs” and thereby caching the elevated credentials on the local workstation. *2

If you have Tier 1 and Tier 2 privileged users who don’t have a separate device (Privileged Access workstation *3) when they are using their elevated credentials and they are connecting to remote devices, it would be advised to protect their credentials via Remote Credential Guard or Restricted Admin mode.

“Introduced in Windows 10, version 1607, Windows Defender Remote Credential Guard helps you protect your credentials over a Remote Desktop connection by redirecting Kerberos requests back to the device that’s requesting the connection. It also provides single sign-on experiences for Remote Desktop sessions.

Administrator credentials are highly privileged and must be protected. By using Windows Defender Remote Credential Guard to connect during Remote Desktop sessions, if the target device is compromised, your credentials are not exposed because both credential and credential derivatives are never passed over the network to the target device.” *4

If your users are not using Windows 10 or there is the threat of gaining access to an open channel and create a session on the remote user’s connection, we instead recommend utilizing /restrictedAdmin mode.

“For helpdesk support scenarios, RDP connections should only be initiated using the /RestrictedAdmin switch. This helps ensure that credentials and other user resources are not exposed to compromised remote hosts.” *4

The rdp option for RestrictedAdminMode was introduced in Windows 8.1/2012 R2 and was back ported via KB2871997 to Windows 7/Server 2008 R2. *5

Authentication Policies and Silos

Starting with Windows Server 2012 R2 a new feature was added to be able control accounts from logging onto specific devices utilizing Authentication Policies and Authentication Policy Silos.

“Authentication policies and authentication policy silos are two of these new features and they help administrators define which user accounts can be restricted to log on to specific systems with those accounts. Administrators can configure these new Windows Server 2012 R2 features in the Active Directory Administrative Center or in PowerShell.” *6

Authentication Policy Silo’s define the accounts that are to be restricted from authenticating on devices. There is one account that cannot be Silo’d and that is the domain “Administrator” (DA). The DA can be added to the Silo, but it will not be blocked from logging onto any device. Similar to how removing the DA identity from the local “Administrators” group didn’t prevent the DA from logging onto the device.

Authentication Policies define access control to determine the Silo to use as well as Kerberos properties, including the Kerberos ticket lifetime. The ticket has a minimum lifetime of 15 minutes and a maximum lifetime of 4 hours once the ticket expires credentials are required to be re-entered, the ticket is not renewable.

Part of the prerequisites to using “Silos” is that the DC’s are running at least Windows Server 2012 R2, for a complete set of prerequisites and how to install, follow the guidance linked below.
*6

How Silos work is that you need to need to enable claims on both the DC and the devices to control via Group Policy. Then you will define an Authentication Policy which will include ticket lifetime and the Silo related to the Policy. Obviously, this is a two-step process, since the Silo hasn’t been created yet. You will then want to create a Silo and define the Privileged Accounts and the devices that they will be allowed to authenticate too. Each Silo can link to an unique “Authentication Policy” for Users, Managed Service Accounts (MSA) and Computers.

If you notice in the picture below all the “Permitted” users have been added to the “Protected Users Group” (PUG). This isn’t a requirement of Silo’s but rather a recommendation. The PUG adds an additional layer of security to the users that belong to this group. Restrictions include while belonging to this group NTLM, CredSSP and WDigest protocols are blocked from being utilized. User accounts are not allowed to be “Delegated” and finally the Kerberos protocol will not use the weaker DES or RC4 encryption types in the pre-authentication process. There is a great Blog by Jerry Devore on PUG that can be found on this site. *7

Well there you have it. A couple of easy ways to protect your most prized credentials in the enterprise. You can then use these steps to start to prevent Tier 1 admins from authenticating to Tier 2 devices in a similar manner than was just presented. Hopefully you found this useful and can find the opportunity to deploy this simple credential theft protection. It is an easy win with a big payback, in that your privileged credentials are no longer exposed on untrusted devices.

References:

• Securing Domain Admins Groups in Active Directory
  https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-f–securing-domain-admins-groups-in-active-directory
  
• RunAs and Credential Exposure
  https://blogs.technet.microsoft.com/jepayne/2016/04/04/when-the-manual-is-not-enough-runas-netonly-unexpected-credential-exposure-and-the-need-for-reality-based-holistic-threat-models/
  
• Privileged Access Workstation
  https://blogs.technet.microsoft.com/askpfeplat/2016/03/14/secure-administrative-workstations/
  
• Remote Desktop Connections and Helpdesk Support Scenarios
  https://docs.microsoft.com/en-us/windows/access-protection/remote-credential-guard
  
• The Importance of KB2871997 for Credential theft
  https://blogs.technet.microsoft.com/askpfeplat/2016/04/18/the-importance-of-kb2871997-and-kb2928120-for-credential-protection/
  
• Restricting Access – Authentication Policies and Authentication Policy Silos
  https://social.technet.microsoft.com/wiki/contents/articles/26945.authentication-policies-and-authentication-silos-restricting-domain-controller-access.aspx
• Protected Users Group
  https://blogs.technet.microsoft.com/askpfeplat/2016/04/04/reading-the-fine-print-on-the-protected-users-group/