ADDS-PIM Application Tour

Active Directory Privileged Identity Management

Time-limited privileged access for Active Directory.

ADDS-PIM provides controlled, policy-driven and fully auditable access to privileged Active Directory groups using TTL-based memberships.

Explore the application View on GitHub
  • Policy-driven TTL access
  • FIDO2 / WebAuthn & TOTP
  • Approval workflows
  • End-to-end audit trail
Start page with quick access to privileged access requests, request history and MFA.

How it works

A privileged request is a workflow, not a single write operation.

The frontend prepares the request, but it never makes the final security decision. Entitlement, policy, MFA, request integrity and current directory state are validated server-side. After execution, ADDS-PIM reads the membership back from Active Directory and verifies the effective TTL before the request can be marked successful.

  1. 1Request
  2. 2Validate
  3. 3MFA
  4. 4Approve
  5. 5Execute
  6. 6Verify
  7. 7Audit

Privileged access request flow

From request to verified membership

The exact path depends on the target-group policy. MFA, ticket references and approval can be required independently or in combination.

01

Request time-limited access

The user selects an entitled target group and target account, chooses an allowed duration, and provides any additional context required by policy.

  • Minimum, maximum, default and step values are policy-controlled.
  • Justification and ticket references can be mandatory.
  • MFA and approval requirements are visible before submission.
02

Confirm the concrete request with MFA

If stronger authentication is required, the user confirms the privileged-access request immediately before it can continue.

ADDS-PIM supports TOTP and FIDO2/WebAuthn passkeys. The factor is associated with the request flow rather than being treated as a generic long-lived MFA session.

Second-factor confirmation
Passkey / security-key verification
03

Enter the approval workflow when required

A request that requires approval enters the AwaitingApproval state and remains blocked until an authorized approver makes a decision.

The request retains its unique identifier so that every subsequent validation, approval, execution and audit event can be correlated.

Request status
Requester view
04

Approver reviews the request

Authorized approvers can explicitly approve or reject pending requests.

Approval is an additional authorization decision. It does not replace entitlement, policy, MFA, request-integrity or Active Directory validation.

05

Execute, read back and verify

After every required check and approval has succeeded, the request is sent to the dedicated Active Directory execution component.

A successful write is not enough. ADDS-PIM reads the resulting membership back from Active Directory and verifies that the TTL-based membership is actually present. Only then can the request transition to Succeeded.

Multi-factor authentication

Phishing-resistant authentication where it matters

Users can manage their registered authentication factors from a dedicated MFA area. The current implementation supports TOTP and multiple FIDO2/WebAuthn passkeys.

Administration

Policies and entitlements instead of hard-coded privilege

The administration area manages people, linked Active Directory accounts, target groups, entitlements, policies, approvers, security-related settings, reconciliation and audit data.

Administration overview

The admin landing page provides access to the major operational areas and surfaces security-relevant certificate status at a glance.

Target-group management

Administrators register the Active Directory groups that may be requested through ADDS-PIM. Important controls such as TTL range, MFA, ticket and approval requirements are visible in the overview.

Group-specific policy

Security requirements follow the sensitivity of the target group instead of being globally hard-coded.

  • Minimum, maximum, default and step TTL
  • Required second factor
  • Ticket-reference requirement
  • Approval requirement
  • Request enable/disable state

Explicit approvers

Groups that require approval can have explicitly assigned approvers. Only accounts with the required capability are eligible.

Persons and account purposes

ADDS-PIM distinguishes a person from the Active Directory accounts associated with that person. Accounts can have explicit purposes such as interactive authentication, receiving temporary privileges or deciding approvals.

Direct entitlements

Entitlements define who may request which privileged target account for which target group. Optional expiry dates allow access eligibility itself to be time-bounded.

Entitlements are re-evaluated server-side during the request workflow; the frontend is never authoritative for authorization.

Security-related settings

Operational controls are visible and manageable

Settings overview

Application-wide and security-sensitive configuration is grouped into a dedicated settings area.

Ticket-reference validation

Accepted ticket formats can be defined per target group and are validated server-side.

TOTP protection-certificate rollover

Stored TOTP secrets are encrypted at rest. Certificate rollover performs an audited re-encryption after the replacement certificate has been securely provisioned.

Audit and traceability

Every security-relevant decision is traceable

Audit events correlate the request across validation, MFA, approval, execution and final Active Directory verification. Technical logging and business/security audit data are kept as separate concerns.

Event type UTC timestamp User / person Target account Target group Request ID Correlation ID Frontend instance Authentication method Requested TTL

End-to-end flow

The final security decision stays server-side.

  1. The user authenticates to ADDS-PIM.
  2. The application determines which target groups the user is entitled to request.
  3. The user selects the target account, group and requested TTL.
  4. Required context such as justification and ticket reference is collected.
  5. If required, the user confirms the concrete request with TOTP or FIDO2/WebAuthn.
  6. The backend validates the request again using current server-side data.
  7. If required, the request enters the approval workflow.
  8. The dedicated AD execution component performs the TTL-based membership change.
  9. ADDS-PIM reads the membership back from Active Directory and verifies the effective TTL.
  10. Only after successful verification is the request marked as successful.
  11. Every relevant decision and state transition is written to the audit trail.

Project status

Feature-complete beta

ADDS-PIM has been exercised end-to-end in a test environment. Additional hardening, testing and operational refinement are still in progress before production use.

Source & documentation