Integration

Temporary group membership in Active Directory

Also called time-based group membership, expiring links, and TTL group membership.

Active Directory is the one platform here with a real native answer. It is a good one, and the price of admission is a forest-wide change you cannot reverse.

What it does

Once enabled, the TTL is a parameter on the ordinary cmdlet:

Add-ADGroupMember -Identity 'Domain Admins' -Members 'SvcAcct' `
                  -MemberTimeToLive (New-TimeSpan -Days 5)

and the remaining time is readable:

Get-ADGroup 'Domain Admins' -Property member -ShowMemberTimeToLive

The part worth knowing, and the part that makes this better than a scheduled removal: the domain controller constrains the Kerberos TGT lifetime to the shortest TTL the account currently holds. Sign in with five minutes left on a Domain Admins membership and you get a ticket good for five minutes; when it renews, the privilege attribute certificate no longer carries that membership. A membership removed by a script leaves an already-issued ticket carrying the group until it expires on its own. AD's native version closes that window. Microsoft's original announcement walks through it, and Add-ADGroupMember documents the parameter.

What it costs to turn on

Two prerequisites, and the second is the one to read twice.

• A Windows Server 2016 or later forest functional level. Which means every domain controller in the forest is at least 2016 — often the real project.
• The Privileged Access Management optional feature, enabled forest-wide with Enable-ADOptionalFeature 'Privileged Access Management Feature' -Scope ForestOrConfigurationSet -Target contoso.com. Enabling it extends the schema, and like the AD Recycle Bin it cannot be turned off again. That is not a warning about risk so much as about approval: it is a one-way forest change, so it is a change-advisory conversation and not an afternoon.

The pre-2016 workaround, and why it reads badly later

Before this existed, the trick was a dynamic object: create a security group with an entryTTL, put the user in it, and nest that group inside the target group. When the TTL expires the temporary group is deleted outright and the nesting breaks, so the user loses access. It works, on anything back to Server 2003.

Its cost is the audit. The object that carried the access is gone — deleted with no tombstone — so six months later there is no record that the access existed, who it was for, or why it ended. It removes access correctly and removes the evidence with it.

What a TTL still does not give you

A TTL is a mechanism, not a process. Enabling PAM gets you expiry and none of the rest of what an access request is:

• No request and no approval. Somebody with rights on the group still runs the cmdlet. The TTL constrains how long, not whether.
• No record of why. The remaining time is queryable; the reason is not stored anywhere, and it is the field that matters when somebody asks eight months later who had Domain Admins and what for.
• Nothing outside the forest. The same person usually needs an Entra ID group, a SaaS role, or a GitHub team in the same breath. AD's TTL is the strongest native expiry of any platform on this list, and it still stops at the forest edge — the same wall every platform has, including the one built by the same vendor: Entra ID does not have this feature, and its answer is a different product with its own license.

How TemprBac does it

TemprBac keeps the expiry outside the directory and drives AD through ADWorker, a Windows service on a domain-joined machine. The practical consequences:

• It works at any functional level, with no schema change. Nothing has to be enabled in the forest, because the clock is not AD's. If a 2016 functional level raise is a two-year program in your environment, this is the difference between having time-bound AD access and not.
• No inbound firewall change. ADWorker polls an Azure Storage queue outbound and writes replies to a second one; nothing dials into the domain. Both the storage connection string and a pre-shared code are stored encrypted, because the connection string embeds the account key — anyone holding it could enqueue commands the domain-joined worker would execute.
• Groups are identified by sAMAccountName, not display name. AD display names are not unique and are not accepted by every lookup path, so a group without a sAMAccountName is not offered for import at all rather than producing a package that saves cleanly and grants nothing. Users can be named by UPN, email or SAM account name.
• The request, the approval and the reason are stored with the grant, and the removal is recorded next to it — so "who had access to what, and why" is one query rather than an archaeology exercise.
• Nothing may block revocation. No plan limit, quota or billing state stops access from expiring.

If your forest is already at 2016 with PAM enabled, the native TTL is good and the Kerberos behavior is better than anything an external tool can do — use it for in-forest privilege. The argument for putting the clock outside is not that AD's clock is worse; it is that it is the only one you have, and the access request that arrives on Monday is rarely about only one system.