Wie veröffentliche ich i-net-Anwendungen über Microsoft Entra Application Proxy mit SSO?

General
1

Kurzantwort: i-net Clear Reports, i-net PDFC, i-net HelpDesk und i-net CoWork können über Microsoft Entra Application Proxy erreichbar gemacht werden. Richten Sie in der jeweiligen i-net-Anwendung zusätzlich die Anmeldung mit Microsoft Entra ID über OAuth ein. Setzen Sie die öffentlich sichtbare URL im i-net-Webserver auf die externe HTTPS-Adresse, deaktivieren Sie für diese Anbindung HTTP/2 im integrierten i-net-Webserver und testen Sie die Anmeldung mit einem zugewiesenen Benutzer. Eine erfolgreiche Vorab-Authentifizierung am Proxy allein meldet den Benutzer noch nicht in der i-net-Anwendung an.

Voraussetzungen

  • Die i-net-Anwendung unterstützt die Anmeldung mit Microsoft Entra ID über OAuth und ist im internen Netz erreichbar.
  • Ein Microsoft-Entra-Mandant mit Administratorzugang und einer Microsoft Entra ID P1- oder P2-Lizenz steht bereit.
  • Ein Private Network Connector ist installiert und erreicht die interne i-net-Adresse.
  • Eine externe HTTPS-Adresse ist festgelegt. Application Proxy unterstützt für die externe URL keinen frei wählbaren Port; verwenden Sie HTTPS auf Port 443.
  • Es ist festgelegt, welche Benutzer oder Gruppen Zugriff erhalten sollen.
  • Bei bestehenden i-net-Konten ist geklärt, welcher Entra-Benutzername zum i-net-Benutzernamen gehört.

Schematische Ansicht: Der Weg vom Browser über Microsoft Entra ID und den Private Network Connector zum i-net-Server. Die Entra-Vorab-Authentifizierung und die Kontozuordnung in der i-net-Anwendung sind getrennte Schritte.

Ablauf über Microsoft Entra Application Proxy zum i-net-Server
Ablauf über Microsoft Entra Application Proxy zum i-net-Server1600×600 64.5 KB

Einrichtung

  1. Öffentliche URL im i-net-Webserver setzen. Öffnen Sie Web Server → Advanced → External visible URL und tragen Sie die vollständige URL ein, unter der Benutzer die Anwendung öffnen, zum Beispiel https://app.example.com/helpdesk. Protokoll, Hostname und gegebenenfalls Anwendungskontext müssen übereinstimmen. Die Einstellung wird unter anderem für absolute Links verwendet. Sie ändert nicht die interne Adresse, auf der der Server lauscht.

  2. HTTP/2 am i-net-Webserver deaktivieren. Für die Anbindung über Microsoft Entra Application Proxy deaktivieren Sie unter Web Server → Performance → Enable HTTP/2 die HTTP/2-Option des integrierten i-net-Webservers. Starten Sie danach den i-net-Server neu.

  3. Anwendung in Microsoft Entra veröffentlichen. Legen Sie unter Entra ID → Enterprise apps → New application eine lokale Anwendung (On-premises application) an. Die Internal URL ist die i-net-Adresse, die der Connector erreicht. Die External URL ist die öffentliche Adresse aus External visible URL. Wählen Sie Pre-Authentication = Microsoft Entra ID und die passende Connector Group. Weisen Sie anschließend die Benutzer oder Gruppen zu, die Zugriff erhalten sollen. Erteilen Sie für eine neu erstellte Proxy-Anwendung außerdem die Administratorzustimmung für User.Read, wie in der Microsoft-Anleitung beschrieben.

  4. URL-Umschreibung ausschalten. Wählen Sie Translate URLs in Headers = No und Translate URLs in Application Body = No. Die i-net-Anwendung verwendet bereits die unter External visible URL eingetragene öffentliche Adresse. Testen Sie danach Links und Weiterleitungen über die externe URL.

  5. Separate OAuth-App registrieren. Erstellen Sie unter App registrations eine Web-Anwendung für den i-net-OAuth-Login. Verwenden Sie hierfür nicht die automatisch zum Application Proxy gehörende App-Registrierung. Tragen Sie als Redirect-URI die externe Basis-URL mit /login/azure ein, zum Beispiel https://app.example.com/helpdesk/login/azure. Notieren Sie die Application (Client) ID und erstellen Sie einen Client Secret. Wenn nur Benutzer Ihres Entra-Mandanten zugelassen werden sollen, wählen Sie bei der Registrierung Single tenant und notieren Sie auch die Directory (Tenant) ID. Geben Sie Secrets nie in Tickets, Screenshots oder FAQ-Beispielen weiter.

  6. OAuth in der i-net-Anwendung einrichten. Aktivieren Sie den Microsoft-Azure-/Entra-OAuth-Provider in der i-net-Konfiguration. Tragen Sie Client ID und Client Secret ein. Bei einer App für nur einen Mandanten tragen Sie auch die Tenant ID ein. Testen Sie den OAuth-Login über die externe URL in einer neuen privaten Browsersitzung. Prüfen Sie, welches i-net-Konto verwendet wird und ob dessen Rollen und Berechtigungen stimmen.

SSO und Benutzerkonten

Nach der Entra-Vorab-Authentifizierung leitet der Connector die Anfrage an den i-net-Server weiter. Erst der konfigurierte i-net-OAuth-Login ordnet die Entra-Identität einem i-net-Konto zu. Wenn dieser Login gestartet wird und die Entra-Sitzung noch gültig ist, kann die Anmeldung ohne erneute Eingabe der Zugangsdaten erfolgen. Auf manchen Anmeldeseiten müssen Benutzer die Schaltfläche für Microsoft Entra ID zunächst auswählen.

Bestehendes Konto: Die i-net-Anwendung kann die Entra-Anmeldung mit einem vorhandenen Konto verbinden, wenn der übermittelte Benutzername zum i-net-Benutzernamen passt. Prüfen Sie mit einem Testbenutzer, ob das richtige Konto und dessen Berechtigungen verwendet werden. Ein gleicher Anzeigename oder dieselbe E-Mail-Adresse reicht für diese Prüfung nicht aus. Abweichende Aliase, Gastkonten und Schreibweisen können zu einem anderen Konto oder fehlenden Berechtigungen führen.

Neuer Benutzer: Existiert noch kein passendes i-net-Konto, hängt die Kontoerstellung von der jeweiligen Benutzer- und Anmeldekonfiguration ab. Prüfen Sie nach dem ersten Login das angelegte Konto und seine Berechtigungen.

Nur eigener Entra-Mandant: Registrieren Sie die OAuth-App für Konten Ihres Mandanten und tragen Sie dessen Tenant ID in der i-net-Anwendung ein. Prüfen Sie Gastzugriffe gesondert: Der Zugriff auf den Proxy verbindet ein Gastkonto nicht automatisch mit einem bestehenden i-net-Konto.

Fehler eingrenzen

Beobachtung Prüfen und beheben
Nach Entra erscheint eine weitere lokale Anmeldung Pre-Authentication muss Microsoft Entra ID statt Passthrough sein. Prüfen Sie, ob der i-net-OAuth-Provider aktiv ist, der OAuth-Login gestartet wird, die Redirect-URI auf die externe URL zeigt und der Benutzer einem i-net-Konto zugeordnet wird.
Redirect-Schleife oder interne/falsche Links Vergleichen Sie External visible URL, externe Proxy-URL, Anwendungskontext und Redirect-URI /login/azure. Prüfen Sie beide URL-Translation-Optionen und testen Sie erneut in einer privaten Browsersitzung. Falls zusätzlich ein Reverse Proxy eingesetzt wird, prüfen Sie dessen Weiterleitung anhand der Dokumentation zur Reverse-Proxy-Konfiguration.
502 oder leere Antwort Prüfen Sie Connector-Status und Connector Group, DNS und Netzwerkzugriff auf die Internal URL, Backend-TLS-Zertifikat, Port und Kontext. Prüfen Sie die i-net-HTTP/2-Einstellung und ob der Server danach neu gestartet wurde.
Anmeldung erfolgreich, aber falsches Konto oder fehlende Rechte Vergleichen Sie den von Entra übermittelten Benutzernamen mit dem Benutzernamen des bestehenden i-net-Kontos. Prüfen Sie Aliase und Gastkonten sowie die Rollen und Berechtigungen des tatsächlich angemeldeten Kontos.

Checkliste vor dem Produktivbetrieb

  • Externe HTTPS-URL auf Port 443, External visible URL und OAuth-Redirect-URI stimmen einschließlich Kontext überein.
  • Connector erreicht die interne i-net-URL; Connector Group und Benutzerzuweisung stimmen.
  • Entra-Vorab-Authentifizierung und beide URL-Translation-Optionen sind wie oben konfiguriert.
  • HTTP/2 am integrierten i-net-Webserver ist deaktiviert und der Server neu gestartet.
  • OAuth-App-Registrierung und Proxy-Enterprise-Application sind getrennt; Client ID, Secret und gegebenenfalls Tenant ID sind korrekt hinterlegt.
  • Ein externer Test mit einem bestehenden Benutzer bestätigt das richtige i-net-Konto und dessen Berechtigungen; ein Test mit einem neuen Benutzer prüft die gewünschte Kontoerstellung.
  • Weiterleitungen, Links und eine neue private Browsersitzung wurden getestet.

Weiterführende Dokumentation