Named Locations und Trusted IPs in Entra ID

von

Wissen

Praxis-Artikel  rund um Microsoft Entra ID – alle frei verfügbar. Conditional Access, MFA, PIM, Governance, Hybrid, NIS2.

Beratung

Beratung, Projektbegleitung, Quick Health Check deines Entra-Tenants. Conditional-Access-Audits, MFA-Rollout, Governance-Aufbau und NIS2-/DORA-Vorbereitung.

Fachbücher

Mein Fachbuch zu Microsoft Entra ID – Architektur, Conditional Access, MFA, PIM, Governance, Hybrid und NIS2-Compliance. Kompromisslos praxisnah. In Vorbereitung!

Tools

Der Entra Diagnostiker analysiert deinen Tenant in 14 Modulen: Conditional Access, MFA, Guest-Hygiene, PIM. Lokal, DSGVO-konform, mit NIS2-Mapping.

Schulungen

Online-Workshops zu Entra ID, Conditional Access, MFA-Rollout, PIM und NIS2-Compliance – kompakt, hands-on, ohne MOC-Folienschlacht.

Named Locations und Trusted IPs in Entra ID

Warum ein benannter Standort allein nichts sperrt – und wo Altlasten zum Sicherheitsrisiko werden.

Named Locations und Trusted IPs – die unterschätzten Stolperfallen

Kurzfassung vorab

Named Locations fühlen sich an wie ein Sicherheitszaun – sind aber nur ein Namensschild. Die unbequeme Wahrheit: Ein benannter Standort blockt von sich aus gar nichts. Er liefert nur ein Signal, auf das eine Conditional-Access-Policy reagieren kann. Und der zugrunde liegende Standort kommt aus der IP-Adresse, die sich mit einem Fünf-Euro-VPN beliebig verschieben lässt. Wer Standort als alleinigen Schutz versteht, baut sich falsche Sicherheit. Richtig eingesetzt sind Named Locations trotzdem nützlich – als Komfort-Hebel und Lärmfilter. Dieser Leitfaden zeigt, wo die Grenze verläuft und welche Altlast dich richtig Geld kosten kann.

Eine Named Location benennt nur einen Standort – erst eine Policy, die sie als Bedingung nutzt, bewirkt etwas.

Was eine Named Location wirklich ist (und was nicht)

Eine Named Location ist nichts weiter als ein benannter Bereich – entweder eine oder mehrere IP-Adressbereiche oder eine Liste von Ländern und Regionen. Du gibst ihr einen Namen wie „Hauptsitz Dortmund“ oder „Gesperrte Länder“, damit du dich in Policies darauf beziehen kannst. Das ist alles. Die Named Location selbst trifft keine Entscheidung und blockt nichts.

Die eigentliche Wirkung entsteht erst, wenn eine Conditional-Access-Policy diesen Standort als Bedingung verwendet – etwa „wenn Anmeldung aus gesperrtem Land, dann blockieren“ oder „wenn nicht aus dem Büro, dann MFA verlangen“. Genau diese Trennung wird ständig verwechselt: Leute legen brav Named Locations an, wundern sich, dass nichts passiert, und merken nicht, dass die Policy dazu fehlt.

Info

Named Locations selbst gibt es bereits in Entra ID Free. Um sie als Bedingung in einer Conditional-Access-Policy zu nutzen, brauchst du allerdings P1 – wie für Conditional Access generell.

Der Standort wird aus der öffentlichen IP-Adresse abgeleitet, mit der die Anmeldung beim Tenant ankommt. Das ist eine Schätzung auf Basis von Geo-IP-Datenbanken, keine präzise GPS-Ortung – und damit grundsätzlich fälschbar.

Das „trusted“-Häkchen und die MFA-Trusted-IP-Altlast

Beim Anlegen einer IP-basierten Named Location kannst du sie als „vertrauenswürdig“ markieren. Was harmlos klingt, hat je nach Kontext eine sehr unterschiedliche Tragweite. In modernen Conditional-Access-Policies ist das Flag ein normales Signal: Du kannst eine Policy bauen, die aus vertrauenswürdigen Standorten auf den MFA-Prompt verzichtet, während Passwortprüfung und alle anderen Policies weiterlaufen. Das ist ein vertretbarer Komfort-Kompromiss.

Als Komfort-Signal in Conditional Access harmlos – als pauschaler MFA-Bypass über die alte Trusted-IP-Logik riskant.

Achtung

Die gefährliche Variante ist die alte MFA-Trusted-IPs-Funktion aus den Multi-Factor-Authentication-Service-Einstellungen. Sie erklärt ein ganzes Netz pauschal als MFA-befreit – oft tenant-weit, schwer zu überblicken und gern vergessen. Ein Angreifer, der es ins Büro-WLAN schafft (oder über einen kompromittierten VPN-Zugang), umgeht damit die komplette MFA. Prüfe bei jedem Tenant-Übernahmeprojekt, ob hier noch alte Trusted-IP-Bereiche schlummern – das ist einer der häufigsten versteckten Seiteneingänge, die ich in der Praxis finde.

Warum Ländersperren keinen ernsthaften Angreifer aufhalten

Die beliebteste Named-Location-Idee ist die Ländersperre: „Wir erlauben nur Anmeldungen aus Deutschland.“ Klingt wasserdicht, ist es aber nicht. Der Standort kommt aus der IP, und jeder halbwegs motivierte Angreifer mietet sich für ein paar Euro einen VPN-Endpunkt oder Proxy im erlaubten Land. Aus Sicht des Tenants kommt die Anmeldung dann brav aus Deutschland.

Ein VPN im erlaubten Land hängt die Geo-IP-Sperre mühelos aus – als Lärmfilter taugt sie trotzdem.

Das heißt nicht, dass Ländersperren wertlos sind. Sie reduzieren das Grundrauschen erheblich: Die täglichen Massen-Anmeldeversuche aus Ländern, in denen niemand von dir arbeitet, verschwinden aus den Logs, und das macht echte Vorfälle besser sichtbar. Als zusätzliche Hürde sind sie sinnvoll – als alleiniger Schutz ohne MFA sind sie ein Trugschluss.

Praxis-Tipp

Bau Ländersperren als Deny-Liste, nicht als Allow-Liste. Sperre die paar Länder, aus denen garantiert niemand legitim zugreift, statt nur ein einziges Land zu erlauben. Eine Allow-Liste auf „nur Deutschland“ fällt dir nämlich beim ersten Mitarbeiter im Urlaub, beim ersten Geschäftsreisenden und beim ersten Home-Office im Ausland auf die Füße – und dann landet ein hektisches „ich komme nicht rein“-Ticket auf deinem Tisch.

Wann Named Locations sinnvoll sind – und wann nicht

Damit du nicht raten musst, hier die Einordnung der gängigen Szenarien. Faustregel: Named Locations sind hervorragend, um Komfort zu schaffen und Lärm zu filtern – und ungeeignet, sobald sie der einzige Schutzmechanismus sein sollen.

Komfort und Lärmfilter: grün. Standort als alleiniger Schutz oder pauschaler MFA-Bypass: rot.

Umsetzung – vorhandene Named Locations prüfen

Gerade bei übernommenen Tenants willst du schnell sehen, welche Named Locations existieren und welche als vertrauenswürdig markiert sind. Über Microsoft Graph PowerShell geht das in einem Rutsch:

Connect-MgGraph -Scopes "Policy.Read.All"

 

Get-MgIdentityConditionalAccessNamedLocation |

ForEach-Object {

[pscustomobject]@{

Name = $_.DisplayName

Trusted = $_.AdditionalProperties.isTrusted

Type = $_.AdditionalProperties.'@odata.type'

}

}

Die Spalte Trusted ist dabei dein wichtigster Prüfpunkt: Jeder als vertrauenswürdig markierte Bereich gehört hinterfragt – nutzt ihn wirklich nur eine saubere Komfort-Policy, oder hängt da noch ein pauschaler Bypass dran? Vergiss dabei nicht, parallel die alten MFA-Service-Einstellungen auf Trusted-IP-Reste zu prüfen, denn die tauchen hier gar nicht auf.

Beispiel aus der Praxis

Die Musterwerk GmbH, solider Mittelständler aus der Fertigung, hat ihre Identitätssicherheit über Jahre gewachsen lassen. Bei der Übernahme des Tenants fällt auf: Das gesamte Werks-WLAN ist als MFA-Trusted-IP eingetragen – ein Relikt aus der Zeit, als MFA „nur von unterwegs“ gelten sollte. Jeder, der im Werk am Netz hängt, meldet sich ohne zweiten Faktor an.

Das Problem: Das Werks-WLAN ist groß, teilweise schlecht segmentiert, und an einigen Stellen kommt man mit etwas Geschick auch ohne Mitarbeiterausweis ins Netz. Damit ist die teuer eingeführte MFA für einen ganzen Gebäudekomplex praktisch ausgeschaltet – ohne dass es jemandem bewusst war.

Der Umbau: Die pauschale Trusted-IP-Regel fliegt raus. Stattdessen eine saubere Named Location für die echte Büro-IP plus eine Conditional-Access-Policy, die aus diesem Standort lediglich das MFA-Intervall verlängert – also seltener nachfragt, statt MFA komplett zu streichen. Ergebnis: Der Komfort im Büro bleibt spürbar, aber der Seiteneingang ist zu. Der Werksleiter merkt vom Umbau praktisch nichts, der nächste Pentester findet dafür keine offene Tür mehr.

Verwandte Artikel

  • Pillar: Microsoft Entra ID – der komplette Leitfaden /entra-id-leitfaden/
  • Conditional Access Policies richtig aufbauen – Reihenfolge, Fallstricke, Blueprint /entra-conditional-access/
  • MFA-Methoden im Vergleich: Authenticator, FIDO2, Passkeys und Co. /entra-mfa-methoden/
  • Conditional-Access-Blockaden debuggen mit dem Was-wäre-wenn-Tool /entra-conditional-access-debuggen/
  • Sign-in Logs lesen und AADSTS-Fehlercodes entschlüsseln /entra-signin-logs-fehlercodes/
  • Häufige Fragen (FAQ)

    Blockiert eine Named Location automatisch unerwünschte Anmeldungen?

    Nein. Eine Named Location ist nur ein benannter Standort und trifft selbst keine Entscheidung. Sie wirkt erst, wenn eine Conditional-Access-Policy sie als Bedingung verwendet – etwa um aus bestimmten Ländern zu blockieren oder außerhalb des Büros MFA zu verlangen. Ohne passende Policy passiert gar nichts.

    Sind Ländersperren ein wirksamer Schutz?

    Nur begrenzt. Der Standort wird aus der IP-Adresse abgeleitet, und die lässt sich mit einem günstigen VPN oder Proxy im erlaubten Land trivial fälschen. Ländersperren reduzieren das Grundrauschen aus Massen-Angriffen und sind als zusätzliche Hürde sinnvoll – als alleiniger Schutz ohne MFA sind sie aber ein Trugschluss.

    Was ist der Unterschied zwischen dem trusted-Flag und MFA-Trusted-IPs?

    Das trusted-Flag an einer Named Location ist ein Signal, das du in Conditional-Access-Policies gezielt nutzen kannst – etwa um im Büro auf den MFA-Prompt zu verzichten. Die alte MFA-Trusted-IPs-Funktion dagegen befreit ein ganzes Netz pauschal von MFA, oft tenant-weit. Letztere ist eine riskante Altlast, die du aufspüren und entfernen solltest.

    Sollte ich das Büro-Netz komplett von MFA ausnehmen?

    Besser nicht. Wer ein ganzes Netz von MFA befreit, schafft einen offenen Seiteneingang: Jeder, der ins Netz gelangt, umgeht damit die gesamte MFA. Sinnvoller ist eine gezielte Policy, die aus dem Büro lediglich seltener nach MFA fragt oder das Sitzungsintervall verlängert – Komfort ja, Pauschal-Bypass nein.

    Brauche ich für Named Locations eine kostenpflichtige Lizenz?

    Named Locations selbst gibt es in Entra ID Free. Um sie als Bedingung in einer Conditional-Access-Policy einzusetzen – und nur dann entfalten sie ihre Wirkung – brauchst du mindestens P1, wie für Conditional Access insgesamt.

    Wie sollte ich Ländersperren am besten konfigurieren?

    Als Deny-Liste statt Allow-Liste. Sperre gezielt die Länder, aus denen garantiert niemand legitim zugreift, statt nur ein einziges Land zu erlauben. Eine enge Allow-Liste blockiert sonst Geschäftsreisende, Urlauber und Home-Office im Ausland – und produziert vermeidbare Support-Tickets.

    Wie geht es weiter?

    Dein nächster Schritt

    Du willst wissen, ob in deinem Tenant noch alte Trusted-IP-Reste oder unsaubere Standort-Ausnahmen schlummern, die deine MFA still aushebeln? Im Entra-ID-Health-Check gehe ich genau diese versteckten Seiteneingänge durch, prüfe deine Named Locations und Standort-Policies und liefere dir eine klare Liste, was bleiben darf und was raus muss. Eine ehrliche Bestandsaufnahme, bevor es ein Pentester oder ein Angreifer für dich erledigt.