Directory accounts

Directory is now part of People

From 0.17.1 there is no separate Directory screen. Searching accounts across every directory connection is the Accounts view of People, at /people?view=accounts, and a person’s live account is on the Account & groups tab of their page. Old /directory links, including those on tickets, open the Accounts view with their search and ticket. This page remains the reference for what each provider supports and what each action needs.

The Account & groups tab on a person’s page needs module.directory, identity.view and an enabled, configured directory connector. Provider data is fetched live and is not saved as an identity inventory in Plugboard. Unavailable data is labelled; the pane does not substitute demonstration records. See Microsoft app registrations for background authentication and customer consent; Plugboard SSO is a separate setup.

What is actually live

Choosing a source in 0.14.0

Select the named directory instance before searching or opening an account. The person identity pane also offers a source selector, and confirmations name the selected source. Switching sources clears the previous account and actions.

For campus-scoped access, a district administrator with directory.manage must confirm the provider account against the local person. The current campus coverage and linked provider ID are checked again when the account is used; an email address alone does not establish access. Account links do not merge people or configure sign-in. Unlinking and reconciliation remain separate work.

When multiple directories are configured, a provider sign-out does not infer which local Plugboard login to revoke by email. The result identifies when local session revocation was skipped. Handle local sessions separately.

These source controls do not change the live and demonstration boundaries below. See multiple instances.

Provider support

Capability	Microsoft Entra	Google Workspace	Active Directory
Account state, sign-in history, authentication posture	Supported, subject to API permissions	Supported, with Google-specific detail	Unsupported
Conditional Access policies	Supported	Unsupported	Unsupported
Licence assignments and waste reports	Supported	Supported, subject to available licensing APIs	Unsupported
Reset registered MFA methods	Supported	Unsupported	Unsupported
Enable / disable account	Supported	Supported	Unsupported
Revoke sessions	Supported	Supported	Unsupported
Assign / remove licence	Supported	Unsupported	Unsupported
Reset password	Supported	Unsupported	Unsupported
Direct Full Access / delegation revocation	Opt-in in 0.12.0-rc.3 source; live Send As grants blocked	Unsupported	Unsupported

Google authentication posture is not an Entra-style list of registered methods, and Google licence assignment counts are not purchased-seat entitlements. See software contracts for the candidate’s commercial register.

Guarded actions

Live identity writes ask for a typed account confirmation, a reason and step-up authentication. Each action requires its own permission, and its intent is audited before the provider call. A timeout can leave the external outcome uncertain: verify the provider before retrying. These privileged writes are not available through the assistant, MCP or the public REST action catalogue.

Permission	Allows
identity.view	Account state and authentication posture
identity.signins.view / identity.policy.view	Sign-in history / Conditional Access policies
identity.mfa.reset	Reset registered MFA methods
identity.account.manage / identity.account.enable	Disable accounts / additional permission to re-enable
identity.session.revoke	Revoke sessions
identity.license.manage	Assign or remove a licence
identity.password.reset	Reset a password
identity.mailbox.delegate	Candidate: direct mailbox-permission revocations; Send As grants blocked
identity.mailbox.fullaccess	Candidate: additional permission for Full Access grants

The Exchange guide describes the five-command role, corrected Full Access pilot and two failed Send As boundary tests. Full Access and authorised revocations require acceptance of the deployed runtime, scope, UI and audit outcomes; Send As grants remain blocked. Check the deployment status.

What you can do

In the Accounts view of People, a live Entra account’s lock, unlock, password reset and licence changes use the guarded identity.* actions above: typed confirmation, a reason and fresh authentication. Every other account uses the older directory.* operations, governed by directory.view and directory.manage. Those operations are demo fixtures only. They refuse when demo mode is off, and configuring live credentials does not make them live.

Inbox delegation in the Accounts view works only on the demo directory. For a live account the delegates are listed read-only; manage delegation from the person’s Account & groups tab.

Every action can be ticketed

An action in the Accounts view is recorded to a ticket, drafted from the Ticket context box or linked automatically when you arrived from a ticket. A demo action logged to a ticket is marked as demo and must not be taken as evidence of a live provider change. Live actions record the confirmed target, technician and reason in the audit log.

Demo mode

demoMode defaults to false. Enabling it permits the demo fixture workflow and makes the live identity pane and writes refuse. It never fabricates live identity data. directory.view and directory.manage govern the Accounts view and its fixture operations; they do not grant the live identity permissions listed above. A demo directory says so at the top of the Accounts view.

Password resets

The person-profile reset is live on Entra. The separate LDAP kiosk flow can reset a person’s own directory password after its verification workflow. Neither makes Google or Active Directory’s legacy directory.resetPassword capability live.

Auditing

Identity reads remain live, while action audit metadata persists: who requested the action, its target, reason and recorded outcome. Passwords and certificate material are not included in that audit record.