V poslední době jsem několikrát řešil publikaci (SSL Web Server Publishing) služby RDP Gateway přes TMG (Threat Management Gateway 2010). A už se mě několikrát někdo ptal, jestli je možné mít tuto službu přímo na TMG, nebo použít čipové karty. S tím, že prý někde četl, že to dělá problémy, nebo to nejde. Tak tento článek by vám měl opovědět na několik otázek typu "lze/nelze" a podobně jako v jiném článku o 802.1x přidat několik užitečných implementačních poznámek.
Pro pořádek - co je RDP Gateway
Na Windows Server 2008 a Windows Server 2008 R2 je k dispozici RDP proxy, která umožňuje připojovat se přes HTTPS na vzdálenou plochu libovolného počtu serverů, nebo i stanic. Dříve se to nazývalo TS Gateway (Terminal Services Gateway), dneska RDP Gateway (MS nemůže nechat žádný název dlouho suchý :-)). Ve skutečnosti se jedná uvnitř o RPCoverHTTP/S komunikaci mezi klientem a RDP Gateway službou, která následně z toho vybaluje RDP čistý protokol a přeposílá ho dále na zadní RDP servery. RDP Gateway sama ověřuje uživatele a může, nebo nemusí, přeposílat jejich přihlašovácí údaje dále na zadní RDP servery. Ověřování uživatelů může být buď heslem, nebo čipovou kartou (smart card) s certifikátem (normální TLS Client Authentication).
Následující obrázek shrnuje síťové interakce, které jak můžete vidět, nenjsou zrovna úplně jednoduché. Tento obrázek platí pro přihlašování heslem. S certifikátem (čipovou kartou, smart card) je ještě o něco složitější.
Na následujícím obrázku jsou vidět dvě hvězdičky. Ty znamenají body ověřování uživatele. Tzn. uživatele ověřuje IIS, při přístupu na jeho /RPC virtuální adresář (virtual directory). Operace na rpcproxy.dll potom probíhají potom v jeho kontextu, který se přenáší také na RDP Gateway službu - není k tomu potřeba žádná delegace (delegation), protože se jedná o lokální přístup (stejně jako na Exchange OutlookAnywhere, což je také RPCoverHTTP/S připojení). RDP Gateway služba je RPC server poslouchající na portu TCP 3388.
Znamená to tedy, že klient samotný umí dvě ověřování. Zaprvé se musí umět ověřovat vůči RPC adresáři na HTTPS serveru. V takovém případě může použít buď Negotiate (NTLM nebo Kerberos protokol), čisté NTLM, Basic autentizaci, nebo TLS Client Authentication certifikát. Pro zadní přístup na cílový RDP server musí klient sám zaslat buď Basic autentizaci (RDP je s heslem normální Basic v principu), nebo PIN k čipové kartě.
Co lze udělat - přihlášení heslem
Publikace RDP Gateway přes TMG 2010 při reverse https proxy inspekci (SSL Web Server Publishing) za použití ověření heslem. Tedy scénář, kdy TMG ukončuje klientský TLS tunel, inspektuje čisté HTTP uvnitř a přeposílá požadavky dále dozadu na RDP Gateway. Chceme současně, aby TMG také samo ověřovalo uživatele a teprve případně přeposílalo jejich přihlašovací údaje dozadu na HTTPS RPC proxy server. Z obrázku by to mělo být zřejmější:
V obrázku je vidět, že TMG ověří uživatele a přepošle přihlašovací údaje na IIS. Na vnější straně TMG (tedy nastavení příslušného Web Listeneru) můžete použít cokoliv - to znamená Basic, Windows Integrated, Forms (má fallback na Basic). Pokud nastavíte Windows Integrated ověřování na straně klienta, musíte pro TMG povolit Kerberos Constrained Authentication (třetí volba To any authentication protocol) a použít tuhle volbu i na záložce Authentication Delegation v pravidle. Na RPC adresáři v IIS bych pro jistotu zkontrolovat, že to nabízí Windows Integrated ověřování a že mezi jeho Provider je Negotiate.
Pokud byste na straně klienta chtěli Basic, nebo Forms authentication (Basic fallback), nepotřebujete za TMG používat Kerberos Constrained Authentication, ale stačí vám libovolná jiná volba. Má to ale nevýhodu, protože MSTSC klient nechce jenom tak používat Basic ověřování. Basic ověření pro klienta je potřeba povolit všem klientům v Group Policy pomocí volby:
User Configurationi / Policies / Administrative Templates / Windows Components /
Remote Desktop Services / RD Gateway / Set RD Gateway authentication method
Takže já bych osobně šel pro Kerberos Constrained Authentication s výchozím Windows Integrated ověřením na straně klienta.
Co lze udělat - RDP Gateway přímo na TMG
Toto funguje. Ověřeno. Jen nezapomeňte na několik detailů:
- IIS má vlastní certifikát (navíc k tomu, který jen Web Listeneru TMGčka) a poslouchá na vlastním portu TCP 443. IIS používá ovladač HTTP.SYS, který právě poslouchá na tom portu TCP 443. Zatímco TMG tento ovladač nepoužívá a porty budou kolidovat, pokud by HTTP.SYS chtěl poslouchat na stejné síťovce, jako nějaký TMG Web Listener. Musíte tedy ručně IIS přenastavit tak, aby poslouchalo například jen na adrese 127.0.0.1, nebo jen na vnitřní síťové kartě (funguje oboje). To ale nestačí, musíte také z příkazové řádky opravit certificate binding, který má HTTP.SYS nastaven. To se provede pomocí NETSH:
NETSH HTTP SHOW SSLCERT
NETSH HTTP DELETE SSLCERT
NETSH HTTP ADD SSLCERT
- Oba dva - RDP Gateway i TMG - používají lokální NPS (Network Policy Server) pro svoje přístupové politiky. TMG tam má VPN politiku. Byl bych opatrný na pořadí. Funguje to, ale pokud by mi nejela VPN, nebo naopak RDP Gateway, hledal bych problémy právě v NPS nastaveních.
- Jak jsem již zmínil, oba dva, jak IIS (lépe řečeno HTTP.SYS), tak i TMG mají svůj vlastní certifikát. Na TMG Web Listeneru budete asi používat nějaký koupený, veřejný certifikát. Na IIS musíte mít takový certifikát, aby mu TMG věřilo. Tady stačí nějaký váš vnitřní, ideálně s doménovým jménem TMG serveru (array člena). Nezapomeňte, že oba dva certifikáty budete muset ručně vyměnit, až jim zkončí platnost.
Co lze udělat - Certifikátové přihlašování čipovou kartou (smart card) s inspekcí na TMG
V tomto případě je to ještě o něco složitější, protože přibude jedno další ověřování na NPS pomocí EAP/TLS. A tedy ještě jeden ceritifikát, který je definován na NPS v přístupovém pravidle. Do zadního RDP serveru je potřeba zaslat uživatelův PIN v plné formě. Znamená to tedy, že bezpodmínečně bude uživatel muset zadávat PIN dvakrát. Jednou pro certifikátové ověřování, podruhé pro MSTSC klienta, aby ho mohl přeposlat na zadní RDP server. Viz. obrázek:
Jak to nastavíte? Na TMG Web Listeneru budete potřebovat SSL Client Certificate Authentication. Pro Web Server Publishing Rule pravidlo budete muset nastavit a povolit Kerberos Constrained Delegation a pravidlo musí navíc vnější požadavky na URI s podcestou /RpcWithCert přesměrovávat dovnitř jen na /Rpc adresář, na kterém se můžete ověřovat Kerberosem. Nebo si na adresáři /RpcWithCert v IIS ručně povolte Windows Integrated autentizaci, ale to bych nedoporučoval.
Nezapomeňte, že v tomto případě bude NPS ukazovat svůj certifikát klientovi kvůli EAP/TLS ověření. To v předchozích případech neplatilo, protože zadní IIS certifikát se ukazoval jen TMG. Proč to vadí? No klient kontroluje CRL toho NPS certifikátu. Musíte pro něho použít tedy buď veřejný certifikát - jenže potom to musíte v té NPS politice vyměnit ručně a nemůžete už na to použít nastavení z konzole RDP Gateway Manager. A nebo, tak jak to dělám já, dát tam klidně vnitřní, ale současně přes TMG vypublikovat jeho CRL.
A to je pro dnešek všechno. Všechno jede, tak hurá do toho!