Mange IT-afdelinger tester det lokale Active Directory og cloudmiljøet hver for sig, som om de var to adskilte verdener. Det er de ikke, når brugere, grupper og adgangskoder synkroniseres fra det ene til det andet. Svaret på, hvordan I skal se på den slags opsætning, hviler på Microsofts egen vejledning om at beskytte Microsoft 365 mod angreb fra det lokale miljø: forbindelsen er et tillidsforhold, og det, der stoler på noget andet, arver dets svagheder. En test af hybrid identitet spørger derfor, hvad en fejl i det ene miljø kan betyde i det andet, og om forbindelsen er indrettet, så skaden bliver begrænset.
Hvad hybrid identitet er
Microsoft beskriver hybrid identitet som en fælles brugeridentitet til login og adgang, uanset om ressourcen står i eget serverrum eller i skyen. Det opnås ved, at objekter fra det lokale katalog oprettes, holdes opdateret og fjernes i Entra ID, og ved at oplysninger synkroniseres løbende.
For medarbejderne er det en fordel. De har én konto og én adgangskode. For IT-afdelingen betyder det, at ændringer i det lokale katalog flyder videre til cloud, måske uden at nogen ser dem undervejs. En gruppe, der oprettes lokalt, kan ende med at give adgang til data i Microsoft 365. En konto, der deaktiveres lokalt, bør forsvinde i skyen, men gør det kun, hvis synkroniseringen kører som forventet.
Der findes flere måder at sætte login op på. Nogle virksomheder lader skyen kontrollere adgangskoden selv, andre sender kontrollen tilbage til lokale servere, og nogle bruger en føderation, hvor en lokal tjeneste udsteder beviset for, at brugeren er logget ind. Valget afgør, hvilke lokale komponenter cloudmiljøet er afhængigt af, og dermed hvad der skal med i testen.
Hvorfor forbindelsen gør to miljøer til ét
Microsoft peger på to hovedveje, hvor et kompromitteret lokalt miljø kan smitte af på skyen: føderation og synkronisering af konti. Hvis en lokal komponent bestemmer, hvem der er logget ind, kan den, der kontrollerer komponenten, i princippet give sig ud for enhver bruger. Hvis synkroniserede konti har administrative roller i skyen, kan en ændring i det lokale katalog give administratoradgang i cloud.
Den modsatte retning findes også. En konto i skyen med vide rettigheder over enheder eller programmer kan få betydning for maskiner, der står på det lokale net. Testen ser derfor på begge retninger og på de steder, hvor de mødes.
Pointen for IT-afdelingen er enkel. Hvis det lokale katalog har en kendt vej fra almindelig bruger til domæneadministrator, er det ikke kun et lokalt problem. Det kan være første trin mod jeres lejer i Microsoft 365. → Active Directory-test i dybden
Det, testen ser på
En test af hybrid identitet ser på forbindelserne mellem miljøerne, ikke kun på hvert miljø for sig. Typiske spørgsmål er:
- Administratorer i skyen · om konti med administrative roller i Entra ID er synkroniseret fra det lokale katalog, eller om de findes kun i skyen. → Administrative roller i Entra ID
- Synkroniseringsserveren · hvem der kan administrere den, og om den er beskyttet som en af de mest kritiske servere. → Synkroniseringsserveren som testområde
- Login og føderation · hvilke lokale komponenter der indgår i login til skyen, og hvem der har adgang til dem.
- Grupper, der giver adgang · om grupper fra det lokale katalog styrer adgang til data eller roller i skyen, og hvem der kan ændre medlemskabet.
- Nødadgang · om der findes konti, der kan bruges, hvis forbindelsen eller det lokale miljø svigter. → Nødadgangskonti
Resultatet kan blive en beskrivelse af, hvor tilliden går på tværs. Et fund om en synkroniseret konto med en høj rolle i skyen er en anden slags fund end et svagt punkt i et af miljøerne alene.
Det, IT-afdelingen forbereder
Testeren kan ikke se forbindelsen uden et kort over den. Forberedelsen handler om at samle det, I allerede ved:
- Login-metoden · hvordan brugerne logger ind i skyen, og hvilke lokale servere der indgår.
- Synkroniseringens omfang · hvilke dele af kataloget der synkroniseres, og hvilke der holdes ude.
- Roller i skyen · en liste over konti med administrative roller, og om de er lokale eller kun findes i cloud.
- Ejere · hvem der ejer det lokale katalog, og hvem der ejer lejeren, hvis det ikke er de samme.
- Testkonti · konti i begge miljøer, så testen kan følge en almindelig bruger fra den ene side til den anden.
Aftal også, hvem der skal kontaktes, hvis testen ser noget, der kræver handling med det samme. Hvis lejeren administreres af en driftsleverandør, skal leverandøren kende testvinduet.
Hvordan fundene prioriteres
Microsofts anbefalinger for at beskytte skyen mod det lokale miljø kan opsummeres som en adskillelse af det mest betroede. Administrative konti i skyen bør være rene cloudkonti, der beskyttes af egne regler for login. Ingen lokal konto bør have høje rettigheder i Microsoft 365. Grupper, der giver adgang til følsomme data, kan med fordel styres fra skyen frem for fra det lokale katalog.
Den rækkefølge giver en naturlig prioritering af fundene. Først det, der giver administrativ kontrol over skyen gennem det lokale miljø. Dernæst det, der giver adgang til data. Til sidst forhold, der gør forbindelsen skrøbelig eller svær at overvåge. Rettelserne kan være omlægninger frem for indstillinger, fordi de kræver nye konti, ændrede rutiner og en plan for overgangen. → Lagdelt administration
Det skal I lade være med
- At teste de to miljøer i hver sin opgave uden at aftale forbindelsen. Ingen af testerne ser så det sted, hvor miljøerne mødes.
- At give synkroniserede konti globale roller i skyen. Så bliver det lokale katalog nøglen til lejeren.
- At glemme de lokale komponenter i login. En server, der udsteder beviser for login, er lige så kritisk som en domænecontroller.
- At regne med, at cloud er beskyttet af Microsoft alene. Jeres egen opsætning af forbindelsen er jeres ansvar.
- At ændre login-metode midt i testen. Resultatet beskriver så en opsætning, der ikke findes længere.
Hvad kan og ikke kan konkluderes
Testen viser, om forbindelsen mellem de to miljøer gav veje på tværs i testperioden, med de konti og den opsætning, der var aftalt. Den kan ikke garantere, at en fremtidig ændring i synkroniseringen ikke åbner en ny vej. Den siger heller ikke noget om dele af lejeren eller kataloget, som lå uden for opgaven. Et resultat uden fund på tværs betyder, at de undersøgte forbindelser holdt, ikke at hvert miljø er uden svagheder.
Tjekliste til den hybride opsætning
- ☐ Er login-metoden og de lokale komponenter beskrevet?
- ☐ Er det kendt, hvilke dele af kataloget der synkroniseres?
- ☐ Er administrative roller i skyen givet til rene cloudkonti?
- ☐ Er synkroniseringsserveren regnet blandt de mest kritiske servere?
- ☐ Findes der nødadgang, der ikke afhænger af det lokale miljø?
- ☐ Har testen konti i begge miljøer?
Kilder
- Microsoft Learn: What is hybrid identity with Microsoft Entra ID?: fælles brugeridentitet på tværs af lokale og cloudbaserede ressourcer gennem provisionering og synkronisering.
- Microsoft Learn: Protect Microsoft 365 from on-premises attacks: føderation og synkronisering som de to hovedveje fra det lokale miljø til skyen, rene cloudkonti til administratorer og ingen lokale konti med høje rettigheder i Microsoft 365.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Administrative roller i Entra ID · Active Directory-test i dybden · Fra lokalt Active Directory til ren Entra ID
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
