This is a follow up on earlier post about JIT and will cover the Time-based groups part.

Expiring links is a new feature in Windows Server 2016 and makes it possible to set Time-To-Live (TTL) values on all linked attributes. In the case of Time-based groups it’s possible to set a TTL value on the member forward link.

It’s up to the domain controller to manage this links and remove them when the TTL limit is reached. This also works well with replication because the TTL value end time is replicated and the link will be deleted locally on all domain controllers.

In conjunction to this there has also been some Kerberos enhancements to really be able to take advantage of Time-based groups.
When the KDC creates tickets it restrict Kerberos ticket lifetime to the lowest possible time-to-live (TTL) value. If a user has 15 minutes left until the TTL on a group membership expires, the KDC will only create TGT/TGSTs that is good for another 15 minutes. When the tickets has expired and new ones is requested, the SID of the expired group memberships will not be in the PAC anymore.

With this feature you could temporary give a user admin access to systems based on a small time limit. The DCs will maintain and remove memberships and it will not be adversely affected by replication convergence or Kerberos ticket lifetime (which is default 10 hours and renewable in 7 days).

To be able to take advantage of Expiring links and Time-based groups we need to enable a new Optional Feature in Active Directory.
With PowerShell run the cmdlet “Get-ADOptionalFeature” and we have the new feature: Privileged Access Management Feature

To enable this feature the Forest Functional Level needs to be at the WindowsThresholdForest level and it can’t be disabled after you enable it. And you can’t lower the FFL/DFL.

With PowerShell: Enable-ADOptionalFeature “Privileged Access Management Feature” –Scope ForestOrConfigurationSet -Target corp.secid.se

Now we can set a TTL value on group memberships. The time value is default in days, in this example I will set it at only 10 minutes.

$ttl = New-TimeSpan -Minutes 10
Add-ADGroupMember -Identity “Sec-Admins-Group” -Members “Tony” -MemberTimeToLive $ttl

Now the user Tony is set to be a member of that group only for 10 minutes. The TTL value won’t be visible in ADUC nor ADSI Edit.

This can be done with PowerShell dough, and if you run this command multiple times you will see the TTL value countdown. When it hits zero the membership will be removed by the DC.

Get-ADGroup -Identity “Sec-Admins-Group” -Properties * -ShowMemberTimeToLive |fl member

This can also be viewed in the good old LDP.exe tool. Load the LDAP Extended Controls LDAP_SERVER_LINK_TTL_OID 1.2.840.113556.1.4.2309 and the search results from the DC will be presented with the TTL-DN value.

  

If we take a look at the Kerberos part we can use klist to list current tickets for the user Tony and it looks pretty normal with a lifetime of 10 hours, renewal period is 7 days.

Whoami /groups command lists the group memberships and at the moment, Tony is not a member of the Sec-Admins-Group group.

If we add the user to the group Sec-Admins-Group and the user purge the tickets and logon again we will see a much shorter lifetime of all tickets.

Conclusion:

Time-based groups is a really cool thing and I like the fact it’s the domain controllers responsible for maintaining the expired links. This is a part of the “Privileged Access Management Feature” and will work great with JIT and the shadow forest concept.

I don’t know if it’s also intended to be used in the regular corp forest, and for that I have a few questions and thoughts.

When used in the corp production forest, I think we need to be quite restricted. It will set a lot of pressure on the Key Distribution Center service for ticket requests if we utilize many Time-based groups.
Replication traffic would also increase because adding users to the groups will be more frequent. Since the links is removed locally by every DC when they’re expired, the replication won’t increase in that point of view.
How is it supposed to work when a user is added for 30 minutes and it hasn’t replicated to the corresponding site the user is located at?
It doesn’t work seamlessly for the users either, I can’t imagine them having to purge tickets, logoff/logon and so on.

Well, this is not a final product yet and there’s not much public info about this. I’m looking forward to the RTM and hopefully this will be as great as I hope for. It would be pretty cool to build my own PAM light app.

PS. If you want hands-on experience, don’t miss my next AD lab at Labcenter_SE