Sådan sætter du Entra ID Named Locations op korrekt, undgå “trusted IP”-huller og få bedre Conditional Access
Mange SMV’er kører hele hverdagen i Entra ID Named Locations og Conditional Access (CA), uden at tænke over det. Logins til mail, Teams og filer bliver vurderet, hver gang. Det er godt. Men det kan også give en falsk tryghed, hvis “trusted IP” bliver brugt som en genvej.
I praksis ser vi samme mønster hos mindre og mellemstore virksomheder i Århus og Lystrup. Der er travlt. it-support skal også løse printere, brugere og licenser. Samtidig vokser kravet til it-sikkerhed, især i microsoft 365, hvor identitet er den nye perimeter.
Målet her er enkelt: Named Locations skal hjælpe jer, ikke lave huller. Conditional Access skal være stram, men realistisk at drifte.
Hvad Named Locations egentlig er, og hvorfor “trusted IP” kan blive et problem
Named Locations er et signal i Entra ID. Et stykke kontekst, der fortæller: “Denne login-forespørgsel kommer fra et netværk, vi kender”. Det bruges typisk i Conditional Access, men kan også indgå i vurderinger af risiko.
Der er to klassiske typer:
- IP-baserede lokationer (offentlig egress-IP set udefra).
- Lande/regioner (geografi baseret på IP).
Microsoft beskriver grundideen og hvordan CA bygges op i deres overblik over Conditional Access. Det er værd at skimme, især hvis I arver en opsætning fra “ham der var her før”.
“Trusted IP”-hullet opstår, når man bruger Named Locations som en undtagelse fra sikkerhed. Det typiske mønster er en policy, der siger “kræv MFA”, men med “Exclude trusted locations”. Det lyder fornuftigt. Det føles som at låse hoveddøren, men lade bagdøren stå på krog, fordi det plejer at være medarbejdere, der går ind der.
Problemet er, at IP ikke altid er stabilt eller entydigt:
- Nogle ISP’er roterer IP’er, eller bruger CGNAT (mange deler samme offentlige IP).
- VPN kan være split-tunnel, så noget trafik går uden om firmens egress.
- Leverandører ændrer egress-IP uden at sige det højt, og pludselig “falder” rigtige brugere ud, mens andre får gratis adgang.
Hvis Named Locations bliver et “MFA-frit” område, skal det kun fejle én gang for at give en angriber et vindue.
Opsæt Entra ID Named Locations korrekt, så de kan driftes i praksis
Et forenklet overblik over Named Locations, IP-ranges og styring, skabt med AI.
God opsætning handler mindre om klik i portalen, og mere om forarbejde og styring. Hos Netdk starter vi altid med at få styr på “hvad er vores netværk set udefra”.
En praktisk opskrift, der holder i drift:
- Kortlæg jeres offentlige egress-IP’er : Brug den IP, Entra ser. Private adresser (10.x/192.168.x) er ikke det, CA matcher på.
- Del lokationer op efter funktion : “Kontor”, “Datacenter”, “VPN-egress”, “Partner-net”. Undgå én stor “Trusted”-klump.
- Brug CIDR korrekt : Vær præcis. For brede ranges giver større angrebsflade.
- Sæt en ejer og et change-log : Hvem opdaterer, når ISP ændrer IP? Hvornår blev det sidst testet?
- Håndtér break-glass-konti : De skal være stærkt beskyttet, men ofte undtaget fra enkelte CA-krav for at sikre adgang ved fejl. Undtagelsen skal være snæver og dokumenteret.
- Test i Report-only : Se effekten før I tænder hårdt.
Microsofts egen forklaring af netværksbetingelsen er god som reference, især når man rammer begrænsninger i logikken: netværksbetingelsen i Conditional Access.
En lille tommelfingerregel: Named Locations er bedst som signal , ikke som tilladelse .
| Named Location-type | Godt til | Typisk faldgrube |
|---|---|---|
| Kontor (statisk egress-IP) | Ekstra signal, bedre log-overblik | Bruges som MFA-undtagelse |
| Datacenter/hosted net | Servicekonti og faste workloads | Glemmer at opdatere ved flyt |
| Blokeret geografi | Stoppe åbenlyse forsøg | Falske positiver ved rejser |
| Partner-netværk | B2B-adgang med faste vilkår | For brede ranges, lav kontrol |
Hvis I automatiserer ændringer, findes der også PowerShell-styring, fx Set-EntraNamedLocationPolicy. Det giver bedre sporbarhed end manuelle klik, når man har flere lokationer.
Undgå “trusted IP”-huller, og byg Conditional Access der passer til en SMV
Et visuelt billede af hvordan “trusted IP” kan blive en omvej uden om MFA, skabt med AI.
Det mest almindelige hul er denne kombination: “Tillad login uden MFA fra trusted locations”. Den virker, indtil den ikke gør.
En bedre tilgang er at flytte “tillid” væk fra IP og over på kontroller, der er sværere at kopiere:
- Phishing-resistant MFA via Authentication Strength (fx FIDO2-sikkerhedsnøgle eller Windows Hello for Business).
- Compliant device (Intune) for at sikre patch-niveau, kryptering og skærmlås.
- Risikobaserede signaler (sign-in risk), når licensen understøtter det.
- Stramme regler for admin-konti (ingen undtagelser, ingen “remember MFA i 30 dage” uden grund).
Named Locations kan stadig bruges, men mere som en betingelse for ekstra kontrol. Eksempel: “Hvis login ikke kommer fra kontor eller kendt net, så kræv stærkere metode og compliant device”. Microsoft har et konkret eksempel på at styre adgang efter lokation i deres guide til at blokere adgang efter lokation.
En enkel policy-struktur for SMV’er med gradvis udrulning, skabt med AI.
En SMV-baseline, der ofte giver ro i maven, har typisk tre policies:
- Admins: stærk MFA, compliant device, ingen lokations-undtagelser.
- Standardbrugere: stærk MFA, evt. compliant device ved følsomme apps.
- Gæster/B2B: stram adgang, kort session, og klare blokeringer.
Start i “Report-only”, og skift til “On”, når loggen viser færre overraskelser.
Hvis I arbejder med Microsofts Global Secure Access, kan I også bruge netværk som et compliance-signal, ikke bare IP. Se fx Compliant Network Check med Global Secure Access. Det er mere robust end “den her IP er god”.
Til mere praktisk inspiration om “trusted network locations” kan denne gennemgang også hjælpe: opsætning af Entra trusted network locations.
Konklusion: Brug Named Locations som signal, ikke som fripas
Entra ID Named Locations er et stærkt værktøj, når det bruges rigtigt. Det skal give bedre kontrol og færre falske alarmer, ikke en genvej uden om MFA. Den sikre model for SMV’er er at basere adgang på stærk autentificering og device-krav, og kun bruge lokation som ekstra kontekst.
For virksomheder i Århus (århus) og lystrup betyder det ofte færre support-sager, færre “hvorfor blev jeg blokeret?”, og en mere rolig drift. Netdk hjælper typisk med at få ryddet op i policies, få dokumentation på plads, og gøre sikkerhed til noget, der kan holdes ved lige. Det er her forskellen mærkes, når en rigtig hændelse rammer.
