Credential Checks

Credential Checks connects ShadowMap to your Microsoft Entra ID (formerly Azure AD) tenant so the platform can automatically compare your real directory accounts against credentials recovered from data breaches, stealer logs, and dark web dumps. Instead of eyeballing a feed of leaked emails and guessing which ones are still live employees, ShadowMap tells you which exposed credentials belong to accounts that actually exist in your organization.

Overview

The page is titled Automated Credential Checks in the app and holds a single configuration card, Microsoft Entra ID Configuration, with three fields:

• Client ID — the Application (client) ID of an app registration in your Entra tenant.
• Client Secret — a client secret generated for that app registration.
• Tenant ID — your Entra Directory (tenant) ID.

Enter all three and click Update Configuration to store them. There is exactly one Credential Checks configuration per company account — saving again overwrites the existing one (it does not create a second entry). Once stored, ShadowMap uses these credentials to read your directory and reconcile it against the leaked-credential data it already collects.

Administrator only

Credential Checks is restricted to administrators (account owners and admins). Members and read-only roles are redirected to the dashboard if they try to open the page, and the backend rejects both read and write attempts from non-admin users. See Roles & Permissions.

How it works

The mechanics here are mostly invisible from the form itself, so they are worth spelling out.

What ShadowMap does with the credentials. The Client ID, Client Secret, and Tenant ID together describe an OAuth app registration that ShadowMap uses to authenticate to the Microsoft Graph / Entra ID API for your tenant. With that access, ShadowMap can enumerate the user accounts in your directory and then cross-reference them against the credentials it has already harvested from the dark web — the same exposure data that surfaces in Leaked Credentials, Stealer Logs, and Data Breaches. The output is a higher-confidence answer to the question that matters most: of all the leaked credentials we found, which ones correspond to a user who is actually a live account in your tenant right now?

Why this is different from passive leak monitoring. Without this integration, ShadowMap still finds leaked credentials by matching against your monitored domains. But a leaked [email protected] could be a former employee, a typo, a shared mailbox, or a fabricated address in a combo list. By reconciling against your live directory, ShadowMap filters the noise down to credentials tied to accounts that exist and can still authenticate — the ones an attacker could actually use for account takeover.

One configuration per account. The settings are stored against your company, not per user. Whoever last saves the form sets the credentials for the whole account.

The secret is write-only. When the page loads, ShadowMap fetches the saved configuration but never returns the Client Secret — the secret field is hidden by the backend and comes back blank. You will see the Client ID and Tenant ID populate, but the secret box stays empty. This is intentional: the secret is stored, just not displayed. To rotate it, type a new secret and save; leaving it blank and saving will fail validation because all three fields are required.

Required-field validation. Both the page and the backend require all three fields. If any is empty, the page shows a "Please fill in…" error listing the missing fields and does not submit. The server independently re-validates, so a partial save cannot slip through.

No connection test on this page. Saving stores the credentials; it does not perform a live test handshake against Entra from this form. If the credentials are wrong or the app registration lacks the right permissions, you will not see an error here — the failure surfaces later, when the credential-check job runs and cannot read your directory. Double-check the values against the Azure portal before relying on the results.

Prerequisites & setup

Credential Checks needs an Entra ID app registration with permission to read your directory's users. The typical setup, performed by an administrator in the Microsoft Entra admin center (or Azure portal), is:

1. Register an application. In Entra ID, go to App registrations → New registration. Give it a name (for example, ShadowMap Credential Checks) and register it. This is a non-interactive, application-only integration — no redirect URI is needed for client-credentials use.
2. Copy the identifiers. On the app's Overview page, copy the Application (client) ID and the Directory (tenant) ID. These map to the Client ID and Tenant ID fields in ShadowMap.
3. Create a client secret. Under Certificates & secrets → Client secrets → New client secret, create a secret, set an expiry, and copy its Value immediately (Entra only shows it once). This maps to the Client Secret field in ShadowMap.
4. Grant directory-read permission. Under API permissions, add a Microsoft Graph application permission that lets the app read user accounts (for example, User.Read.All / Directory.Read.All), then Grant admin consent so the permission is active tenant-wide. Confirm the exact scope with your ShadowMap contact, as required permissions can change.
5. Enter the values in ShadowMap. On this page, paste the Client ID, Client Secret, and Tenant ID, then click Update Configuration. A "Configuration updated" toast confirms the save.

Secrets expire

Entra client secrets have an expiry date. When a secret expires, credential checks stop working silently — there is no test on this page to warn you. Track the expiry, and when you rotate the secret in Entra, paste the new value here and save again. Use the visibility toggle (the eye icon) to confirm you pasted the secret correctly before saving.

Least privilege

The app registration only needs to read your directory's users for reconciliation. Grant read-only Graph permissions; do not assign write, password-reset, or privileged roles to this app.

Field reference

Field	Maps to (Entra)	Stored as	Notes
Client ID	Application (client) ID	client_id	Returned and displayed on page load.
Client Secret	Client secret Value	client_secret	Write-only — never returned; field stays blank on load. Required on every save.
Tenant ID	Directory (tenant) ID	tenant_id	Returned and displayed on page load.

All three fields are required. Saving with any field blank fails validation on both the page and the server.

Common questions

Do I need this if I already see leaked credentials in ShadowMap? No — leaked-credential monitoring works without it. Credential Checks is an enrichment layer: it tells you which of those leaked credentials belong to accounts that still exist in your live Entra directory, so you can prioritize forced resets for real, active users instead of triaging noise.

Why is the Client Secret field empty even though I saved it? That is expected. ShadowMap stores the secret but never sends it back to the browser, so the field is always blank when the page loads. The Client ID and Tenant ID do load. To change the secret, type a new value and save.

Can I save just the Client ID and Tenant ID and leave the secret blank? No. All three fields are required on every save. If you only want to update the Client ID or Tenant ID, you must re-enter the Client Secret at the same time.

Who can configure this? Only administrators (account owners and admins). Other roles cannot open the page or read/write the configuration through the API.

Is this the same as connecting a cloud source? No. Cloud Sources connect cloud provider accounts (AWS, Azure, GCP) so ShadowMap can discover assets in your cloud estate. Credential Checks connects your Entra ID directory specifically to reconcile user accounts against leaked credentials. They are separate integrations with separate purposes.

What happens if my credentials are wrong or the secret expires? The save still succeeds (this page does not test the connection). The failure shows up later when the credential-check job cannot authenticate to your tenant. If your reconciled results stop updating, verify the app registration's permissions and secret expiry in Entra and re-save fresh credentials here.

Does this give ShadowMap the ability to change accounts or reset passwords? Only if you grant it. ShadowMap needs read access to enumerate your directory users; grant least-privilege, read-only Graph permissions. Do not assign write or password-management permissions to the app registration.

Related

• Leaked Credentials — the feed of exposed credentials that Credential Checks reconciles against your live directory.
• Stealer Logs — infostealer-harvested credentials, a primary source of the exposures matched against your accounts.
• Data Breaches — third-party breach corpora that also feed the credential exposure data.
• Compromised Computers — devices whose stealer logs may contain your employees' credentials.
• Cloud Sources — the related but distinct integration for connecting cloud provider accounts for asset discovery.
• Integrations — sibling settings page for notification and ticketing connectors (Slack, Jira, and others).
• Roles & Permissions — why this page is administrator-only.