Back in the day when I had a “real job” in IT, one of the things that often caused me grief was temporary permissions. Every so often, someone would ask me to temporarily make a particular user a member of an Active Directory group. Although there is nothing difficult about adding someone to a group, the same cannot be said for removing that person from the group later on when they no longer need membership.
I learned early on that trusting myself to remember to pull the plug on the temporary group was probably a bad idea. As such, I used to mark my calendar with reminders to remove the temporary group member. Even this was not a great solution, though. The first time that I removed a temporary group member when their time was up, it was only a matter of time before I got an irate phone call from a department head who was upset because their temporary employee had suddenly lost access to whatever resource they were supposed to have temporary access to. Needless to say, it became a chore to have to call people to make sure that it was OK to remove temporary users from groups.
Today, things are a lot better than they were back in the dark ages when I was a network administrator. There is any number of different ways that an administrator might approach this problem today. For example, an administrator might use an automation engine to create an automated task that sends an email notification to the department head on the day before the Active Directory group membership expires. Assuming that nobody raises any objections, this same automated process could then process the group removal when the time comes.
Building an automated task around maintaining temporary group memberships sounds great, but it might not always be practical. After all, setting up such a task would require some sort of orchestration tool, and it would require the skills necessary to create a workflow that would perform the task at hand.
In Windows Server 2016, Microsoft has made things a lot easier on Windows Server administrators by providing a mechanism for assigning users to an Active Directory group on a temporary basis.
Temporary Active Directory group memberships: Required infrastructure
While preparing to write this article, I did some experimenting, and the use of temporary group memberships within a single domain forest seems to work. In fact, I will be demonstrating the technique in the next section. However, Microsoft’s documentation explains that you should be using two separate forests with a trust relationship between the two.
To unlock the ability to assign temporary group memberships, you will need to enable something called the privileged access management feature. You can do this in a single domain (although that does not seem to be officially supported), but Microsoft really intends for you to create what is known as a bastion environment.
The simple explanation is that you can create two different Active Directory forests. One forest is the one that you already have in place. This forest contains all of your existing users, groups, etc. The other forest is a dedicated administrative forest that has been hardened to the maximum extent possible. It is within this administrative forest that you enable the privileged access management feature.
When using this approach, you won’t be able to assign users on a temporary basis to an existing Active Directory group, but you can re-create those groups in the administrative domain and then assign members on a temporary basis.
You can learn all about the Microsoft Identity Manager architecture and how privileged identity management works here. Microsoft has also provided step by step instructions for preparing your environment here.
What does it look like?
I don’t want to waste your time by rehashing the instructions that Microsoft provides. I do, however, want to show you what it looks like to enable privileged access management and to assign a temporary group membership. Keep in mind that the procedure that I am about to demonstrate is for lab use only.
For the sake of example, let’s pretend that I wanted to enable privileged access management for a domain named poseylab.com, and that I wanted to give a user named User5 temporary access to a group called Payroll. Assuming that the necessary infrastructure was in place, the first step in the process would be to enable privileged access management for the domain. It is important to note that this process is irreversible. The PowerShell command that I would use is:
Enable-ADOptionalFeature ‘Privileged Access Management Feature’ -Scope ForestOrConfigurationSet -Target poseylab.com
You can see what this looks like in the figure below.
Now, all I have to do is add User5 to the Payroll group, while also telling PowerShell how long the group membership should be valid for.
The easiest way to accomplish this is to start by creating a variable that will hold the time limit. For my purposes, I will create a variable called $TimeLimit, and I will set it to five minutes. Here is the command:
$TimeLimit = New-TimeSpan -Minutes 5
To add User5 to the Payroll group, it is necessary to append the -MemberTimeToLive parameter to the Add-ADGroupMember cmdlet, in a way that references the $TimeLimit variable. Here is an example of the command:
Add-ADGroupMember -Identity ‘Payroll’ -Members User5 -MemberTimeToLive $TimeLimit
Ordinarily, if you want to see the properties for a group’s users, you could use a command like this one:
Get-ADGroupMember -Identity Payroll |Where-Object { $_.objectClass -eq 'user' } |Get-ADUser -Properties *
Oddly enough, however, using this command does not display the time-to-live value among the group member’s other properties. This is most likely because the time to live is associated with the group object rather than the user object. Even so, looking at the group’s properties using a command like the one below does not reveal the user’s time to live:
Get-ADGroupMember -Identity Payroll | Select-Object *
The only way that I have found to display the group member’s time-to-live value is by referencing the ShowMemberTimeToLive property in a very specific way. Here is an example:
Get-ADGroup ‘Payroll’ -Property member –ShowMemberTimeToLive
To show you how this works, I have run the command above twice. The first time, the member property that is displayed in the command’s output shows a TTL of 267 for a user named User 5. I waited several minutes before running the command a second time. Now, the command shows an empty group, because the TTL for User5 has expired. You can see the output below.
A huge benefit
Having the ability to add a user to an Active Directory group for a specific length of time will be a huge benefit to overworked Active Directory admins. Even so, enabling that functionality requires major and irreversible changes to the Active Directory environment.
