Why permanent admin rights in AD are a problem
Giving “forever access” (for example, permanent Domain Admin membership) creates several predictable failure modes:
- Privilege creep: users accumulate rights over months/years, and nobody remembers why they have them.
- Bigger blast radius: if a privileged account is compromised, the attacker gains high-impact access immediately.
- Harder audits & compliance: “Who has what access, and why?” becomes a manual, error-prone exercise.
- Reduced accountability: if everyone is always privileged, you lose a clean signal of when privilege was actually needed.
Even if your administrators are careful, permanent privilege is an unnecessary risk when many admin tasks are sporadic and time-bound (patching windows, emergency changes, one-off troubleshooting, etc.).
Just in time admin access flips the default: users are unprivileged most of the time and become privileged only for a short, controlled period.
The built-in AD feature: time-based (temporary) group membership
Starting with Windows Server 2016, Active Directory introduced an approach to short-lived group membership as part of the PAM optional feature. The idea is simple:
- You add a user to a security group with a TTL.
- After the TTL expires, AD automatically removes that membership.
- No scheduled task, no “remove later” reminder, no cleanup scripts.
This enables a pragmatic “good-first-step” implementation of Just in time admin access on-prem, specially if your privilege model is group-based.
Prerequisites and important caveats
Before implementing this in production, make sure you understand these constraints:
1) Your forest functional level must be Windows Server 2016 or higher
This feature requires the forest to be at least Windows Server 2016. You can check with the following Powershell command on a Domain Controller:
(Get-ADForest).ForestMode
2) The PAM optional feature must be enabled (and it’s irreversible)
In many environments the PAM feature is not enabled by default. You can check and enable it via PowerShell.
Be aware: multiple sources warn that once enabled, it cannot be disabled. Treat it like a design decision and test it in a lab first.
3) TTL membership is PowerShell-driven
You typically can’t set TTL membership in ADUC (dsa.msc). Plan to operationalize this via scripts, automation, or a self-service workflow.
A practical workflow for Just in time admin access in AD
A clean operational pattern looks like this:
- Define “privilege groups” (e.g., “Server Admins – PROD”, “AD DNS Admins”, “Tier-0 Emergency Admins”).
- Require a request/approval (even if initially manual), including justification + duration.
- Add the user with a TTL using PowerShell.
- Verify TTL (for transparency).
- Let AD expire the membership automatically.
This instantly reduces standing privilege and prevents “forgotten admins” from accumulating over time.
PowerShell example: add a user to an AD group for a limited time (auto-remove)
Copy/paste example. Adjust domain/group/user values to your environment.
Full Script available on GitHub: https://github.com/au2mator/AD-Time-Based-Group-Membership/blob/main/Prerequisites and Test.ps1
# ------------------------------------------------------------
# Time-based (Temporary) Group Membership in Active Directory
# Enables "Just in time admin access" via expiring group membership (TTL)
# ------------------------------------------------------------
# 1) Check forest functional level (must be Windows Server 2016 or higher)
(Get-ADForest).ForestMode
# 2) Check whether the PAM optional feature is enabled
Get-ADOptionalFeature -Filter "name -eq 'privileged access management feature'"
# 3) Enable PAM optional feature (RUN ONCE - review carefully!)
# Replace 'domain.local' with your AD forest root domain DNS name.
# Enable-ADOptionalFeature 'Privileged Access Management Feature' `
# -Scope ForestOrConfigurationSet `
# -Target domain.local
# 4) Add a user to a group with a TTL (example: 5 minutes)
$User = "Michael.Seidl"
$Group = "TTLGroup"
$ttl = New-TimeSpan -Minutes 5
Add-ADGroupMember -Identity $Group -Members $User -MemberTimeToLive $ttl
# 5) Verify: show remaining TTL for members (seconds)
(Get-ADGroup $Group -Property member -ShowMemberTimeToLive).member
When AD TTL is not enough: bring governance, approvals, and hybrid role management
What is just in time admin access?
Time-based group membership is a powerful AD-native building block—but by itself it doesn’t automatically give you:
- a user-friendly request portal (self-service),
- approvals and escalations,
- policy enforcement (max durations per group, MFA, justification),
- cross-environment coverage (on-prem AD + Entra ID),
- centralized reporting and audits.
That’s where a dedicated PIM layer adds real operational value.
Frequently Asked Questions
Just in time admin access is a security approach where elevated privileges (like Domain Admin rights) are granted only when needed and for a limited time, instead of permanently. Users request access for a specific task, receive temporary privileges, and those rights are automatically removed when the time expires minimizing the window of exposure if an account is compromised.
Yes. When you use Active Directory PAM with time-based group membership, AD automatically removes users from groups after the TTL (time-to-live) expires. No scheduled tasks or manual cleanup required the expiration is handled natively by the domain controllers.
No. Once you enable the Privileged Access Management optional feature in Active Directory, it cannot be disabled or rolled back. This is why Microsoft and most AD experts recommend testing the feature thoroughly in a lab environment before enabling it in production.
Yes. EntraID (formerly Azure AD) offers Privileged Identity Management (PIM), with additional, monthly License Cost. For a single Platform with Hybrid PIM, you might be interested in the au2mator hybrid PIM Management Solution.
If you want to operationalize Just in time admin access as a scalable process (not just a script), see our hybrid PIM approach here: au2mator Privileged Identity Management (PIM)
