Time Is Running Out

Just-in-time (JIT) administration forms the basis for minimizing the administrator account attack vector in Microsoft's security strategy, combined with a precise definition of assigned authorizations (i.e., Just Enough Admin, JEA). Microsoft architects like Jeffrey Snover have been promoting this strategy since 2014. In Server 2016, it was put on an elegant technical base in Active Directory (AD) for use in an environment without too much overhead.

Like most rights allocation strategies in AD environments, JIT is based on groups: The account to be authorized is assigned to a group that either has direct access rights or is itself a member of groups that possess the desired access rights. The AGDLP (Account, Global, Domain Local, Permissions) principle [1] is a known variant of this authorization assignment and is therefore a question of interrupting the membership chain between users and permissions at a predetermined point in time.

JIT via PowerShell

The easiest way to terminate group memberships at a specified time is to remove the user account from the group with the usual AD administration tools. The corresponding process can be triggered in a time-controlled manner with the Task Scheduler or in an event-controlled manner in an orchestration or identity management system. The calling account must have the appropriate rights in AD. With PowerShell, all you need is the AD module, which is part of the Remote Server Management Tools (RSAT) for AD Domain Services. To add a user to a group, type:

> Add-ADGroupMember -Identity "Group" -Members "User"

To remove them again, type:

> Remove-ADGroupMember -Identity "Group" -Members "User" -Confirm:$false

An edit-protected SQL database or text file can serve as the data basis for the memberships, or you can initiate appropriate commands with your identity management or orchestration tool. When you call the two PowerShell cmdlets, note that:

• The two cmdlets do not generate errors or warnings if the operation fails (e.g., if you try to add an account that is already a member of the group or remove an account that is not a member of the group).
• The existence of the group and the user account is checked against the directory. If one of these is not available, a terminating condition occurs that you then need to field.
• Neither cmdlet produces any output. If assured results are required, you have to use the Get-ADGroupMember cmdlet to see whether the action was successful. However, you also need to consider replication – either run all the commands against the same domain controller with the -Server parameter or insert a short pause between the action and the query.

Dynamic Groups

A kind of JIT with on-board tools that doesn't have to call a time-controlled function became available in Server 2003. The Server 2003 schema and function level introduced dynamic objects that can be users or groups, as well as, theoretically, other object types. The functional principle is described in Microsoft Docs [2]. Dynamic objects have a lifetime (entryTTL) measured in seconds. After this time period has expired, the object is deleted from each domain controller without leaving behind a tombstone object.

By the way, entryTTL is a calculated attribute. If you retrieve it repeatedly, you will see that the displayed value continuously decreases. The actual attribute that determines the lifetime of the dynamic object is msDS-Entry-Time-To-Die (Figure 1). Its value is calculated when the object is created, remains valid until it is deleted, and is replicated to all domain controllers. The connection between entryTTL and msDS-Entry-Time-To-Die might seem confusing, in that you can change the value of entryTTL, whereas msDS-Entry-Time-To-Die cannot be edited.

To create an AGDLP construct with an expiration date, you can use dynamic objects in the following way:

• Create a dynamic group with the desired expiration date (see below).
• Add a user (or users) to this group as members.
• Add the newly created dynamic group to the required authorization groups as a member.

At the end of its lifetime, the dynamic group disappears without further action and the chain of memberships is interrupted.

Depending on how extensively you want to use dynamic groups as a link between users and permissions, you need to pay attention to the number of groups in which an account is a direct or indirect member, as with any role-based access control (RBAC). If the number is too high, the user token inflates, which many applications cannot handle. Processes such as monitoring and security audit might also need to be adjusted when temporary dynamic objects come into play, especially because they leave no traces when their time elapses – not even if the Recycle Bin is enabled.

To create a dynamic global group, you can write the required attributes directly to AD. However, this must be done immediately when the group is created; subsequent conversion of static objects into dynamic objects is not possible. Create a text file with at least the following information for the new dynamic group TempGroup:

dn: cn=TempGroup,ou=PAMLAB,dc=pamlab,dc=metabpa,dc=org
objectClass: group
objectClass: dynamicObject
entryTTL: 86400
SAMAccountName: TempGroup

The value of entryTTL corresponds exactly to 24 hours. Load the text file you just created into your Active Directory using LDIFDE:

> ldifde.exe -i -f <textfile>

You will notice that the new group behaves in every way like a normal global security group.

By the way, you cannot create dynamic groups with the PowerShell cmdlets from the AD module. If you want to use PowerShell to provision dynamic groups, you have to use Active Directory Service Interfaces (ADSI). Creation of the group from the LDIFDE example above is shown in Listing 1.

$group = "TempGroup"
$ttl = 86400
$ou = "OU=PAMLAB,DC=pamlab,DC=metabpa,DC=org"
$container = [ADSI]("LDAP://PAMDC/$ou")
$dg = $container.Create("group","CN=$group")
$dg.PutEx(2,"objectClass",@("dynamicObject","group"))
$dg.Put("sAMAccountName",$group)
$dg.Put("entryTTL",$ttl)
$dg.SetInfo()

If you omit the value of entryTTL, the default value preset in Active Directory is used for the new object. By default, this is 86400 (i.e., exactly 24 hours), although you can change this value by connecting to the configuration partition of your domain with ADSI Edit and opening the properties of the CN=Directory Service, CN=Windows NT, CN= Services node. The msDS-Other-Settings attribute contains a collection of configuration settings in the format Name=Value.

In addition to DynamicObjectDefaultTTL, DynamicObjectMinTTL has a default value of 900 seconds (i.e., 15 minutes). A corresponding maximum value unfortunately cannot be provided, so your dynamic objects can live for up to one year (the upper limit for the entryTTL attribute defined in the AD schema is 31557600).

Problem: Kerberos Ticket Lives On

Both methods described above for terminating group membership at a specified time have the same problem with the way Windows authentication works. After a user account has had its access rights revoked by terminating group memberships, they may still be able to exercise these rights for a while – as long as the Kerberos ticket for the authenticated session is valid. The default setting for the validity period of a user ticket is 10 hours, but this can be increased up to 99,999 hours using Group Policy [3]. That's almost 11.5 years.

This scenario can lead to subsequent abuse of access rights by an attacker, even if you disable the associated user account or delete it from the directory immediately after the rights have been withdrawn. For users whose work order causes them to log on interactively to many machines, it is very difficult to tell where a separate RDP session might still exist.

Strict enforcement of remote administration, as opposed to interactive logons, on the affected machines helps solve the problem of multiple logons. The JEA principle is also based on the fact that PowerShell Remoting connections to many systems are established from an interactive session using the correct endpoints. Sometimes, however, secure working methods like these are not possible because of the application, and the employee leaves behind many valid tickets when they leave their primary workstation after the working day.

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>

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.

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).

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.