Microsoft Entra ID: Tenant, tokens og hybrididentitet

Microsoft Entra ID er en skykatalog, Identity Provider og Policy Enforcement Point for Microsoft- og tredjepartsapplikasjoner. Den lagrer brukere, grupper, enheter, applikasjoner, Service Principals og roller; Security Token Service utsteder signerte tokens etter vellykket autentisering og policykontroll. Microsoft Graph utgjør administrasjons-control plane. Disse rollene må vurderes separat: Et eksisterende brukerobjekt garanterer ikke vellykket pålogging, et gyldig token garanterer ikke faglig objektautorisasjon, og et synkronisert attributt får ikke nødvendigvis umiddelbar effekt i hver måltjeneste.

For meldingsadministratorer ligger Entra i flere kritiske stier: Brukere og proxyAddresses mater Exchange Online, grupper styrer distribusjon og tilgang, apprettigheter tillater automatisert postboks- eller Graphtilgang, Conditional Access påvirker administrator- og klientpålogginger, og hybridsynkronisering kobler Active Directory Domain Services til skyen. Tenant er derfor ikke bare «AD på Internett», men en selvstendig identitets- og autorisasjonsplattform.

Forklaringen følger en identitet fra pålogging til tilgang til en konkret ressurs. Først forklares tenant, katalog og token, deretter roller, applikasjoner, enheter, hybridtilkobling, protokoller og gjenoppretting.

Microsoft Entra ID kobler en katalog med tokenutstedelse og policykontroll. En bruker får ikke tilgang «til Entra», men ber om et token for en konkret ressurs; Entra kontrollerer da identitet, applikasjon, enhet og policy.

Arkitektur: Directory, STS, Policy og Resource

Microsoft beskriver Entra ID som en skybasert identitets- og tilgangsadministrasjonstjeneste. Hovedflatene er:

1. Directory: Objekter, attributter, relasjoner, roller, domener og tenantlokal konfigurasjon.
2. Security Token Service (STS): Protokollendepunkter, autentisering, tokenutstedelse og nøkkelpublisering.
3. Policy Engines: Conditional Access, Identity Protection, Authentication Methods, Consent og andre tilgangsavgjørelser.
4. Provisioning/Sync: Replikering eller klargjøring til og fra AD DS, SaaS og HR-kilder.
5. Microsoft Graph: API for katalog-, identitets-, revisjons- og policyadministrasjon.
6. Resource Services: Exchange Online, Graph, egne API-er og SaaS validerer tokens og håndhever autorisasjonen deres.

Entra støtter flere leietakere. En tenant utgjør en administrativ og policymessig grense, men ikke automatisk fullstendig data- eller nettverksisolasjon for alle SaaS-tjenester som brukes (Microsoft Entra fundamentals – What is Microsoft Entra ID?).

Teknologistack fra et administratorperspektiv

For en SaaS-tjeneste med flere leietakere er den interne stakken av programmeringsspråk, databaser og orkestrering ikke en produktegenskap kunden kontrollerer. Å utlede den fra vertsnavn, klientbiblioteker eller stillingsannonser ville være verdiløst for drift og gjenoppretting. Den dokumenterbare teknologistacken fra et administratorperspektiv består av de publiserte avtalene: HTTPS som transport, OAuth 2.0, OpenID Connect, SAML og WS-Federation for identitet, JWT/JWS og JWKS for tokens og nøkler, Microsoft Graph som REST-/OData-control plane samt agentbasert synkronisering for hybrididentiteter. Microsoft dokumenterer uttrykkelig disse protokollene og Graph som støttede grensesnitt (Microsoft identity platform protocols, Microsoft Graph overview).

For administrasjon er derfor ikke et antatt serverspråk avgjørende, men den konkrete kombinasjonen av tenant, authority, protokollversjon, tokenformat, Graph-endepunkt, SDK- eller PowerShell-modul, synkroniseringsagent og Resource Service. Hvert av disse lagene har egne grenser for versjonering, rettigheter, logging og feil.

Tenant, domener og objektankere

Hver tenant har en uforanderlig Tenant-ID. Verifiserte domenenavn gir lesbare påloggingsnavn og rutingtilknytning, men erstatter ikke Tenant-ID-en. Et domeneendring eller oppsett med flere leietakere må derfor ikke identifiseres utelukkende ut fra UPN-suffikset.

Objekter har tenantlokale ID-er. Brukere kan være Member eller Guest; en B2B-gjest er et objekt i Resource Tenant med tilknytning til en ekstern identitet. Application Objects har en global Client-/Application-ID, og Service Principals har i tillegg sin egen Object-ID i den aktuelle tenant. For join og synkronisering blir ytterligere ankere som onPremisesImmutableId, enhets-ID-er og kildeattributter relevante.

Administratorer dokumenterer minst:

• Tenant-ID, primære og verifiserte domener;
• Object-ID i stedet for bare visningsnavn eller UPN;
• Home Tenant kontra Resource Tenant;
• kildesystem og Source of Authority per attributt;
• Soft-Delete-/Restore-tilstand og livssyklus;
• lisens-, rolle- og grupperelasjoner som separate objekter.

Microsoft skiller mellom Single-Tenant- og Multi-Tenant-applikasjoner ut fra hvilke kataloger som kan bruke kontoer og Service Principals (Microsoft identity platform – Single- and multi-tenant apps).

Entra ID er ikke Active Directory Domain Services

AD DS bruker domener, forests, Domain Controllers, LDAP, Kerberos, NTLM, DNS-integrasjon, gruppepolicyer og replikering. Entra ID bruker tenantobjekter, HTTPS-endepunkter, moderne federation-/tokenprotokoller og skybasert policy. Den eksponerer ikke et generelt LDAP- eller Kerberos-endepunkt for applikasjoner.

Microsofts sammenligning viser uttrykkelig til de ulike protokoll- og administrasjonsmodellene (Microsoft Learn – Compare Active Directory to Microsoft Entra ID). En appliance med LDAP-binding kan ikke autentisere direkte mot Entra ID uten gateway eller Domain Services; et OAuth-API forstår omvendt ikke en Kerberos-ticket.

Protokollendepunkter og metadata

OpenID Connect Discovery-endepunktet publiserer Issuer, Authorization Endpoint, Token Endpoint, JWKS URI og støttede funksjoner. Klienter bruker tenantspesifikke authorities som en konkret Tenant-ID; common, organizations eller consumers tillater bredere kontotyper og endrer issuer-kontroll og tenantgodkjenning.

$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 og jq leser offentlige metadata. De utfører ingen tokenvalidering. OIDC Discovery- og JWKS-formater er standardiserte (OpenID Connect Discovery 1.0, RFC 7517 – JSON Web Key).

Når tenant, domene og objektankere er avklart, følger selve påloggingsveien. OAuth 2.0, OpenID Connect og SAML har forskjellige oppgaver og leverer forskjellige artefakter.

OAuth 2.0, OpenID Connect og SAML

OAuth 2.0 delegerer autorisasjon for Resource API-er. OpenID Connect legger til et autentiseringslag med ID Token og UserInfo. SAML transporterer signerte assertions mellom Identity Provider og Service Provider. Microsoft publiserer de støttede protokollvariantene i Identity Platform (Microsoft identity platform protocols, OpenID Connect Core 1.0, OASIS SAML 2.0 Technical Overview).

De vanlige OAuth-flytene skiller mellom identitet og klienttype:

• Authorization Code med PKCE: interaktiv bruker, Public eller Confidential Client.
• Client Credentials: arbeidsbelastning uten bruker; Application Permissions/App Roles.
• On-Behalf-Of: mellomliggende API bytter et brukertoken mot et token for et etterfølgende API.
• Device Code: enhet uten praktisk nettleser; koden bekreftes på en annen enhet.
• Refresh Token: fornyer tilgang uten full interaktiv pålogging, men er fortsatt underlagt policy- og revocation-hendelser.

Microsoft dokumenterer hver flyt med egne request-, credential- og sikkerhetsgrenser (Authorization Code Flow, Client Credentials Flow, On-Behalf-Of Flow, Device Authorization Grant).

Tokentyper og claims

Et ID Token er beregnet for klienten og dokumenterer en autentisering. Et Access Token er beregnet for et Resource API; bare denne ressursen skal validere det. Et Refresh Token er en credential mot Authorization Server og sendes aldri til et Resource API (Microsoft identity platform – Security tokens).

For JWT-baserte tokens er blant annet følgende relevant:

Validering kontrollerer signatur, algoritme, issuer, audience, tid og applikasjonsspesifikke claims. JWT Best Current Practices advarer mot algoritmeforveksling, Cross-JWT-Confusion og blind tillit til mottatte claims (RFC 8725 – JWT Best Current Practices, Microsoft – Validate tokens).

Et token kan dekodes lokalt for diagnose; reelle tokens kopieres aldri til fremmede nettsteder eller saker. Dekoding er ikke en 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 og base64 behandler bare en lokal kopi. Etter analysen forkastes den; logger og shellhistorikk må ikke lagre tokenet.

Application Object og Service Principal

En App Registration oppretter et Application Object i Home Tenant. Det beskriver blant annet Client-ID, Redirect URIs, App Roles, forespurte API-rettigheter og credentials. Når applikasjonen brukes eller consentieres i en tenant, finnes det der en Service Principal som tenantlokal instans. Managed Identities er spesielle Service Principals der Azure administrerer credential-livssyklusen (Application objects and service principals).

Disse ID-ene må ikke forveksles:

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

Et visningsnavn er ikke entydig og er ikke et automatiseringsanker. Sletting og nyoppretting kan ikke fritt gjenskape samme Client-ID og oppretter nye objektrelasjoner.

Et gyldig token besvarer fortsatt ikke hva en applikasjon kan gjøre. Delegerte og rene applikasjonsrettigheter skiller seg ved om en brukerkontekst er involvert og hvem som godkjenner rettighetene.

Delegated Permissions, Application Permissions og Consent

Delegated Permissions virker i konteksten til en pålogget bruker og vises typisk som scp. Appen kan ikke automatisk mer enn brukeren og tenantpolicyen tillater. Application Permissions virker uten bruker som App Roles i roles-claimet og kan muliggjøre omfattende tilgang (Permissions and consent overview).

Consent oppretter tenantlokale grants og app-rolletildelinger. Admin Consent er ikke bare en bekreftelse av en dialog, men en autorisasjonsendring. Inventar og gjennomgang omfatter:

• Client- og Resource-Service-Principal;
• delegerte scope-grants og Application App-Role-Assignments;
• hvem som consentierte, når og gjennom hvilken prosess;
• faktisk bruk, Publisher Verification og opprinnelse;
• objekt-/postboksbegrensning i ressursen, der det er tilgjengelig;
• effekt av tilbakekalling og utfall.

I Exchange Online kan en Application Permission i tillegg begrenses av Exchange-spesifikk tilgangspolicy eller RBAC for Applications. Graph-/Entra-consentobjektet alene avbilder ikke fullt ut den faglige postboksrekkevidden (Exchange Online – Role Based Access Control for Applications).

Workload Identities og Credentials

En Workload Identity er en programvareidentitet, vanligvis Service Principal eller Managed Identity. Credentials kan være Client Secret, sertifikat/privat nøkkel, Managed-Identity-plattformcredential eller Federated Identity Credential. Secrets er bearer credentials; sertifikater og federation forbedrer nøkkelbesittelse eller unngår lagrede langvarige secrets, men krever egen tillitsdrift (Microsoft Entra Workload ID overview).

Workload Identity Federation stoler på en ekstern OIDC-issuer og knytter issuer, subject og audience til en Service Principal eller en User-Assigned Managed Identity. CI-system, Kubernetes-servicekonto eller cloud workload bytter sitt kortvarige eksterne token mot et Entra-token uten å lagre en statisk secret (Workload identity federation).

Credential-drift omfatter utsteder, lagring, private-key-tilgang, NotBefore/Expiry, overlapp, rotasjon, siste bruk og tilbakekalling. Utløpsdatoen i Application Object beviser ikke at en integrasjon faktisk bruker denne credentialen.

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 og Get-MgServicePrincipal viser Graph-kontekst og begge objekttypene. az account show, az ad app og az ad sp viser Azure CLI-visningen. Utdata kan inneholde credentialmetadata og tenantinventar.

Conditional Access og Continuous Access Evaluation

Conditional Access behandler signaler som bruker/workload, målressurs, enhet, plassering, risiko, klienttype og autentiseringsstyrke, og anvender grant- eller session controls. Policyer virker sammen; en enkelt vellykket policy er ikke et samlet resultat (Conditional Access overview).

Report-only og What If hjelper ved planlegging, men erstatter ikke en pilotgruppe med reelle klienter. Meldingsrelevante spesialtilfeller er Legacy Authentication, SMTP AUTH, Mobile Clients, Service Accounts, Break-Glass-kontoer, administratorportaler og non-interactive sign-ins.

Access Tokens er normalt gyldige til de utløper. Continuous Access Evaluation lar støttede resources og klienter ta hensyn til kritiske hendelser og policyendringer tidligere (Continuous Access Evaluation). CAE er ikke en global umiddelbar tilbakekalling for hver applikasjon; ressurs og klient må støtte protokollen.

MFA, Authentication Methods og Authentication Strengths

MFA er en policyuttalelse, ikke én enkelt produktmetode. Authentication Methods Policies styrer hvilke metoder som kan registreres og brukes; Conditional Access Authentication Strengths kan kreve konkrete metodekombinasjoner (Authentication methods overview, Conditional Access authentication strengths).

Phishingresistente metoder som FIDO2/Passkeys eller sertifikatbasert autentisering endrer enrollment-, recovery- og enhetsprosesser. Temporary Access Pass kan muliggjøre bootstrap og er selv en tidsbegrenset credential. Helpdesk-tilbakestilling, ny telefonregistrering og mistede enheter er arbeidsflyter med høy risiko og hører hjemme i revisjonssporet.

Directory Roles, PIM og Administrative Units

Directory Roles autoriserer Entra- og Microsoft 365-administrasjonsfunksjoner. Roller kan tildeles direkte, via grupper eller tidsbegrenset gjennom Privileged Identity Management. PIM skiller mellom eligible og active, Approval, MFA, begrunnelse, varighet og Access Reviews (Microsoft Entra PIM overview).

Administrative Units kan begrense scope for utvalgte roller til delmengder av objekter. Ikke alle roller eller operasjoner støtter dette scopet; Graph-, Exchange- og sikkerhetsportaler har delvis egne RBAC-modeller (Administrative units).

Privilegier dokumenteres som en kjede: tildelingskilde → aktivering → token/rolle → målservice-RBAC → konkret objekthandling. «Global Administrator finnes» forklarer ikke automatisk en 403 i Exchange eller Graph.

Enhetsidentitet og Primary Refresh Token

Entra Registered, Entra Joined og Hybrid Entra Joined er ulike enhetsrelasjoner. Registered knytter vanligvis en personlig eller eksternt administrert enhet; Joined bruker Entra som primær organisasjonstilknytning; Hybrid Joined kombinerer AD-DS-Domain Join med Entra-registrering (Microsoft Entra device identity).

På Windows støtter Primary Refresh Token Single Sign-On og bærer enhets- og autentiseringskontekst. PRT-utstedelse og -fornyelse avhenger av bruker-, enhets- og nøkkeltilstand; det er ikke et vanlig Refresh Token som administratorer bør kopiere (Primary Refresh Token).

Enhetsstatus, MDM-compliance, Hybrid Join, sertifikater og Conditional Access kan være tidsmessig usynkroniserte. Diagnosen kontrollerer derfor lokal joininformasjon, Entra-enhetsobjekt, administrasjonsobjekt, sign-in-logg og policyresultat samlet.

I hybride miljøer starter identiteten ofte i lokal Active Directory. Synkronisering overfører utvalgte objekter og attributter, men gjør ikke Entra ID til en LDAP- eller Kerberos-erstatning.

Hybrididentitet: Connect Sync og Cloud Sync

Microsoft Entra Connect Sync kjører en synkroniseringsmotor på Windows Server og kan håndtere omfattende regler og bestemte hybridfunksjoner. Cloud Sync bruker lette Provisioning Agents og skyadministrert konfigurasjon; funksjonsomfang og topologi er forskjellige (Microsoft Entra Connect overview, Microsoft Entra Cloud Sync overview).

Et synkroniseringssystem har tre nivåer:

1. Connector Spaces eller kilde-/målkobling med importerte objekter;
2. Metaverse-/mappinglogikk eller Cloud Provisioning-konfigurasjon;
3. Export til Entra med målobjekt, attributtflyt og feiltilstand.

Matching og Source Anchor hindrer duplikater. Filtre, joinregler, attributtprioritet og writeback definerer dataeierskap. En vellykket schedulerkjøring beviser ikke at hvert objekt ble eksportert; karantene, provisioningfeil og skytjenestebehandling kontrolleres separat.

Autentisering i hybriddrift

• Password Hash Synchronization (PHS): en avledet hash lagres i Entra; skyauthentisering er mulig ved feil lokalt.
• Pass-through Authentication (PTA): agents validerer passord mot AD DS; agentstien blir driftsrelevant.
• Federation: Entra videresender autentisering til en føderert STS; sertifikater, Claims Rules og tilgjengelighet utvider feilområdet.

Microsoft beskriver valg og avveininger for disse påloggingsmetodene (Choose the right authentication method). Seamless SSO og PRT er tilleggsmekanismer og ikke synonymer for den primære autentiseringsmetoden.

Entra Domain Services

Microsoft Entra Domain Services tilbyr et administrert domene med Domain Join, gruppepolicyer, LDAP, Kerberos og NTLM. Brukere, grupper og credential-hasher synkroniseres fra Entra til det administrerte domenet. Kunder får ingen Domain- eller Enterprise-Admin-rettigheter og administrerer ikke Domain Controllers selv (Microsoft Entra Domain Services overview).

Domain Services er ikke en toveis bro til AD DS og ikke en erstatning for Entra-tokenprotokoller. Eldre applikasjoner ser LDAP-/Kerberosobjekter i Managed Domain; moderne SaaS-applikasjoner bruker fortsatt Entra. Secure LDAP krever sertifikat, publisert nettverksgrense, NSG/firewall og credentialpolicy.

External Identities og Cross-Tenant-tilgang

B2B Collaboration oppretter gjesteobjekter i Resource Tenant, mens autentisering ofte skjer i Home Tenant. Cross-Tenant Access Settings styrer inbound- og outbound-trust, tillit til MFA-/enhetsclaims og organisatoriske relasjoner (Microsoft Entra B2B collaboration overview, Cross-tenant access overview).

Resource Tenant autoriserer fortsatt sine data. En slettet eller deaktivert Home-konto, et eksisterende gjesteobjekt, Access Packages og gruppemedlemskap kan ha ulike livssykluser. Regelmessige Access Reviews og sponsor-/ownerprosesser lukker dette gapet.

Microsoft Graph som Control Plane

Microsoft Graph eksponerer ressurstier som /users, /groups, /applications, /servicePrincipals, /policies og /auditLogs. Rettighet, API-versjon, paging, throttling og eventual consistency for visse spørringer er en del av avtalen (Microsoft Graph overview).

Delta Query leverer endringer siden en initial tilstand gjennom opake tokens; Change Notifications sender webhooks, men erstatter ikke en reconciliation-kjøring (Microsoft Graph delta query, Microsoft Graph change notifications). For API-er gjelder også idempotens, paginering, 429/Retry-After og 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 og Invoke-MgGraphRequest bruker den viste Graph-konteksten. az account get-access-token leverer et kortvarig CLI-token; det logges ikke eller lagres permanent. Graph-svar inneholder personopplysninger og sikkerhetsrelevante data.

Nettverks- og TLS-avhengigheter

Entra er en distribuert HTTPS-tjeneste. Proxy, firewall, DNS, TLS-inspeksjon, tid og endpoint-allowlist påvirker autentisering, Graph, Device Registration, Sync og Revocation. En statisk IP-liste er ikke alltid riktig modell; Microsoft publiserer Service Tags og URL-/IP-kategorier for Microsoft 365- og Entra-relaterte endepunkter (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 og dig kontrollerer først navneoppløsningen. Test-NetConnection, nc og openssl s_client skiller TCP og TLS. Invoke-WebRequest kontrollerer HTTP, w32tm og timedatectl tidskilden.

Sign-in Logs, Audit Logs og Provisioning Logs

Sign-in Logs dokumenterer interaktive, non-interactive, Service-Principal- og Managed-Identity-pålogginger med status, Conditional-Access-evaluering, klient-, enhets- og risikoinformasjon. Audit Logs dokumenterer Directory- og policyendringer. Provisioning Logs viser klargjøringstrinn og mappingfeil (Microsoft Entra sign-in logs, Microsoft Entra audit logs, Provisioning logs).

Correlation ID, Request ID, tid i UTC, tenant, Client-ID, Resource-ID, bruker-/Service-Principal-ID og feilkode utgjør minimumsdokumentasjonen. Portaltekster kompletteres med feilkode og token-/protokollfase; like UI-meldinger kan ha ulike årsaker.

Loggoppbevaring avhenger av lisens og eksportkonfigurasjon og kan endres. Langsiktig dokumentasjon sendes før hendelsen gjennom Diagnostic Settings eller støttede eksportbaner til et kontrollert loggsystem.

Break Glass, sikkerhetskopiering og gjenoppretting

Entra er en SaaS-tjeneste; kunder sikkerhetskopierer ikke en Domain Controller-database. De må likevel beskytte konfigurasjon, eksterne credentials og administrativ gjenopprettbarhet:

• minst to skybaserte Emergency Access Accounts med uavhengige sterke metoder;
• unntak fra Conditional Access bare så langt som nødvendig for recovery og med overvåking;
• Tenant-/Domain-/Federation-/Cross-Tenant-konfigurasjon og rolleeksport;
• App Registrations, Service Principals, Grants, App Roles og credentialmetadata;
• Conditional-Access-, Authentication-Methods-, PIM- og Lifecycle-policyer;
• Hybrid Sync-regler, Source Anchors, agent-/serverkonfigurasjon og stagingsti;
• eksterne CA-/KMS-/Federation-/DNS-/Break-Glass-avhengigheter;
• eksport av Audit-/Sign-in-logger og Change Tickets.

Microsoft anbefaler dedikerte Emergency Access Accounts, der bruk varsles og testes regelmessig (Manage emergency access accounts).

Soft-deleted objekter har produktspesifikke gjenopprettingsvinduer og begrensninger som kan endres. Recovery-runbooks lenker derfor til den aktuelle Microsoft-dokumentasjonen og tester bruker, gruppe, app, Service Principal, Conditional-Access-feilkonfigurasjon og mistet Federation-/Domain-sti separat.

Feilsøkingen følger tokenavgjørelsen: identifiser bruker og applikasjon, kontroller påloggingsmetode og Conditional Access, les tokenclaims og evaluer til slutt autorisasjonen ved ressursen.

Diagnose etter beslutningsfase

En Entra-feil kan avgrenses raskere hvis fasen først bestemmes: pålogging, tokenutstedelse eller målprogrammets avgjørelse. Tabellen knytter passende dokumentasjon til hver fase.

En Entra-feil løses ikke ved vilkårlig ny pålogging. Først fasen avgjør om nettverk, klientkonfigurasjon, identitet, policy, token eller ressursautorisasjon må korrigeres.

Teknisk historikk

Microsoft utviklet Windows Azure Active Directory som en skykatalog- og federationstjeneste for flere leietakere for Microsoft Online Services og tredjepartsapplikasjoner. Azure AD tok i bruk moderne tokenprotokoller og var arkitektonisk aldri en driftet AD-DS-Domain-Controller. Microsoft Graph erstattet flere eldre API-er som felles cloud-control plane.

Hybrid Identity oppstod fra synkroniserings- og federationverktøy som DirSync, Azure AD Sync, AD FS og senere Azure AD Connect. Password Hash Sync, Pass-through Authentication, Seamless SSO, Cloud Sync og Workload Federation supplerte ulike driftsmodeller. Managed Identities flyttet credentialrotasjon for Azure-workloads inn i plattformen.

I 2023 endret Microsoft navnet Azure Active Directory til Microsoft Entra ID; protokollendepunkter, API-er, tenant- og lisensgrunnlag forble en del av samme tjenestekontinuitet (Microsoft – New name for Azure Active Directory). Historikken forklarer dagens blanding av login.microsoftonline.com, AzureAD-eldre betegnelser, Microsoft Graph, AD-DS-hybridbegreper og Entra-produktnavn.

Administrator-sjekkliste på et øyeblikk

Til slutt vurderes identiteter, applikasjoner, roller, policyer og gjenoppretting samlet. Sjekklisten fungerer som kort driftsdokumentasjon for disse sammenhengende kontrollene.

Kilder

• 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