Microsoft Entra ID: Klientorganisation, token och hybrididentitet

Microsoft Entra ID är en molnkatalog, identitetsprovider och policytillämpningspunkt för Microsoft- och tredjepartsapplikationer. Den lagrar användare, grupper, enheter, applikationer, tjänstehuvudnamn och roller; dess Security Token Service utfärdar signerade token efter lyckad autentisering och policykontroll. Microsoft Graph utgör administrationskontrollplanet. Dessa roller måste betraktas separat: ett befintligt användarobjekt garanterar inte en lyckad inloggning, en giltig token ingen verksamhetsmässig objektbehörighet och ett synkroniserat attribut ingen omedelbar effekt i varje måltjänst.

För meddelandeadministratörer ligger Entra på flera kritiska vägar: användare och proxyAddresses matar Exchange Online, grupper styr distributionslistor och åtkomst, appbehörigheter möjliggör automatiserad åtkomst till postlådor eller Graph, Conditional Access påverkar administratörs- och klientinloggningar, och hybridsynkronisering kopplar Active Directory Domain Services till molnet. Klientorganisationen är därmed inte bara ”AD på internet”, utan en självständig identitets- och auktoriseringsplattform.

Förklaringen följer en identitet från inloggning till åtkomst till en konkret resurs. Först förklaras klientorganisation, katalog och token, därefter roller, applikationer, enheter, hybridanslutning, protokoll och återställning.

Microsoft Entra ID kombinerar en katalog med tokenutfärdande och policykontroll. En användare får inte åtkomst ”till Entra”, utan begär en token för en konkret resurs; Entra kontrollerar då identitet, applikation, enhet och policy.

Arkitektur: Directory, STS, Policy och Resource

Microsoft beskriver Entra ID som en molnbaserad tjänst för identitets- och åtkomsthantering. Dess huvudkomponenter är:

1. Directory: Objekt, attribut, relationer, roller, domäner och lokal konfiguration för klientorganisationen.
2. Security Token Service (STS): Protokollslutpunkter, autentisering, tokenutfärdande och nyckelpublicering.
3. Policy Engines: Conditional Access, Identity Protection, Authentication Methods, Consent och andra åtkomstbeslut.
4. Provisioning/Sync: Replikering eller etablering till och från AD DS, SaaS och HR-källor.
5. Microsoft Graph: API för katalog-, identitets-, gransknings- och policyhantering.
6. Resource Services: Exchange Online, Graph, egna API:er och SaaS validerar token och verkställer sin auktorisering.

Entra har stöd för flera klientorganisationer. En klientorganisation utgör en administrativ och policymässig gräns, inte automatiskt en fullständig data- eller nätverksisolering för alla konsumerade SaaS-tjänster (Microsoft Entra fundamentals – What is Microsoft Entra ID?).

Teknikstack ur administratörsperspektiv

För en SaaS-tjänst med flera klientorganisationer är den interna teknikstacken med programmeringsspråk, databaser och orkestrering inte en produktegenskap som kunden kan kontrollera. Att härleda den från värdnamn, klientbibliotek eller platsannonser vore värdelöst för drift och återställning. Den verifierbara teknikstacken ur administratörsperspektiv består av de publicerade avtalen: HTTPS som transport, OAuth 2.0, OpenID Connect, SAML och WS-Federation för identitet, JWT/JWS och JWKS för token och nycklar, Microsoft Graph som REST-/OData-kontrollplan samt agentbaserad synkronisering för hybrididentiteter. Microsoft dokumenterar uttryckligen dessa protokoll och Graph som gränssnitt som stöds (Microsoft identity platform protocols, Microsoft Graph overview).

För administrationen är därför inte ett antaget serverspråk avgörande, utan den konkreta kombinationen av klientorganisation, authority, protokollversion, tokenformat, Graph-slutpunkt, SDK- eller PowerShell-modul, synkroniseringsagent och resurstjänst. Var och en av dessa lager har egna gränser för versionshantering, behörigheter, loggning och fel.

Klientorganisation, domäner och objektankare

Varje klientorganisation har ett oföränderligt klientorganisations-ID. Verifierade domännamn erbjuder läsbara inloggningsnamn och routningskoppling, men ersätter inte klientorganisations-ID:t. Ett domänbyte eller en konfiguration med flera klientorganisationer får därför inte identifieras enbart utifrån UPN-suffixet.

Objekt har klientorganisationslokala ID:n. Användare kan vara medlemmar eller gäster; en B2B-gäst är ett objekt i resursklientorganisationen med koppling till en extern identitet. Application Objects har ett globalt klient-/applikations-ID, medan Service Principals dessutom har ett eget Object ID i respektive klientorganisation. För join och synkronisering blir ytterligare ankare som onPremisesImmutableId, enhets-ID:n och källattribut relevanta.

Administratörer dokumenterar minst:

• klientorganisations-ID, primära och verifierade domäner;
• Object ID i stället för endast visningsnamn eller UPN;
• Home Tenant jämfört med Resource Tenant;
• källsystem och Source of Authority per attribut;
• tillstånd för mjuk borttagning/återställning och livscykel;
• licens-, roll- och grupprelationer som separata objekt.

Microsoft skiljer mellan Single Tenant- och Multi Tenant-applikationer utifrån vilka kataloger som får använda konton och Service Principals (Microsoft identity platform – Single- and multi-tenant apps).

Entra ID är inte Active Directory Domain Services

AD DS använder domäner, skogar, domänkontrollanter, LDAP, Kerberos, NTLM, DNS-integration, grupprinciper och replikering. Entra ID använder klientorganisationsobjekt, HTTPS-slutpunkter, moderna federations-/tokenprotokoll och molnbaserad policy. Det exponerar ingen allmän LDAP- eller Kerberos-slutpunkt för applikationer.

Microsofts jämförelse pekar uttryckligen på de olika protokoll- och administrationsmodellerna (Microsoft Learn – Compare Active Directory to Microsoft Entra ID). En appliance med LDAP-bindning kan inte autentisera direkt mot Entra ID utan gateway eller Domain Services; ett OAuth-API förstår omvänt ingen Kerberos-biljett.

Protokollslutpunkter och metadata

OpenID Connect Discovery-slutpunkten publicerar issuer, Authorization Endpoint, Token Endpoint, JWKS URI och funktioner som stöds. Klienter använder klientorganisationsspecifika authorities, till exempel ett konkret klientorganisations-ID; common, organizations eller consumers tillåter bredare kontotyper och ändrar issuer-kontroll och klientorganisationsbehörighet.

$tenant = $env:ENTRA_TENANT_ID
$metadata = Invoke-RestMethod "https://login.microsoftonline.com/$tenant/v2.0/.well-known/openid-configuration"
$metadata | Select-Object issuer,authorization_endpoint,token_endpoint,jwks_uri
Invoke-RestMethod $metadata.jwks_uri | Select-Object -ExpandProperty keys | Select-Object kid,kty,use

metadata="https://login.microsoftonline.com/$ENTRA_TENANT_ID/v2.0/.well-known/openid-configuration"
curl --silent --show-error --fail "$metadata" | jq '{issuer,authorization_endpoint,token_endpoint,jwks_uri}'
jwks_uri="$(curl --silent --show-error --fail "$metadata" | jq -r .jwks_uri)"
curl --silent --show-error --fail "$jwks_uri" | jq '.keys[] | {kid,kty,use}'

Invoke-RestMethod, curl och jq läser offentlig metadata. De utför ingen tokenvalidering. OIDC Discovery- och JWKS-format är standardiserade (OpenID Connect Discovery 1.0, RFC 7517 – JSON Web Key).

När klientorganisation, domän och objektankare har klargjorts följer själva inloggningsvägen. OAuth 2.0, OpenID Connect och SAML fyller olika uppgifter och levererar olika artefakter.

OAuth 2.0, OpenID Connect och SAML

OAuth 2.0 delegerar auktorisering för resurs-API:er. OpenID Connect lägger till ett autentiseringslager med ID Token och UserInfo. SAML transporterar signerade assertioner mellan Identity Provider och Service Provider. Microsoft publicerar de protokollvarianter som Identity Platform stöder (Microsoft identity platform protocols, OpenID Connect Core 1.0, OASIS SAML 2.0 Technical Overview).

De vanliga OAuth-flödena skiljer mellan identitet och klienttyp:

• Authorization Code med PKCE: interaktiv användare, Public eller Confidential Client.
• Client Credentials: arbetsbelastning utan användare; Application Permissions/App Roles.
• On-Behalf-Of: mellanliggande API byter en användartoken mot en token för ett underordnat API.
• Device Code: enhet utan bekväm webbläsare; koden bekräftas på en annan enhet.
• Refresh Token: förnyar åtkomst utan fullständig interaktiv inloggning, men är fortfarande underkastad policy- och återkallelsehändelser.

Microsoft dokumenterar varje flöde med egna gränser för begäran, autentiseringsuppgifter och säkerhet (Authorization Code Flow, Client Credentials Flow, On-Behalf-Of Flow, Device Authorization Grant).

Tokentyper och claims

En ID Token är avsedd för klienten och styrker en autentisering. En Access Token är avsedd för ett resurs-API; endast denna resurs ska validera den. En Refresh Token är en autentiseringsuppgift gentemot Authorization Server och skickas aldrig till ett resurs-API (Microsoft identity platform – Security tokens).

För JWT-baserade token är bland annat följande relevanta:

Valideringen kontrollerar signatur, algoritm, issuer, audience, tid och applikationsspecifika claims. JWT Best Current Practices varnar för algoritmförväxling, Cross-JWT-Confusion och blint förtroende för mottagna claims (RFC 8725 – JWT Best Current Practices, Microsoft – Validate tokens).

En token kan dekodas lokalt för diagnostik; riktiga token kopieras varken till externa webbplatser eller ärenden. Avkodning är ingen signaturkontroll.

$parts = $env:ACCESS_TOKEN -split '\.'
$payload = $parts[1].Replace('-','+').Replace('_','/')
$payload += '=' * ((4 - $payload.Length % 4) % 4)
$claims = [Text.Encoding]::UTF8.GetString([Convert]::FromBase64String($payload)) | ConvertFrom-Json
$claims | Select-Object iss,aud,tid,oid,sub,scp,roles,iat,nbf,exp

payload="$(printf '%s' "$ACCESS_TOKEN" | cut -d. -f2 | tr '_-' '/+')"
case $((${#payload} % 4)) in 2) payload="${payload}==";; 3) payload="${payload}=";; esac
printf '%s' "$payload" | base64 --decode 2>/dev/null | jq '{iss,aud,tid,oid,sub,scp,roles,iat,nbf,exp}'

ConvertFrom-Json, cut, tr och base64 bearbetar endast en lokal kopia. Efter analysen kasseras den; loggar och shell-historik får inte lagra token.

Application Object och Service Principal

En App Registration skapar ett Application Object i Home Tenant. Det beskriver bland annat Client ID, Redirect URI:er, App Roles, begärda API-behörigheter och autentiseringsuppgifter. När applikationen används eller ges consent i en klientorganisation finns där en Service Principal som en klientorganisationslokal instans. Managed Identities är särskilda Service Principals vars livscykel för autentiseringsuppgifter hanteras av Azure (Application objects and service principals).

Dessa ID:n får inte förväxlas:

• appId/Client ID identifierar applikationsdefinitionen på protokollnivå;
• Application Object ID identifierar registreringsobjektet i Home Tenant;
• Service Principal Object ID identifierar instansen i Resource Tenant;
• Resource-/API-App ID respektive Audience identifierar tokenmålet.

Ett visningsnamn är inte unikt och inte ett ankare för automatisering. Att ta bort och skapa på nytt kan inte godtyckligt återskapa samma Client ID och skapar nya objektrelationer.

En giltig token besvarar ännu inte vad en applikation får göra. Delegerade och rena applikationsbehörigheter skiljer sig åt genom huruvida en användarkontext ingår och vem som godkänner rättigheterna.

Delegated Permissions, Application Permissions och Consent

Delegated Permissions verkar i kontexten för en inloggad användare och visas vanligen som scp. Appen kan inte automatiskt göra mer än vad användare och klientorganisationspolicy tillåter. Application Permissions verkar utan användare som App Roles i roles-claimen och kan möjliggöra omfattande åtkomst (Permissions and consent overview).

Consent skapar klientorganisationslokala grants och App Role-tilldelningar. Admin Consent är inte bara en bekräftelse av en dialogruta, utan en auktoriseringsändring. Inventering och granskning omfattar:

• Client- och Resource-Service Principal;
• delegerade scope-grants och Application App-Role-Assignments;
• vem som gav consent, när och via vilken process;
• faktisk användning, Publisher Verification och ursprung;
• objekt-/postlådebegränsning i resursen, om tillgängligt;
• effekt vid återkallelse och driftstopp.

I Exchange Online kan en Application Permission dessutom begränsas genom en Exchange-specifik åtkomstpolicy eller RBAC for Applications. Graph-/Entra-consentobjektet ensamt återger inte den verksamhetsmässiga postlåderäckvidden fullt ut (Exchange Online – Role Based Access Control for Applications).

Workload Identities och autentiseringsuppgifter

En Workload Identity är en programvaruidentitet, vanligtvis en Service Principal eller Managed Identity. Autentiseringsuppgifter kan vara Client Secret, certifikat/privat nyckel, Managed Identity-plattformautentiseringsuppgift eller Federated Identity Credential. Hemligheter är bearer credentials; certifikat och federation förbättrar nyckelinnehav eller undviker lagrade långlivade hemligheter, men kräver egen trustdrift (Microsoft Entra Workload ID overview).

Workload Identity Federation förlitar sig på en extern OIDC-issuer och binder issuer, subject och audience till en Service Principal eller en User-Assigned Managed Identity. CI-systemet, Kubernetes-tjänstekontot eller molnarbetsbelastningen byter sin kortlivade externa token mot en Entra-token utan att lagra en statisk hemlighet (Workload identity federation).

Drift av autentiseringsuppgifter omfattar utfärdare, lagring, åtkomst till privat nyckel, NotBefore/Expiry, överlappning, rotation, senaste användning och återkallelse. Utgångsdatumet i Application Object bevisar inte att en integration faktiskt använder denna autentiseringsuppgift.

Connect-MgGraph -Scopes 'Application.Read.All','Directory.Read.All'
Get-MgContext
$app = Get-MgApplication -Filter "appId eq '$env:CLIENT_ID'"
$sp = Get-MgServicePrincipal -Filter "appId eq '$env:CLIENT_ID'"
$app | Select-Object Id,AppId,DisplayName,SignInAudience,PasswordCredentials,KeyCredentials
$sp | Select-Object Id,AppId,DisplayName,ServicePrincipalType,AccountEnabled

az account show --output json | jq '{tenantId,user,name}'
az ad app list --filter "appId eq '$CLIENT_ID'" --output json | jq '.[] | {id,appId,displayName,signInAudience,passwordCredentials,keyCredentials}'
az ad sp list --filter "appId eq '$CLIENT_ID'" --output json | jq '.[] | {id,appId,displayName,servicePrincipalType,accountEnabled}'

Connect-MgGraph, Get-MgContext, Get-MgApplication och Get-MgServicePrincipal visar Graph-kontexten och båda objekttyperna. az account show, az ad app och az ad sp visar Azure CLI-vyn. Utdata kan innehålla metadata om autentiseringsuppgifter och klientorganisationsinventering.

Conditional Access och Continuous Access Evaluation

Conditional Access behandlar signaler som användare/arbetsbelastning, målresurs, enhet, plats, risk, klienttyp och autentiseringsstyrka och tillämpar grant- eller session controls. Policyer samverkar; en lyckad enskild policy är inte ett samlat resultat (Conditional Access overview).

Report-only och What If hjälper vid planering, men ersätter inte en pilotgrupp med riktiga klienter. Särskilda fall relevanta för meddelanden är Legacy Authentication, SMTP AUTH, mobilklienter, tjänstekonton, Break Glass-konton, administratörsportaler och non-interactive sign-ins.

Access Tokens är normalt giltiga fram till utgången. Continuous Access Evaluation gör det möjligt för resurser och klienter som stöds att ta hänsyn till kritiska händelser och policyändringar tidigare (Continuous Access Evaluation). CAE är ingen global omedelbar återkallelse för varje applikation; resursen och klienten måste stödja protokollet.

MFA, Authentication Methods och Authentication Strengths

MFA är ett policyuttalande, inte en enskild produktmetod. Authentication Methods Policies styr vilka metoder som får registreras och användas; Conditional Access Authentication Strengths kan kräva konkreta metodkombinationer (Authentication methods overview, Conditional Access authentication strengths).

Nätfiskeresistenta metoder som FIDO2/Passkeys eller certifikatbaserad autentisering förändrar registrerings-, återställnings- och enhetsprocesser. Temporary Access Pass kan möjliggöra bootstrap och är självt en tidsbegränsad autentiseringsuppgift. Helpdesk-återställning, ny telefonregistrering och förlorade enheter är arbetsflöden med hög risk och hör hemma i granskningsspåret.

Directory Roles, PIM och Administrative Units

Directory Roles auktoriserar administrationsfunktioner för Entra och Microsoft 365. Roller kan tilldelas direkt, via grupper eller tidsbegränsat genom Privileged Identity Management. PIM skiljer mellan eligible och active, approval, MFA, motivering, varaktighet och Access Reviews (Microsoft Entra PIM overview).

Administrative Units kan begränsa omfånget för utvalda roller till delmängder av objekt. Inte varje roll eller åtgärd stöder detta omfång; Graph-, Exchange- och säkerhetsportaler har delvis egna RBAC-modeller (Administrative units).

Privilegium dokumenteras som en kedja: tilldelningskälla → aktivering → token/roll → målservice-RBAC → konkret objektåtgärd. ”Global Administrator finns” förklarar inte automatiskt en 403 i Exchange eller Graph.

Enhetsidentitet och Primary Refresh Token

Entra Registered, Entra Joined och Hybrid Entra Joined är olika enhetsrelationer. Registered kopplar vanligtvis en personlig eller externt hanterad enhet; Joined använder Entra som primär organisationskoppling; Hybrid Joined kopplar AD DS Domain Join med Entra-registrering (Microsoft Entra device identity).

I Windows stöder Primary Refresh Token Single Sign-On och bär enhets- samt autentiseringskontext. Utfärdande och förnyelse av PRT beror på användar-, enhets- och nyckeltillstånd; det är ingen vanlig Refresh Token som administratörer ska kopiera (Primary Refresh Token).

Enhetsstatus, MDM-compliance, Hybrid Join, certifikat och Conditional Access kan vara tidsmässigt osynkroniserade. Diagnostik kontrollerar därför tillsammans lokal join-information, Entra-enhetsobjekt, hanteringsobjekt, sign-in-logg och policyresultat.

I hybridmiljöer börjar identiteten ofta i det lokala Active Directory. Synkronisering överför utvalda objekt och attribut, men gör inte Entra ID till en LDAP- eller Kerberos-ersättning.

Hybrididentitet: Connect Sync och Cloud Sync

Microsoft Entra Connect Sync kör en synkroniseringsmotor på Windows Server och kan representera omfattande regler och vissa hybridfunktioner. Cloud Sync använder lättviktiga Provisioning Agents och molnstyrd konfiguration; funktionsomfång och topologi skiljer sig åt (Microsoft Entra Connect overview, Microsoft Entra Cloud Sync overview).

Ett synkroniseringssystem har tre nivåer:

1. Connector Spaces eller käll-/målconnector med importerade objekt;
2. Metaverse-/mappningslogik respektive Cloud Provisioning-konfiguration;
3. Export till Entra med målobjekt, attributflöde och feltillstånd.

Matchning och Source Anchor förhindrar dubbletter. Filter, joinregler, attributprioritet och writeback definierar dataägarskap. En lyckad scheduler-körning bevisar inte att varje objekt har exporterats; karantän, provisioningfel och bearbetning i molntjänsten kontrolleras separat.

Autentisering i hybriddrift

• Password Hash Synchronization (PHS): en härledd hash lagras i Entra; molnautentisering är möjlig vid on-prem-fel.
• Pass-through Authentication (PTA): agenter validerar lösenord mot AD DS; agentvägen blir driftsrelevant.
• Federation: Entra dirigerar autentisering till ett federerat STS; certifikat, claims rules och tillgänglighet utökar felområdet.

Microsoft beskriver urval och avvägningar för dessa inloggningsmetoder (Choose the right authentication method). Seamless SSO och PRT är ytterligare mekanismer och inte synonyma med den primära autentiseringsmetoden.

Entra Domain Services

Microsoft Entra Domain Services tillhandahåller en hanterad domän med Domain Join, grupprinciper, LDAP, Kerberos och NTLM. Användare, grupper och autentiseringshashar synkroniseras från Entra till den hanterade domänen. Kunder får inga Domain Admin- eller Enterprise Admin-rättigheter och hanterar inte domänkontrollanter själva (Microsoft Entra Domain Services overview).

Domain Services är ingen dubbelriktad brygga till AD DS och ingen ersättning för Entra-tokenprotokoll. Äldre applikationer ser LDAP-/Kerberosobjekt i den hanterade domänen; moderna SaaS-applikationer fortsätter att använda Entra. Secure LDAP kräver certifikat, publicerad nätverksgräns, NSG/firewall och credentialpolicy.

External Identities och Cross-Tenant-åtkomst

B2B Collaboration skapar gästobjekt i Resource Tenant, medan autentisering ofta sker i Home Tenant. Cross-Tenant Access Settings styr inbound och outbound trust, förtroende för MFA-/enhetsclaims och organisatoriska relationer (Microsoft Entra B2B collaboration overview, Cross-tenant access overview).

Resource Tenant auktoriserar fortsatt sina data. Ett borttaget eller inaktiverat hemkonto, ett befintligt gästobjekt, Access Packages och gruppmedlemskap kan ha olika livscykler. Periodiska Access Reviews och sponsor-/ägarprocesser sluter denna lucka.

Microsoft Graph som Control Plane

Microsoft Graph exponerar resurssökvägar som /users, /groups, /applications, /servicePrincipals, /policies och /auditLogs. Behörighet, API-version, paging, throttling och eventual consistency för vissa frågor ingår i avtalet (Microsoft Graph overview).

Delta Query levererar ändringar sedan ett initialt tillstånd via ogenomskinliga token; Change Notifications skickar webhooks, men ersätter inte en avstämningskörning (Microsoft Graph delta query, Microsoft Graph change notifications). För API:er gäller även här idempotens, pagination, 429/Retry-After och Request ID.

Connect-MgGraph -Scopes 'User.Read.All','AuditLog.Read.All'
Get-MgContext
Get-MgUser -UserId $env:USER_OBJECT_ID -Property Id,UserPrincipalName,AccountEnabled,OnPremisesSyncEnabled,ProxyAddresses
Invoke-MgGraphRequest -Method GET -Uri "v1.0/auditLogs/signIns?`$filter=userId eq '$env:USER_OBJECT_ID'&`$top=20"

az account get-access-token --resource-type ms-graph --output json | jq '{tenant,expires_on}'
token="$(az account get-access-token --resource-type ms-graph --query accessToken -o tsv)"
curl --silent --show-error --fail \
  --header "Authorization: Bearer $token" \
  "https://graph.microsoft.com/v1.0/users/$USER_OBJECT_ID?%24select=id,userPrincipalName,accountEnabled,onPremisesSyncEnabled,proxyAddresses" | jq .

Get-MgUser och Invoke-MgGraphRequest använder den visade Graph-kontexten. az account get-access-token levererar en kortlivad CLI-token; den loggas inte och lagras inte permanent. Graph-svar innehåller personuppgifter och säkerhetsrelevant data.

Nätverks- och TLS-beroenden

Entra är en distribuerad HTTPS-tjänst. Proxy, brandvägg, DNS, TLS-inspektion, tid och endpoint allowlist påverkar autentisering, Graph, Device Registration, Sync och återkallelse. En statisk IP-lista är inte alltid rätt modell; Microsoft publicerar Service Tags och URL-/IP-kategorier för Microsoft 365 och Entra-relaterade slutpunkter (Microsoft 365 URLs and IP address ranges, Azure service tags overview).

Resolve-DnsName login.microsoftonline.com
Test-NetConnection login.microsoftonline.com -Port 443 -InformationLevel Detailed
Invoke-WebRequest "https://login.microsoftonline.com/$env:ENTRA_TENANT_ID/v2.0/.well-known/openid-configuration" -UseBasicParsing
w32tm /query /status

dig login.microsoftonline.com A
nc -vz login.microsoftonline.com 443
openssl s_client -connect login.microsoftonline.com:443 -servername login.microsoftonline.com -alpn h2,http/1.1 </dev/null
timedatectl show --property=NTPSynchronized --property=TimeUSec

Resolve-DnsName och dig kontrollerar först namnupplösningen. Test-NetConnection, nc och openssl s_client separerar TCP och TLS. Invoke-WebRequest kontrollerar HTTP, w32tm och timedatectl tidskällan.

Sign-in Logs, Audit Logs och Provisioning Logs

Sign-in Logs dokumenterar interaktiva, non-interactive, Service Principal- och Managed Identity-inloggningar med status, Conditional Access-utvärdering, klient-, enhets- och riskinformation. Audit Logs dokumenterar katalog- och policyändringar. Provisioning Logs visar etableringssteg och mappningsfel (Microsoft Entra sign-in logs, Microsoft Entra audit logs, Provisioning logs).

Correlation ID, Request ID, tid i UTC, klientorganisation, Client ID, Resource ID, användar-/Service Principal-ID och felkod utgör minsta bevisunderlag. Portaltexter kompletteras med felkod och token-/protokollfas; samma UI-meddelanden kan ha olika orsaker.

Loggkvarhållning beror på licens och exportkonfiguration och kan ändras. Långsiktiga bevis skickas före incidenten via Diagnostic Settings eller stödda exportvägar till ett kontrollerat loggsystem.

Break Glass, backup och återställning

Entra är en SaaS-tjänst; kunder säkerhetskopierar inte någon domänkontrollants databas. De måste dock skydda konfiguration, externa autentiseringsuppgifter och administrativ återställbarhet:

• minst två cloud-only Emergency Access Accounts med oberoende starka metoder;
• undantag från Conditional Access endast så långt som behövs för återställning och under övervakning;
• konfiguration för klientorganisation/domän/federation/cross-tenant och rollexport;
• App Registrations, Service Principals, grants, App Roles och metadata om autentiseringsuppgifter;
• policies för Conditional Access, Authentication Methods, PIM och livscykel;
• hybridsynkroniseringsregler, Source Anchors, agent-/serverkonfiguration och stagingväg;
• externa beroenden av CA/KMS/federation/DNS/Break Glass;
• export av Audit-/Sign-in-Logs och ändringsärenden.

Microsoft rekommenderar dedikerade Emergency Access Accounts vars användning larmar och testas regelbundet (Manage emergency access accounts).

Mjukt borttagna objekt har produktspecifika återställningsfönster och begränsningar som kan ändras. Återställningsrunbooks länkar därför till respektive Microsoft-dokumentation och testar separat användare, grupp, app, Service Principal, felkonfiguration av Conditional Access och förlorad federations-/domänväg.

Felsökningen följer tokenbeslutet: identifiera användare och applikation, kontrollera inloggningsmetod och Conditional Access, läs tokenclaims och utvärdera slutligen auktoriseringen på resursen.

Diagnostik enligt beslutsfas

Ett Entra-fel kan avgränsas snabbare om fasen först fastställs: inloggning, tokenutfärdande eller målprogrammets beslut. Tabellen kopplar lämpliga bevis till varje fas.

Ett Entra-fel löses inte genom godtyckliga nya inloggningar. Först fasen avgör om nätverk, klientkonfiguration, identitet, policy, token eller resursauktorisering måste korrigeras.

Teknisk historik

Microsoft utvecklade Windows Azure Active Directory som en multitenant molnkatalog- och federationstjänst för Microsoft Online Services och tredjepartsapplikationer. Azure AD använde moderna tokenprotokoll och var arkitektoniskt aldrig en värdbaserad AD DS-domänkontrollant. Microsoft Graph ersatte flera äldre API:er som gemensamt molnkontrollplan.

Hybrid Identity uppstod ur synkroniserings- och federationsverktyg som DirSync, Azure AD Sync, AD FS och senare Azure AD Connect. Password Hash Sync, Pass-through Authentication, Seamless SSO, Cloud Sync och Workload Federation kompletterade olika driftmodeller. Managed Identities flyttade rotation av autentiseringsuppgifter för Azure-arbetsbelastningar till plattformen.

År 2023 bytte Microsoft namn på Azure Active Directory till Microsoft Entra ID; protokollslutpunkter, API:er, klientorganisations- och licensgrunder förblev del av samma tjänstekontinuitet (Microsoft – New name for Azure Active Directory). Historiken förklarar dagens blandning av login.microsoftonline.com, AzureAD-äldre beteckningar, Microsoft Graph, AD DS-hybridtermer och Entra-produktnamn.

Adminchecklista i korthet

Avslutningsvis betraktas identiteter, applikationer, roller, policyer och återställning tillsammans. Checklistan fungerar som ett kort driftbevis för dessa sammanhängande kontroller.

Källor

• Microsoft Learn – Resolve-DnsName
• BIND 9 – dig
• Microsoft Entra fundamentals – What is Microsoft Entra ID?
• Microsoft identity platform – Single- and multi-tenant apps
• Microsoft Learn – Compare AD DS to Microsoft Entra ID
• Microsoft Learn – Invoke-RestMethod
• curl manual
• jq manual
• OpenID Connect Discovery 1.0
• RFC 7517 – JSON Web Key
• Microsoft identity platform protocols
• OpenID Connect Core 1.0
• OASIS SAML 2.0 Technical Overview
• Authorization Code Flow
• Client Credentials Flow
• On-Behalf-Of Flow
• Device Authorization Grant
• Microsoft identity platform – Security tokens
• RFC 8725 – JWT Best Current Practices
• Microsoft identity platform – Access tokens and validation
• Microsoft Learn – ConvertFrom-Json
• GNU coreutils – cut
• GNU coreutils – tr
• GNU coreutils – base64
• Application objects and service principals
• Permissions and consent overview
• Exchange Online – RBAC for Applications
• Microsoft Entra Workload ID overview
• Workload identity federation
• Microsoft Graph PowerShell – Connect-MgGraph
• Microsoft Graph PowerShell – Get-MgContext
• Microsoft Graph PowerShell – Get-MgApplication
• Microsoft Graph PowerShell – Get-MgServicePrincipal
• Azure CLI – az account show
• Azure CLI – az ad app
• Azure CLI – az ad sp
• Conditional Access overview
• Continuous Access Evaluation
• Authentication methods overview
• Conditional Access authentication strengths
• Microsoft Entra PIM overview
• Administrative units
• Microsoft Entra device identity
• Primary Refresh Token
• Microsoft Entra Connect overview
• Microsoft Entra Cloud Sync overview
• Choose the right authentication method
• Microsoft Entra Domain Services overview
• Microsoft Entra B2B collaboration overview
• Cross-tenant access overview
• Microsoft Graph overview
• Microsoft Graph delta query
• Microsoft Graph change notifications
• Microsoft Graph PowerShell – Get-MgUser
• Microsoft Graph PowerShell – Invoke-MgGraphRequest
• Microsoft 365 URLs and IP address ranges
• Azure service tags overview
• Microsoft Learn – Test-NetConnection
• OpenBSD – nc
• OpenSSL – s_client
• Microsoft Learn – Invoke-WebRequest
• Microsoft Learn – Windows Time tools
• systemd – timedatectl
• Microsoft Entra sign-in logs
• Microsoft Entra audit logs
• Microsoft Entra provisioning logs
• Manage emergency access accounts
• Microsoft – New name for Azure Active Directory