M365 EntraID | Private Access für externe Benutzer

Der externe Dienstleister braucht Zugriff auf zwei Server im internen Netz. Klassisch bekommt er dafür einen VPN-Zugang, ein Konto in deinem Verzeichnis und im schlimmsten Fall ein Notebook, das du beschaffen, patchen und irgendwann zurückfordern musst.

Der VPN-Tunnel setzt ihn auf ein Netzsegment, die Beschränkung auf genau diese zwei Server passiert erst danach per Firewall-Regel. Wer sich in dieser Kette vertut, öffnet mehr als geplant, und niemand merkt es, solange nichts passiert.

External user access mit Global Secure Access dreht die Reihenfolge um. Der externe Benutzer bleibt in seinem Heimmandanten angemeldet, arbeitet auf seinem eigenen Gerät und wechselt im Global Secure Access Client gezielt in deinen Ressourcenmandanten.

Beim Wechsel entsteht ein Private-Access-Tunnel, der ausschließlich die Anwendungen transportiert, die du diesem Konto zugewiesen hast. Die Zuweisung ist die primäre Kontrolle, nicht die nachgelagerte Netzwerkregel.

Der Client ist im Heimmandanten des Dienstleisters angemeldet und fragt dort ab, in welchen fremden Mandanten dieses Konto als externer Benutzer existiert. Diese Mandanten erscheinen im Benutzermenü zur Auswahl. Der Heimmandant braucht dafür keine eigene Global-Secure-Access-Konfiguration, weil die Erkennung über die Identität läuft und nicht über ein Traffic-Forwarding-Profil.

Wählt der Benutzer deinen Mandanten aus, trennt der Client sämtliche bestehenden Tunnel zum Heimmandanten. Private Access, Internet Access und der Microsoft-Traffic-Tunnel fallen weg. Anschließend baut der Client einen einzelnen Private-Access-Tunnel zu deinem Mandanten auf. Diese Exklusivität ist kein Bug im Client, sondern eine Folge der Architektur: Ein Gerät kann zu einem Zeitpunkt nur einem Traffic-Forwarding-Profil folgen, und Profile sind mandantengebunden.

Für den Betrieb hat das eine Konsequenz, die du vor dem ersten Rollout klären solltest. Der Dienstleister verliert für die Dauer seiner Arbeit in deiner Umgebung die Absicherung durch die Internet-Access-Policy seines eigenen Arbeitgebers. Wenn dessen Compliance durchgehendes Web-Filtering verlangt, ist der Mandantenwechsel eine Abweichung, die auf seiner Seite dokumentiert werden muss.

Was durch den Tunnel läuft, entscheidet ausschließlich dein Mandant. Der Client zieht dein Private-Access-Profil und darin die Application Segments der Anwendungen, denen der Benutzer zugewiesen ist. Alles andere verlässt das Gerät direkt ins Internet des Partners. Ein Routing in dein Netz über die veröffentlichten Segmente hinaus gibt es nicht, weil es keinen Pfad dafür gibt.

Bevor es an die Konfiguration geht, trenne zwei Dinge sauber, die in vielen Anleitungen vermischt werden.

Der Standard-x64-Installer läuft nicht auf Arm64-Geräten. Wenn dein Partner mit einem Surface Laptop auf Snapdragon-Basis arbeitet, braucht er das gesonderte Arm-Paket.

Die Connectors sind stateless und speichern außer den Verbindungseinstellungen und dem Authentifizierungszertifikat nichts lokal. Ihre Konfiguration ziehen sie beim Verbindungsaufbau aus dem Dienst und aktualisieren sie alle paar Minuten.

Für Hochverfügbarkeit setzt du mindestens zwei Connectors pro Connector-Gruppe auf getrennte Server, weil ein einzelner Connector sonst zum Single Point of Failure für den gesamten Partnerzugriff wird.

Das externe Konto muss in deinem Mandanten als Objekt existieren. Beide Typen funktionieren: userType Guest aus der klassischen B2B-Einladung und userType Member, den Cross-Tenant Sync standardmäßig erzeugt. Für die Abrechnung ist der Unterschied allerdings erheblich, dazu gleich mehr.

Bei mehreren Partnerorganisationen mit vielen Konten lohnt sich Cross-Tenant Sync statt einzelner Einladungen. Die Synchronisierung legt die Konten automatisch an, aktualisiert Attribute und entfernt sie wieder, wenn sie im Quellmandanten wegfallen. Das nimmt dir einen Teil des Offboarding-Risikos ab, das bei manuell eingeladenen Gästen erfahrungsgemäß liegen bleibt.

Private Access muss in deinem Mandanten aktiv sein, das Private-Access-Profil muss den externen Konten zugewiesen sein, und mindestens eine private Anwendung muss veröffentlicht und demselben Konto zugewiesen sein.

Eine Gruppenzuweisung funktioniert, verschachtelte Gruppen dagegen nicht. Das ist eine Altlast aus dem Per-App-Access-Modell und fällt bei gewachsenen Gruppenstrukturen regelmäßig auf die Füße. Lege für externe Zugriffe flache, dedizierte Gruppen an, statt bestehende Verschachtelungen weiterzuverwenden.

Für die Verwaltung reicht die Rolle Global Secure Access-Administrator. Nach dem Prinzip der geringsten Berechtigung aktivierst du sie über PIM just in time, weil die Rolle Zugriff auf die gesamte Traffic-Steuerung des Mandanten hat und damit auf einen Pfad, über den sich Datenabflüsse umleiten ließen.

Eine Registrierung des Partnergeräts in deinem Mandanten ist nicht nötig. Das ist der eigentliche Gewinn gegenüber jedem Modell, das ein verwaltetes Gerät voraussetzt: Du bekommst BYOD-Zugriff, ohne fremde Hardware in dein Intune zu holen.

Im Heimmandanten des Dienstleisters ist keine Global-Secure-Access-Lizenz erforderlich. Ein Mandant mit Entra ID Free genügt, und den hat jede Organisation mit einem Microsoft-Konto ohnehin.

In deinem Mandanten sieht es anders aus, und hier ist die Doku seit dem Frühjahr 2026 deutlicher geworden. Gäste bekommen keinen P1- oder P2-Platz zugewiesen, sondern werden über ein Monthly-Active-User-Modell abgerechnet. Voraussetzung dafür ist, dass dein Mandant per Microsoft Entra External ID Subscription Linking mit einer Azure-Subscription verknüpft ist. Fehlt diese Verknüpfung, funktioniert der Zugriff nicht, weil die Nutzung nicht abgerechnet werden kann.

Gezählt wird pro Kalendermonat und pro Konto mit userType Guest, sobald sich dieses Konto mindestens einmal über den Global Secure Access Client in einen Private-Access-Tunnel anmeldet. Reine Anwesenheit im Verzeichnis kostet nichts, aktive Nutzung schon.

Zwei Details daran werden gern übersehen. Das Kontingent von 50.000 kostenlosen MAU, das viele aus der External-ID-Kalkulation kennen, gilt für Entra ID P1 und P2 und deckt Global Secure Access für Gäste nicht ab. Die Abrechnung hängt am Attribut, nicht an der Herkunft: Ein internes Konto, das aus einer alten Migration heraus userType Guest trägt, fällt in dasselbe Modell, sobald es den Client für Private Access nutzt. Wenn du dein Verzeichnis nicht sauber führst, zahlst du für eigene Mitarbeiter Gastgebühren.

Prüfen kannst du das in den Anmeldeprotokollen. Abrechnungsrelevante Anmeldungen tragen User type Guest, Cross tenant access type B2B collaboration, Application Global Secure Access Client und Client app Mobile Apps and Desktop clients.

Auf dem Gerät des externen Benutzers muss die Funktion explizit freigeschaltet werden. Der Wert liegt unter dem Client-Schlüssel in HKEY_LOCAL_MACHINE:

Der Wert 0x0 deaktiviert die Funktion wieder. Microsoft nennt MDM-Lösungen wie Intune sowie Gruppenrichtlinien als Wege für die Verteilung. Das ist derselbe Schlüsselpfad, unter dem auch die übrigen Client-Steuerwerte liegen, etwa HideDisableButton oder RestrictNonPrivilegedUsers.

Genau hier entsteht der organisatorische Aufwand, den die Feature-Beschreibung nicht abbildet. HKEY_LOCAL_MACHINE bedeutet lokale Administratorrechte auf einem Gerät, das dir nicht gehört und das du nicht verwaltest. Du kannst diesen Key nicht ausrollen. Der Partner muss ihn setzen, entweder manuell oder über seine eigene Geräteverwaltung.

Damit wird aus einer technischen Konfiguration eine Vertragsfrage. Nimm in die Dienstleistervereinbarung auf, wer den Key setzt, auf welchen Geräten er gesetzt wird und wer ihn zum Vertragsende wieder entfernt. Der Rückbau ist keine Formalie: Solange der Key gesetzt und das Gastobjekt in deinem Verzeichnis aktiv ist, kann sich das Gerät weiterhin in deinen Mandanten schalten. Die harte Abschaltung bleibt die Deaktivierung des Kontos oder der App-Zuweisung auf deiner Seite.

Der Partner hat den Client installiert, der Registry-Key ist gesetzt, du hast Profil und Anwendung zugewiesen. Dann sieht sein Weg so aus:

Er klickt auf das Global-Secure-Access-Symbol im Systray und öffnet damit die Statusanzeige des Clients. Über das Benutzermenü mit dem Profilbild bekommt er die Liste der Mandanten, in denen sein Konto als externer Benutzer existiert. Dort wählt er deinen Ressourcenmandanten aus. Der Client trennt daraufhin die Tunnel zum Heimmandanten und baut den Private-Access-Tunnel zu dir auf. Anschließend prüft er im Client, ob der angezeigte Organisationsname deinem Mandanten entspricht, und greift auf die zugewiesene Anwendung zu.

Der Rückweg läuft identisch: Systray-Symbol, Benutzermenü, Heimmandant auswählen. Der Client trennt den Private-Access-Tunnel zu dir und stellt die im Heimmandanten konfigurierten Tunnel wieder her.

Ein Detail für dein Partner-Runbook: Bestehende Sitzungen wie RDP bleiben beim Wechsel zunächst am vorherigen Mandanten hängen. Bricht die Verbindung ab, lässt sie sich nicht wieder aufbauen. Weise deine Partner an, sensible Sitzungen vor dem Wechsel sauber zu beenden.

Conditional Access greift bei Private Access nicht am Traffic-Profil, sondern an der Anwendung. Der Private-Access-Tunnel lässt sich als Ziel nicht adressieren, nur die Enterprise Applications dahinter. Du legst deine Richtlinien also auf die Quick-Access-App und die einzelnen Global-Secure-Access-Apps.

Cross-Tenant-Signale funktionieren: MFA und Gerätekonformität aus dem Heimmandanten werden akzeptiert, wenn du in den Cross-Tenant-Zugriffseinstellungen den entsprechenden Inbound Trust konfiguriert hast. Eine App-spezifische MFA-Anforderung für externe Konten ist möglich und sollte der Normalfall sein.

Eine Kontrolle musst du bewusst ausnehmen: Der Compliant Network Check wird für Private-Access-Anwendungen nicht unterstützt. Erzwingst du ihn per Richtlinie, scheitert der Zugriff externer Benutzer. Die Konsequenz ist eine dokumentierte Ausnahme in deinem Regelwerk, die du im Audit erklären können musst. Wer sein Zero-Trust-Konzept auf den Compliant Network Check als tragende Kontrolle gestützt hat, verliert diese Ebene für genau die Benutzergruppe, bei der das Restrisiko am höchsten ist.

Für die Nachvollziehbarkeit liefern die Traffic-Logs im Ressourcenmandanten zwei zusätzliche Felder: Cross-tenant access type mit dem Wert B2B collaboration und die Home tenant ID der Herkunftsorganisation. Damit lässt sich externer Zugriff sauber von internem trennen und auswerten.

Diese Grenze entscheidet in vielen Umgebungen über die gesamte Machbarkeit: Externe Benutzer erreichen über Private Access keine Ressourcen, die Kerberos-Authentifizierung voraussetzen. Betroffen sind SMB-Dateifreigaben, Anwendungen mit Integrated Windows Authentication und alles Weitere, was auf Kerberos-Tickets aufsetzt.

Der Grund liegt in der Identität: Der externe Benutzer authentifiziert sich gegen seinen Heimmandanten. Ein Kerberos-Ticket für deine Domäne bekommt er dadurch nicht, und eine Delegation über die Mandantengrenze gibt es nicht.

Für Webanwendungen mit IWA bleibt der klassische Weg über Microsoft Entra Application Proxy mit Kerberos Constrained Delegation. Der Connector übernimmt dort die Kerberos-Authentifizierung stellvertretend für den vorauthentifizierten Benutzer.

Für Dateifreigaben bleiben drei Optionen: eine an deinen Mandanten gebundene VM über Windows 365 oder Azure Virtual Desktop, ein separater VPN-Zugang für genau diesen Anwendungsfall, oder die Ablösung der Freigabe durch SharePoint Online.

Prüfe diesen Punkt vor allem anderen. Wenn der Dienstleister im Kern auf Fileshares arbeitet, trägt das BYOD-Modell den Anwendungsfall nicht, unabhängig davon, wie sauber der Rest konfiguriert ist.

Für die Diagnose auf dem Partnergerät liefert der Client selbst zwei Werkzeuge: die Ansicht Troubleshooting mit Log-Export und das Advanced-Diagnostics-Tool. Beides erreichst du über das Symbol im Systray. Die Logs landen standardmäßig unter C:\Program Files\Global Secure Access Client\Logs.

Für Szenarien mit vielen externen Benutzern gibt es einen zweiten Weg, der den Registry-Key und den manuellen Wechsel überflüssig macht. Stellst du Windows 365 oder Azure Virtual Desktop im Single-Session-Betrieb bereit und konfigurierst External ID Linking, ist die virtuelle Maschine an deinen Mandanten gebunden. Der Global Secure Access Client auf der VM authentifiziert den externen Benutzer automatisch gegen deinen Mandanten, weil die Domänenzugehörigkeit der VM eindeutig ist.

In diesem Modell kannst du Private Access, Internet Access und Microsoft-365-Traffic-Policies auf externe Identitäten anwenden, also die volle Kontrolle behalten statt nur den Private-Access-Pfad. Auch Kerberos-Ressourcen sind erreichbar, weil die Sitzung in deiner Umgebung läuft. Für MSPs und für Umgebungen mit regulatorischen Anforderungen an die Arbeitsumgebung ist das die sauberere Variante. Sie kostet dafür VM-Laufzeit und Windows-365-Lizenzen, die du gegen den MAU-Preis des BYOD-Modells rechnen musst.

Das Risikodelta gegenüber klassischem VPN ist real und lässt sich benennen. Der externe Zugriff endet an der Anwendungsgrenze statt am Netzsegment, jede Sitzung ist einer Identität und einer Herkunftsorganisation zugeordnet, und Continuous Access Evaluation zieht Token bei Risikoereignissen zeitnah zurück. Für die Prüfung nach ISO 27001 sind das belastbare Belege zu den Maßnahmen A.5.19 bis A.5.22 zu Lieferantenbeziehungen, für NIS2 zur Absicherung der Lieferkette.

Das Restrisiko bleibt aber sichtbar: Das Gerät ist nicht verwaltet, der Compliant Network Check entfällt, Kerberos-Ressourcen sind nicht erreichbar, und die Aktivierung hängt an einem Registry-Wert im Verantwortungsbereich des Partners. Wer diese Punkte nicht in Vertrag, Access Reviews und Offboarding-Prozess spiegelt, hat die technische Kontrolle verbessert und die organisatorische Lücke behalten. Ein Ablaufdatum auf Gastkonten und wiederkehrende Zugriffsüberprüfungen sind hier keine Kür.

Kaufmännisch ist die MAU-Abrechnung dann günstig, wenn Externe sporadisch zugreifen, etwa für Wartungsfenster oder Projektphasen. Bei Dienstleistern, die täglich in deiner Umgebung arbeiten, kann ein regulärer Lizenzplatz oder die AVD-Variante günstiger sein. Rechne das mit echten Nutzungszahlen aus den Anmeldeprotokollen durch, bevor du das Modell auf alle Partner ausrollst.

Externer Benutzerzugriff über Microsoft Entra Private Access löst ein Problem, das mit VPN-Zugängen nie sauber lösbar war: Der Dienstleister nutzt seine eigene Identität und sein eigenes Gerät, und trotzdem endet sein Zugriff exakt an den Anwendungen, die du ihm zugewiesen hast. Der Verzicht auf Gerätemanagement und Netzsegmentierung senkt den Aufwand pro Partner erheblich, und die Trennung nach Herkunftsmandant in den Traffic-Logs liefert eine Nachvollziehbarkeit, die eine Firewall-Regel für ein VPN-Subnetz nie erreicht hat.

Vier Punkte solltest du vor der Einführung geklärt haben.

Für Umgebungen mit wenigen, klar abgegrenzten Dienstleistern, modernen Anwendungen und einer bereits laufenden Private-Access-Installation ist die Funktion eine sinnvolle Ergänzung, die du in wenigen Stunden aufsetzt. Für Szenarien mit hoher Regulierungsdichte, vielen parallelen Partnern oder Abhängigkeit von Fileshares lohnt der Blick auf die Variante mit Windows 365 oder AVD und External ID Linking, weil du dort die vollständige Traffic-Kontrolle behältst und keinen Eingriff auf fremden Geräten brauchst.