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.

Figure 1: The entryTTL attribute can be edited, but the real value is stored elsewhere.

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.