The inventory was correct on the day it was written
Privileged accounts get created constantly, by people acting reasonably.
| Where they come from | Why nobody records it |
|---|---|
| Server builds | Each one gets a local administrator account, created during the build and never mentioned again |
| Migrations and projects | An account is created with broad rights “for the cutover”. The cutover succeeds, the project closes, the account stays |
| Applications | Installers create service accounts and grant them what they need. The grant is in the installation guide, not in your directory design |
| Nested groups | A group is added to a group for an unrelated reason and quietly confers administrator on everyone in it. Nobody added a person to Domain Admins, and yet |
| Appliances and OT equipment | Local accounts on a firewall, a SAN, an HMI, a robot controller. No directory has ever seen them |
| Vendor support | Accounts created during an incident, at speed, by people who then went home |
Every one of those is defensible on the day it happens. The list drifts anyway, and it drifts faster than a quarterly review closes the gap.
An access review can only ask about accounts somebody already knows exist.
The half your directory can answer, and the half it can’t
Worth separating, because the two need different tools and only one of them is a product question.
Your directory can already tell you about domain accounts. Recursive membership of privileged groups, accounts with old privilege still flagged on them, accounts with delegation or password flags that shouldn’t be set. Built-in tooling reports all of it, and you should run it — recursive membership especially, because direct membership is not membership.
What no directory report can see is what exists locally on a member server. The local administrator account created during a build. The account somebody added directly to the local Administrators group instead of through a domain group. These appear in no group audit, survive every leaver process, and expire never.
How many Windows servers do you have, and how many local administrator accounts exist across them?
The first number takes minutes. The second almost never does — and the second is the one an attacker will be working from.
What Mirket discovers
Point it at the domain and it imports the servers joined to it, and the local accounts on those servers. That is the half the directory cannot answer, read directly from the machines themselves.
- Servers Hostname, IP address, operating system, OU — and reachability by both ping and WinRM. Filterable by OS version, by whether they answer, and by discovery status, before anything is imported.
- Accounts Account name, username, the server it lives on, enabled or not, group membership, and last logon. That last column is what separates the accounts in use from the ones nobody ever closed.
Configuration is deliberately small: a name, the LDAP address and port of the domain, an account to read with, and a schedule. It is the one place in the platform that talks to the directory directly, and it stands apart from everything else.
It runs on a schedule, which is what makes it an inventory
A one-off assessment measures a moment. The gap between assessments is where new privilege appears, and nothing in most environments schedules the second run.
Discovery repeats daily, weekly, monthly, every N hours, every N minutes, or on a custom cron expression when it has to line up with something else you already run.
That changes what the result is. Not a document describing the estate as it was in March, but a view of the estate as it is — which is the only version worth acting on.
Reachability is part of the answer, not a footnote
Most inventories tell you what exists. Rather less useful than knowing what you can do something about.
Each discovered server carries whether it answers ping and whether it answers WinRM, because those two decide which pile a finding goes into: a machine you can bring under management this afternoon, one that needs a network or configuration change first, or one that nobody can reach at all — which is its own finding.
Filtering on that before importing is what stops a discovery run from becoming a spreadsheet nobody opens.
Finding and managing are the same action
This is where most discovery programmes end. A list of four hundred accounts arrives at a team with no mechanism to act on it, so it gets filed, and the next assessment produces a longer one.
Because discovery and the control are the same platform, a discovered server is imported as an asset and its accounts come in with it. From that moment they are inside account mapping, session policy, credential injection and rotation, and recording.
No export, no ticket, no handoff to a second project. What you found is managed in the place you found it.
The first thing to do with the result
Sort the accounts by last logon, oldest first.
Accounts that are enabled, privileged and unused are the highest-value, lowest-risk work available anywhere in this subject: nothing depends on them, so disabling them breaks nothing — and every one removed is a credential that can no longer be stolen.
Who can reach what, right now
The access matrix answers the question the inventory was being built for: who can reach which system, with which account, as things currently stand.
Not as they were documented, and not as they were at the last review. That distinction is the difference between an inventory and an answer.
What changes with Mirket
| Before | With Mirket |
|---|---|
| A spreadsheet from an assessment, accurate for about a month | A scan that repeats on a schedule you choose |
| Domain accounts only | The local accounts on every domain-joined server as well |
| “Is this host even reachable?” is a separate investigation | Ping and WinRM are columns in the result |
| Findings arrive as a report | Findings arrive as assets you can import |
| “How many privileged accounts exist?” is unanswerable | It is a screen |
| Dormant privileged accounts stay enabled indefinitely | They sort to the top by last logon |
| Who can reach what is reconstructed from documents | It is a matrix, as things currently stand |
Frequently asked questions
What is privileged account discovery?
Finding the accounts in an environment that can administer something, including the ones no directory manages. The directory half is reportable with built-in tooling. The half that is not — local accounts sitting on individual servers — is where discovery earns its place.
What does Mirket discover?
Servers joined to the domain, and the local accounts on those servers. Servers come back with hostname, IP address, operating system, OU, and reachability by both ping and WinRM. Accounts come back with account name, username, the server they sit on, whether they are enabled, group membership and last logon.
Why do local administrator accounts matter so much?
They appear in no directory report, they are not covered by a leaver process, and nothing expires them. An account created during a build in 2019 is still there, still enabled, and still holds administrative rights on that machine — and nobody has a list.
Doesn't my directory already report on privileged accounts?
For domain accounts, yes, and you should use it — recursive group membership in particular, because direct membership is not membership. What it cannot see, by design, is what exists locally on a member server. Those two halves need different tools.
How often does discovery run?
On whatever schedule suits: daily, weekly, monthly, every N hours, every N minutes, or a custom cron expression when it has to line up with something else you run. That is the difference between an inventory and an assessment.
What is discovery configured with?
A name, the LDAP address and port of the domain, an account to read with, and a schedule. It is the one place in PAM that talks to the directory directly, and it is independent of everything else.
Why does reachability matter in a discovery result?
Because it decides whether a finding is something you can act on or only note. A host that answers ping but not WinRM is a different problem from one that answers neither — and both are different from a server you can bring under management this afternoon.
What is the quickest win from a discovery run?
Sort the accounts by last logon, oldest first. Accounts that are enabled, privileged and unused are the highest-value, lowest-risk work on the list: nothing depends on them, so disabling them breaks nothing, and each one removed is a credential that can no longer be stolen.
What happens after an account is found?
You import it. A discovered server becomes an asset and its accounts come in with it, which puts them inside account mapping, session policy, credential injection, rotation and recording. No export, no ticket, no second project — Privileged Password Vaulting covers what happens once they are in.
Can I narrow the results before importing anything?
Yes. Servers can be filtered by operating system version, by whether they are reachable, and by discovery status. A few thousand results are not a decision until they have been narrowed to the ones that matter.
How do I see who can reach which system?
The access matrix — who can reach which system, with which account, as things currently stand rather than as they were last documented. That is the question the inventory was being built to answer.
Is it available as a service?
No. Discovery is part of Mirket PAM, which runs on your own servers — and it reads your directory and your member servers directly, which is not something to route through anybody's cloud. Deployment covers which modules run where.
Related
Solutions — Privileged Password Vaulting · Just-in-Time Access · RDP & SSH Session Recording · Third-Party & Vendor Access · LDAP Service Account Security
Product — Privileged Access Management
Industries — Manufacturing · Education