Memberships with an Expiration Date

In Server 2016, Microsoft puts JIT on a new technological footing. "Time To Live" (TTL) now no longer belongs to an object in Active Directory, like a user or group, as is the case with dynamic objects. Instead, the linked attributes, such as group memberships (memberOf), have an expiry stamp. In this way, your role-based group construct can be used for permanent memberships of your root administrators and temporary memberships of project staff and external consultants alike.

At the same time, the "10-hour problem" has been solved in a way that does not impose any restrictions with regard to the operating systems in use and their versions. Temporary memberships are taken into account when a user ticket is issued by domain controllers. The ticket issued is only valid as long as the shortest temporary membership. After that, the ticket expires and must be renewed, but the group membership that has just expired is no longer included in the new ticket. The rights granted in this way have effectively been withdrawn.

The feature, known as the Privileged Access Management Feature, was introduced under the scenario of the same name in Microsoft Identity Manager (MIM) 2016. Although managing JIT using MIM is undoubtedly very convenient, you can also use the feature with on-board resources. Administration is only possible with PowerShell; the usual graphical tools such as Active Directory Users and Computers or LDAP-based tools do not display the TTLs of group memberships.

To use the new feature, your AD forest must be at the Server 2016 functional level. Therefore, all domain controllers on Server 2016 must have been updated and the domain functional level raised. First, you need to enable the feature throughout the forest. To do this, you can use the Enable-ADOptionalFeature cmdlet (Figure 2), which you might remember from the time when admins had to enable the AD Recycle Bin explicitly:

> Enable-ADOptionalFeature "Privileged Access Management Feature" -Scope ForestOrConfigurationSet -Target <Forest-Root-domain>

Figure 2: The Privileged Access Management Feature must be enabled and replicated in the forest first.

Once the command is issued and the change has been replicated across the entire forest, you can use the Add-ADGroupMember cmdlet with the -MemberTimeToLive parameter. The argument expects a TimeSpan as a value, which allows you to determine the expiration of the membership either by duration or desired end time:

> Add-ADGroupMember -Identity <Group> -Members User -MemberTimeToLive (New-TimeSpan -Seconds 3600)

On the other hand, you could use the command:

> Add-ADGroupMember -Identity <Group> -Members User -MemberTimeToLive (New-TimeSpan -End "31.12.2017 23:59:59")

However, in both cases the absolute duration of TimeSpan is applied, so you cannot determine in advance that the membership should start at a later time. At first glance, the new membership looks quite normal: Neither Active Directory Users and Computers, the AD Management Center, the LDAP browser, or the output of Get-ADGroupMember show any anomalies.

Only Get-ADGroup with the additional parameter -ShowMemberTimeToLive can determine its transient nature from group memberships. To do this, you need to include the Member attribute in the output and expand it:

> Get-ADGroup <Group> -ShowMemberTimeToLive -Property Member | select Member -ExpandProperty Member

The displayed TTL value (Figure 3) decreases with each new call. As soon as it drops to zero, the group membership expires – including the Kerberos ticket for each session where this user is logged in.

Figure 3: At first glance, the membership looks quite normal, but it only lasts for three minutes.

A temporary group membership can be extended or shortened by running the Add-ADGroupMember cmdlet with the new TTL value. If your group construct results in temporary memberships being nested, the lifetime of the Kerberos ticket will correctly depend on the shortest membership (Figure 4).

Figure 4: The lifetime of a ticket depends on group nesting, because this expires first.

Conclusions

At the Server 2016 functional level, JIT is finally, genuinely maturing. The expiration time defined in the authorization assignment is binding and takes effect simultaneously everywhere. Of course, optimum protection is only possible if you ensure, when assigning temporary authorizations, that the authorized person cannot permanently secure their rights (e.g., through direct membership in the authorization groups), and you will not want to forget to audit the current authorizations with JIT at all times.