Når login til jeres systemer bor i Entra ID, afhænger også de systemer, der intet har med Microsoft at gøre, af jeres Microsoft-aftale. Planen skal derfor vise, hvilke systemer der logger ind den vej, hvordan de kan få login fra et andet sted, og hvordan I kommer ind, hvis login svigter.
Spørgsmålet handler både om en egentlig entra id migrering og om noget mere hverdagsagtigt, nemlig at vide, hvad der stopper, hvis kontoen forsvinder. Microsofts sider om Entra ID er læst 6. november 2026 og kan ændre sig. Den generelle metode står i login som afhængighed. Her er det produktets udgave.
Hvad der er bundet
Entra ID er Microsofts identitetstjeneste. Den samler brugere, grupper, adgangskoder, to-faktor og fælles login. Fælles login betyder, at en bruger logger ind én gang og derefter kan åbne de tildelte programmer. Microsoft beskriver det som en styrke, at programmerne ikke længere selv holder styr på brugernavne og adgangskoder.
For exit-planen er det samme egenskab, der binder. Når regnskab, CRM og lønsystem har overladt login til Entra ID, har de ofte ingen brugere af egen kraft. Dertil kommer betinget adgang, som er reglerne for, hvem der må logge ind hvorfra, fra hvilken enhed og med hvilken form for to-faktor. De regler er en del af jeres sikkerhed og er skrevet til dette produkt.
Azure og Microsoft 365 bruger samme identitet, så en løsning i det ene rammer det andet, se exit-plan for Azure.
Hvad der kan komme ud
Standardprotokollerne hjælper. Microsoft skelner selv mellem programmer med moderne protokoller, som SAML og OpenID Connect, og ældre programmer, som kræver andre veje ind. Vores læsning er, at et program med en standardprotokol i de fleste tilfælde kan pege på en anden identitetsudbyder, fordi protokollen ikke er Microsofts egen. Det er en vurdering, og hvert system skal tjekkes.
Har I stadig en lokal Active Directory, der synkroniserer brugere til skyen med Entra Connect, ligger en kopi af brugerkartoteket også hos jer. Det ændrer planen, for brugerne findes da et sted, I selv styrer.
Brugere og grupper kan læses ud af tjenesten, og betingelserne for betinget adgang kan beskrives. Adgangskoder og to-faktor-registreringer skal I regne med at oprette på ny, indtil en test viser andet. Det er vores forsigtige antagelse, og den læste dokumentation afgør det ikke.
Hvad der mangler
Disse punkter følger ikke af sig selv:
- Domænet. Jeres eget domæne er knyttet til tjenesten. Microsoft skriver, at et domæne kun kan slettes fra tjenesten, når ingen ressourcer er afhængige af det. Der findes en tvungen sletning, som skifter referencer til standarddomænet på onmicrosoft.com. Skriv ned, hvad flytning af domænet kræver, og læs hvem ejer kontoen, domænet og abonnementet.
- Ophør. Når et Microsoft 365-abonnement er slettet, fjernes Entra ID, hvis andre tjenester ikke bruger det. Det rammer også systemer uden for Microsoft.
- Tjenestekonti. Integrationer logger ofte ind med egne konti og hemmeligheder, som skal findes og skiftes.
Hvad der skal testes
Microsofts egen vejledning til at flytte programmer til Entra ID anbefaler at teste med en testudgave af programmet og gerne en separat testorganisation. Samme fremgangsmåde kan bruges i modsat retning:
- Træk en liste over programmer med fælles login og marker protokollen for hvert.
- Vælg et mindre kritisk program med en testudgave.
- Spørg leverandøren, hvordan det kan pege på en anden identitetsudbyder, og om det kan have lokale brugere imens.
- Prøv at logge ind i en nødsituation. Findes der en konto, der ikke afhænger af fælles login?
Microsoft råder selv til nødkonti, der er undtaget fra betinget adgang, så administratorer ikke låser sig ude. Tjek, at de findes, og at nogen ved, hvor oplysningerne ligger.
Hvad planen skal rumme
Tabellen i planen har en række pr. program: protokol, ejer, om det kan køre med lokale brugere, hvad der sker, hvis Entra ID er væk, og hvad en ændring kræver. Hertil kommer en beskrivelse af reglerne for betinget adgang i almindeligt sprog, oversigten over tjenestekonti, nødadgangen og domænet.
Rækkefølgen betyder noget i en exit. Login er ofte det sidste, der flyttes, fordi alt andet afhænger af det. Planen skal kunne vise den rækkefølge, men slutter dér, hvor flytningen begynder. Hvilken identitetsudbyder der skal afløse, er en anden beslutning.
Hvad det kræver, og hvad det koster at lade være
Listen over programmer tager en administrator få timer. Afklaringen med leverandørerne tager længere, fordi den afhænger af svar udefra. Skriv et lavt og et højt skøn pr. program, og datér det.
Uden oversigten bliver et login-svigt til et stop i alle systemer samtidig. Brug forretningens egne tal for en dag uden systemerne, se et stop i forretningens egne tal. Listen giver noget i dag: færre glemte tjenestekonti, bedre styr på, hvem der må hvad, og et svar til revisor eller kunde om adgangsstyring.
Det skal I lade være med
- At gemme nødadgangen hos én person · så er den ikke en nødadgang.
- At regne med, at adgangskoder følger med · test det, før I skriver det.
- At glemme domænet · mail og login hænger på det.
Det skal planen kunne vise
- ☐ En liste over programmer med fælles login og protokol.
- ☐ Hvilke programmer der kan køre med lokale brugere.
- ☐ Reglerne for betinget adgang beskrevet i almindeligt sprog.
- ☐ En oversigt over tjenestekonti og deres ejere.
- ☐ En testet nødadgang og en dato for testen.
- ☐ Hvad flytning af domænet kræver.
Kilder
Alle læst 6. november 2026. Kilderne er leverandørens egne og på engelsk.
- Microsoft: fælles login
- Microsoft: faser i flytning af programmers login
- Microsoft: administration af domæner
- Microsoft: betinget adgang og nødkonti
- Microsoft: hybrid identitet
- Microsoft: abonnementets ophør
Senest gennemgået: november 2026.
Næste skridt
Træk listen over programmer med fælles login, og prøv nødadgangen i denne måned. Tag de systemer, forretningen ikke kan undvære, op som særskilte punkter i planen.
Læs også: Exit-plan for Microsoft 365 · Integrationer i exit-planen
→ Kontakt · Tlf. 70 13 63 23 · Exit-plan og exit-rådgivning hos Nielco IT
