/identity-fabric

name: identity-fabric
description: "Concrete endpoints, probes, and enumeration techniques for identity provider fingerprinting and auth surface mapping. Covers Microsoft Entra (Azure AD), Okta, ADFS, Google Workspace, generic OIDC (Keycloak/Auth0/Ping/OneLogin/Duo), SAML metadata, AWS account-ID extraction, Microsoft 365 deep enumeration (Teams/SharePoint/OneDrive/OAuth/Power Platform), GraphQL field-suggestion enumeration when introspection is disabled, and LinkedIn employee enumeration with role prioritization. Use when mapping an org's auth architecture, enumerating SSO/IdP surfaces, or building a target employee list."
when_to_use: "Use when fingerprinting SSO/IdP or tenants, enumerating Okta/Entra/Azure AD/ADFS users (getuserrealm, GetCredentialType), inspecting SAML metadata, running Microsoft 365 deep enumeration (Teams federation, SharePoint, OneDrive, OAuth, Power Platform), GraphQL field-suggestion enumeration, LinkedIn/employee enumeration, or planning device-code phishing."

Identity Fabric — Concrete Endpoints

> Sub-skill of `offensive-osint`. For pipeline and triage context load `osint-methodology`. > Authorized targets only.

BEHAVIORAL CONTRACT

**When triggered:** SSO/IdP fingerprinting, tenant discovery, auth architecture mapping, Microsoft 365 enumeration, Okta/Entra/ADFS probing, OIDC discovery, LinkedIn employee enumeration, or device-code phishing feasibility assessment is needed.

**Execute:**

1. Probe OIDC discovery endpoints (§1.1-1.5) on every alive subdomain and known SSO prefixes (auth._, login._, sso._, idp._, iam._, identity._, accounts._, oauth._). Probe `/.well-known/openid-configuration` on every alive subdomain regardless of prefix. 2. Extract tenant GUIDs from OIDC metadata issuer fields. 3. Run getuserrealm.srf to classify Managed vs Federated (§1.1). 4. If deep mode authorized, run GetCredentialType user-enum capped at 20 attempts (§1.1). Medium detectability. 5. Probe M365 deep surfaces: SharePoint, OneDrive, Teams federation (§1.8). 6. Check device-code phishing feasibility (§1.8). 7. Extract AWS account IDs, OAuth client_ids, and scopes from JSON/HTML/JS (§1.7). 8. For LinkedIn employee enum: use Google dorking (§2.1), prioritize by role tier (§2.2), derive candidate emails (§2.3), output per §2.4 schema. 9. Feed discovered tenants to `people-breach-intel` for SSO_EXPOSURE correlation.

**Output:** Per-tenant and per-person findings. Tenant = asset type `sso_tenant` with GUID. Person = asset type `person` with derived emails at TENTATIVE confidence.

**Severity rules:** SharePoint anonymous share = HIGH. Device-code phishing feasible = MEDIUM. GetCredentialType user-enum success = INFO (asset only, not a vulnerability).

**Gating rules:** GetCredentialType and Okta authn are medium-detectability; cap at 20 per tenant. LinkedIn enum: throttle to <20 profile views/day per persona. For sock-puppet discipline, see `osint-methodology` §6.1.

**Chain to:** Feed tenant list to `people-breach-intel` for SSO_EXPOSURE correlation. Load `osint-methodology` §12 for breach × identity correlation logic. Feed derived emails to `secrets-and-dorks` for breach lookups.

1. Identity Fabric — Concrete Endpoints

Methodology lives in the companion `osint-methodology` skill §11. This is the URL/payload reference.

1.1 Microsoft Entra (Azure AD)

**OIDC metadata + tenant GUID extraction:**

GET https://login.microsoftonline.com/{tenant-or-domain}/.well-known/openid-configuration

Response field `issuer` contains the tenant GUID. GUID regex:

\b[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}\b

Detectability: low.

**getuserrealm.srf — managed vs federated probe:**

GET https://login.microsoftonline.com/getuserrealm.srf?login=<probe-user>@<domain>

Response: JSON with `NameSpaceType` field (`Managed` / `Federated` / `Unknown`). Federated also includes `FederationBrandName` and `AuthURL` (the upstream IdP URL). Detectability: low.

**Autodiscover v2:**

POST https://autodiscover-s.outlook.com/autodiscover/metadata/json/1
Body: {"Email": "<probe-user>@<domain>"}

Returns the protocol endpoint for the user; presence indicates tenant membership. Detectability: low.

**Autodiscover IP correlation (passive M365 confirmation):**

Resolve `autodiscover.<domain>` and check if it lands in Microsoft Exchange Online IP space. This works even when MX is wrapped by Mimecast/Proofpoint/Barracuda inbound filtering, where MX alone doesn't reveal the underlying mail platform.

dig +short A autodiscover.target.example

Resolve-DnsName "autodiscover.$D" -Type A | Select Name,IPAddress

Microsoft Exchange Online IPs (truncated common ranges): `40.96.0.0/13`, `52.96.0.0/14`, `13.107.6.152/31`, `13.107.18.10/31`, `40.99.0.0/16`, `40.104.0.0/15`, `52.98.0.0/15`. Full list: [Office 365 URLs and IP address ranges](https://learn.microsoft.com/en-us/microsoft-365/enterprise/urls-and-ip-address-ranges).

If `autodiscover.<domain>` lands in that space → `M365_CONFIRMED` even when nothing else does. Detectability: low (passive DNS).

**GetCredentialType — user-enum (deep mode only):**

POST https://login.microsoftonline.com/common/GetCredentialType
Content-Type: application/json
Body:
{
  "username": "<email>",
  "isOtherIdpSupported": true,
  "checkPhones": false,
  "isRemoteNGCSupported": true,
  "isCookieBannerShown": false,
  "isFidoSupported": true,
  "originalRequest": "",
  "country": "US",
  "forceotclogin": false,
  "isExternalFederationDisallowed": false,
  "isRemoteConnectSupported": false,
  "federationFlags": 0
}

Response field `IfExistsResult` indicates user existence: `0` = exists, `1` = doesn't exist, `5` = exists in federated tenant. Detectability: medium (logged in tenant audit). Cap at 20 attempts per tenant.

1.2 Okta

**Org slug derivation:** start with stems from discovered subdomains and root-domain stem. Probe `<slug>.okta.com` and `<