7.1. Terms A–Z
Access package — Requestable bundle of resource roles with request/approval/expiration policy; entitlement management's core unit (5.1.1). · Access review — Scheduled attestation of access with configurable auto-apply of removals (5.2). · Access token — Short-lived bearer token presented to a resource API; carries scp/roles (1.4.1, 1.4.3). · Administrative unit (AU) — Container scoping role assignments to a subset of users/groups/devices (3.1.2). · Admin consent — Tenant-wide grant of permissions by an administrator; mandatory for application permissions (4.2.3). · Admin consent workflow — Request-and-approve pipeline for users blocked from consenting (4.2.3). · App registration — The application object/blueprint: audience, redirect URIs, credentials, permissions (4.3.1). · App role — Application-defined role delivered in the token's roles claim (4.2.3, 4.3.2). · Application Proxy — Outbound-connector publishing of on-prem web apps with Entra pre-authentication (4.2.2). · Application permission — App's own standing permission, no user present; client credentials + admin consent (4.3.2). · Authentication context — Taggable label binding stricter CA policy to sensitive resources/actions (2.2.3). · Authentication methods policy — Tenant policy enabling and scoping sign-in methods (2.1.1). · Authentication strength — CA grant control requiring a named set of methods, e.g. phishing-resistant (2.2.1).
B2B collaboration — Guest object + home-tenant authentication for external users (3.3.1). · B2B direct connect — Objectless cross-tenant access for Teams shared channels (3.3.2). · Break-glass account — Permanently active, CA-excluded emergency GA account with vaulted credentials and sign-in alerting (5.3.3).
Catalog — Delegation container of resources from which access packages are built (5.1.1). · Certificate-based authentication (CBA) — X.509 sign-in against Entra; phishing-resistant (2.1.3). · Cloud Sync — Lightweight-agent sync engine; HA by default, multi-forest (3.4.1). · Compliant network check — CA condition verifying traffic transited your GSA tenant (2.4.1). · Conditional Access (CA) — If-then policy engine at token issuance: assignments → conditions → controls (2.2.1). · Connected organization — Registered partner org whose users may request packages (5.1.2). · Connect Health — Monitoring for sync, AD FS, AD DS with alerting (3.4.3). · Connect Sync — Full-featured on-prem sync server; writebacks, custom rules, staging mode (3.4.1). · Continuous access evaluation (CAE) — Event-driven token rejection by capable services (1.4.3, 2.2.2). · Cross-tenant access settings — Per-partner inbound/outbound B2B policy incl. MFA/device trust (3.3.2). · Cross-tenant synchronization — Automated B2B provisioning across owned tenants (3.3.2). · Custom security attributes — Permission-gated attribute sets; even GA needs explicit attribute roles (3.2.2).
Delegated permission — Permission exercised as the signed-in user; effective access is the intersection (4.3.2). · Diagnostic settings — Export pipeline: Log Analytics / storage / Event Hub (5.4.1). · Dynamic group — Rule-based membership, asynchronously evaluated (3.2.1).
Eligible assignment — PIM right-to-activate; no standing power (5.3.1). · Entitlement management — Governed self-service access: catalogs, packages, policies, lifecycle (5.1). · Entra joined — Organization-owned device signed into with Entra credentials (3.2.3). · Entra registered — Personal device with a work account added (3.2.3).
Federated credential — Trust of an external issuer's tokens on a service principal; zero stored secrets (4.1.1). · FIDO2 passkey — Origin-bound key-pair credential; phishing-resistant (2.1.2).
Global Secure Access (GSA) — Entra's SSE: clients, traffic profiles, universal CA (2.4.1). · Group-based licensing — License inheritance via group membership; requires usageLocation (3.2.4). · Guest — userType for externally-homed identities; credentials remain at home (1.2.2, 3.3.1).
Hybrid joined — AD-joined device also registered in Entra via sync (3.2.3).
ID token — OIDC token consumed by the client app to establish the user session (1.4.1). · ID Protection — Risk detection engine: user risk vs sign-in risk feeding policy (2.3.1). · Identity Secure Score — Posture assessment with ranked improvement actions (5.4.2).
KQL — Query language over exported logs in Log Analytics (5.4.2). · Kerberos constrained delegation (KCD) — Connector exchanges Entra identity for Kerberos ticket to on-prem apps (4.2.2).
Managed identity — Azure-fabric-managed service principal; system-assigned (1:1, dies with resource) or user-assigned (standalone, shareable) (4.1.2). · MDCA (Defender for Cloud Apps) — Discovery, catalog, session policing, OAuth app governance (4.4). · My Access portal — Where users request and approvers act on packages (5.1.2).
Named location — Defined IP ranges/countries for CA conditions (2.2.1). · Number matching — Authenticator push anti-fatigue control (2.1.1).
OAuth 2.0 / OIDC — Authorization protocol + identity layer; code flow issues ID/access/refresh tokens (1.4.1). · OAuth app policies — MDCA policies auditing standing consent grants (4.4.3).
Password hash sync (PHS) — Hash-of-hash synced to cloud; sign-in survives on-prem outage (3.4.2). · Password protection — Global + custom banned password lists, extendable on-prem via agents/proxy (2.1.5). · Password writeback — SSPR/user-risk password changes propagated to AD (2.1.4). · Pass-through authentication (PTA) — Outbound agents validate passwords against DCs in real time (3.4.2). · PIM — Privileged Identity Management: eligible/active, activation gates, alerts, audit (5.3). · PIM for Groups — JIT membership/ownership of groups, incl. role-assignable groups (5.3.2). · Private Access — GSA ZTNA to private TCP/UDP resources via client + connectors (2.4.2). · Protected actions — Authentication-context gating of high-risk directory operations (2.2.3). · Provisioning logs — Journal of SCIM/HR/cross-tenant provisioning operations (5.4.1).
Refresh token — Long-lived token redeemed for new access tokens; the policy re-evaluation moment; revocation target (1.4.3). · Report-only mode — CA evaluation-without-enforcement dry run (2.2.4). · Restricted management AU — AU whose members only AU-scoped admins can modify (3.1.2). · Risk (sign-in vs user) — Event probability vs account-compromise probability; MFA vs secure password change (2.3.1). · Role-assignable group — isAssignableToRole group (creation-time flag, assigned membership only) that can hold Entra roles (3.2.1).
SAML — XML federation protocol; IdP-SP trust via signing certificates (1.4.2, 4.2.1). · SCIM provisioning — Automated account lifecycle into SaaS apps (4.2.1). · Seamless SSO — Kerberos-based silent sign-in for domain-joined corporate machines (3.4.2). · Security defaults — Free baseline protections; mutually exclusive with CA (2.1.1). · Service principal — App's local instance/identity in a tenant; the enterprise application object (1.2.2, 4.2). · Session controls — Sign-in frequency, persistent browser, CA app control, app-enforced restrictions (2.2.2). · Smart lockout — Attacker-vs-owner-aware lockout (2.1.5). · Staged rollout — Per-group migration from federation to cloud auth before domain cutover (3.4.2, 3.4.3).
Temporary Access Pass (TAP) — Time-limited bootstrap/recovery credential (2.1.3). · Tenant — An organization's Entra ID instance; the identity trust boundary (1.2.1). · Tenant restrictions v2 — Blocks sign-ins to foreign tenants from managed environments (2.4.3). · Terms of use (ToU) — Tracked agreement acceptance via CA or packages (5.1.2).
Universal Conditional Access — CA applied to GSA traffic profiles as a resource (2.4.1). · UsageLocation — Required user attribute for license assignment (3.2.4). · User assignment required — Service principal switch limiting token issuance to assigned principals (4.2.3).
What If — CA simulation tool for hypothetical sign-ins (2.2.4). · Windows Hello for Business — Per-device TPM-backed credential unlocked by PIN/biometric; phishing-resistant (2.1.2). · Workload identity — Non-human identity: application, service principal, managed identity (4.1). · Workload identity federation — See federated credential (4.1.1).
