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.
Here, I am logged on as TempGroupUser, that has temporarily been added to Domain Admins for 10 minutes.
Using TempGroupUser, I create a new user, Rogue1 (Star Wars reference intentional, couldn’t help it!) and add it to the Domain Admins group with no Time To Live.
After this, you will see both TempGroupUser and Rogue1 as Domain Admins, the latter with no time restraints.
And just to confirm: More than 20 minutes later – when TempGroupUser’s TTL has expired and is no longer Domain Admin – Rogue1, that was created using TempGroupUsers temporary group Membership, is still able to log on as Domain Admin and with no time limits.
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.
As you see in the attached screenshot, the web page recognizes the user’s membership of the group “Test-Admins” (SID ending in “1142”), which is what gives access to the page.
But looking at the clients local access token (using joeware.net’s SecTok), we can see that the client does not know about the user being a member of any domain groups other than Domain Users group, even though it has been added (See the Get-ADGroup output at the bottom of the command shell window).
This is of course because the user has logged on, before being added temporarily to the Test-Admins group.
Having logged on after being temporarily added to the Test-Admins group, we have full SSO to the website, and the local access token has Test-Admins represented.
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.
In this screenshot, I have refreshed the web page with less than 5 minutes left of the group membership TTL.
The user is met with a logon prompt, and logon attempts fail.
This is despite the fact, that the TempGroupTest user according to the screenshot obviously still member of the Test-Admins group, not only according to the local access token, but evidently also according to Active Directory.
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).
As you can see in the output from SecTok.exe, both membership of Test-Admins and the local Administrators group are in the access token on the local client. (and Active Directory also confirms the membership of the group).
Note the time 8:59 AM.
Now we leave the client for some hours making sure, that the Temporary Group Membership has expired.
What are we able to do then?
Now – at 4:39 PM – memberships of both Test-Admins and therefore also local Administrators groups are still in the local access token, although Get-ADGroup confirms the user is not a member of the group according to Active Directory.
To proof the administrative access is in effect, in the screenshot the user creates a local user account with no expiry or password expiry and adds it to the local Administrators group.
And using the MMC console, we can verify the successful addition of Rogue1Local to the Administrators group. (Using the same console we can also take advantage of the “lingering administrative permissions“ to remove the user again or create another)
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.
Using Kerberos:
Using NTLM:
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.
At the exact time of the TTL expiry, access to the share is revoked.
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.
TempGroupTest connects to the file share at 10:00 PM, as shown the Logon Event on the file server
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.
As you see in the screenshot, I’m able to continue writing to the share, as long as I keep the SMB connection (and with that the Logon Session) alive. Even 49 minutes after the expiry of the user’s group membership!
At the server side, you will see an active SMB session, that has been active for 57 minutes, although the TTL for the group membership was only 10 minutes
Looking at the logon events, we see a Logon Session being created at 5:53 PM with the Logon ID 0x269E8E2, when we first connect to the file share from the client.
And the Logon Session for this Logon ID is not destroyed until 6:52 PM, when the user disconnects from the share, and the SMB session is closed.
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.
Even after the TTL has expired, and Active Directory no longer considers the TempGroupTest user a member of Test-Admins, the IIS ASP.NET page reports back to me, that it considers TempGroupTest user a member of Test-Admins.
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:
“NTLM blocking is no joke. I didn’t bother to discuss how you actually disable NTLM here because you’re not ready to do it yet. NTLM blocking can be a résumé generating event!”
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.
With Protected Users group, it is clearly stated, that your account is being restricted.
Using NTLM blocking, the end user is told, there was a "Network Error".
I could imagine this resulting in some Service Desk calls from users complaining about faults in the network.
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