RDS 2019 + Gateway + Azure Application Proxy

[exchangekoala 1]

Hallo zusammen, 

 

Ich habe ein kleines Problem was die Bereitstellung einer RemoteApp über den Azure Application Proxy betrifft. 

Zuerst kurz zur Grundkonfiguration: 

- RDS 2019 Dienste auf mit 3 VM's, 1x Web Access + Gateway, 1x Connection Broker, 1x Session Host

- öffentliches Wildcard Zertifikat mit Public Domain

- Split Brain DNS angelegt 

- Gateway aufgrund lokaler Adresse umgehen deaktiviert

- Testlauf Gateway über extern + Firewall i.O.

 

Sprich mein Setup mit Gateway funktioniert intern wie extern einwandfrei mit Windows, MacOS und Android. 

 

Nun zu meinem Problem, ich habe mir den Azure Application Proxy eingerichtet und einen Connector auf einer anderweitigen VM installiert. 

Weiterhin habe ich zwei Anwendungen in der Azure angelegt, einmal für domain.net/rdweb/ und domain.net/rpc/. 

Für /rdweb/ Azure Authentifzierung und für /rpc/ Passthrough Authentifzierung. 

Test ich nun von extern funktioniert die Verbindung über Windows oder Android einwandfrei und die RemoteApp wird sauber bereitgestellt. 

SingleSign On Funktionalität ist noch außen vor. 

Versuche ich es aber nun über den Mac, erhalte ich nach letztmaliger Anmeldung in der Remoteapp den Fehler 0x607. 

Da der Mac keinerlei Probleme bei der internen Verwendung des Gateway hat, kann es vermutlich nur am Application Proxy liegen. 

 

Hat jemand eine Idee? MacOS Mojave mit RDP 10 App. Auch auf einem zweiten Gerät erscheint der Fehler. 

Was ich bereits probiert habe: 

- Authentifizierung auf Netzwerkebene deaktiviert

- Verschlüsselung auf Niedrig gestellt

- Wildcard Zertifikat auf Session Host importiert 

- SSLCertificateSHA1Hash in der Registry gesucht, aber dieser Wert scheint nicht mehr zu existieren.

 

Gruß

echangekoala

 

bearbeitet 1. November 2019 von exchangekoala

[exchangekoala 1]

Ok, nach einigem hin und her hat sich herausgestellt das es an der 10er Version der Remote Desktop App auf MacOS liegt. 

Das Verhalten tritt unter MacOS 10.14.6 sowie auch mit 10.15.1 auf. 

 

Als Workaround kann man die 8er Version verwenden, diese verbindet sich anstandslos.

Der Microsoft Support hat mir das geschilderte Verhalten gerade noch bestätigt. Siehe Foto.

 Also alles richtig gemacht

 

 

bearbeitet 1. November 2019 von exchangekoala