7 lessons worth learning about account administration features

The useful way to read a feature list in this category is to turn it into questions the console has to be able to answer. A directory product is worth what it can tell you, and worth nothing for the things it merely stores.

There are eight questions. If a product can answer all of them quickly, without a support case, the feature list has done its job. If it cannot answer three of them, no amount of dashboard will help.

What to take away

Eight questions the console must answer

Take that table into a demonstration and ask for each answer live. It is a more informative twenty minutes than any prepared walkthrough.

Lifecycle features, which are the point

Creating accounts is easy. The features worth paying for are the ones that handle change and departure.

Provisioning comes from a source of truth, usually the human resources system, so a new joiner gets the right access instead of a copy of a colleague's. Role-based assignment means a move removes old access rather than adding new.

Time-bounded access is the single most useful feature for anyone who works with contractors because it expires without a human remembering. Deprovisioning must reach every connected system rather than the directory alone.

Test the middle two. Adding access is demonstrated everywhere and removing it is demonstrated nowhere, and removal is where organizations accumulate their real exposure.

Sessions and revocation

This is the feature most often assumed and least often verified. When an account is suspended, what happens to a browser session already open on a laptop at home, or a mail application holding a token?

Ask specifically whether an administrator can terminate active sessions, whether that reaches applications connected through single sign on, and how long a token remains valid if it cannot be revoked directly. Then test it: sign in on a second device, suspend the account from the console, and see how long the second device keeps working.

Continuous access checks, not a single check at the door, are where the field has moved. The standards body's security control catalog sets out the reasoning at length: its control families treat session termination as its own requirement, not a side effect of account status.

Business email security depends on the same session controls. Account takeover usually starts with a token that was never revoked.

Conditional rules, used sparingly

Most products can vary access by conditions: device, location, network, or the sensitivity of what is being reached. Used well, this is the feature that lets you require less friction for ordinary work and more for administrative work.

Used badly, it produces a rule set nobody understands and a helpdesk queue. Three principles keep it sane. Write fewer rules than you think you need. Make every rule explainable in one sentence to the person it blocks. And check what each rule does to somebody traveling, because that is where the false blocks appear.

Where devices are part of the condition, the settings involved are their own discipline, and the guidance on device policies and settings is a practical reference for deciding which ones are worth enforcing rather than merely available.

Reporting and export

Two features, and they are not the same.

A report is something the console displays. An export is a file you hold. For anything that might be evidence, you want the second, produced by you, on demand, without asking anyone. Ask whether every list in the console can be exported, in what format, and whether the export includes the fields shown or a reduced set.

Then ask about the access record itself: how far back it goes, whether that is configurable, and whether it can be sent continuously somewhere else. The last one is the answer to expensive in product retention.

Features that are less important than they look

Directory synchronization is essential if you have two directories and irrelevant if you have one, so establish which you are before weighing it. A large catalog of pre built connectors is impressive, but it only matters for the specific applications on your list.

Self service password reset is genuinely useful, but check its recovery path. A reset flow that depends on a factor the person just lost causes most support calls.

Where this fits

The category overview sets out how the estate ends up shaped this way. The evaluation drill turns the questions above into a timed test.

Most features here sit above the entry tier, which the cost model covers. If the estate is small, the cheaper arrangements may answer the same eight questions with a list and a review date.

Common questions

How many administrators should we have?

More than one and fewer than you would guess. One is a single point of failure and a bad day waiting to happen. The number that matters more is how many people hold the highest level of rights, and that number should be small, named, and reviewed.

Is single sign on worth it if only half our systems support it?

Usually yes, because the half that supports it is normally the half holding the most sensitive material. Just be clear that the other half still needs credentials managed some other way, and that your leaver checklist has to cover both.

Should access reviews be quarterly?

Quarterly for anything with elevated rights, annually for the rest, and immediately whenever somebody changes role. The interval matters less than whether the review results in removals. A review where nothing is removed is a review that was not done.

What does good look like for a fifty person organization?

One directory that most systems trust, groups matching a handful of named roles, strong authentication everywhere with a documented recovery path, time bounded access for anyone outside the organization, and a leaver checklist that somebody actually runs. Everything beyond that is refinement.