RDS2012R2/2016: Connettersi attraverso l’RD-Gateway se il dominio pubblico è diverso dal local domain in active directory

Quando ci si collega ad un’infrastruttura RDS passando attraverso il Remote Desktop Gateway il compito del certificato pubblico e del nome del dominio interno ed esterno sono molto importanti.

Il compito del certificato SSL pubblico installato sul/sui server di un’infrastruttura RDS è quello di autenticarci e di farci passare tramite SSO, prima sull’RD-Gateway, e poi sull’RD-Connection Broker. Ma per far si che tutto questo giro funzioni il nome del server scritto nel certificato SSL deve essere perfettamente uguale al nome dell’RD-Gateway, inoltre il nome del dominio pubblico deve coincidere con quello in Active directory.

Infatti se analizziamo il file RDP che si esegue quando mi collego tremite l’RD-WebAccess (es. app WordPad) noteremo che tutti i campi evidenziati hanno lo stesso nome di dominio e nel campo gatewayhostname:s:: è indicato il nome esatto del nome del certificato SSL.

  • remoteapplicationprogram:s:||WordPad
  • gatewayhostname:s:gateway.dominio.eu  —————> nome del certificato SSL
  • remoteapplicationname:s:WordPad
  • workspace id:s:srv-rds01.dominio.eu
  • loadbalanceinfo:s:tsv://MS Terminal Services Plugin.1.QuickSessionCollection
  • alternate full address:srv-rds01.dominio.eu
  • full address:s:srv-rds01.dominio.eu

Se il nome del certificato pubblico corrisponde al nome del dominio interno tutto funzionerà perfettamente.

In questo scenario infatti il nome del certificato SSL coincide col nome del dominio interno e verrà anche risolto dal DNS server del dominio interno, vedi Figura 1

image

Figura 1

Quando invece il nome del server indicato sul certificato SSL è diverso dal nome di dominio interno (esempio .local, .private, .demo, .lab etc) , non avverrà il “match” tra il nome del dominio interno e il nome scritto nel certificato SSL.

Nell’esempio, indicato in Figura 2, il nome scritto nel certificato SSL è dominio.eu mentre il nome del dominio Active Directory è dominio.local

image

Figura 2

Per risolvere il problema si deve cambiare il “Client Access Name” il nome del CB-Connection Broker che viene specificato nel file .rdp in modo che corrisponda al nome del certificato SSL e che venga mantenuto e risolto anche nel dns interno.

Un forte ringraziamento ad un mio collega MVP Toby Phipps che ha creato uno script che esegue il cambio del nome del CB-Connection Broker e prelevabile a questo link

Come accennato, anche il DNS interno dovrà riconoscere e risolvere il nome del server, si dovrà quindi aggiungere una zona con il nome del dominio pubblico e gli host con il nomi dei server con i rispettivi indirizzi interni. In realtà si potrebbero anche aggiungere i record nel file hosts locale del client che si deve collegare ma, ovviamente, è molto meno gestibile e facilmente dimenticabile.

Il risultato sarà come raffigurato nella Figura 3

 

image

Figura 3