[W2K8] RDWeb en Access Gateway

[_AN]

Voor een testomgeving heb ik een Domain Controller en een Terminal Server ingericht. Beide zijn geïnstalleerd met Windows Server 2008 R2. De Domain Controller is verantwoordelijk voor zowel de Access Gateway als RDWeb. De Terminal Server is verantwoordelijk voor de Remote Session Host. Vanaf de Terminal Server worden de Remote Apps aangeboden (via RDWeb).

De Access Gateway is voorzien van een geldig certificaat. Bij het surfen naar RDWeb krijgt de gebruiker dus geen melding over het ontbreken van een geldig certificaat.

Tot zover werkt alles goed.

Na het inloggen op RDWeb, kan de gebruiker kiezen voor het starten van bijv. MS Word of een RDP verbinding naar de betreffende Terminal Server. Beide werken, maar de gebruiker moet nogmaals een wachtwoord invoeren. Uiteraard is dit vervelend en wil ik dit niet. Bij wat zoeken op Google kwam ik dit tegen. Om SSO in te schakelen moet de RDWeb Server lid zijn van TS Web Access Computers, dit is het geval. Daarnaast moet Digitally sign ingeschakeld zijn. Dit is ook het geval, maar met een Self Signed Certificaat. Omdat de CA niet door te client wordt vertrouwd, krijgen gebruikers nog steeds een melding over een niet-geldig certificaat en moet gebruikersnaam en wachtwoord nog steeds dubbel ingevoerd worden, tenzij het certificaat wordt geïnstalleerd op de betreffende computer.

Mijn vraag is, kan ik het certificaat (demo.domein.nl), die gebruikt wordt voor de Access Gateway ook gebruikt worden voor de RD Session Host, of moet dit een ander certificaat zijn. Momenteel wordt er een certificaat gebruikt op de FQDN van de server (servernaam.domein.local). Mocht er een extra certificaat nodig zijn, dient deze dan aangevraagd te worden op servernaam.domein.local? Ik vind het namelijk heel apart om een certificaat aan te vragen op servernaam.domein.local, de naam van de RD Session Host Server.

[alt-92]

PKI (certificaten) vereist een complete trust chain, dus ook de intermediate en root CA moeten trusted zijn op de client.

Zo werkt PKI nu eenmaal.

[_AN]

alt-92 schreef op woensdag 16 maart 2011 @ 20:03:
PKI (certificaten) vereist een complete trust chain, dus ook de intermediate en root CA moeten trusted zijn op de client.

Zo werkt PKI nu eenmaal.

Dat is mij ook duidelijk.

Mijn vraag is of er minimaal twee certificaten nodig zijn in deze opstelling. Momenteel heb ik 1 certificaat waarvan de clients de CA vertrouwen. Deze is geïnstalleerd op de RD Access Gateway. Ik vraag mij af of hetzelfde certificaat ook gebruikt kan worden op de RD Session Host (geïnstalleerd op een andere server). Ik kan me voorstellen dat dit een andere certificaat moet zijn, die ik graag wil bestellen, alleen vind ik het raar om een certificaat te bestellen op naam van de Terminal Server (servernaam.domein.local).

[Appel]

Ik heb een vergelijkbare situatie opgezet.

RDS server met Session Host, RDWeb access en een RemoteApp. Ik heb een goed certificaat gebruikt van een publieke root CA. Ik liep tegen het probleem aan dat de Terminal Services ActiveX add-on niet goed ingesteld werd in Internet Explorer.

Ik kan het probleem helaas niet reproduceren omdat wij vanwege dit irritante probleem er af zijn gestapt.

Je zou ook nog naar deze info kunnen kijken. Dit is ook nodig om SSO goed aan de praat te krijgen.
http://blogs.msdn.com/b/r...l-server-connections.aspx

[alt-92]

Je bent niet persé gebonden aan één naam op een certificaat he, je kan alternate names opgeven.

[_AN]

alt-92 schreef op woensdag 16 maart 2011 @ 20:14:
Je bent niet persé gebonden aan één naam op een certificaat he, je kan alternate names opgeven.

Dit zou betekenen dat ik het huidige certificaat ook kan gebruiken voor de RD Session Host?

LzpAppel schreef op woensdag 16 maart 2011 @ 20:13:
Ik heb een vergelijkbare situatie opgezet.

RDS server met Session Host, RDWeb access en een RemoteApp. Ik heb een goed certificaat gebruikt van een publieke root CA. Ik liep tegen het probleem aan dat de Terminal Services ActiveX add-on niet goed ingesteld werd in Internet Explorer.

Ik kan het probleem helaas niet reproduceren omdat wij vanwege dit irritante probleem er af zijn gestapt.

Je zou ook nog naar deze info kunnen kijken. Dit is ook nodig om SSO goed aan de praat te krijgen.
http://blogs.msdn.com/b/r...l-server-connections.aspx

Apart, deze pagina omschrijft iets anders dan de pagina die ik gaf in de TS. Misschien hier eens mee knutselen.

[alt-92]

_AN schreef op woensdag 16 maart 2011 @ 20:17:
[...]
Dit zou betekenen dat ik het huidige certificaat ook kan gebruiken voor de RD Session Host?

Dan heb je nog steeds een invalid certificate vanwege de name mismatch - tenzij je door een dns alias deze via de naam op je certificate gaat aanspreken.

[_AN]

alt-92 schreef op woensdag 16 maart 2011 @ 20:49:
[...]

Dan heb je nog steeds een invalid certificate vanwege de name mismatch - tenzij je door een dns alias deze via de naam op je certificate gaat aanspreken.

Oké. bedankt, dit zal ik proberen.

[_AN]

alt-92 schreef op woensdag 16 maart 2011 @ 20:49:
[...]

Dan heb je nog steeds een invalid certificate vanwege de name mismatch - tenzij je door een dns alias deze via de naam op je certificate gaat aanspreken.

Ik heb het idee dat ik dit probleem niet kan oplossen. Tenminste, vermoedelijk kan ik mijn gebruikers niet voorzien van SSO en ze niet lastig vallen met een melding over een certificaat.

Het probleem is volgens mij dat ik mijn domein .local heb genoemd. Deze had ik beter een .nl of .com domein kunnen geven. Ik kan namelijk geen certificaat aanvragen voor een computernaam.domein.local, als dit computer.domein.nl was geweest, had dit een stuk gemakkelijk geweest.

RDWeb blijft tenslotte verbinding naar computernaam.domein.local.

Ik heb een nieuwe zone gemaakt in de DNS, domein.nl, daarbij een CNAME demo.domein.nl, maar als ik deze aangeef in de RD Session Host, kan ik er niet meer naar verbinden. Wellicht omdat de RD Session Host zoekt naar een computernaam, die niet bestaat.

Misschien heeft iemand nog ideeën?

[alt-92]

Hoe bedoel je niet bestaat?
Je maakt toch een DNS zone aan en zet daar zowel binnen als buiten de benodigde records in zodat je name resolution ook echt werkt?

Ik bedoel: het ding is te pingen of niet. Als ie niet te bereiken is op die naam gaat een certificaat kopieren ook niet helpen

[Verwijderd]

als je een publiek certificaat genomen had zowel op de RD gateway als op de RD Webaccess, zoals bvb. een Globalsign, dan had je dergelijke problemen niet.

Als je niet met 1 SAN-certificaat werkt, heb je sowieso voor elke rol 1 Domain-SSL certificaat nodig.

[_AN]

alt-92 schreef op donderdag 17 maart 2011 @ 17:21:
Hoe bedoel je niet bestaat?
Je maakt toch een DNS zone aan en zet daar zowel binnen als buiten de benodigde records in zodat je name resolution ook echt werkt?

Ik bedoel: het ding is te pingen of niet. Als ie niet te bereiken is op die naam gaat een certificaat kopieren ook niet helpen

Je hebt gelijk, natuurlijk bestaat het adres wel, maar kennelijk verreist Windows toch een Computernaam en niet een CNAME die verwijst naar de Computernaam. Zodra ik in de RemoteApp Manager het adres van de RemoteApp Server aanpas, werken geen van de RemoteApps meer. Ik dacht dit ook op deze manier op te lossen, maar kennelijk kan dit niet.

Verwijderd schreef op donderdag 17 maart 2011 @ 18:31:
als je een publiek certificaat genomen had zowel op de RD gateway als op de RD Webaccess, zoals bvb. een Globalsign, dan had je dergelijke problemen niet.

Als je niet met 1 SAN-certificaat werkt, heb je sowieso voor elke rol 1 Domain-SSL certificaat nodig.

Ik heb twee publieke certificaten, maar hiermee krijg ik het niet aan de praat. Vooralsnog wordt dit veroorzaakt doordat mijn computernaam niet overeenkomt met de naam van het publieke certificaat.

Eventueel kan wat screenshots plaatsen, mocht het niet duidelijk zijn.

[alt-92]

Dat bedoelde ik ook met: je kan op een cert doorgaans meerdere namen kwijt - dus niet alleen je publieke DNS-hosted name maar ook de echte hostname.

[_AN]

alt-92 schreef op donderdag 17 maart 2011 @ 20:34:
Dat bedoelde ik ook met: je kan op een cert doorgaans meerdere namen kwijt - dus niet alleen je publieke DNS-hosted name maar ook de echte hostname.

En hoe kan ik dit volgens jou het beste realiseren?
Met een CNAME wat ik hierboven vertelde?

[_AN]

Iemand nog enig idee?

@Alt-92: Zou jij bovenstaande vraag kunnen beantwoorden?

Bedankt..