Problem after applying the Deny Log on locally GPO setting

Question

Hello!
While testing tiered AD infrastructer I was greatly suprised to see how one of the key gpo parameters is working.
Suppose there's a domain controller - DC - which belongs to Tier0 OU (with no gpo applied except the Default Domain Policy) and a number of servers in the SERVERS OU (Tier1) to which the gpo with the following setting is applied:

The most important idea in the tiered AD model is preventing the cross-tier logons - in other words, you should not be able to log on to Tier1 servers under Tier0 accounts - in my case it means I shouldn't be able to use any domain/enterprise admin accounts (which are Tier0 accounts) for logging onto Tier1 servers (in the SERVERS OU), and the aforementioned Deny log on locally policy setting is the setting that is supposed to do exactly that.

And it really does what I expect it to do - any domain/enterprise-wide administrative accounts can no longer log on to Tier1 servers - so far so good, but... either I'm missing something or enabling this option may lead to other - rather weird - consequences.

Once again: here's the MS's explanation of the Deny log on locally parameter:

As far as I understand this text it means that the ONLY goal of this parameter is to deny log on locally TO THIS COMPUTER for the defined accounts.

Why in this case I'm loosing the ability to connect to DC right after the policy gets applied?

For example, when I try to access \dc as Domain\AdminT1 I see this:

ANY domain user can access ANY domain computer by default so what is preventing Domain\AdminT1 from accessing \DC AFTER applying the policy ???

There're other gpo settings being applied but they do not have any effect on the possibility to connect to \dc - as soon as I delete the domain admins/enterprise admins accounts from the policy \dc gets accessible again:

???

Answer 1

...have run two more tests (with removing and re-adding domain admins to Deny Log on Locally policy setting) - now it works flawlessly... weird...

Answer 2

I suggest you look at the Authentication Policies and Authentication Policy Silos. Those features came with WIni Server 2012 R2 and they make the isolation of admintrative zone easier (because no GPO are involved) more robust (because local admins can't override them).

You could create a Silo called Tier-0 on which you add your domain admin account, the machine account of their dedicate workstations as well as the computer account of your domain controllers. Then you apply an authentication policy is such a way that the domain admins account can only log-in on machine of the sale silo as theirs.

Here is an example. I have Pierre member of the domain admins group. Pierre's workstation is wks1 and he needs to be able to administrate DC1 (a domain controller). You enable claim support in your environment and run the following:

#Create a new policy  
New-ADAuthenticationPolicy -Name "Tier-0_TGT_120mins" -Description "Authentication policy for Tier-0 (120 minutes TGT)." -UserTGTLifetimeMins 120 -Enforce -ProtectedFromAccidentalDeletion $True  
  
#Create a new silo  
New-ADAuthenticationPolicySilo -Name "Tier-0" -Description "Authentication policy silo to control the scope of logon for administrators" -UserAuthenticationPolicy "Tier-0_TGT_120mins" -ComputerAuthenticationPolicy "Tier-0_TGT_120mins" -ServiceAuthenticationPolicy "Tier-0_TGT_120mins" -Enforce -ProtectedFromAccidentalDeletion $True  
  
#Modify the policy to allow TGT issuance only if the silo is a match  
Set-ADAuthenticationPolicy -Identity "Tier-0_TGT_120mins" -UserAllowedToAuthenticateFrom "O:SYG:SYD:(XA;OICI;CR;;;WD; (@USER.ad://ext/AuthenticationSilo == 'Tier-0'))"  
  
#Grant access to the silo to the admins and their systems  
Grant-ADAuthenticationPolicySiloAccess -Identity "Tier-0" -Account "CN=Pierre,OU=_Admins,DC=contoso,DC=com"  
Grant-ADAuthenticationPolicySiloAccess -Identity "Tier-0" -Account "CN=WKS1,OU=_Admins,DC=contoso,DC=com"  
Grant-ADAuthenticationPolicySiloAccess -Identity "Tier-0" -Account "CN=DC1,OU=Domain Controllers,DC=contoso,DC=com"  
  
#Assign the silo to the admins and their systems  
Get-ADUser -Identity Pierre | Set-ADAccountAuthenticationPolicySilo –AuthenticationPolicySilo "Tier-0"  
Get-ADComputer -Identity WKS1$ | Set-ADAccountAuthenticationPolicySilo –AuthenticationPolicySilo "Tier-0"  
Get-ADComputer -Identity DC1$ | Set-ADAccountAuthenticationPolicySilo –AuthenticationPolicySilo "Tier-0"  

Then Pierre can only log on WKS1 and DC1. If Piere tries to log in on a system which is not a member of the silo, he gets the following error message:

Let me know if you want to know more about this. If so, I would suggest you create a new thread.