Beware of NTLM when using Temporary Group Memberships
Short-term group memberships might lead to long-term permissions
Temporary Group Memberships are a very welcome addition to Windows Server 2016 Active Directory Domain Services.
It gives you the means to elevate privileges for someone temporarily.
Previously, what many IT Admins would do was to give a person the needed privileges manually and then they would forget to remove these privileges, when they are no longer needed.
I see this happen in many Active Directory domains, I come in contact with.
You could have used a Scheduled Task to remove the privilege at a configured time, or you could have used the little know feature of Dynamic Objects.
But Temporary Group Memberships is now the way to accomplish the goal.
Basically, it works by setting a Time To Live on the link between the user and the group, that gives the permissions, and also on the Kerberos ticket issued, so that when it is renewed at the end of the TTL, the user will no longer be a member of that group.
However, this blog post is not here to give instructions on enabling it or using it. You will find plenty of that elsewhere.
This blog post is here to remind you not to trust this feature blindly.
Your short-term group membership might give you long-term privileges.
Let’s look at two things:
- The ability for a user with temporary privileges to create a new user with permanent privileges.
- The fact that a user with temporary privileges in some cases could keep those privileges after the TTL expiry
Creating a permanent Domain Admin with a Temporary Group Membership
Is this possible? Well, obviously yes.
If you make someone temporary Domain Admin, you give him full control for a limited amount of time.
You also give him ability to create a new Domain Admin, that has no time restraints.
See these screenshots as an example.
key take away
Do not use Temporary Group Memberships for highly privileged groups, like Enterprise Admins, Domain Admins, Administrators, Account Operators or similar.
Instead, you should define layered privileges and assign them to groups, that have been given only the necessary privileges.
For example, if someone needs to be able to reset passwords for a set of users for a limited time, do Delegation of Control to a group and scope it only to the users, he needs to reset passwords for.
The group, which he will be a temporary member of, should not have reset password permissions for highly privileged accounts.
Lingering permissions after TTL expiry?
After stating the obvious, that a Domain Admins – even if only temporary – has the keys to the kingdom, let’s look at twist with Temporary Group Memberships, you might not have thought about.
What if someone could continue to use their temporary privileges, even after their temporary group membership has been revoked?
Before diving in to this, let’s first see the Temporary Group Membership actually denying access, when it should.
This will give us a pretext for the lingering permissions.
Playing with Temporary Group Memberships against a web-server
So, before starting, let’s line up the test setup:
Let’s first see, that what happens, when an already logged on user is added to a temporary group, that gives access to the website.
Authenticating with Kerberos, you will be met with a logon prompt, as the local client cannot provide an access token containing the group, that has access. The access-granting group is not included the Kerberos PAC, that was delivered as part of the TGT from the KDC sent to the client at logon.
But once you type in your username and password, the page will load.
Using NTLM authentication (can be forced server side and by connecting to the resource by IP-address), authentication happens seamlessly without a logon prompt, because the server will authenticate the TempGroupTest user against the DC and receive the temporary group membership of Test-Admins.
Now, let’s talk timing!
So, when will access to the website expire?
This will probably come as a surprise, but access does not expire, when the TTL expires, but 5 minutes before that.
I suspect this to be connected with the default time skew tolerance of 5 minutes accepted in Kerberos.
However, changing the Maximum tolerance for computer clock synchronization Kerberos Policy GPO setting on Domain level does not change the 5-minute threshold for access given to Temporary Group Memberships.
So it seems to be hardcoded in this technology.
Key take away
When assigning Temporary Group Memberships on a very short term to a user, you should set the TTL 5 minutes higher than the time, the user actually needs access for.
But users’ access being revoked 5 minutes before, what they expected, might not be what you should worry most about.
What if access remains long after the temporary group membership has expired?
Let’s look at two scenarios:
1. Permissions in Interactive Logon sessions
2. SMB permissions when accessing files on file servers using NTLM
Lingering permissions in an Interactive Logon session
This one really shouldn’t come as any surprise, as we have always been aware, that you should log off and log on again in order for your access token to represent changes in your group memberships.
But let’s show, that this – unsurprisingly – is also true for Temporary Group Memberships.
First, a screenshot of the user TempGroupTest logged on to the client during his Temporary Group Membership of Test-Admins (which is a member of the local Administrators group).
Now we leave the client for some hours making sure, that the Temporary Group Membership has expired.
What are we able to do then?
Not much of a surprise here.
But still something to keep in mind when using Temporary Group Memberships.
Especially, when you use Temporary Group Memberships to give admins temporary access to servers.
At the time of writing this, I logged on to a server using RDP as a temporary admin with a TTL of 10 minutes.
1 hour later, I'm still logged on to this server and able to create local users and add them to the local administrators group.
I was eventually after 2,5 hours kicked off the RDP session by the server with "Connection was denied because the user account is not authorized for remote login".
But until then I was admin on the server, even though my group membership giving admin access had expired a long time ago.
Had I logged on using a Hyper-V/VMware console session, I would just keep my admin access for as long, as I didn't log off the console.
But let’s now look at a client/server scenario with SMB file sharing.
Lingering permissions to a file share after Temporary Group Membership expiry
Let’s first see, what happens, if TempGroupTest user tries to access a share using Kerberos authentication and next NTLM authentication, while he’s a member of Test-Admins group, that provides access to the share.
The 5 minute threshold kicks in again, and denies access to the share, although the user is actually a member of the group, that provides access to the share.
We’ve seen this before, nothing new here. Moving on!
With Kerberos authentication to the file server, we are able to access and write to the share for the duration of the TTL for the temporary group membership.
This is because of a clever implementation of the Temporary Group Memberships feature:
It is not only the link between the user and the group, that has a TTL.
The TTL of the Ticket Granting Ticket (TGT) – which includes the PAC with the group memberships – is set accordingly.
Therefore, when the TTL expire, the client is forced to renew its TGT to one without the temporary group membership in the PAC.
The file server gets a new Session Ticket without the group membership included, and the client is denied access.
This happens even if the logon session to the file server has not yet expired.
TTL of the temporary group membership expires at 10:07 PM, as shown in the previous screenshot.
But the logon session on the file server lives on until 10:11 PM, but without the group membership for the last 4 minutes:
Unfortunately, this is not how it works with NTLM authentication and Temporary Group Memberships.
NTLM is a protocol, that is less advanced than Kerberos.
It has no concept for a TTL on the access token.
Your group memberships lives on for the duration of the logon session.
Let’s demonstrate this by connecting to the file share using the IP-address, forcing the use of NTLM.
Again: The temporary group membership had a TTL of 10 minutes, but I was able to use the resulting permissions for almost an hour, and could have kept it alive longer, had I wished to do so.
Lingering permissions on a web server
We can do this with http against an IIS server as well, when we’re using NTLM.
In this example, I have refreshed the web page regularly during the TTL of the temporary group membership.
What can be done to mitigate this?
If we want to avoid this issue, we should avoid using NTLM authentication for Temporary Group Membership based access to ressources.
One way to accomplish this is to add all users with temporary group memberships to the Active Directory group Protected Users.
When a user account is a member of this group, Active Directory prevents NTLM authentication for this user.
However, this has other consequences. Members of the Protected Users group cannot:
· Sign on offline
· Be delegated with unconstrained or constrained delegation
So if these users needs access to resources, that use Kerberos delegation, Protected Users-membership will break this.
Another option could be implementing NTLM blocking.
However, implementing this at the domain level would most likely break some applications in your environment.
As the blog post in the link above puts it at the end:
One thing, you could consider, though, is if it is possible to implement NTLM blocking on the specific resource servers, that the Temporary Group Memberships give access to.
If you use Temporary Group Memberships for administrative tasks from Privileged Access Workstations, you could also consider implementing NTLM blocking of outgoing NTLM authentications.
Both of these solutions could be implemented with Group Polices applied only to the clients/servers, that are involved, instead of the more dangerous NTLM blocking applied as a Domain Controller GPO.
But still, first: audit, audit, audit!
There's a difference in the end user experience with the two approaches, though.
In both approaches you effectively prohibit the access to resources using their IP-address, as Kerberos does not have SPNs for IP-addresses and therefore cannot issue a Session Ticket.
If neither Protected Users-group or NTLM blocking are options for you, that doesn’t mean you shouldn’t be using Temporary Group Memberships.
You are still better off with a managed solution, that makes sure, that your users are automatically removed from unnecessary group memberships, than having no solution at all.
But just be aware of the implications mentioned above:
1. Don’t use it to add users temporarily to highly privileged Active Directory groups, if you wouldn’t trust them to be permanently members of these groups.
2. Be aware of the 5-minute threshold
3. Be aware, that permissions to resources might be lingering long after the group membership has expired, if there has been authenticated using NTLM