Ein Desktopzugang, eine selbst betriebene Webanwendung und ein Cloud-Verwaltungsportal stellen unterschiedliche Anforderungen an die Anmeldung. Für den Benutzer soll sich der Wechsel trotzdem möglichst vertraut anfühlen.
Microsoft Entra ID kann diese Anmeldewege verbinden. Anhand ausgewählter Integrationsmuster erklären wir, wie persönliche Identitäten, zusätzliche Absicherung und anwendungsbezogene Berechtigungen zusammenspielen. Die Beispiele sind keine vollständige Aufstellung unserer Verwaltungszugänge.
Eine Identität verbindet verschiedene Welten
Entra ID übernimmt bei diesen Anbindungen die Prüfung der Identität. Die Anwendung vertraut dem vereinbarten Anmeldeverfahren und ordnet die bestätigte Person ihrem eigenen Benutzerbestand zu. SSO, also Single Sign-on, kann dabei bereits vorhandene Anmeldesitzungen nutzen. Wir müssen dadurch nicht bei jedem Wechsel wieder ein eigenes Anwendungspasswort eingeben.
Die beteiligten Systeme müssen nicht auf dieselbe Weise angebunden sein. Ein Gateway kann zwischen Cloud-Anmeldung und Desktopumgebung vermitteln. Eine Webanwendung kann über einen Application Proxy veröffentlicht werden, während ein Cloud-Portal eine eigene SSO-Integration verwendet. Für den Benutzer sieht vieles ähnlich aus; im Betrieb brauchen die Wege eigene Prüfungen.
Citrix: Vom Microsoft-Login bis zum Windows-Desktop
Ein Beispiel ist ein Citrix-Zugang mit NetScaler: Der Einstieg am Gateway führt zur Entra-Anmeldung. Über SAML erhält NetScaler eine signierte Bestätigung der Identität. StoreFront stellt die berechtigten Ressourcen bereit. Für die anschliessende Windows-Anmeldung kann der Citrix Federated Authentication Service, kurz FAS, eingesetzt werden.
FAS ist dabei ein wichtiger Baustein: Die erfolgreiche Anmeldung bei Entra übergibt nicht einfach das Windows-Passwort an die gesamte Citrix-Kette. Der konfigurierte FAS-Weg ermöglicht die Zertifikatsanmeldung an der Windows-Sitzung. Die NetScaler-Dokumentation zur Entra-SAML-Anbindung beschreibt die Rollen von Identitätsanbieter und Gateway; die nachgelagerten Citrix-Komponenten müssen dazu passen.
In einem solchen Test gelang der Windows-Start mit FAS. Frühere StoreFront- und App-Startfehler machten deutlich: Eine erfolgreiche Microsoft-Anmeldung und eine sichtbare Anwendungsliste sind jeweils nur ein Teil des Wegs. Zur Prüfung gehört auch der tatsächliche Start der Sitzung. Browserzugang und native Workspace-App können unterschiedliche Fehler zeigen.
IPAM: Eine eigene Anwendung mit vorgelagerter Anmeldung
Eine selbst betriebene Webanwendung wie phpIPAM lässt sich mit vorgeschalteter Entra-Anmeldung verbinden. Bei einer Veröffentlichung über Microsoft Entra Application Proxy prüft Entra den Zugang; ein Connector vermittelt zur internen Webanwendung. Innerhalb der Anwendung kann SAML die bestätigte Person ihrem persönlichen Anwendungskonto zuordnen.
Diese beiden Aufgaben gehören zusammen: Der Application Proxy regelt den veröffentlichten Zugangsweg, während die Anwendung selbst weiterhin Benutzer und Rechte kennt. Eine Weiterleitung zum Anmeldeverfahren ist dabei von einer direkten Veröffentlichung des Anwendungsservers zu unterscheiden.
Im untersuchten SAML-Test waren persönlicher Login, zusätzliche Authenticator-Bestätigung und lesende Funktionstests in einer privaten Browsersitzung erfolgreich. Die Berechtigungen bleiben dabei eine Aufgabe der Anwendung und müssen unabhängig von der Anmeldung geprüft werden.
Für diesen Zugangsweg benötigt der Connector ausgehende Verbindungen zum Microsoft-Dienst. Das unterscheidet ihn von einer direkten eingehenden Veröffentlichung des Backends. Microsoft erläutert das in den Sicherheitshinweisen zum Application Proxy. Zusätzliche Zugangswege brauchen eine eigene Prüfung und werden nicht automatisch durch die Vorauthentifizierung geschützt.
Checkmk: Auch das Monitoring braucht einen persönlichen Zugang
Auch eine Monitoringoberfläche braucht eine geprüfte Identitätsübergabe. Eine vorgeschaltete SAML-Komponente kann die bestätigte Identität an Checkmk Community weiterreichen. Die integrierte SAML-Anbindung anderer Checkmk-Editionen ist ein eigener Weg; die Checkmk-Dokumentation zur SAML-Anmeldung beschreibt die editionsabhängigen Möglichkeiten.
Der persönliche Entra-Login und die erfüllte MFA-Anforderung sind für die geprüfte Instanz bestätigt. Wichtig war auch eine Gegenprobe: Ein gefälschter Benutzerheader ohne gültige Sitzung führte zur lokalen Login-Seite und verschaffte keinen angemeldeten Zugang. Eine vom Browser gelieferte Benutzerbehauptung darf nicht einfach als geprüfte Identität gelten.
Die Ergebnisse gelten für den geprüften Zugang. Abmeldung, maschinelle Zugänge und die Kommunikation von Agenten sind separate Prüfgegenstände. Browser-SSO deckt diese Wege nicht automatisch ab.
Action1: Identität zentral, Geräteaktionen gezielt berechtigen
Bei Action1 geht es um weitreichende Verwaltungsfunktionen. Wer Software verteilen, Updates auslösen oder Geräte fernsteuern darf, braucht mehr als eine erfolgreiche Anmeldung. Deshalb betrachten wir die Entra-Anbindung und die Rollen in Action1 getrennt.
Bei einer SSO-Umstellung müssen bestehende Benutzer gezielt berücksichtigt werden. Das Aktivieren des Identitätsanbieters migriert ihre Anmeldung nicht automatisch. Die Action1-Anleitung zu Entra-SSO beschreibt den Übergang und die Bedeutung eines unabhängig geprüften Notfallzugangs.
Ein Test auf einem weiteren Gerät kann neben der zentralen Anmeldung zusätzliche Bestätigungen auslösen. Zentraler Login bedeutet nicht, dass jede Anwendung auf eigene Prüfungen verzichtet. Organisationsumfang und Geräteaktionen müssen zusätzlich über die jeweiligen Rollen begrenzt und mit Testkonten geprüft werden.
Zyxel Nebula: Portalzugang und Gerätezugang auseinanderhalten
Bei Netzwerk-Verwaltungsportalen wie Zyxel Nebula ist eine Entra-Integration ein weiterer möglicher Anmeldeweg. Der Portalzugang und die Anmeldung am einzelnen Gerät bleiben dabei unterschiedliche Aufgaben.
Bei Zyxel ist der Umfang der Umstellung besonders wichtig: Der Hersteller beschreibt einen Wechsel des Anmeldeverfahrens für die betroffene Unternehmensdomain. Das ist mehr als ein zusätzlicher Login-Knopf für eine einzelne Person. Die Zyxel-Beschreibung der Entra-Integration erklärt diese Reichweite.
Eine Person braucht weiterhin die passenden Organisations- und Standortrechte in Nebula. Die Entra-App-Zuweisung allein vergibt diese nicht. Portalzugang, lokale Geräteanmeldung und Notfallzugang müssen jeweils zum vorgesehenen Berechtigungskonzept passen.
Weshalb das Handy nicht bei jedem Klick fragt
Eine wiederkehrende Frage lautet: Funktioniert MFA überhaupt, wenn diesmal keine Authenticator-Abfrage erscheint? Bei einem dokumentierten Action1-Login meldete Entra die MFA-Anforderung als erfüllt, weil ein vorhandener Nachweis im Token anerkannt wurde. Eine erneute Abfrage war für diesen Vorgang nicht erforderlich.
Entscheidend ist deshalb die Auswertung der konkreten Anmeldung: Welche Anforderungen galten, welche Richtlinien wurden angewendet und wie wurde die Authentifizierung erfüllt? Die Microsoft-Anleitung zur MFA-Auswertung erläutert diese Unterschiede. Aus einem einzelnen erfolgreichen Vorgang leiten wir keine pauschale Aussage über alle Konten und Anwendungen ab.
Gemeinsam anmelden, bewusst berechtigen
Der gemeinsame Nenner dieser Integrationsmuster ist die persönliche Identität. Die Berechtigung bleibt anwendungsbezogen: Ressourcen, Datenbereiche, Verwaltungsrollen und Organisationszuordnungen haben jeweils ihre eigene Wirkung. Ob fremde Bereiche tatsächlich ausgeschlossen sind, lässt sich mit gezielten Gegenproben prüfen.
Zur Planung gehören auch Lizenzen und Rückfallwege. Für Application Proxy setzt Microsoft eine entsprechende Entra-ID-P1- oder P2-Berechtigung voraus. Vor einer Erweiterung müssen wir den tatsächlichen Lizenzumfang pro Benutzer prüfen. Ein Notfallkonto wiederum hilft nur, wenn dessen Zugangsdaten und gegebenenfalls E-Mail-Codes auch bei einer Störung erreichbar bleiben.
Für unsere KMU-Betreuung liegt der Nutzen darin, die Anmeldung über unterschiedliche Systeme hinweg verständlicher und gezielter steuerbar zu machen. Die Arbeit verschwindet dadurch nicht. Sie verlagert sich zu sauberer Benutzerzuordnung, passenden Anwendungsrechten und geprüften Wiederherstellungswegen. Genau diese Zusammenhänge dokumentieren wir inzwischen systematisch – damit beim nächsten neuen Dienst bereits klar ist, welche Fragen wir stellen müssen.