Microsoft introduced a new feature back in 2016 called „time based group membership“ . Since then it is possible to add groupmembership with an expiration date.
There are plenty of examples on how to add a ttl to a groupmembership. I will only explain the basic mechanism on how to determine if a membership is time based or not.
After adding a time based membership you can check the groupmemberships with powershell by adding a ShowMemberTimeToLive parameter like this:
(Get-ADGroup -LDAPFilter „(CN=ROL-TEST-DIFEO)“ -Properties member -ShowMemberTimeToLive).member
The Result of the member field is mixed with normal memberships and time based memberships.
Time based memberships have the distinguishedname in the members field with an TTL prefix and look like this <TTL=xxx>,cn=difeo,ou=users… while xxx is time in seconds that this object remains in this group. These seconds count down to 0. After this, the object isnt member of this group anymore.
For flexibility we put groups into groups to summarize permissions to roles and not to persons. So it usual that a user has 3 groupmemberships with tons of groups with additional permissions. We cascade groups only one level to keep complexity under contol.
So my user difeo is in a group calles ROL-TEST. This group is member in a group called RES-TEST that binds the permissions to the resource.
Due to the lack of implementation for Active directory, a lot of systems can’t resolve groups in groups on LDAP level. We have such software in use and don’t want to make compromises in giving our users permission, so we use a special query called LDAP_MATCHING_RULE_IN_CHAIN that does the resolving job for us.
This query works pretty well, while being very slow. But in the end it does it’s job, unfortunately not for permissions with a TTL. If we do the query with LDAP_MATCHING_RULE_IN_CHAIN it will return all the users plus the users that has been added with a TTL, even when they shoudln’t be part of the group anymore. This break the permission model, because people still have access to things that they dont have to.
We opened a case for this one at microsoft and hope to get a fix for that.
Here are some powershell screenshots of this
Adding my users to ROL-TEST group with TTL of 2 minutes
Getting all members of this group (see my TTL membership)
Getting all members (none) again and then do the LDAP_MATCHING_RULE_IN_CHAIN query with the result of my user that isn’t part of the group anymore.
What I’ve missed here was querying the RES group, because this is the scenario we have (cascaded groups) but the result is the same
Microsoft can reproduce this behaviour in their lab. They’ll keep me updated on this topic. Lets see when this will be fixed
Recursive LDAP queries to AUTHZ a user is not the right way how to use its memberships for such – the right way is to consume the Kerberos/NTLM PAC information with its pre-calculated SIDs.
The right question would be therefore: Are KERBEROS/NTLM access tokens also showing the temp. memberships?
Keyword: constructed msds-tokenGroupNames* attributes of the affected user.
The kerberos tokens have the TTL as well and remove the group when TTL is over, so if we would only use kerberos, there shouldn’t be a problem.
Msds-tokenGroupNames would work, if our 3rd party app would check that on login time, but they „sync“ all users from these known RES groups to their internal database with LDAP queries. This app was designed to work with LDAP (not AD LDAP) in that way and needless to say, it is kind of strange to do it like this. Nevertheless changing this logic isn’t at our hands and we have to work with this. Msds-tokenGroupName needs further LDAP functionality in the 3rd party app, while LDAP_MATCHING_RULE_IN_CHAIN maybe not.
Anyway, the question is, why does LDAP_MATCHING_RULE_IN_CHAIN returns users that don’t belong to this group anymore?