RDS 2016 / Zugriff von extern nicht möglich

[Ebenezer 13]

Hi, die 2016er RDS Umgebung sieht wie folgt aus:

- 1x vmrdcb.local (Connection Broker)
- 1x vmrdgwwa.local (Gateway + Web Access)
- vmrdsh01.local bis vmrdsh03.local (Session Hosts)
- Split-DNS (rdsfarm.domain.de + rdsgateway.domain.de zeigen intern auf vmrdgwwa.local und rdscb.domain.de auf vmrdcb.local) -> extern sind die DNS-Records auch gesetzt. Es gibt ein offizielles Zertifikat welches
alle drei Namen enthält. Dieses Zertifikat ist via "Bereitstellung konfigurieren" auf allen Servern hinterlegt (Status überall vertrauenswürdig)

- Auf dem Connection Broker wurde folgendes Skript ausgeführt damit die Clients sich mit dem FQDN (rdscb.domain.de) und nicht mit vmrdcb.local verbinden: https://gallery.technet.microsoft.com/Change-published-FQDN-for-2a029b80
- Auf der Firewall sind die Ports 443 (TCP) und 3391 (UDP) auf vmrdgwwa.local weitergeleitet. Die CAP- und RAP-Richtlinien sind angepasst (Domänenbenutzer raus und spezifische Benutzergruppe rein, die Session Hosts sind ebenfalls über eine Gruppe hinzugefügt).

 

Intern funktioniert auch alles prima. Nur wenn ich von extern zugreifen möchte dann kommt immer die Meldung:

 

Mit dem Remote-Computer rdscb.domain.de kann aus einen der folgenden Gründe keine Verbindung hergestellt werden:

1. Benutzer verfügt über keine Rechte auf dem Gateway

2. Computer verfügt über keine Rechte auf dem Gateway

3. Falsche Authentifizierung

 

Telnet rdscb.domain.de 443 funktioniert. Aber ich sehe dort in den Logs keine Verbindungsversuche. Passt das denn vom Setup oder habe ich irgendwo einen Denkfehler?

 

Danke + Grüße,

 

Nico

 

 

 

 

[speer 19]

Hallo,

ein Schuß von mir ins blaue... gebe zusätzlich zur Weiterleitung des GW noch die Sessionhosts mit an. Soweit ich weiß benötigst du von extern zum GW nur HTTPS und kannst RDP Port schließen.

Wieso verwendest du einen anderen Port als den Default 3389 Port für RDP?

Schau dir den Verbindungsversuch auf der Firewall an. Somit weißt du ob die FW blockt oder das RDP-GW ein Problem hat.

[testperson 1.728]

Hi,

vor einer Stunde schrieb speer:

Wieso verwendest du einen anderen Port als den Default 3389 Port für RDP?

Schau dir den Verbindungsversuch auf der Firewall an. Somit weißt du ob die FW blockt oder das RDP-GW ein Problem hat.

es ist UDP 3391 und nicht TCP 3389. "Neuere" RDP Clients verwenden übers Gateway UDP für den besseren Transport bzw. für eine verbesserte User Experience.

 

@Ebenezer Gehst du über die RDWeb Site oder hast du eine RDP Datei entsprechend mit Gateway erstellt?

 

Gruß

Jan

[Ebenezer 13]

Hallo Jan, ich hab beides probiert. Kennst Du die Konstellation mit Gateway + Web Server auf einem Host? Klappt das überhaupt wenn sowohl das Gateway als auch der Webserver auf 443 "lauschen"?

 

Es gab auf der Firewall noch ein Portwarding von Port 3389 auf einen alten Terminal-Server (2008 R2) und als ich mich das erste Mal über das 2016er Webinterface einloggen wollte bin ich plötzlich auf dem 2008er TS gelandet und habe die Welt nicht verstanden ... das kann doch eigentlich gar nicht passieren da alles über 443 getunnelt wird, oder? Nach dem Löschen des Portforwardings erschien dann Fehlermeldung aus meinem o.a. Beitrag ...

[Ebenezer 13]

Es muss irgendwas mit dem Netzwerkrichtlinienserver auf dem Gateway zu tun haben ... die Anmeldeversuche kommen dort an ... zunächst konnte keine Verbindung mit der Domäne hergestellt werden (Quelle: NPS, ID:4402) habe dann via MMC den NPS mit dem Active Direcotry verbunden (Schaltfläche Server in Active Diretory registrieren) , die Verbindung zum DC ist nun aufgebaut. Wenn ich mich versuche anzumelden kommt nun diese Fehlermeldung:

 

1.Ihr Benutzerkonto wird nicht in der Berechtigungsliste des Remotedesktopgateways aufgeführt

oder

2. Sie haben den Remotecomputer im NETBIOS Format angegeben.

 

Parallel dazu sehe ich jetzt aber im Security Eventlog erstmals erfolgreiche Anmeldeversuche:

 

Protokollname: Security
Quelle:        Microsoft-Windows-Security-Auditing
Datum:         22.06.2018 17:42:29
Ereignis-ID:   6272
Aufgabenkategorie:Netzwerkrichtlinienserver
Ebene:         Informationen
Schlüsselwörter:Überwachung erfolgreich
Benutzer:      Nicht zutreffend
Computer:      vmrdgwwa.Domäne.local
Beschreibung:
Der Netzwerkrichtlinienserver hat einem Benutzer den Zugriff gewährt.

Benutzer:
    Sicherheits-ID:            Domäne\testuser1
    Kontoname:            Domäne\testuser1
    Kontodomäne:            Domäne
    Vollqualifizierter Kontoname:    Domäne\testuser1

Clientcomputer:
    Sicherheits-ID:            NULL SID
    Kontoname:            PC04.dienstleister.local
    Vollqualifizierter Kontoname:    -
    ID der Empfangsstation:        UserAuthType:PW
    ID der Anrufstation:        -

NAS:
    NAS-IPv4-Adresse:        -
    NAS-IPv6-Adresse:        -
    NAS-ID:            -
    NAS-Porttyp:            Virtuell
    NAS-Port:            -

RADIUS-Client:
    Clientanzeigename:        -
    Client-IP-Adresse:            -

Authentifizierungsdetails:
    Name der Verbindungsanforderungsrichtlinie:    TS GATEWAY AUTHORIZATION POLICY
    Netzwerkrichtlinienname:        RDG_CAP_Kunde_RDS_FARM
    Authentifizierungsanbieter:        Windows
    Authentifizierungsserver:        vmrdgwwa.Domäne.local
    Authentifizierungstyp:        Nicht authentifiziert
    EAP-Typ:            -
    Kontositzungs-ID:        -
    Protokollierungsergebnisse:            Die Kontoinformationen wurden in die lokale Protokolldatei geschrieben.

 

[testperson 1.728]

vor 6 Stunden schrieb Ebenezer:

Hallo Jan, ich hab beides probiert. Kennst Du die Konstellation mit Gateway + Web Server auf einem Host? Klappt das überhaupt wenn sowohl das Gateway als auch der Webserver auf 443 "lauschen"?

Ja, das funktioniert. Wie sieht denn der Rest aus? Wo ist der Broker und wie viele RDSHs gibts?

[Ebenezer 13]

Also es lag an der RD-RAP Richtlinie - unter Netzwerkressource hatte ich eine AD-Gruppe angelegt in welcher die Computerobjekte vmrdsh01 - vmrdsh03 enthalten sind. Aber erst mit Auswahl der Option "Benutzer können Verbindung mit beliebiger Netzwerkressource herstellen" funktioniert es ...