RDWeb + Application Proxy - Mehrfache Credential-Abfrage - Kein Zugriff von extern
Hallo Zusammen
Wir haben bei uns aktuell folgendes Thema: Wir verabschieden uns von unserer Citrix-Farm, da einerseits die Lizenzen immer teurer werden, andererseits da es nur noch 2 Sessions pro Woche gibt, die effektiv genutzt werden.
Wir haben uns somit für eine neue RDS-Farm auf Windows-Server 2022 entschieden und diese nun konfiguriert, auch mit einem Application Proxy auf Azure, um den Zugriff auch für Lieferanten weiterhin zugänglich zu machen.
Wir haben aktuell zwei Probleme:
Das erste ist, dass intern soweit alles eigentlich soweit funktioniert, bis auf das, dass beim Zugriff auf sowohl RDWeb als auch den HTML5-Webclient die Credentials doppelt, bzw. dreifach abgefragt werden - im Klartext folgende Schritte:
Zusätzlich beim HTML5-Webclient folgt nochmals eine Eingabe der Credentials mittels Login-Maske auf https://login.domain.ch/RDWeb/Webclient/
Somit haben wir einerseits eine Abfrage der Credentials für den ApplicationProxy, zusätzlich RDWeb und nochmals für den HTML5-Webclient, was deutlich zu viel ist.
Info: Wir haben grundsätzlich SSO für RDWeb gemäss folgendem Link eingerichtet: blog.matrixpost.net/sso-single-sign-on-to-your-onpremise-rds-remote-desktop-services-2016-2019-environment/
Das zweite Problem ist, dass wenn wir von extern von einem privaten Gerät welches nicht Unternehmensgerät ist, versuchen auf die entsprechende Domain zuzugreifen, die Weiterleitung funktioniert, aber die Credentials nicht akzeptiert werden, hier passiert in allen Browsern nach erfolgreichem Login in das Microsoft-Konto eine Credential-Abfrage vor dem Login, bzw. der Weiterleitung zu RDWeb, respektive dem RDWeb Webclient (Siehe Screenshot mit maskiertem Domain-Name im Anhang). Bei Abbruch erhalte ich lediglich folgende, logische, Errormeldung:
Detaillierte Fehlerinformationen:
Modul IIS Web Core
Benachrichtigung AuthenticateRequest
Handler ExtensionlessUrlHandler-Integrated-4.0
Fehlercode 0x80070005
Angeforderte URL https://login.domain.ch:443/RDWeb/
Physischer Pfad C:\Windows\Web\RDWeb\
Anmeldemethode Noch unbestimmt
Benutzeranmeldung Noch unbestimmt
Mit einem vom internen Zertifikatserver ausgestellten Zertifikat für die externen und internen FQDN's funktioniert sowohl die Credential-Abfrage sowohl der Webclient, ein Download der RDP-Files funktioniert auch, es kann jedoch keine Verbindung aufgebaut werden, da das RootCA nicht auf nicht Unternehmensgeräten publiziert wird, weshalb wir uns für den Einsatz eines Drittanbiter-Zertifikats entschieden haben.
Wir haben hierzu dem IIS ein Binding für die externe Domäne, sowie entsprechend das Zertifikat zugewiesen, einen internen DNS-Eintrag auf die entsprechende IP des RD-Brokers gesetzt, sowie in den Bereitstellungseigenschaften ein 3rd-Party-Zertifikat (Zum Testing von ZeroSSL) für Web Access und den RD-Gateway gesetzt. Zusätzlich ist dieses Zertifikat auch auf dem Application Proxy in Azure eingerichtet.
Vielleicht könnt ihr hier weiterhelfen, oder habt einen Ansatz, was wir hier falsch machen.
Ich danke euch im Voraus für eure konstruktive Antworten!
Liebe Grüsse
the.frickman
Wir haben bei uns aktuell folgendes Thema: Wir verabschieden uns von unserer Citrix-Farm, da einerseits die Lizenzen immer teurer werden, andererseits da es nur noch 2 Sessions pro Woche gibt, die effektiv genutzt werden.
Wir haben uns somit für eine neue RDS-Farm auf Windows-Server 2022 entschieden und diese nun konfiguriert, auch mit einem Application Proxy auf Azure, um den Zugriff auch für Lieferanten weiterhin zugänglich zu machen.
Wir haben aktuell zwei Probleme:
Das erste ist, dass intern soweit alles eigentlich soweit funktioniert, bis auf das, dass beim Zugriff auf sowohl RDWeb als auch den HTML5-Webclient die Credentials doppelt, bzw. dreifach abgefragt werden - im Klartext folgende Schritte:
- Zugriff auf login.domain.ch
- Authentifizierung via Microsoft-Konto (Azure)
- Weiterleitung zu RDWeb (HTTP-Umleitung auf IIS konfiguriert (/RDWeb) mit Statuscode 302 und Anforderungen zu Inhalt in diesem Verzeichnis (nicht Unterverzeichnissen) umleiten ist angehakt)
- Zusätzliche Abfrage der Domain-Credentials über den Browser (Siehe Screenshot mit maskiertem Domain-Name im Anhang)
- RDWeb funktioniert
Zusätzlich beim HTML5-Webclient folgt nochmals eine Eingabe der Credentials mittels Login-Maske auf https://login.domain.ch/RDWeb/Webclient/
Somit haben wir einerseits eine Abfrage der Credentials für den ApplicationProxy, zusätzlich RDWeb und nochmals für den HTML5-Webclient, was deutlich zu viel ist.
Info: Wir haben grundsätzlich SSO für RDWeb gemäss folgendem Link eingerichtet: blog.matrixpost.net/sso-single-sign-on-to-your-onpremise-rds-remote-desktop-services-2016-2019-environment/
Das zweite Problem ist, dass wenn wir von extern von einem privaten Gerät welches nicht Unternehmensgerät ist, versuchen auf die entsprechende Domain zuzugreifen, die Weiterleitung funktioniert, aber die Credentials nicht akzeptiert werden, hier passiert in allen Browsern nach erfolgreichem Login in das Microsoft-Konto eine Credential-Abfrage vor dem Login, bzw. der Weiterleitung zu RDWeb, respektive dem RDWeb Webclient (Siehe Screenshot mit maskiertem Domain-Name im Anhang). Bei Abbruch erhalte ich lediglich folgende, logische, Errormeldung:
Detaillierte Fehlerinformationen:
Modul IIS Web Core
Benachrichtigung AuthenticateRequest
Handler ExtensionlessUrlHandler-Integrated-4.0
Fehlercode 0x80070005
Angeforderte URL https://login.domain.ch:443/RDWeb/
Physischer Pfad C:\Windows\Web\RDWeb\
Anmeldemethode Noch unbestimmt
Benutzeranmeldung Noch unbestimmt
Mit einem vom internen Zertifikatserver ausgestellten Zertifikat für die externen und internen FQDN's funktioniert sowohl die Credential-Abfrage sowohl der Webclient, ein Download der RDP-Files funktioniert auch, es kann jedoch keine Verbindung aufgebaut werden, da das RootCA nicht auf nicht Unternehmensgeräten publiziert wird, weshalb wir uns für den Einsatz eines Drittanbiter-Zertifikats entschieden haben.
Wir haben hierzu dem IIS ein Binding für die externe Domäne, sowie entsprechend das Zertifikat zugewiesen, einen internen DNS-Eintrag auf die entsprechende IP des RD-Brokers gesetzt, sowie in den Bereitstellungseigenschaften ein 3rd-Party-Zertifikat (Zum Testing von ZeroSSL) für Web Access und den RD-Gateway gesetzt. Zusätzlich ist dieses Zertifikat auch auf dem Application Proxy in Azure eingerichtet.
Vielleicht könnt ihr hier weiterhelfen, oder habt einen Ansatz, was wir hier falsch machen.
Ich danke euch im Voraus für eure konstruktive Antworten!
Liebe Grüsse
the.frickman
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 7480233755
Url: https://administrator.de/forum/rdweb-application-proxy-mehrfache-credential-abfrage-kein-zugriff-von-extern-7480233755.html
Ausgedruckt am: 28.04.2025 um 01:04 Uhr
2 Kommentare
Neuester Kommentar
Hi,
die doppelte Authentifzierung ist in deinem Konstrukt gewollt und lässt sich auch nicht "wegbauen"
Siehe: https://learn.microsoft.com/en-us/azure/active-directory/app-proxy/appli ...
Durch die Nutzung von einem Azure Application Proxy und der damit verbundenen Authentifizierung am Azure AD wird Conditonal Access ein Thema, eigentlich eher ein Feature, als ein Problem, insofern korrekt konfiguriert.
Schau also mal nach, wie eure Conditonal Access Policies aufgebaut sind (z.B. jeder muss ein unternehmensdevice haben) Auf Gäste kann man idr. vorallem gerätebasierende Policies nicht anwenden, die muss man hier excluden. Mittlerweile gibts dafür sogar vordefinierte Häkchen, die automatisch alle Gäste excluded (Auch Gäste die danach erstellt werden)
die doppelte Authentifzierung ist in deinem Konstrukt gewollt und lässt sich auch nicht "wegbauen"
Siehe: https://learn.microsoft.com/en-us/azure/active-directory/app-proxy/appli ...
Durch die Nutzung von einem Azure Application Proxy und der damit verbundenen Authentifizierung am Azure AD wird Conditonal Access ein Thema, eigentlich eher ein Feature, als ein Problem, insofern korrekt konfiguriert.
Schau also mal nach, wie eure Conditonal Access Policies aufgebaut sind (z.B. jeder muss ein unternehmensdevice haben) Auf Gäste kann man idr. vorallem gerätebasierende Policies nicht anwenden, die muss man hier excluden. Mittlerweile gibts dafür sogar vordefinierte Häkchen, die automatisch alle Gäste excluded (Auch Gäste die danach erstellt werden)
Zitat von @Cloudrakete:
Hi,
die doppelte Authentifzierung ist in deinem Konstrukt gewollt und lässt sich auch nicht "wegbauen"
Siehe: https://learn.microsoft.com/en-us/azure/active-directory/app-proxy/appli ...
Durch die Nutzung von einem Azure Application Proxy und der damit verbundenen Authentifizierung am Azure AD wird Conditonal Access ein Thema, eigentlich eher ein Feature, als ein Problem, insofern korrekt konfiguriert.
Schau also mal nach, wie eure Conditonal Access Policies aufgebaut sind (z.B. jeder muss ein unternehmensdevice haben) Auf Gäste kann man idr. vorallem gerätebasierende Policies nicht anwenden, die muss man hier excluden. Mittlerweile gibts dafür sogar vordefinierte Häkchen, die automatisch alle Gäste excluded (Auch Gäste die danach erstellt werden)
Hi,
die doppelte Authentifzierung ist in deinem Konstrukt gewollt und lässt sich auch nicht "wegbauen"
Siehe: https://learn.microsoft.com/en-us/azure/active-directory/app-proxy/appli ...
Durch die Nutzung von einem Azure Application Proxy und der damit verbundenen Authentifizierung am Azure AD wird Conditonal Access ein Thema, eigentlich eher ein Feature, als ein Problem, insofern korrekt konfiguriert.
Schau also mal nach, wie eure Conditonal Access Policies aufgebaut sind (z.B. jeder muss ein unternehmensdevice haben) Auf Gäste kann man idr. vorallem gerätebasierende Policies nicht anwenden, die muss man hier excluden. Mittlerweile gibts dafür sogar vordefinierte Häkchen, die automatisch alle Gäste excluded (Auch Gäste die danach erstellt werden)
Danke für deine konstruktive Antwort.
Grundsätzlich haben wir mehrere Conditional Access Policies, die aber hier nicht reinspielen. Mit meinem privaten Computer kann ich mich verbinden. Es besteht hier "lediglich" das Problem, dass ich mit meinem privaten PC keine Vebindung aufbauen kann, sobald ein Drittanbieterzertifikat eingerichtet ist, hier fragt er in Dauerschleife nach Credentials bevor ich in RDWeb eingelassen werde, ohne Erfolg.
Mit einem vom internen CA-ausgestellten Zertifikat kann ich widerum im Webclient die RDP-Files vergessen, da dann die Authentifizierung nicht korrekt ist, respektive das lokale RootCA benötigt wird, bevor eine Verbindung aufgebaut werden kann, was wir logischerweise nicht an Geräte ausrollen können, welche keine Unternehmensgeräte sind. HTML5-Client funktioniert soweit mit dem Zertifikat vom internen CA.
