Weekend Scripter: Authentication Silos Part 2

Doctor Scripto

Summary: Microsoft PFE, Ian Farr, continues his series about using Windows PowerShell to work with Authentication Policy Silos.

Microsoft Scripting Guy, Ed Wilson, is here. Welcome back today, guest blogger, Ian Farr. If you missed yesterday's post I suggest that you read it before reading todays post: Authentication Silos: Part 1.

Yesterday, I left you by saying that we would explore a bit in my lab today. From my lab:

Notice that both the msDS-AuthNPolicySiloMembersBL and msDS-AssignedAuthNPolicySilo attributes are populated with the distinguished name of the new Authentication Policy Silo for each User and Computer object returned.  

On each User and Computer object, the AuthenticationPolicySilo attribute is also populated. Let’s look at a couple of accounts from the demo:

Get-ADUser -Identity ianfarr -Properties AuthenticationPolicySilo; Get-ADComputer -Identity HALODC01 -Properties AuthenticationPolicySilo

Sanity check two

We now have:

• All domain admins in the Protected Users group.
• An enforced Authentication Policy that restricts User TGTs to two hours and has an access control condition that only allows users to authenticate from devices within a named Authentication Policy Silo.
• An enforced Authentication Policy Silo that references the aforementioned Authentication Policy.
• All read-write domain controllers permitted to use the Authentication Policy Silo.
• All domain admins permitted to use the Authentication Policy Silo.
• The Authentication Policy Silo associated with the read-write domain controller accounts.
• The Authentication Policy Silo associated with the Domain Admin accounts.

 I’m sane! Time to test.

Testing

The first thing I need to do is reboot the computer accounts within the silo to renew their TGTs. With that done, I can begin my testing!

Here’s what happens when I try to access a server outside of the Authentication Policy Silo with a Domain Admin account.

The failed logon is also captured in a new event log called "Microsoft-Windows-Authentication/AuthenticationPolicyFailures-DomainController". 

Let’s have a look:

(Get-WinEvent -LogName "Microsoft-Windows-Authentication/AuthenticationPolicyFailures-DomainController" | Select-Object -First 1).Message

Notice the Authentication Policy Information section of the event message. It has our silo name, policy name, and applicable TGT lifetime value. I can also see what device refused the logon in the Device Information section.

Now, let’s access a domain controller (HALODC02) with the same account. And, there you go…I’m logged on! Trust me!

For the doubters, let’s have a look at the new "Microsoft-Windows-Authentication/ProtectedUserSuccesses-DomainController" log:

(Get-WinEvent -LogName "Microsoft-Windows-Authentication/ProtectedUserSuccesses-DomainController" -FilterXPath "*[System[EventID=303]]" | Select-Object -First 1).Message

This is a Protected Users group-related event. The FilterXPath parameter of Get-WinEvent cmdlet is used to filter on event ID 303 (“A Kerberos ticket-granting-ticket (TGT) was issued for a member of the Protected User group.”) Notice the Authentication Policy information.

Let’s check out the logged-on user’s TGT lifetime:

klist tgt | Select-String –SimpleMatch time

We can see that the TGT has the expected two hour duration, as per the Authentication Policy.

Finally (because this is all claims driven), let’s look at the user’s claims:

whoami /claims

Notice how the Claim ID and its value match the condition that we configured in the User section of the Authentication Policy.

That’s all folks. In my test lab, my Domain Admin accounts can only log on to my read-write domain controllers.

With all of this funky credential protection stuff introduced in Active Directory in Windows Server 2012 R2, I suspect those elderly, bearded gentlemen are already busy writing a new chapter for the book of Active Directory wisdom…or, perhaps not!

~Ian

Thanks, Ian, for once again sharing your time and knowledge.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy 

Doctor Scripto Scripter, PowerShell, vbScript, BAT, CMD

Follow