Learn about Windows PowerShell
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
We now have:
I’m sane! Time to test.
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:
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!
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 firstname.lastname@example.org, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy