---

name: identity-provider-recon description: "Organization-grade identity-fabric mapping: tenant/federation fingerprinting and the pre-auth user-ENUMERATION oracle methodology — enumeration and fingerprint only, never credential submission. Covers domain-to-tenant resolution (Microsoft getuserrealm.srf Managed/Federated namespace check, Entra OIDC metadata tenant-GUID extraction, Autodiscover v2), keyless Microsoft tenant-federation mapping (GetFederationInformation SOAP -> sibling-domain discovery, discover-only ROE, FEDERATED_WITH provenance edge held out of attack-path pivoting), Okta org-slug derivation + OIDC fingerprint + governed custom-domain enumeration, ADFS passive/active fingerprint + version inference, Google Workspace MX-correlated detection, generic OIDC (Auth0/Keycloak/Ping Identity/OneLogin/Duo) discovery, SAML metadata (5 paths), Azure AD Seamless-SSO Negotiate-challenge detection, Microsoft Defender for Identity (MDI) sensor-API presence check, the user-enumeration oracle methodology for Microsoft GetCredentialType (IfExistsResult semantics: exists / doesn't-exist / exists-in-federated-tenant / throttled) and Okta /api/v1/authn (errorCode differential), Medium-detectability discipline with a hard 20-candidate-per-tenant cap and admin/role interest-based ranking, and name x confirmed-email-pattern login-candidate synthesis that FAILS CLOSED with zero output when no org pattern is confirmed. Grounded directly in a production ASM implementation's sso_idp.py, tenant_recon.py, and core/email_patterns.py modules. Deepens — does not duplicate — offensive-osint skill's Identity Fabric endpoint reference with the tenant-federation MAP, the oracle WORKFLOW, and the candidate-SYNTHESIS methodology that reference lacks. Use when fingerprinting an organization's identity provider, mapping its tenant/federation boundary, running an authorized pre-auth user-enumeration pass, or synthesizing login candidates from harvested names to feed that oracle — never for password spray, credential submission, or auth bypass." version: 1.0 sources: asm_reference_impl, public_research triggers:

• identity fabric
• identity provider recon
• IdP recon
• IdP fingerprinting
• tenant fingerprinting
• tenant recon
• SSO discovery
• SSO fingerprinting
• federation mapping
• federation boundary
• tenant federation map
• domain to tenant resolution
• GetFederationInformation
• M365 tenant federation
• Entra tenant recon
• Azure AD tenant recon
• Azure AD enum
• entra enum
• getuserrealm
• Managed vs Federated namespace
• okta enum
• Okta org slug
• Okta governed domains
• Okta OIE vs Classic
• ADFS enum
• ADFS version fingerprint
• ADFS mex endpoint
• Google Workspace enum
• SAML metadata discovery
• generic OIDC discovery
• Auth0 fingerprint
• Keycloak fingerprint
• tenant GUID extraction
• Seamless SSO detection
• Azure AD Seamless SSO
• AZUREADSSOACC
• MDI presence
• Defender for Identity detection
• user enumeration oracle
• account existence enumeration
• pre-auth user enum
• GetCredentialType
• IfExistsResult
• Okta authn enum
• authn endpoint enumeration
• credential type endpoint
• user enum detectability
• email pattern synthesis
• login candidate synthesis
• login candidate list
• name to email pattern
• sibling tenant domains
• federated sibling domain
• fail closed synthesis
• identity fabric mapping

---

Identity-Provider Recon — Tenant, Federation & User-Enumeration Oracle Mapping

Companion skills: osint-methodology (§6.2 detectability tagging, §11 identity-fabric pointer — the "how to think" skill this plugs into) and offensive-osint (§22 Identity Fabric — the concrete endpoint/payload reference this skill builds a workflow on top of, rather than re-listing). This skill answers the question those two don't: how do the tenant, its federation partners, its IdP, and its user-enumeration oracle fit together as one map — and where exactly enumeration stops and credential submission begins.

0. When to Use / When NOT

Use this skill when:

• You need to resolve a domain to its identity tenant (Entra/Okta/ADFS/Google Workspace) and determine whether auth is Managed or Federated.
• You need to map an org's federation boundary — every sibling domain that shares the same M365/Azure AD tenant trust, not just the seed.
• You need to distinguish Entra vs. Okta vs. ADFS vs. Google Workspace vs. a generic OIDC IdP from passive/low-detectability signals.
• You need to detect Seamless SSO or Microsoft Defender for Identity (MDI) presence — both change the risk calculus of anything downstream.
• You have authorization for a Medium-detectability, log-generating pass and need to run a pre-auth user-enumeration oracle (GetCredentialType / Okta /api/v1/authn) to build a valid-account list — without ever submitting a password.
• You have harvested employee names and a confirmed org email-format pattern and need to synthesize ranked login candidates to feed that oracle.

Do NOT use this skill when:

• You need to submit credentials, replay breach creds, forge/replay a token, or confirm an auth-bypass — that is a different, higher-authorization tier. See §14.
• The target's authorization for active, logged probing isn't established — the passive half of this skill (§7–§10) needs the same soft-scope posture as every companion skill; the active half (§11) needs it explicitly, because it generates tenant-side audit-log events (§1, §11.4).
• You already have concrete endpoints and just need the reference table — go straight to offensive-osint §22.

---

1. Authorization & Legal Posture

Same base posture as osint-methodology §1: intended for assets the operator owns or has written authorization to assess.

This skill carries a sharper posture than most of the pack because §11 is not passive. Every domain-resolution, federation, IdP-fingerprint, Seamless-SSO, and MDI probe in §7–§10 is Low detectability (a metadata GET/POST that any browser makes) — but the user-enumeration oracle in §11 is Medium detectability: it is a targeted, per-account POST against a live authentication endpoint, and both Microsoft and Okta log it in the tenant's own sign-in/audit trail. Treat §7–§10 and §11 as two separate authorization tiers even within one engagement.

Soft scope check — ask once before running §11:

"I can build a valid-account list by probing Microsoft/Okta's pre-auth user-existence oracle. This never submits a password, but it IS logged in the tenant's own audit trail and is rate-limited on my end to stay under the radar. Confirm you want me to run this active pass?"

Always-on guardrails specific to this skill:

• Never submit a real password, a guessed password, or any credential to any login endpoint. §11's oracles work by reading the shape of a rejection (§11.2, §11.3), not by trying to succeed.
• Cap user-enumeration at 20 candidates per tenant (§11.4) — this is not a suggestion, it is the production cap in the module this skill is grounded in.
• A discover_only federated sibling domain (§8) is a lead, never a target. Confirm ownership before extending §7–§11 to it.
• Nothing in this skill authorizes §14's excluded techniques, no matter how interesting the oracle results look.

---

2. Confidence Levels

Same three-tier model as the companion skills, applied to identity-fabric assertions:

| Level | Meaning | Identity-fabric example | |---|---|---| | TENTATIVE | Plausible, unverified. | Okta org-slug guess ({stem}-prod.okta.com) not yet confirmed by a live OIDC response; an 8-permutation passive email guess (core/email_patterns.infer_patterns_for_name) for enrichment only. | | FIRM | Directly observed, single probe. | getuserrealm.srf returns NameSpaceType=Federated; ADFS idpinitiatedsignon.aspx returns a version-identifiable body; Seamless-SSO Negotiate 401 observed once. | | CONFIRMED | Independently corroborated or an oracle differential fired. | Entra tenant GUID extracted from OIDC issuer AND matched by a second probe (getuserrealm/autodiscover); an Okta org's OIDC issuer contains okta.com (self-corroborating — the provider's own metadata endpoint answered); a GetCredentialType/Okta-authn oracle differential fired for a specific address (§11) — direct verification, not inference. |

Rule of three still applies to anything you'd report as organizational fact ("this org uses Entra") beyond a single tenant-level metadata hit — a single OIDC response is enough to say "an Entra tenant answers for this domain," but attributing that tenant to a specific subsidiary or brand needs the same corroboration discipline as org-attack-surface §2.

---

3. Output Format

Standard Finding schema (companion skill §3), with category: SSO_EXPOSURE for every identity-fabric finding in this skill — that is the category the reference implementation this skill is grounded in uses uniformly, from an INFO tenant-identified breadcrumb through a LOW confirmed-user-enumeration result:

Finding:
  id:          <stable hash>
  module:      identity-provider-recon
  asset_key:   svc:0.0.0.0:443:<product>      # tenant SERVICE asset key pattern — see §7.9
  category:    SSO_EXPOSURE
  severity:    <info|low|medium|high|critical>   # see per-section severity notes below
  confidence:  <tentative|firm|confirmed>
  title:       <one-line summary>
  description: <2-5 sentences>
  evidence:
    url:               <probe endpoint hit>
    timestamp:         <UTC ISO8601>
    discovery_method:  <oidc_metadata|getuserrealm|autodiscover|okta_oidc|adfs|saml_metadata|
                         workspace_mx|mx_inference|tenant_federation|seamless_sso|mdi_presence|
                         user_enum_microsoft|user_enum_okta>
    tenant_id:         <GUID / org slug / entity_id, when known>
  references:  [<AADInternals, MITRE ATT&CK technique, vendor doc>]
  remediation: <action the tenant owner can take>

UTC timestamps everywhere. For §11 oracle results specifically, the evidence block MUST carry probed_count, the enumerated address list(s) split by outcome, and — critically — a credential_submitted: false marker, so a downstream reader (or auditor) can never mistake an enumeration result for a proven-live credential.

---

4. Source Hygiene & Citations

Same discipline as the companion skills: URL + UTC timestamp + tool version + run_id on every artifact.

• Record the exact request body sent to GetCredentialType / Okta authn, not just "I probed the endpoint" — the oracle's entire evidentiary value is in the response differential, which is worthless without the paired request.
• Cache raw SOAP/JSON responses from GetFederationInformation, OIDC metadata, and getuserrealm.srf — these are the primary evidence for the tenant-federation map and should survive a re-run months later even if the live tenant configuration has since changed.
• Never log a probed password value in any artifact, even the fixed placeholder Okta's authn oracle requires (§11.3) — redact it in stored evidence as <oracle-placeholder>.

---

5. Do NOT

• Do NOT submit a real, guessed, or breach-sourced password to any login endpoint under this skill. §11's oracles are read-only-by-design: Microsoft's GetCredentialType and Okta's /api/v1/authn both reveal account existence from the shape of a rejection, never from a successful login.
• Do NOT exceed the 20-candidate-per-tenant cap on user enumeration (§11.4).
• Do NOT auto-promote a discover_only federated sibling domain (§8) into active scope. Confirm ownership first.
• Do NOT treat a STRONG-looking Okta-org-slug guess as confirmed until its own OIDC metadata answers and its issuer field actually contains okta.com (§7.4) — a guessed slug that happ