Skip to main content

Users without AD

The Users without AD screen lists every account known to a connected application that cannot be matched to a corporate LDAP / Active Directory entry. One line per (Application, User) pair.

The match runs against two AD attributes: the Description (typically the HR matricule) and the samAccountName (the Windows login). When neither resolves to an AD entry, the row lands here.

At a glance​

Nomasx-1 · Security · LDAP · Users without ADAPPUSERUSER NAMESTATUSREGISTRATIONCREATEDLAST LOGIN12SVC_BATCHBatch service accountActive—2017-04-022026-05-1412FORMER_JDOEJohn Doe (left)Active2007142014-02-102024-09-1212CONSULT.XExternal consultant XActive—2024-01-152026-04-303 EXPECTED PROFILESTechnical / batch accounts (no AD by design), externally-managed identities (consultants, AD not synced), accounts of leavers whose AD entry was already removed.

Goal of the view​

For every account that exists in a source system but does not exist in the corporate directory:

  • Is it a legitimate technical account? Batch users, service accounts, integration logins are typically not provisioned in AD by design. Mark them in Settings → Users properties so they stop being flagged.
  • Is it an externally-managed identity? Consultants whose AD is the consulting firm's, not the customer's, also land here. Same treatment — declare them as such once.
  • Is it a ghost account? A real human, no AD entry, recent login. That is the row that must be investigated — the AD entry was probably removed at offboarding without the corresponding source-system account being deactivated.

The screen is the cleanest leavers-process audit available: every row is a potential offboarding gap.

Columns​

ColumnSourceWhat it tells you
Application IDUSR_APPS_ID — application identifier from the source system.The application the unmatched account belongs to.
User IDUSR_ID — user identifier.The technical login that has no AD match.
User NameUSR_NAME — display name.Human-readable name.
StatusUSR_STATUS — 01 means Active.Active accounts surface here first; an inactive account without AD is normal (offboarding completed cleanly).
RegistrationUSR_REGISTRATION — HR matricule stored in the source system.The field the LDAP join uses against the AD Description attribute. Empty / wrong values are the main cause of false positives.
Creation DateUSR_DT_CREATION — date.When the account was created — old account + recent login = ghost candidate.
Login DateUSR_DT_LOGIN — date.Last authentication. Drives the urgency.

Tips & best practices​

  • Sort by Last Login descending to find ghosts first — a recent login with no AD entry is the most urgent row.
  • Empty Registration is the first thing to check — if the HR matricule is missing on the source-system account, the LDAP join can never succeed even though the person exists in AD. Populate the registration field in the source system and re-scan.
  • Declare known-good technical accounts via the Settings → Users properties screen so they stop appearing here. The recurring exception list shortens, the real ghosts stand out.
  • Cross-reference with the AD admin — if a row corresponds to a known person whose AD entry was removed yesterday, that is the proof that the offboarding workflow needs to also touch the source system.