Active Directory records screen

The Active Directory Records screen reads the encrypted Active Directory credential records in the active vault and shows the directory details stored with each record. It offers the eligible record, sign-in, and DC Agent actions; it is not a live LDAP browser, PAM checkout queue, or general directory-administration console.

Access, active vault, and license boundary

The screen requires the Integration license feature and an unlocked active vault. Owner, Admin, and User can use vault-secret screens; Auditor cannot. Within the active vault, Viewer can read, reveal, copy, inspect, and launch a stored record. Editor or Manager plus a writable license is required for changes such as delete or supported edits.

Directory-provider data and DC Agent actions are more restricted. Only the Owner sees current provider and action data and can change VaultPilot sign-in access or queue directory actions. A directory action also requires a writable license, a target that still matches a directory user, a Connected ready agent, and the matching capability. Built-in and bind accounts stay blocked; other privileged targets need extra approval. The server and agent check protected targets again; a disabled button is not the only safeguard.

A read-only license hides licensed screens and blocks vault and directory changes. An already loaded record can stay readable, but read-only mode never allows changing AD, VaultPilot sign-in access, or the encrypted record.

Record origin and ownership

New directory records are selected and imported from Integrations > Active Directory into a writable vault. The Active Directory records screen has no New record button and does not create RDP or SSH credentials manually. A directory record needs a synced provider and user, and VaultPilot prevents a second record for the same directory user in the same vault.

An imported record contains an encrypted copy of the selected user’s details. Depending on what the agent reports, it can include provider, domain, account, DN/OU, enabled and lock state, password-state signals, last logon, last seen, last sync, privilege signal, host, protocol, category, owner, tags, and risk. It is not read live every time the list opens.

The DC Agent does not read an existing AD password. A newly imported directory record therefore starts without a password. A stored host or default RDP protocol is launch context, not proof that the account was tested or that the host is an approved administrative server.

The visible Owner value comes from the record: its owner, directory account, or username. It is not the system Owner role, the vault role, an AD object owner, or proof of who is responsible. Vault access stays controlled separately by Viewer, Editor, and Manager grants.

Search, filters, and layout

The search box matches record title, username, URL, host, domain, owner, category, source, risk, tags, provider name, directory account, parent DN, object type, and protocol. It does not search Active Directory and is not a full DN search.

The quick-filter row is built from the records and shows a limited number of controls:

• All resets credential protocol, source, risk, and smart filters.
• RDP and SSH appear when matching records exist.
• Source shortcuts can include AD Sync, Manual, Imported, and Discovered.
• Risk shortcuts can include Critical, Warning, Expired, and Unknown when matching records exist and space permits.

Quick-filter counts cover all Active Directory records in the active vault, ignoring other active filters. Selecting a protocol, source, or risk shortcut resets the other credential shortcuts and clears smart filters.

Add smart filter builds options from the loaded records. Available options can include username or owner, product or service, category, tag, protocol, source, risk, and credential state:

Multiple smart filters must all match. Remove an individual filter chip or use Clear to remove them all. These states describe stored record details; they are not a fresh agent-health or password check.

The density control switches between Cards and Table. Table headers are Record, Encrypted session value, and Actions. Both layouts show the same filtered records, most recently updated first.

Record row and detail drawer

Each row can show:

• RDP or SSH identity, title, stored target, and account;
• source and risk chips;
• directory domain, owner, and last-sync time when present;
• up to three AD-state chips, with +N for additional states;
• the record’s last-updated time.

AD-state chips appear in this order when data exists: Enabled or Disabled, Locked, Must change, Expired, Privileged, Never expires, Stale login, and Last login. Locked, password expired, or must-change signals are rated critical during directory import. Privileged, stale, never-expiring-password, and disabled signals raise a warning. The row keeps showing the stored details until a later import refreshes them.

View record details opens a side drawer with source, risk, record status, account, target, category, owner, tags, last update, AD provider, domain, OU/DN, last sync, last logon, last seen, and a short AD-state list. The drawer never displays the password or other secret value. Use the separate reveal or copy action when authorized.

Record actions

The row can offer these primary actions:

• Prepare RDP package when a stored RDP host exists. The browser downloads an .rdp file; a stored password is copied to the clipboard briefly. Local drive and device sharing is turned off in the generated file.
• Open SSH URI when a stored SSH host exists. A stored password is copied to the clipboard briefly but is not placed in the link.
• Copy username when a username exists.

The actions menu can include:

• View record details;
• Open history and, for an Active Directory source, Go to agent;
• Allow VaultPilot sign-in or Remove from VaultPilot sign-in;
• eligible DC Agent actions described below;
• Copy secret value, Reveal secret, and the breach check when a value exists;
• Copy SSH command for SSH records; the password is not placed in the command;
• Edit secret and Delete secret when the active vault is writable.

Reveal requires confirmation, makes the value temporarily visible in the browser, and records the view in the audit history. Copy and launch actions clear the clipboard shortly afterwards where applicable and are recorded in the audit history. Investigate any audit failure notice; it does not make a value safe to expose elsewhere.

Reveal secret works only when the encrypted vault record actually contains a password. Because the agent cannot read the current AD password, this action cannot fetch one for an empty directory record. Use the authorized Assign random password now action or an approved rotation policy when a new value is required.

Generic edit does not change AD. Directory-controlled credential records are protected and can be refused by the generic editor even when the menu is visible. Delete secret removes the encrypted record from the active vault after confirmation and is recorded in the audit history; it does not delete, disable, unlock, or change the AD account.

There is no duplicate-record action for Active Directory credentials. The general bulk menu can offer export, category and tag, archive, disable or revoke, security check, audit report, share, note, edit, and remove, but these act on vault records only. They are not bulk LDAP, PAM, password-reset, unlock, or directory-disable actions, and directory-owned records keep their protections. Sensitive export writes the selected decrypted records to a file after confirmation and is recorded in the audit history.

VaultPilot sign-in access

Allow VaultPilot sign-in manages a VaultPilot account; it does not change AD permissions. It requires the Owner, a writable license, a usable username, and a password stored in the encrypted record. A directory record also needs its provider and DN. Allowing creates or reactivates the matching VaultPilot account and its personal vault; removing disables that VaultPilot account and updates the directory sign-in selection when the provider is available.

The VaultPilot account change and the provider sign-in selection are separate steps. The account can be created, reactivated, or disabled before the provider update fails. A failure notice therefore does not prove that every change was undone. Stop and check the account in Users, the sign-in selection in Integrations > Active Directory, and the entries in Audit Log before retrying.

An AD Sync record normally has no password because the agent cannot read one. Sign-in therefore stays unavailable until an approved password-change workflow has produced and safely stored a value. Allowing sign-in is not an AD group change, MFA enrollment, PAM approval, or a test that the directory password is current.

DC Agent actions and capability boundary

The four account actions appear only when the record still matches a current directory user in a provider the Owner can see:

Every account action requires confirmation and is queued rather than done instantly. The connected agent must report the matching capability. Track pending, running, success, failure, review-required, or cancelled outcomes in Integrations and Executions.

Built-in accounts and the agent’s bind account are hard stops; the server and agent always refuse them. A manual action against a privileged but non-built-in account requires a second explicit confirmation. Automated rotation also needs a lasting privileged-target approval on the policy, and turning the policy off clears that approval.

After Assign random password now succeeds in AD, the action result and the vault-record update are separate outcomes. The browser tries to store the new value in the vault record when the vault is unlocked and writable. Confirm both the agent success and a separate record-update notice, the updated record, and the audit entry. If they disagree, treat the AD password as changed but the vault record as unconfirmed and stop before retrying.

Record history and rotation

Open history shows each revision’s time, actor, source, and state. An authorized user can restore an earlier revision as a new current revision without deleting the revisions in between. For an Active Directory password, restore changes only the vault record; it does not roll the AD password back. Follow with an explicit agent action or approved rotation so AD and the vault stay in step.

Configure rotation can schedule a calendar run daily, weekly, monthly, or at a custom interval. A custom interval supports 1–365 days, 1–52 weeks, or 1–12 months and requires a start date. Optional triggers can run 5–1440 minutes after a secret is revealed, or when the AD password reaches an age of 1–365 days. When several triggers are on, whichever comes first runs; a daylight-saving change does not create the same run twice, and missed runs are not caught up in bulk.

An uncertain rotation result is not retried blindly. Inspect status and logs under Tasks > Scheduled. Go to agent in the record or history panel opens the matching provider under Integrations > Active Directory.

This screen offers no direct LDAP bind, arbitrary PowerShell, PAM approval, session recording, or privilege elevation. Provider enrollment, selection, sync, health, capabilities, and agent tokens belong to Integrations > Active Directory.

Audit and evidence

Directory record import is recorded as record creation. Reveal, copy, launch, export, edit, and delete are each recorded in the audit history. Directory action creation, cancellation, and result are recorded with action, provider, and status; never share the exact DN or generated password. Allowing or removing VaultPilot sign-in is recorded as a user change; check the provider selection separately.

Treat the record row, detail drawer, action notice, Integrations action history, Executions entry, and Audit Log as separate evidence. A queued notice is not proof of AD success. Agent success is not proof that the new password was stored in the vault. A changed vault timestamp is not proof that the AD action succeeded.

Screen states

Before you act

• Confirm the intended active vault, system role, vault role, Integration feature, and writable license.
• Compare record source, provider, domain, account, last sync, and last seen before treating the details as current.
• Confirm the provider is connected, the exact capability is present, and the target still matches a directory user.
• Stop on a built-in or bind account; do not use another tool to get around the block. Confirm the required second approval for other privileged targets.
• Tell a vault-record change apart from an AD action and from VaultPilot sign-in.
• For a password change, plan where the new password will be stored and check the AD result, action result, vault update, and audit entry separately.
• Before changing VaultPilot sign-in access, plan to check Users, the provider sign-in selection, and Audit Log before any retry.

Safe evidence

• Safe to share: broad source type, RDP or SSH protocol, general risk or state, system and vault role, directory action type, action status, approximate time window, and the redacted error message.
• Keep private: title, username and account, owner, host, domain, provider name, DN, OU and base DN, tags, exact sync and logon times, privileged-group names, record, action and provider IDs, RDP package, SSH link or command, and full row or drawer screenshots.
• Never share: stored or generated passwords, clipboard contents, the action’s password result, encrypted record content, vault key, master password, user private key, bind credential, agent token, raw directory inventory, sensitive exports, or agent or server logs containing real targets.
• If a password, generated action result, bind credential, or agent token was shared anywhere, treat it as exposed and rotate or revoke it through the normal procedure.

When to stop and escalate

Stop when the active vault or source provider is uncertain, the target no longer matches, privilege state is unexpected, agent capability or health conflicts with the screen, an action stays in review-required state, AD reports success but the vault password update is unconfirmed, the VaultPilot account state disagrees with the provider sign-in selection, or audit evidence is missing. Do not retry sign-in changes until Users, provider selection, and Audit Log agree. Email support@vaultpilot.io with the broad record type, agent health, capability, action type and status, approximate time, and redacted error, without DN, account, password, token, or exported data.

Operator notes

Active Directory records are encrypted vault records with directory context. They are not live AD objects and do not add a general credential-management or PAM layer. Keep provider work in Integrations, execution tracking in Executions, and evidence review in Audit Log.

Related

• Domain dashboard screen
• Integrations screen
• Executions screen
• Audit Log screen
• Active Directory agent
• DC Agent troubleshooting

Back to Documentation →