Active Directory 2016 Time-Based Group Membership

Group membership control and management is one of the cornerstones of Active Directory Domain Services. In Windows Server 2016, Microsoft introduced a new feature to Active Directory that forms part of the Microsoft Privileged Access Management (PAM) strategy.

When used in conjunction with automation, this can be used to provide Just-In-Time (JIT) access to protected and administratively sensitive services. When used in an environment that is synchronised with Azure Active Directory using Azure AD Connect, this can be used to provide JIT for hybrid solutions in Microsoft Azure (when RBAC has been applied to Azure Resource Manager objects).

In this post, I will briefly explain the processing for implementing time-based group membership in Active Directory.

The Preparation

As the PAM features are new to Active Directory in Windows Server 2016, there are some requirements that need to be met before we can use it:

Domain Controllers must be running Windows Server 2016

Forest Functional Level must be raised to Windows Server 2016 mode

Optional Feature for Privileged Access Management must be enabled

I am not going to labour over the finer points of how to do a Forest or Domain Functional Level update in this post because there are plenty of other resources online for that. We can, however, use PowerShell to very quickly verify that the pieces are in place. The AD PowerShell Module provides the commands Get-ADForest and Get-ADDomain which can be used to verify the mode for each.

(Get-ADForest).ForestMode
(Get-ADDomain).DomainMode

Once these are verified, we can check the current status of the Privileged Access Management Optional Feature. We can use the Get-ADOptionalFeature command to test this.

Get-ADOptionalFeature -Filter {Name -like "Privileged*"}

The output from this command looks a little bit overwhelming if you don’t know what to expect. The information of interest here is the EnabledScopes. This tells us where in AD the feature has been applied and activities (if it is indeed activated). As we can see above, the feature has no scopes currently which proves that it is not enabled.

Enabling the Privileged Access Management Feature

Once we have completed the verification steps, it is time to enable the optional feature. This is pretty simple using one line of PowerShell.

Once the feature has been enabled, we can verify whether it has indeed been activated by once more using the Get-ADOptionalFeature command.

Top Tip: If you have a large or complicated AD environment, you will want to wait for this to fully replicate before moving further. You can try this by using the -Server parameter on the Get-ADOptionalFeature command to check the state of the feature on each Domain Controller.

Using Time-based Group Membership

Now that you have followed the previous steps to enable the optional feature, you can start using it. In this example, we will just do it manually. To get the maximum power from this, you need to use this in conjunction with an automation solution that acts as a means for Just-in-Time access.

For brevity, I have consolidated everything into one PowerShell screenshot.

The first activity is to create a Time Span object. This is our way to tell PowerShell the time period we want to grant the access. Using the New-TimeSpan command, we can specify Minutes, Hours, and Days as parameters.

Top Tip: If you are using this in automation, you could create a header block that defines all of the different spans you will typically use such as one hour, one day, one week, and more to make them highly reusable.

Once you have created the Time Span, we can use the Add-ADGroupMember command by incorporating the new MemberTimeToLive parameter. Here we reference our Time Span object.

Once the user is added to the group, we can use Get-ADGroupMember to verify that the user was added to the group. In the second instance of Get-ADGroupMember, we can see that the user is no longer a member of the group. I promise there is no voodoo here: the user was automatically removed.

Top Tip: If you are planning to use this in a hybrid scenario with Azure AD and Azure AD Connect, remember your sync internal! If you set the time that the user will remain a member of the group too short, it may not be detected in time to grant the user permissions to the resources in Azure before they are removed from the group. You could initiate a Delta Sync in Azure AD Connect as part of the automation if you desired.

Richard works as a Cloud Consultant for Fordway Solution where his primary focus is to help customers understand, adopt and develop with Microsoft Azure, Office 365 and System Center.
Richard Green is an IT Pro with over 15 years' of experience in all things Microsoft including System Center and Office 365. He has previously worked as a System Center consultant and as an internal solutions architect across many verticals.
Outside of work, he loves motorbikes and is part of the orange army, marshaling for NGRRC, British Superbikes and MotoGP. He is also an Assistant Cub Scout Leader.

About Richard J Green

Richard Green

Richard works as a Cloud Consultant for Fordway Solution where his primary focus is to help customers understand, adopt and develop with Microsoft Azure, Office 365 and System Center.

Richard Green is an IT Pro with over 15 years' of experience in all things Microsoft including System Center and Office 365. He has previously worked as a System Center consultant and as an internal solutions architect across many verticals.

Outside of work, he loves motorbikes and is part of the orange army, marshaling for NGRRC, British Superbikes and MotoGP. He is also an Assistant Cub Scout Leader.