19
RDS Gateway Konfiguration 2016
Guten Abend zusammen,
vorne weg unsere Konfiguration:
BLN-BK01:
Broker, WebAccess. Lizenz und Gateway
Das Gateway ist über einen ReverseProxy(IIS) über Port 443 zu erreichen. Cert ist auch hinterlegt.
BLN-SH01 und BLN-SH02:
Session Hosts.
DNS RoundRobin ist hinterlegt für die beiden IPS der SH Server.
wir sind im Moment dabei, zu evaluieren wie wir unsere HomeOffice User mit Hilfe von TerminalServer besser ans unser Netz anbinden können.
Intern funktionier unsere TS Farm auch soweit gut. Die freigegebenen User melden sich sauber an der Farm an und ich sehe auch auf dem Broker in der RDS Verwaltung die einzelnen Sitzungen.
Soweit so gut.
Jetzt wollte ich ein Gateway hinzufügen, um eine einfachere und sichere Verbindung von außen zu ermöglichen.
Bei unserem Provider habe ich eine SubDomain registriert, diese leitet mittels HostA auf unsere statische IP weiter von dort geht es per ReverseProxy(IIS) auf den BLN-BK01 weiter.
Wenn ich jetzt https://rds.unsere-domain.de/RDWeb/WebClient/index.html aufrufe komme ich auch sauber auf dem Broker an.
Wenn ich dort dann eine Session auf unserer rdsFarm starte bekomme ich folgende Fehlermeldung:
Die Verbindung mit dem Remotecomputer wurde unterbrochen.
Unter Umständen liegt ein Problem mit der Netzwerkverbindung vor.
Versuche ich das ganze per mstsc.exe oder rdp App auf dem Mac bekomme ich eine ähnliche Fehlermeldung.
Schaue ich mir dann auf dem BK01 die Ereignisse im Server Manager an bekomme ich eine wilde Mischung aus Fehlern:
Fehler des RD-Verbindungsbrokers beim Verarbeiten der Verbindungsanforderung für den Benutzer "DOMAIN\USER".
Der in der RDP-Datei (Hinweise) des Benutzers angegebene Farmname konnte nicht gefunden werden.
Fehler: Die für die Verbindung angegebene Farm ist nicht vorhanden.
Der Benutzer "DOMAIN\USER" auf dem Clientcomputer "XXX.XXX.XXX.XXX" hat die Anforderungen der Ressourcenautorisierungsrichtlinie nicht erfüllt und wurde daher nicht für die Ressource "rdsFarm" autorisiert. Fehler: "23002".
Eigentlich sin dim Gateway Manager sowohl die RD-CAP mit der Gruppe der User, als auch die RAP hinterlegt.
Beid er Netzwerkresourcen-Gruppe habe ich alle drei Server, sowie noch ein mal den Farmnamen (hatte ich ein einem Anderen Betrag gelesen) hinterlegt(alle als FQDN).
Auf unsere Firewall ist der Port 443 zum ReverseProxy und die Ports 3389 und 3391 direkt zum Broker durchgesteckt.
Ich schlage mich seit 2 Tagen mit dem Gateway rum und sehen leider kein Land.
Ich hoffe hier kann mir einer Helfen.
vorne weg unsere Konfiguration:
BLN-BK01:
Broker, WebAccess. Lizenz und Gateway
Das Gateway ist über einen ReverseProxy(IIS) über Port 443 zu erreichen. Cert ist auch hinterlegt.
BLN-SH01 und BLN-SH02:
Session Hosts.
DNS RoundRobin ist hinterlegt für die beiden IPS der SH Server.
wir sind im Moment dabei, zu evaluieren wie wir unsere HomeOffice User mit Hilfe von TerminalServer besser ans unser Netz anbinden können.
Intern funktionier unsere TS Farm auch soweit gut. Die freigegebenen User melden sich sauber an der Farm an und ich sehe auch auf dem Broker in der RDS Verwaltung die einzelnen Sitzungen.
Soweit so gut.
Jetzt wollte ich ein Gateway hinzufügen, um eine einfachere und sichere Verbindung von außen zu ermöglichen.
Bei unserem Provider habe ich eine SubDomain registriert, diese leitet mittels HostA auf unsere statische IP weiter von dort geht es per ReverseProxy(IIS) auf den BLN-BK01 weiter.
Wenn ich jetzt https://rds.unsere-domain.de/RDWeb/WebClient/index.html aufrufe komme ich auch sauber auf dem Broker an.
Wenn ich dort dann eine Session auf unserer rdsFarm starte bekomme ich folgende Fehlermeldung:
Die Verbindung mit dem Remotecomputer wurde unterbrochen.
Unter Umständen liegt ein Problem mit der Netzwerkverbindung vor.
Versuche ich das ganze per mstsc.exe oder rdp App auf dem Mac bekomme ich eine ähnliche Fehlermeldung.
Schaue ich mir dann auf dem BK01 die Ereignisse im Server Manager an bekomme ich eine wilde Mischung aus Fehlern:
Fehler des RD-Verbindungsbrokers beim Verarbeiten der Verbindungsanforderung für den Benutzer "DOMAIN\USER".
Der in der RDP-Datei (Hinweise) des Benutzers angegebene Farmname konnte nicht gefunden werden.
Fehler: Die für die Verbindung angegebene Farm ist nicht vorhanden.
Der Benutzer "DOMAIN\USER" auf dem Clientcomputer "XXX.XXX.XXX.XXX" hat die Anforderungen der Ressourcenautorisierungsrichtlinie nicht erfüllt und wurde daher nicht für die Ressource "rdsFarm" autorisiert. Fehler: "23002".
Eigentlich sin dim Gateway Manager sowohl die RD-CAP mit der Gruppe der User, als auch die RAP hinterlegt.
Beid er Netzwerkresourcen-Gruppe habe ich alle drei Server, sowie noch ein mal den Farmnamen (hatte ich ein einem Anderen Betrag gelesen) hinterlegt(alle als FQDN).
Auf unsere Firewall ist der Port 443 zum ReverseProxy und die Ports 3389 und 3391 direkt zum Broker durchgesteckt.
Ich schlage mich seit 2 Tagen mit dem Gateway rum und sehen leider kein Land.
Ich hoffe hier kann mir einer Helfen.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 497743
Url: https://administrator.de/contentid/497743
Printed on: April 26, 2024 at 19:04 o'clock
19 Comments
Latest comment
Moin,
Hast du schon einmal mit Wireshark vom vermeidlichen externen Rechner den Datenverkehr angesehen? Hört sich für mich nach einem DNS Problem an.
Server 2012 RDWeb internal / external domain name mismatch
RDS 2012 deployment public access points RRS feed
Drei Anmerkungen/Fragen:
Gruß,
Dani
Broker, WebAccess. Lizenz und Gateway
Puh, RDS ist schon ein wenig her. Ich meine RDS Gateway und RDS Broker auf der selben Maschine ist nicht empfohlen. Aber ich bin bei 50%/50%.Die Verbindung mit dem Remotecomputer wurde unterbrochen.
Unter Umständen liegt ein Problem mit der Netzwerkverbindung vor.Hast du schon einmal mit Wireshark vom vermeidlichen externen Rechner den Datenverkehr angesehen? Hört sich für mich nach einem DNS Problem an.
Server 2012 RDWeb internal / external domain name mismatch
RDS 2012 deployment public access points RRS feed
Auf unsere Firewall ist der Port 443 zum ReverseProxy und die Ports 3389 und 3391 direkt zum Broker durchgesteckt.
Hört sich nach deiner Beschreibung für mich nach "Broken by Design" an. Du hast einen A-Eintrag angelegt, welcher auf eure öffentliche, statische IP-Adresse zeigt. Anschließend hast du auf der Firewall verschiedene Destiation NAT Rules auf Portebene eingerichtet? Denn weiter oben und auch hier schreibst du, dass Port 443/TCP auf einen Reverse Proxy weitergeleitet wird. Hingegen die Ports 3389 und 3391 direkt auf den Server, auf dem unter anderem RDS Broker/Gateway läuft. Das kann eigentlich nicht funktionieren...Drei Anmerkungen/Fragen:
- Warum leitest du die Anfragen, Port 443/TCP nicht direkt auf das RDS Gatway. Der Name ist eigentlich Programm.
- Warum nutzt du nicht grundsätzlich RDS RemoteApps? Somit wird ausschließlich zwischen Client <-> Firewall <-> RDS Gateway keine weiteren Ports benötigt. Somit werden auch die Löcher kleiner und damit auch die mögliche Angriffsfläche.
- Wer hast das Design für RDS entworfen? Sag bitte nicht ein IT-Dienstleister.
Gruß,
Dani
Danke Dani
für die schnelle Reaktion.
Drei Anmerkungen/Fragen:
Das Problem ist/war das auf der gleichen außen IP auch Exchange und unser CMS ankommen. Deswegen der Reverse Proxy. Aber wo ich das grad schreibe, den Port kann man dich bestimmt ändern nehm ich halt 445 und fertig. Kann man das auch beim Tod client dann so eingeben?
Naja, es soll unbedingt der Klassische Desktop nutzbar sein
Noch viel schlimmer, ich allein.
Habe mich so versucht gut einzulesen in das Thema.
Gruß Jens
für die schnelle Reaktion.
Drei Anmerkungen/Fragen:
- Warum leitest du die Anfragen, Port 443/TCP nicht direkt auf das RDS Gatway. Der Name ist eigentlich Programm.
Das Problem ist/war das auf der gleichen außen IP auch Exchange und unser CMS ankommen. Deswegen der Reverse Proxy. Aber wo ich das grad schreibe, den Port kann man dich bestimmt ändern nehm ich halt 445 und fertig. Kann man das auch beim Tod client dann so eingeben?
* Warum nutzt du nicht grundsätzlich RDS RemoteApps? Somit wird ausschließlich zwischen Client <-> Firewall <-> RDS Gateway keine weiteren Ports benötigt. Somit werden auch die Löcher kleiner und damit auch die mögliche Angriffsfläche.
Naja, es soll unbedingt der Klassische Desktop nutzbar sein
* Wer hast das Design für RDS entworfen? Sag bitte nicht ein IT-Dienstleister.
Noch viel schlimmer, ich allein.
Habe mich so versucht gut einzulesen in das Thema.
Gruß Jens
Moin Jens,
Damit wäre nämlich Punkt 1) und 2) sauber gelöst und alle sind glücklich. Und du brauchst keine großen Löcher in der Firewall.
Ansonsten empfehle ich dir die chienischen Anleitungen zur Seite zu legen und die deutsche/englische Blogs zu dem Thema herzunehmen.
Gruß,
Dani
Das Problem ist/war das auf der gleichen außen IP auch Exchange und unser CMS ankommen. Deswegen der Reverse Proxy.
Das ist doch kein Problem... noch nicht. Aber wo ich das grad schreibe, den Port kann man dich bestimmt ändern nehm ich halt 445 und fertig. Kann man das auch beim Tod client dann so eingeben?
Nie, nie nie Ports verbiegen, die vom Standard abweichen. Das fällt dir früher oder später auf die Füße. Das muss du nämlich bei jeder Fehlersuche auf dem Schirm haben. Zumal du im Worst Case eingeschränkten Support von Microsoft erhalten würdest. Naja, es soll unbedingt der Klassische Desktop nutzbar sein
Das ist auch mit RemoteApps möglich. Damit wäre nämlich Punkt 1) und 2) sauber gelöst und alle sind glücklich. Und du brauchst keine großen Löcher in der Firewall. Noch viel schlimmer, ich allein.
Habe mich so versucht gut einzulesen in das Thema.
Jeder fängt klein an. Wichtig ist bei sowas ein Lab zu nutzen und nicht die produktive Umgebung als Spielwiese.Habe mich so versucht gut einzulesen in das Thema.
Ansonsten empfehle ich dir die chienischen Anleitungen zur Seite zu legen und die deutsche/englische Blogs zu dem Thema herzunehmen.
Gruß,
Dani
Guten Morgen,
ich hab das ganze jetzt mal getestet.
Die Ports 3389 und 3391 hab ich auf der Firewall erstmal wieder zu gemacht. es läuft nur 443 über den ReverseProxy aufs gateway.
Ich habe über die Registry den Schlüssel HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\CentralPublishedResources\PublishedFarms\<collection>\RemoteDesktops\<collection>\ShowInPortal auf 1 gesetzt, damit ich Zugriff die Apps und den klassischen Desktop habe. Funktioniert intern super. Hab es auf ein paar PCs hier getestet(Win7 und Win10) alles top. Tabletts klappen leider nicht. Hier bekomme ich die Meldung:
Die Verbindung mit dem Remotecomputer wurde unterbrochen. Unter Umständen liegt ein Problem mit der Netzwerkverbindung vor....
Wenn ich das Ganze von außen teste passiert leider das gleiche.
Gruß,
Jens
ich hab das ganze jetzt mal getestet.
Die Ports 3389 und 3391 hab ich auf der Firewall erstmal wieder zu gemacht. es läuft nur 443 über den ReverseProxy aufs gateway.
Ich habe über die Registry den Schlüssel HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\CentralPublishedResources\PublishedFarms\<collection>\RemoteDesktops\<collection>\ShowInPortal auf 1 gesetzt, damit ich Zugriff die Apps und den klassischen Desktop habe. Funktioniert intern super. Hab es auf ein paar PCs hier getestet(Win7 und Win10) alles top. Tabletts klappen leider nicht. Hier bekomme ich die Meldung:
Die Verbindung mit dem Remotecomputer wurde unterbrochen. Unter Umständen liegt ein Problem mit der Netzwerkverbindung vor....
Wenn ich das Ganze von außen teste passiert leider das gleiche.
Gruß,
Jens
Moin,
Gruß,
Dani
Tabletts klappen leider nicht. Hier bekomme ich die Meldung:
Die Verbindung mit dem Remotecomputer wurde unterbrochen. Unter Umständen liegt ein Problem mit der Netzwerkverbindung vor....
Wenn ich das Ganze von außen teste passiert leider das gleiche.
die Umstellung auf RemoteApp löst nicht ein mögliches Konfigurationsproblem. Hast du dir die beiden Links aus meinem ersten Kommentar gestern Abend unters Kopfkissen gelegt und gelesen? Die Verbindung mit dem Remotecomputer wurde unterbrochen. Unter Umständen liegt ein Problem mit der Netzwerkverbindung vor....
Wenn ich das Ganze von außen teste passiert leider das gleiche.
Gruß,
Dani
Moin,
lag alles untern Kopfkissen
Den ersten Artikel hab ich soweit durch und alles nachgeprüft. Es steht überall rds.unsere-domain.de drin
Beim zweiten bin ich mir nicht ganz sicher.
Den A Record intern habe ich, im Moment zeigt dieser nur auf den Broker.
Parallel gibt es halt noch einen rdsFarm, welcher auf die beiden Session Hosts zeigt.
Ich hab auch im Gateway Manager umgestellt und alle Netzwerkresourcen freigegeben.
Geholfen hat bis jetzt nichts. Leider
Gruß
Jens
lag alles untern Kopfkissen
Den ersten Artikel hab ich soweit durch und alles nachgeprüft. Es steht überall rds.unsere-domain.de drin
Beim zweiten bin ich mir nicht ganz sicher.
Den A Record intern habe ich, im Moment zeigt dieser nur auf den Broker.
Parallel gibt es halt noch einen rdsFarm, welcher auf die beiden Session Hosts zeigt.
Ich hab auch im Gateway Manager umgestellt und alle Netzwerkresourcen freigegeben.
Geholfen hat bis jetzt nichts. Leider
Gruß
Jens
Moin,
Melde dich dort an und füge der HOSTS-Datei rds.unsere-domain.de -> IP-Adresse des RDS Gateways hinzu. Speichern nicht vergessen. Anschließend mittels Ping das Ergebnis prüfen. Wenn die HOSTS-Datei wirksam ist nochmals alle Szenarien durchspielen.
Gruß,
Dani
Den A Record intern habe ich, im Moment zeigt dieser nur auf den Broker.
Du hast sicherlich einen Testclient zur Hand. Melde dich dort an und füge der HOSTS-Datei rds.unsere-domain.de -> IP-Adresse des RDS Gateways hinzu. Speichern nicht vergessen. Anschließend mittels Ping das Ergebnis prüfen. Wenn die HOSTS-Datei wirksam ist nochmals alle Szenarien durchspielen.Parallel gibt es halt noch einen rdsFarm, welcher auf die beiden Session Hosts zeigt.
Hm... okay. Ich hab auch im Gateway Manager umgestellt und alle Netzwerkresourcen freigegeben.
Tutut... da komm ich leider nicht mit. Was hast du wie wo umgestellt?Gruß,
Dani
Den A Record intern habe ich, im Moment zeigt dieser nur auf den Broker.
Du hast sicherlich einen Testclient zur Hand. Melde dich dort an und füge der HOSTS-Datei rds.unsere-domain.de -> IP-Adresse des RDS Gateways hinzu. Speichern nicht vergessen. Anschließend mittels Ping das Ergebnis prüfen. Wenn die HOSTS-Datei wirksam ist nochmals alle Szenarien durchspielen.werde ich testen.
Ich hab auch im Gateway Manager umgestellt und alle Netzwerkresourcen freigegeben.
Tutut... da komm ich leider nicht mit. Was hast du wie wo umgestellt?
Gruß
Jens
Den A Record intern habe ich, im Moment zeigt dieser nur auf den Broker.
Du hast sicherlich einen Testclient zur Hand. Melde dich dort an und füge der HOSTS-Datei rds.unsere-domain.de -> IP-Adresse des RDS Gateways hinzu. Speichern nicht vergessen. Anschließend mittels Ping das Ergebnis prüfen. Wenn die HOSTS-Datei wirksam ist nochmals alle Szenarien durchspielen.werde ich testen.
Wenn ich versuche mit telnet bzw. netcat auf dem Mac mich gegen rds.unsere-domain.de 443 zu verbinden klappt das. Sogar ohne vorher die HOST Datei anzufassen.
und ich komme ja auch sauber auf https://rds.unsere-domain.de/RDWeb/WebClient/index.html von außen. Oder hat das nichts mit einander zu tun?
Wenn ich Wireshark mitlaufen lasse kommt zwar viel Traffic auf unserer IP aber so richtig einen Fehler kann ich da nicht sehen.
EDIT:
wenn ich von zuhause auf die in den RemoteApps angezeigte RDSFarm klicke bekomme ich nach etwas warten beim Punkt "Remoteport wird geöffnet" den Fehler Die Verbindung zum Remotecomputer wurde unterbrochen. Blablabla....
Abend,
ich habe mir eben mal die Logs auf dem Gateway angesehen.
wenn ich mich versuche von zu Hause aufzuwählen steht im Log:
Der Benutzer "j.albrecht@DOMAINE" auf Clientcomputer "REVERSE-PROXY_IP:50397" hat eine ausgehende Verbindung initiiert. Diese Verbindung wurde möglicherweise noch nicht authentifiziert.
kann es sein, das der Proxy nicht sauber weiterleitet? Und wie könnte ich es testen?
Doch mal test halber den Port verbiegen? Damit ich Direkt rauf komme?
Verwirrte Grüße
Jens
ich habe mir eben mal die Logs auf dem Gateway angesehen.
wenn ich mich versuche von zu Hause aufzuwählen steht im Log:
Der Benutzer "j.albrecht@DOMAINE" auf Clientcomputer "REVERSE-PROXY_IP:50397" hat eine ausgehende Verbindung initiiert. Diese Verbindung wurde möglicherweise noch nicht authentifiziert.
kann es sein, das der Proxy nicht sauber weiterleitet? Und wie könnte ich es testen?
Doch mal test halber den Port verbiegen? Damit ich Direkt rauf komme?
Verwirrte Grüße
Jens
Moin,
Gruß,
Dani
Habe das ganze mal von zuHause getestet. Ping gegen rds.unsere-domain.de löst sauber auf unsere IP auf aber der ping selber scheitert. Das glaube ich liegt aber eher an unserer Firewall, die den Ping blockt.
Glaube ich auch... wobei wissen besser wäre. Wenn ich versuche mit telnet bzw. netcat auf dem Mac mich gegen rds.unsere-domain.de 443 zu verbinden klappt das. Sogar ohne vorher die HOST Datei anzufassen.
Denk mal kurz drüber nach... logisch oder? Denn für die Auflösung von externen Anfragen wir ja nicht der DNS-Server in eurem LAN gefragt, sondern der DNS-Server eures Anbieters der die Domain bzw. DNS Zone verwaltet.und ich komme ja auch sauber auf https://rds.unsere-domain.de/RDWeb/WebClient/index.html von außen. Oder hat das nichts mit einander zu tun?
Das zeigt dir, dass deine Konfiguration von Reverse Proxy und Firewall korrekt ist. Mehr leider auch nicht. Wenn ich Wireshark mitlaufen lasse kommt zwar viel Traffic auf unserer IP aber so richtig einen Fehler kann ich da nicht sehen.
Logo...denn du siehst du ausschließlich den Datenverkehr zwischen deinem Client und der Firewall. Den Rest siehst du so natürlich nicht.kann es sein, das der Proxy nicht sauber weiterleitet?
Gut möglich... was setzt du für den Reverse Proxy ein, Nginx? Es kann z.B. gut sein, dass der Reverse Proxy mit dem Authentifizierungsprotokoll nicht klar kommt. Daher immer zuerst den Szenario testen - intern. Danach kannst du nach und nach darauf aufbauen. Alles andere wird bei der Fehleranalyse so unglaublich komplex, dass du den Überblick irgendwann verlierst. Doch mal test halber den Port verbiegen? Damit ich Direkt rauf komme?
Wie gesagt teste es weiter erst einmal im LAN, lokalen Netzwerk. Wenn da alles funktioniert, nächster Schritt.Gruß,
Dani
Noch mal Guten Abend
OHHHH okay, da haben wir uns total missverstanden!
Hab ich mich vielleicht unklar ausgedrückt. Im LAN ist alles tuti und per VPN auch, wenn ich per HOST Datei die Auflösung von rds.meine-domain.de auf die interne IP verbiege.
Deswegen glaube ich ist es halt ein Problem mit der außen Anbindung des Gateway.
Sorry noch mal für die Verwirrung.
Gruß,
Jens
Doch mal test halber den Port verbiegen? Damit ich Direkt rauf komme?
Wie gesagt teste es weiter erst einmal im LAN, lokalen Netzwerk. Wenn da alles funktioniert, nächster Schritt.Hab ich mich vielleicht unklar ausgedrückt. Im LAN ist alles tuti und per VPN auch, wenn ich per HOST Datei die Auflösung von rds.meine-domain.de auf die interne IP verbiege.
Deswegen glaube ich ist es halt ein Problem mit der außen Anbindung des Gateway.
Sorry noch mal für die Verwirrung.
Gruß,
Jens
moin ...
hast du mal in der sitzungssammlung ---> sicherheitseinstellungen ----> verschlüsselungsstufe auf Niedrig gestellt
dann klappt es auch auch von draußen....
Verbindungen nur mit Authentifizierung auf Netzwerkebene .... bla blub sollte natürlich aus sein!
teste mal ob das geht!
Frank
hast du mal in der sitzungssammlung ---> sicherheitseinstellungen ----> verschlüsselungsstufe auf Niedrig gestellt
dann klappt es auch auch von draußen....
Verbindungen nur mit Authentifizierung auf Netzwerkebene .... bla blub sollte natürlich aus sein!
teste mal ob das geht!
Frank
Moin,
P.S. Welche Software nutzt ihr für den Reverse Proxy?
Gruß,
Dani
Hab ich mich vielleicht unklar ausgedrückt. Im LAN ist alles tuti und per VPN auch, wenn ich per HOST Datei die Auflösung von rds.meine-domain.de auf die interne IP verbiege.
sehr gut! Deswegen glaube ich ist es halt ein Problem mit der außen Anbindung des Gateway.
Geschickt wäre es, wenn du im nächsten Schritt temporär den Reverse Proxy in den Wartungsmodus versetzen kannst. Sprich die DestinationNAT Regel auf der Firewall direkt auf das RDS Gateway umbiegen und anschließend nochmals testen.P.S. Welche Software nutzt ihr für den Reverse Proxy?
Gruß,
Dani
Hey,
Geschickt wäre es, wenn du im nächsten Schritt temporär den Reverse Proxy in den Wartungsmodus versetzen kannst. Sprich die DestinationNAT Regel auf der Firewall direkt auf das RDS Gateway umbiegen und anschließend nochmals testen.
Da muss ich morgen mal schauen, den Proxy in den Wartungsmodus wird schwer, da Exchange dahinter hängt. Aber wir haben noch eine zweite Internet Leitung, zwar mit dynamischer IP aber zum testen reicht die ja auch. Da kann ich mich austoben.
Windows Server mit einem IIS mit dem ReverseProxy Plugin.
Zum einen war der schon da und der soll bei Windows Domain Anmeldungen auch am wenigsten Stress machen. Da läuft auch unser CMS stabile drüber, konnte mich bis jetzt nie drüber beschweren
Hab bei meiner Suche von vielen Problemen mit anderen Proxys gelesen, die die Anmeldung dann nicht sauber durchreichen.
Gruß
Jens
Geschickt wäre es, wenn du im nächsten Schritt temporär den Reverse Proxy in den Wartungsmodus versetzen kannst. Sprich die DestinationNAT Regel auf der Firewall direkt auf das RDS Gateway umbiegen und anschließend nochmals testen.
Da muss ich morgen mal schauen, den Proxy in den Wartungsmodus wird schwer, da Exchange dahinter hängt. Aber wir haben noch eine zweite Internet Leitung, zwar mit dynamischer IP aber zum testen reicht die ja auch. Da kann ich mich austoben.
P.S. Welche Software nutzt ihr für den Reverse Proxy?
Windows Server mit einem IIS mit dem ReverseProxy Plugin.
Zum einen war der schon da und der soll bei Windows Domain Anmeldungen auch am wenigsten Stress machen. Da läuft auch unser CMS stabile drüber, konnte mich bis jetzt nie drüber beschweren
Hab bei meiner Suche von vielen Problemen mit anderen Proxys gelesen, die die Anmeldung dann nicht sauber durchreichen.
Gruß
Jens
Zitat von @Vision2015:
moin ...
hast du mal in der sitzungssammlung ---> sicherheitseinstellungen ----> verschlüsselungsstufe auf Niedrig gestellt
dann klappt es auch auch von draußen....
Verbindungen nur mit Authentifizierung auf Netzwerkebene .... bla blub sollte natürlich aus sein!
teste mal ob das geht!
Frank
moin ...
hast du mal in der sitzungssammlung ---> sicherheitseinstellungen ----> verschlüsselungsstufe auf Niedrig gestellt
dann klappt es auch auch von draußen....
Verbindungen nur mit Authentifizierung auf Netzwerkebene .... bla blub sollte natürlich aus sein!
teste mal ob das geht!
Frank
Hey Frank,
Authentifizierung auf Netzwerkebene war schon draußen und Sicherheitsstufe niedrig hat leider nicht geholfen.
Gruß
Jens
Moin,
Gruß,
Dani
Da muss ich morgen mal schauen, den Proxy in den Wartungsmodus wird schwer, da Exchange dahinter hängt.
naja, in der Mittagspause können die Leute unterwegs sicherlich mal 15-30 Minuten ohne Exchange Server klar kommen. E-Mailing ist kein Echtzeitkommunikationsmittel, wenn das auch viele so sehen. Ansonsten hast du sicherlich alle vier Wochen ein Wartungsfenster, wegen den Windows Updates. Windows Server mit einem IIS mit dem ReverseProxy Plugin.
Puhh... Okay. Damit werde und habe ich nie gearbeitet. Ich kann dir sagen, dass mit dem Web Appliation Proxy (Windows Server 2016 und höher) keinerlei Probleme mit der Authentifizierung gibt. Gruß,
Dani
Moin Jungs
now the shit is getting real.
ich hab jetzt mal mit unserer anderen Leitung getestet. Und siehe da, ich bekomme am Handy sofort eine Verbindung.
Okay, ich kannte bis jetzt nur im IIS die Erweiterung des Url Rewrite Moduls für ReversProxy.
Gruß
Jens
now the shit is getting real.
Da muss ich morgen mal schauen, den Proxy in den Wartungsmodus wird schwer, da Exchange dahinter hängt.
naja, in der Mittagspause können die Leute unterwegs sicherlich mal 15-30 Minuten ohne Exchange Server klar kommen. E-Mailing ist kein Echtzeitkommunikationsmittel, wenn das auch viele so sehen. Ansonsten hast du sicherlich alle vier Wochen ein Wartungsfenster, wegen den Windows Updates. ich hab jetzt mal mit unserer anderen Leitung getestet. Und siehe da, ich bekomme am Handy sofort eine Verbindung.
Windows Server mit einem IIS mit dem ReverseProxy Plugin.
Puhh... Okay. Damit werde und habe ich nie gearbeitet. Ich kann dir sagen, dass mit dem Web Appliation Proxy (Windows Server 2016 und höher) keinerlei Probleme mit der Authentifizierung gibt. Okay, ich kannte bis jetzt nur im IIS die Erweiterung des Url Rewrite Moduls für ReversProxy.
Gruß
Jens
Moin,
Nun has du zwei Möglichkeiten aus meiner Sicht:
A) Den Reverse Proxy tauschen
B) Eure Anbieter, wo die Domain hostet unterstützt DynDNS.
Gruß,
DAni
ich hab jetzt mal mit unserer anderen Leitung getestet. Und siehe da, ich bekomme am Handy sofort eine Verbindung.
sehr schön...freut mich.Nun has du zwei Möglichkeiten aus meiner Sicht:
A) Den Reverse Proxy tauschen
B) Eure Anbieter, wo die Domain hostet unterstützt DynDNS.
Okay, ich kannte bis jetzt nur im IIS die Erweiterung des Url Rewrite Moduls für ReversProxy.
Darum bist du ja bei uns gelandet. Authentifizierung auf Netzwerkebene war schon draußen und Sicherheitsstufe niedrig hat leider nicht geholfen.
Wenn alles funktioniert wie soll, nach und nach die Sicherheitsstufe wieder nach oben stellen.Gruß,
DAni