Directory Administration

Scope

This guide covers routine directory work: tenant membership, user lifecycle, guest invitations, recovery methods and emergency identities.

Tenant membership

• Add an existing Portal user to a tenant from the tenant list. The user search leaves out people who are already members.
• Member lists are paged. Use the page controls; the first page is not the whole list.
• Portal refuses any change that would leave a tenant with no super user. Promote a successor first.
• If a tenant’s only administrator leaves with no successor, recovery needs an approved support access request. The person who requests it cannot approve it.

Suspending and deactivating users

Suspend or deactivate from the user’s page. Both revoke every session in every tenant at once. When you know a leave or termination date in advance, set it under Scheduled offboarding in the user editor. Reactivation restores sign-in only.

Guest invitations

1. Open Guest Access and select Invite Guest.
2. Enter the recipient’s email address.
3. Check the delivery state in the list. If the email failed, copy the one-time token from the banner, or reissue the invitation. Reissuing replaces the token and resets its expiry.
4. Revoke the invitation or grant when the guest should lose access.

Accepting an invitation creates an access grant in your tenant. Guests have no administrative rights unless you grant delegated administration and choose its permission bundles. A delegated guest administrator cannot change the tenant’s sign-in policy.

Limits: a tenant can send 100 invitations in any 24 hours. The same person cannot be invited to the same tenant again within 15 minutes. A pending invitation can be reissued five times.

An expired, revoked or used invitation link shows the same generic page, which does not reveal the tenant or recipient. Use the Guest Access filters to troubleshoot delivery.

Recovery codes and passkeys

• Users generate recovery codes in My Profile after MFA is on. Portal shows the codes once. A new set revokes the old one, and each code works once.
• Recovery codes are a fallback and do not count as phishing-resistant sign-in.
• Users enroll passkeys in My Profile once MFA is on. An enrolled passkey can be the first factor at sign-in.
• Revoking a passkey or disabling MFA ends the user’s active sessions.
• An administrator MFA reset revokes the user’s passkeys and recovery codes. A self-service password reset keeps them, unless the user proves a second factor and chooses to remove them.

Emergency recovery identities

Emergency identities are operator accounts kept for when normal sign-in is unavailable.

• Keep at least two, with credentials held by different custodians outside everyday tools.
• Create one from Users in the operator tenant with Emergency Identity turned on. It is always a super user.
• Normal sign-in, self-service password and MFA changes, and administrator resets are blocked for these accounts. They sign in only through Emergency Recovery Access, which works even when the tenant requires federated sign-in.
• To rotate one, create and test a replacement, update the custody records, then deactivate the old identity. Do not reset an emergency identity in place, and do not convert a personal account into one.