[Win2008] Authenticeren RDP clients met TLS

[xelnaha]

Hoi,

Bij ons op kantoor zijn we bezig met het inrichten van een Terminal server infrastructuur, waarbij consultants extern toegang moeten kunnen krijgen tot de applicaties op de TS.

Om het een en ander te beveiligen ben ik op zoek naar een manier om de remote desktop clients the authenticeren, en wel middels TSL. Het probleem hierbij is dat het lijkt alsof alleen server authenticatie mogelijk is, en niet anders om. Ik heb reeds een CA in het domein gehangen die certificaten kan afgeven.

Alleen is het nu zo, dat als het certificaat niet klopt oid, dat de gebruiker altijd het certificaat kan lezen en er voor kan kiezen om de CA te " trusten". Effectief schiet ik hier dus geen hout mee op; Is het mogelijk om vanuit het AD een Certificated Trust List te maken, waartegen alle te connecten clients vergeleken worden, en of deze de CA mogen vertrouwen? If so, ergens een beschijving hoe ik dit op zet?

wat ik zelf al gevonden heb:
- vraag certificaat aan bij CA in het domain
- in de group policy edit hier:
user configuration - Policies - windows settings - security settings - public key policies - enterprise trust - certificate trust list aangemaakt


alleen kan ik nu helemaal niet meer connecten met clients.... wat o wat gaat er fout?

[Equator]

Om je zelfgemaakte CA te vertrouwen zal je het CA certificaat moeten importeren in de "Trusted Root CA certificate Store" van je computer. Dan is dat voor alle gebruikers op die PC meteen geregeld.
Hiervoor moet je in Computer Configuration zijn onder Windows Settings, Security Settings, Public Key Policies,
Trusted Root Certification Authorities

Bij het toepassen van deze policy zal je CA certificaat geimporteerd worden in de computer Certificate Store.

De TLS (Niet TSL) setting van RDP doet IMO alleen Server Authentication. Daarvoor moet elke servert dus een eigen Server Certificaat hebben, maar zover was je al. Maar hiermee weet je dus zeker dat je met de correcte server aan het kletsen ben..

[xelnaha]

Volgens mij heb ik dat ook al gedaan op de test client. Ik ben op de test client naar http://server/certsrv te gaan heb ik de hele CA aan mijn trust lijst toegevoegd.

Wat ik nou eigenlijk wil, is dat alleen clients die ik rechten heb gegeven in het domein middels een certificaat kunnen connecten naar de terminal server. Ik las ergens dat door dus zo'n CTL te gebruiken, dat je heel gericht bepaalde gebruikers / pc's die rechten kunt geven om aan te loggen of niet.

zoals je zegt, gaat het hier alleen om server authenticatie. Voor mij is client authenticatie nou juist belangrijk. Zijn daar nog opties voor die ik nu over het hooft zie....

[Equator]

Waarom wil je dan persee je clients met Certificaten aan laten melden? Daarvoor kan je natuurlijk gewoon gebruik maken van smartcards.

[xelnaha]

Omdat je voor smartcards weer nieuwe hardware aan moet schaffen en het onderhoud is moeilijker: wat als iemand smartcard kwijt raakt etc... attans dat is wat ik verwacht. Om eerlijk te zijn heb ik nog niet naar Smart cards gekeken.

[ Voor 0% gewijzigd door xelnaha op 24-11-2008 16:16 . Reden: spelvout ]

[Equator]

Als je clients (personen) met een certificaat aan wilt laten melden, dan zal je dat certificaat ergens veilig opgeslagen moeten hebben. En dan bedoel ik niet de User Certificate Store.
Daarvoor zijn hardware tokens/smartcards uitermate geschikt. Natuurlijk kan je ook een USB-token gebruiken (RSA SID800, eToken Pro) om je certificaat op te plaatsen, dan heb je alleen een stukje software en een vrij usb-slot nodig.

Maar de vraag blijft: Waarom wil je mensen op een RDP server aan laten melden met een certificaat.? Wat is je beweegreden daarachter.

[xelnaha]

De reden is beveiliging,

De gebruikers gaan werken met het financiele systeem van onze onderneming. Ze willen expliciet vast stellen dat het persoon dat inlogt ook wel dat persoon is. Wachtwoorden zijn daar over het algemeen niet veilig genoeg voor.

Als je de beveiliging op certificaten gaat baseren lijkt me een stuk sterker en moeilijker te kraken. Alleen krijg ik het idee dat ik hierin wellicht een denkvout maak.

[itlee]

1 koop een officiele server certificate...(kost 120 euro voor 3 jr)
2 koop een aantal client certificates (5 euro perstuk min.afname dacht ik 25 stuks)

heb je alles officieel met certificates geconfigd en je zit niet te klooien met je settings,...(+geen untrusted meldingen meer).

kortom, goedkoper als tokens, maar voor een paar honderd euro is je probleem opgelost. de site waar ik ze gekocht had was sslcertificaten . nl

[alt-92]

itlee schreef op maandag 24 november 2008 @ 16:37:
1 koop een officiele server certificate...(kost 120 euro voor 3 jr)
2 koop een aantal client certificates (5 euro perstuk min.afname dacht ik 25 stuks)

heb je alles officieel met certificates geconfigd en je zit niet te klooien met je settings,...(+geen untrusted meldingen meer).

Leuk.

Heb je ook doorgekregen dat een financiële instelling (lees: bank met bijvoorbeld verzekeringstussenpresonen) aan iets strengere regelgeving moet voldoen?
Je moet die certificaten ook ergens laten, en dat zie ik niet terugkomen.

[xelnaha]

alt-92 schreef op maandag 24 november 2008 @ 18:01:
[...]

Leuk.

Heb je ook doorgekregen dat een financiële instelling (lees: bank met bijvoorbeld verzekeringstussenpresonen) aan iets strengere regelgeving moet voldoen?
Je moet die certificaten ook ergens laten, en dat zie ik niet terugkomen.

Daar bij komt juist, dat het mij niet gaat om de " untrusted" meldingen. Zoals er in een post staat is dat vrij makkelijk op te lossen. Zeker aangezien we controle hebben over de workstations (allemaal onze interne CA trusten)

Ik ben al tijdje aan het lezen over smart card oplossingen

[alt-92]

Tokens/Smartcards zijn wat dat betreft wel redelijk industry standard oplossingen hiervoor.
Let er wel op dat je voor x86 én x64 drivers moet hebben die ook TS-aware zijn.

[xelnaha]

alt-92 schreef op maandag 24 november 2008 @ 18:26:
Tokens/Smartcards zijn wat dat betreft wel redelijk industry standard oplossingen hiervoor.
Let er wel op dat je voor x86 én x64 drivers moet hebben die ook TS-aware zijn.

oh thanks!

[Equator]

Dat, in combinatie met de policy setting: "Interactive logon: Require smartcard" enabled op dat systeem

xelnaha schreef op maandag 24 november 2008 @ 16:30:
De reden is beveiliging,

De gebruikers gaan werken met het financiele systeem van onze onderneming. Ze willen expliciet vast stellen dat het persoon dat inlogt ook wel dat persoon is. Wachtwoorden zijn daar over het algemeen niet veilig genoeg voor.

Als je de beveiliging op certificaten gaat baseren lijkt me een stuk sterker en moeilijker te kraken. Alleen krijg ik het idee dat ik hierin wellicht een denkvout maak.

Neen, daarin maak je geen denkfout.. Dat maakt het juist veel veiliger. Maar dan moet dat certificaat (althans het private deel van het sleutelpaar) op een cryptografisch token staan (ala smartcard/usb-token) anders is je beveiliging nog steeds zoek.

Het enige waarin jij de denkfout maakte was het TLS deel van de RDP sessie. Deze versorgt alleen een veilige sessie waarbij het overdragen van de symmetrische sleutel via een TLS/SSL sessie verloopt. En om dan zeker te weten dat je niet met een rogue server aan het babgelen bent (of een man in the middle) geef je die server een certificaat wat jij vertrouwd.
Maar je kan op een RDP sessie niet aangeven dat je een client certificaat vereist (voor zover ik weet althans, technisch is het wel mogelijk, maar dan hooguit voor de client verificatie..) om daarmee dan ook aan te melden.

[ Voor 86% gewijzigd door Equator op 25-11-2008 08:38 ]

[xelnaha]

ik wacht op dit moment op een reactie van alladin, aangezien ik een van hun USB eTokens gebruik alleen wordt hij niet herkent, da's dan weer minder....

keep u posten

[Equator]

Waar wordt de token niet herkent? Welk type token heb je, en welke RTE gebruik je?