Active Directory

Clarity Transform reads computer and user objects from Active Directory over LDAP, to seed physical Windows servers into the inventory and enrich identity data.

Where to find it

Go to Discover → Integrations, then select the Active Directory card. The card's category label is Identity. The integration's page has the Endpoints and History tabs; Integrations describes the page, its grid and its row actions.

Why we do this

A hypervisor tells you about virtual machines. Active Directory is frequently the only complete list of the physical Windows servers in an estate, which is exactly the population that gets missed when discovery starts from the virtualisation platform.

What we collect

• Computer objects, with the organisational unit structure they sit in
• User objects, for identity enrichment
• The account state and last-logon information that distinguishes a live server object from a stale one

What it adds

The physical server population.

A computer object is not proof of a running machine

Directories accumulate stale objects. An object whose last logon is two years old is a record of a server that used to exist, and treating the object count as an estate size overstates it, sometimes substantially. Clarity records the state on User records (Account Enabled, Last Logon) in the CMDB, so the distinction can be made rather than assumed.

What is deliberately not inferred

• No passwords and no password hashes.
• No Group Policy contents, and no directory permissions.
• Nothing is written to the directory. No object is created, modified or deleted.
• Domain membership is not a dependency. Two servers in the same domain, or the same organisational unit, are not related by that fact alone.

What we require

An ordinary domain user account. Domain Administrator is not required, and neither is any delegated directory permission: reading computer and user objects is granted to authenticated users by default in a standard directory.

• Interface: LDAP, bound as DOMAIN\username
• Connectivity: the LDAP port from Clarity to a domain controller
• Account: any authenticated domain user

Where a directory has been hardened so that authenticated users cannot read computer objects, a read grant on the organisational units in scope is needed. That is unusual but not rare, and it presents as an empty result rather than an error.

Verification before handover

Run these as the system owner before handing the credential over, so a failed discovery run is never the first time anyone finds out.

1. Confirm the bind succeeds. Bind to a domain controller as the account. The bind uses DOMAIN\username form, so a user principal name that works elsewhere may not work here.
2. Confirm computer objects are readable. Search for computer objects under the naming context. A hardened directory returns an empty result rather than a permission error, so an empty search is a permission question rather than an empty directory.
3. Confirm the domain controller Clarity will use is reachable. Discovery reads from the controller the endpoint names rather than discovering one, so that specific host needs to be reachable and to stay reachable.

Configuring the endpoint

On the integration's Endpoints tab, select the add icon (Create New Integration Endpoints). The Create new entry form opens with these fields, in this order:

Field	Value
Name	A name for the endpoint
End Point	A domain controller hostname
Credential	The stored credential for the domain account, as DOMAIN\username
Job Schedule	A five-field cron expression, for example 0 2 * * 0 (weekly). Directory objects change on a provisioning cadence
Enabled	Ticked. The box is unticked when the form opens

The help texts: End Point "FQDN or IP Address of management system for technology e.g. vCenter, Nutanix Prism"; Credential "Credentials can be configured under Settings/Identity and Access Management/Credentials."; Job Schedule "Cron schedule – Use five fields: 〈mm〉 〈hh〉 〈day-of-month〉 〈month〉 〈weekday〉".

The Credential list offers the credentials stored under Settings → Identity & Access Management → Credentials, so create the credential there first.

No field is marked as required. Technology is set by the card and is hidden in the form. Select Save to create the endpoint, or Cancel to close the form. The edit icon opens the same fields as Edit entry.

Removing the access

Disable or delete the domain account. Nothing was written to the directory, so there is nothing to undo. Then, in Clarity, remove the endpoint (select its row on the Endpoints tab, then Remove selected) or clear its Enabled box, and remove the credential under Settings → Identity & Access Management → Credentials.

Troubleshooting

Symptom	Cause
The bind fails with a credential that works elsewhere	The bind needs DOMAIN\username form rather than a user principal name.
An empty result rather than an error	The directory has been hardened so authenticated users cannot read the objects. A read grant on the organisational units in scope is needed.
More servers than the estate actually has	Stale computer objects. Check Last Seen on Device records or Last Logon on User records in the CMDB before treating the object count as an estate size.
Cannot reach the directory	The endpoint names one domain controller rather than discovering one. That host must be reachable from Clarity.