Optimální řešení certifikátů pro RDP session farmu

Tak po mnoha laborováních a řešení problémů s certifikáty na několika RDP (Remote Desktop neboli Terminal Services) nasazeních Windows 2012/R2 jsem dospěl k tomuto optimálnímu řešení problému SSL/TLS certifikátů. Takže jestli se chcete stát RDP statkářem, (po americku farmářem) tak si to přečtěte, protože snad předejdete zbytečným problémům.

Problém certifikátů na Remote Desktop session host farmě

Obvykle máte AD doménu na nějakém vnitřním DNS jméně - jako já mám například testovací prostředí gopas.virtual:

Ve výchozím stavu jsou tedy jména všech RD session host serverů, stejně jako RD connection broker serverů vnitřní (něco jako RDBROKER1.gopas.virtual). Obykle ale potřebujeme také přístup z internetu a "podivných" zařízení, která nespravujeme centrálně, jako jsou mobily a tablety apod. případně od ne-doménových zákazníků páč dneska má každej kulak klaud.

Certifikát potřebujete jen pro RD web, RD gateway a RD connection broker. RD session hosti přežijí uživatelský přístup jen se svým výchozím, automaticky generovaným self-signed certifikátem, protože přístup na ně se ověřuje z RD connection broker. Ale taky ne vždycky ( /admin přístup například).

Pro RD web a RD gateway logicky zvolíte ne-doménové veřejné jméno, například něco jako rd.gopas.cz, aby to bylo dostupné z internetu. Toto jméno si prostě zadáte do vnitřního i veřejného DNS ručně (podstatná informace o split-dns například i zde). Pro tyto stroje si také koupíte certifikát od veřejné autority a je to.

Jenže co s těmi ostatními mašinami. RD connection broker automaticky používá svoje vnitřní doménové jméno, dokud ho nepřepnete do high-available konfigurace. Jenže to každý nechce. High-available configuration vyžaduje SQL server a pokud ten nemáte taky vysoce dostupný, tak to nedává smysl (takže nějaký hustý Always On apod.). Přitom i s jedním RDP connection brokerem můžete mít krásně rozloženou zátěž mezi více RD session hostů.

Veřejné certifikační autority (certification authority - CA) vám certifikát pro vnitřní jména nevydají, nejpozději od ledna 2015. Ty byste si museli vydávat sami z vnitřní AD CS autority. Jenže to každý nechce řešit, podobně jako SQL always on pro high-available connection broker. Vaší vnitřní CA naopak nevěří zákazníci, nevěří tomu podivná zařízení apod.

Dobře, můžeme to tedy také rozjet na nějakých DNS aliasech, jenže to zase při vnitřním přístupu nebo KDS ztrácíme Kerberos ověření a vůbec jsou problémy se single-sign-on (SSO).

Elegantní řešení pomocí změny primárního DNS suffixu na serverech

Nejspíš o tom nevíte, ale počítače se ve skutečnostni mohou jmenovat úplně jinak, než se jmenuje jejich vnitřní Active Directory doména. Prostě jim změníte primary DNS suffix. Říká se tomu disjoint AD namespace.

A je to. Koupíte si rovnou jedinný certifikát od veřejné certifikační autority a použijete ho na všech serverech. Bude mít buď jméno s hvězdičkou (wildcard certificate), tedy *.gopas.cz. Hvězdičkové certifikáty jsou ale obvykle poněkud dražší, než certifikáty s několika jmény (subject alternative name, SAN). Takže můžete mít také certifikát s více jmény všech vašich serverů.

A jestli se později rozhodnete zavést high-available configuration pro RD connection broker, není problém, prostě přidáte to další jméno do nového certifikátu.

Takto jede i Kerberos, SSO a všechno je prostě na veřejných jménech, která jsou vlastně ale také vnitřní :-)

Nevýhody

Tak samozřejmě nic není zadarmo.

Máte malinký problém s dynamickou DNS registrací. Buď máte ve vnitřním DNS přímo celou tu veřejnou zónu - to ale zakrývá veřejné záznamy. Nebo si musíte pro každý server udělat ručně separátní zónu a záznam tam udělat ručně - A záznamy pro jméno zóny nelze dynamicky aktualizovat. Nebo uděláte ten DNS suffix na nějaké jiné veřejné doméně, která vám nebude nic zakrývat a přitom dostanete v pohodě certifikát od veřejné CA. Ještě existuje možnost veřejné domény třetího řádu (third-level domain), například servery.gopas.cz. Takže by se servery jmenovaly rdhost1.servery.gopas.cz. To veřejné autority umí vydávat, ale neplatí pro to wildcard certifikáty vyšší úrovně.

Potom samozřejmě může být problém s nějakými aplikacemi, které takovou konfiguraci nechápou. Ale z mé zkušenosti to je ok.

To jsou ale malinké problémy ve srovnání s tím, jak moc problémů je jinak s certifikáty.

- Ondřej Ševeček, MVP