VMware vSphere & Microsoft LDAP Channel Binding & Signing...

Aktualizace (5/13/2020): Tento příspěvek byl aktualizován, aby odrážel aktuální pokyny k tomuto tématu a že se tato změna týká integrovaného ověřování systému Windows. V tomto příspěvku jsou dobré informace, ale více informací lze nalézt v příspěvku „vSphere Authentication, Microsoft Active Directory LDAP a Event ID 2889“.

—-

Aktualizace (6. 2. 2020): 4. února 2020 společnost Microsoft změnila své pokyny pro aktualizace systému Windows z března 2020, aby uvedla, že výchozí hodnoty se v této aktualizaci NEZMĚNÍ.

https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV190023

Tento příspěvek necháváme aktivní jako referenci, ale komentáře ořízneme, aby bylo možné označit a/nebo omezit nepodporované & nebezpečné rady a diskuze.

Stále opakujeme, že podporované verze VMware vSphere fungují správně s oběma nastaveními vazby LDAP, naše doporučení je vždy používat šifrování k ochraně dat za letu v síti a změna vSphere mimo doporučení od VMware Global Support Services není doporučené nebo tolerované a mohou ovlivnit funkčnost produktu a podporu.

—-

Aktualizace (16. 1. 2020): Aktualizace odrážející výsledky testování integrovaného ověřování systému Windows.

Microsoft nedávno vydal varování pro svou zákaznickou základnu, že v březnových aktualizacích systému Windows 2020 hodlá změnit výchozí chování serverů Microsoft LDAP, které jsou součástí nasazení služby Active Directory. Tyto změny učiní zabezpečenou vazbu kanálu LDAP a podepisování LDAP výchozím požadavkem při přístupu k Microsoft Active Directory pomocí LDAP nebo LDAPS. Tyto změny jsou reakcí na bezpečnostní problém zdokumentovaný v CVE-2017-8563, kde mohou špatní herci zvýšit svá oprávnění, když se Windows vrátí k ověřovacím protokolům NTLM.

Jakýkoli systém, který se připojuje k Active Directory prostřednictvím LDAP bez použití TLS, bude touto změnou negativně ovlivněn. To zahrnuje VMware vSphere. Pokud pro připojení vSphere k Microsoft Active Directory používáte nešifrovaný LDAP (ldap://, nikoli ldaps://) nebo integrované ověřování Windows, přečtěte si prosím dále.

Všechny podporované verze VMware vSphere byly ověřeny VMware Engineering, aby po těchto změnách fungovaly podle očekávání, kde očekáváme, že nešifrovaná autentizace LDAP bude úspěšná se starými výchozími nastaveními, selže s novými výchozími nastaveními a bude úspěšná při použití TLS/LDAPS.

Integrované ověřování systému Windows (IWA) bylo také testováno společností VMware Engineering. IWA používá k autentizaci GSSAPI a Kerberos a neposílá přihlašovací údaje v čisté podobě. IWA však v zákulisí používá nepodepsaný LDAP, aby umožnil vyhledávání uživatelů a skupin, a to přestane fungovat. To může ovlivnit možnost přidávat uživatele & skupiny do autentizačních konfigurací. VMware KB 78644 o některých z nich pojednává a VMware zkoumá změny, které mohou tuto situaci zlepšit.

Důležité poznámky

Tyto problémy jsou přímým důsledkem změn systému Windows od společnosti Microsoft. I když jsme ve VMware odhodláni pomáhat našim zákazníkům orientovat se v podobných problémech, žádáme vás, abyste nám zaslali zpětnou vazbu ke změnám ve Windows & aktualizace pro samotný Microsoft. Konfigurace zdrojů autentizace ve vSphere je zdokumentovaná & podporovaná činnost, se kterou mohou pomoci profesionálové z VMware Global Support Services (GSS), ale která přichází s předpokladem, že váš zdroj ověřování je použitelný a spolupracující. Obraťte se na podporu společnosti Microsoft pro pomoc s překonfigurováním a všemi aspekty služby Microsoft Active Directory.

Tyto problémy ovlivňují jakýkoli systém využívající LDAP pro přístup ke službě Active Directory a nejsou omezeny na VMware vSphere. Musíte také zkontrolovat zbytek svých systémů. Jako součást dokumentace k těmto změnám Microsoft uvádí způsoby auditování připojení ve formátu prostého textu k vaší infrastruktuře Active Directory, které mohou být užitečné.

Všechny snímky obrazovky v tomto příspěvku pocházejí z vSphere 6.7 Update 3 a HTML5 vSphere Client. Zkušenosti by měly být podobné pro vSphere 6.0 a 6.5.

Veškeré testování a dokumentace vSphere předpokládá přímé spojení mezi vSphere a zdroji ověřování. Pokud jsou vaše zdroje ověřování přes proxy nebo za nástrojem pro vyrovnávání zatížení aplikace, budete muset nezávisle posoudit, jak vás tyto změny ovlivňují. Prostudujte si prosím dokumentaci a dodavatele těchto produktů a systémů.

Pokud povolíte auditování ve své implementaci Active Directory, prostudujte si dokumentaci společnosti Microsoft, abyste zjistili, co znamená záznam v protokolu událostí, kdy k němu dojde a jaké informace jsou shromážděny v záznamu protokolu událostí, než otevřete případ podpory se společností Microsoft nebo VMware.

Koho se to týká?

Pokud jste nakonfigurovali vCenter Server pro přístup k Active Directory přes LDAP s TLS (LDAPS) nebo Identity Federation, nebude to ovlivněno. Můžete to zkontrolovat zobrazením zdrojů identity v klientovi vSphere:

Červená & Jako ilustraci jsme přidali zelený text. Zdroje používající LDAP (ldap://, port 389) budou pravděpodobně ovlivněny. Zdroje používající LDAPS (ldaps://, port 636) jsou pravděpodobně v pořádku, pokud se jedná o přímá připojení a ne přes proxy nebo load balancery.

Zdroje uvádějící svůj typ jako „Active Directory (Integrated Windows Authentication)“ se budou nadále ověřovat, ale jejich schopnost vyhledávat v Active Directory uživatele & skupiny se přeruší, protože k tomu používá nepodepsaný LDAP. To může ovlivnit možnost přidávat uživatele & skupiny do autentizačních konfigurací. VMware KB 78644 o některých z nich pojednává a VMware zkoumá změny, které mohou tuto situaci zlepšit.

Co se stane

Bez proaktivní akce z vaší strany přestanou dotčené zdroje identity fungovat, jakmile společnost Microsoft vydá tyto aktualizace a budou použity. Toto se objeví jako selhání přihlášení v klientovi vSphere:

a také chyby při pokusu o přidání nebo překonfigurování zdroje identity:

Poznámky & Doporučení k testování

Doporučujeme testování, abyste se s těmito aktualizacemi seznámili. Společnost Microsoft vydala pokyny, jak povolit tato nastavení:

Dokument o povolení podepisování LDAP v systému Windows Server 2008 uvádí, že je třeba změnit „Výchozí zásady domény“, ale aby byly účinné pro řadiče domény, musíte upravit také „Výchozí zásady řadičů domény“ nebo kteroukoli zásadu. platí pro řadiče domény, pokud jste přiřadili nový. Postup v tomto dokumentu se také zdá být použitelný pro všechny verze systému Windows, nejen pro 2008. Jakmile budou provedeny úpravy zásad skupiny, můžete počkat, až se zásady skupiny automaticky obnoví, nebo pomocí shellu na úrovni správce vydat „gpupdate / síla“ příkaz.

Mějte na paměti, že aktualizace zásad skupiny ovlivní ostatní řadiče domény & členové také. vCenter Server může konfigurovat více LDAP & Zdroje ověřování LDAPS a mohou specifikovat konkrétní řadiče domény, proto doporučujeme vytvořit nový & izolovanou instanci služby Active Directory pro testování (v tomto příspěvku můžete vidět můj motiv hospodářských zvířat pro testovací domény a lesy, který je oddělený od mého hlavního zdroje ověřování).

Chcete-li otestovat, zda se nastavení projevilo, použijte nástroj „ldp.exe“ (Start->Spustit->ldp) ze samotného řadiče domény. V nabídce Připojení vyberte Připojit a zadejte „localhost“ a port 389:

Odtud se vraťte do nabídky Připojení a vyberte možnost „Svázat“. Zadejte přihlašovací údaje své domény a vyberte „Jednoduché svázání“, jak je znázorněno zde:

Měla by se zobrazit chyba „Chyba 0x2028 Pro tento server je vyžadována bezpečnější metoda ověřování“, jak je uvedeno níže, což znamená, že jste správně zakázali vazby LDAP s prostým textem.

Pokud se při tomto postupu tato chyba nezobrazí, změny se neprojevily!

Zde můžete otestovat připojení serveru vCenter ke službě Active Directory a sledovat chování uvedené na začátku tohoto příspěvku. Jak již bylo zmíněno dříve, VMware vCenter Server může mít nakonfigurováno více instancí Active Directory, takže se doporučuje testování s izolovanou instancí Active Directory. Podobně se doporučuje nasazení testovacího zařízení vCenter Server. Udělejte snímek prostředí a můžete jej obnovit, pokud se vše pokazí. Vnořená virtualizační prostředí jsou obecně vynikajícím způsobem, jak otestovat funkční změny, jako je tato. William Lam má na svém osobním blogu pro vnořené ESXi rozsáhlé zdroje.

Pro ještě větší izolaci testování, pokud nejprve nasadíte virtuální počítač Windows Active Directory a nakonfigurujete službu AD DNS, můžete jej použít jako server DNS pro testovací nasazení serveru vCenter Server.

Možný postup č. 1: Povolení TLS na Active Directory (LDAPS)

Být zaměřen na bezpečnost, první & nejlepším doporučením je zabezpečit své ověřování pomocí TLS. Z praxe by měla být veškerá komunikace v síti šifrována. To platí zejména pro autentizační provoz. Informace o konfiguraci služby Active Directory Certificate Services a vydávání certifikátů pro služby řadiče domény Active Directory naleznete v dokumentaci společnosti Microsoft.

Konfigurace vCenter Server pro použití LDAPS je jednoduchá a dobře zdokumentovaná na docs.vmware.com. Je tu jeden obrat: budete potřebovat certifikát pro řadič domény. Můžete jej exportovat ze systému Windows, ale pokud máte přístup k OpenSSL, ať už nainstalovanému na počítači se systémem Windows nebo zabudovanému do hostitele Linux/UNIX, je tento ukázkový příkaz často jednodušší:

echo | openssl s_client -showcerts -connect cows-ad-a1.cows.local:636

zobrazí požadovaný certifikát mezi řádky „—–ZAČÁTEK CERTIFIKÁTU—–“ a „—–KONEC CERTIFIKÁTU—–“. Zkopírujte tyto řádky a vše mezi nimi do textového souboru a po zobrazení výzvy jej použijte. Samozřejmě nahraďte FQDN mého testu na farmě nativním názvem DNS řadiče domény, ke kterému se připojujete!

Možný postup č. 2: Proaktivně nakonfigurujte tato nastavení na původní výchozí hodnoty

Rozhodnutí, které by mohlo negativně ovlivnit zabezpečení, může být obtížné, protože se zajímáte o bezpečnost. Zabezpečení informací však zahrnuje mnohem více než jen změnu nastavení registru. Profesionálové v oblasti informační bezpečnosti používají „triádu CIA“ – důvěrnost, integritu a dostupnost – k promyšlenému zvážení rizika konfigurace, přičemž krátké časové rámce a povaha těchto změn by mohly vážně ovlivnit dostupnost. Pokud jste již v této konfiguraci běželi, pravděpodobně máte zavedeny kompenzační ovládací prvky, jako je izolace (firewally, samostatné sítě), abyste se chránili před někým, kdo sleduje autentizační provoz.

Microsoft uvedl, že tyto nadcházející opravy změní výchozí nastavení. Ačkoli to neřekli přímo, znamená to, že tato nastavení můžete proaktivně nastavit na aktuální výchozí hodnoty pomocí stejných procesů (klíč registru LdapEnforceChannelSigning nastavte na 0, zásady skupiny nastavte na „Žádné“). To předpokládá, že je Microsoft opravou nepřepíše, což je pravděpodobně rozumné, ale všichni si to budeme chtít ověřit, až budou opravy k dispozici.

Měli byste to udělat? Může to být zatím nejjednodušší cesta vpřed, ale nezlepšuje zabezpečení a pravděpodobně stojí za to si promluvit s vaším CISO.

Další úvahy

Není dobrý nápad výrazně zdržovat záplatování. Patching je JEDINÝ způsob, jak odstranit zranitelnost ze systému, a je to způsob číslo 1, jak se mohou organizace a jednotlivci zabezpečit (druhý způsob jsou skvělá hesla a hygiena účtu). Microsoft dělá tuto velkou změnu z nějakého důvodu a zatím nevíme, co se změnilo od původního zveřejnění zranitelnosti z roku 2017. Je velmi pravděpodobné, že za pár měsíců se dozvíme více o tom, co to pohání. To nebude dobrá zpráva, ať je to cokoliv. Odložením nebo vynecháním oprav oddálíte nevyhnutelné a zvýšíte riziko, a to jak ze strany hackerů, tak ze strany lidí s dobrými úmysly, kteří omylem použijí kumulativní aktualizace.

Ať už zvolíte jakýkoli postup, je to skvělá příležitost, jak se ujistit, že znáte a/nebo můžete získat heslo pro účet správce instance serveru vCenter Server SSO (často administrator@vsphere.local).

Active Directory je báječná v tom, že je to multimaster, replikující se distribuovaná databáze s integrovanými funkcemi dostupnosti a obnovitelnosti. Využijte toho ve svůj prospěch a naplánujte postupné zavádění pro tento problém i jako budoucí strategii oprav. Stejně tak nezapomeňte na flexibilitu, kterou má vCenter Server při zacílení na konkrétní řadiče domény, a také na možnost aplikovat zásady skupiny na konkrétní řadiče domény.

Děkujeme

Jako vždy děkujeme, že jste zákazníkem společnosti VMware. Vážíme si vás a doufáme, že stejně jako naše pokračující pokyny týkající se zranitelností CPU, i toto bylo užitečné při orientaci v těchto větších změnách v celém odvětví.

S dotazy a zpětnou vazbou o službě Active Directory, aktualizacích systému Windows a těchto aktualizacích společnosti Microsoft se obraťte přímo na společnost Microsoft. Máme rádi zpětnou vazbu, ale pokud jde o Active Directory a Windows, to nejlepší, co můžeme udělat, je soucit s vámi. Zpětná vazba je nejsilnější, když je přímo od uživatele k odpovědnému dodavateli.

V případě provozních problémů s produkty VMware se obraťte na služby globální podpory společnosti VMware, které jsou vám k dispozici 24 hodin denně, 7 dní v týdnu. Pokud existují další věci, se kterými vám můžeme pomoci, nebo pokud máte dotazy nebo zpětnou vazbu k produktům VMware, obraťte se na tým pro váš účet nebo technického manažera účtu. V případě problémů přímo týkajících se tohoto příspěvku zanechte komentář níže.

Poslední věc – přihlaste se k odběru tohoto blogu a sledujte nás na Twitteru nebo Facebooku! Píšeme spoustu technicky zaměřených článků, jako je tento, pokrývající novinky a aktuální témata a budeme rádi, když budete s námi.

Děkuji!