Актуализация (13.05.2020 г.): Тази публикация е актуализирана, за да отразява текущите насоки по тази тема и че интегрираното Windows удостоверяване е засегнато от тази промяна. В тази публикация има добра информация, но повече информация може да бъде намерена в публикацията „vSphere Authentication, Microsoft Active Directory LDAP и Event ID 2889.“
—-
Актуализация (2/6/2020): На 4 февруари 2020 г. Microsoft промени насоките си за актуализациите на Windows от март 2020 г., за да покаже, че настройките по подразбиране НЯМА да се променят в тази актуализация.
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV190023
Оставяме тази публикация активна като справка, но ще съкратим коментарите, за да маркираме и/или намалим неподдържаните & опасни съвети и дискусии.
Продължаваме да повтаряме, че поддържаните версии на VMware vSphere работят правилно и с двете настройки за обвързване на LDAP, нашата препоръка е винаги да се използва криптиране за защита на данните в полет в мрежа и промяната на vSphere извън насоките от VMware Global Support Services не е препоръчва се или се допуска и може да повлияе на функционалността и поддръжката на продукта.
—-
Актуализация (16.01.2020 г.): Актуализации за отразяване на резултатите от тестването на интегрирано удостоверяване на Windows.
Microsoft наскоро пусна предупреждения към своята клиентска база, че в актуализациите за Windows от март 2020 г. възнамерява да промени поведението по подразбиране на LDAP сървърите на Microsoft, които са част от внедряване на Active Directory. Тези промени ще направят защитеното обвързване на LDAP канал и LDAP подписване изискване по подразбиране при достъп до Microsoft Active Directory чрез LDAP или LDAPS. Тези промени са отговор на проблем със сигурността, документиран в CVE-2017-8563, където лошите участници могат да повишат привилегиите си, когато Windows се върне към NTLM протоколи за удостоверяване.
Всяка система, която се свързва с Active Directory чрез LDAP, без да използва TLS, ще бъде отрицателно засегната от тази промяна. Това включва VMware vSphere. Ако използвате некриптиран LDAP (ldap://, не ldaps://) или интегрирано удостоверяване на Windows за свързване на vSphere към Microsoft Active Directory, моля, прочетете повече.
Всички поддържани версии на VMware vSphere са проверени от VMware Engineering, за да работят според очакванията след тези промени, където очакваме нешифрованото LDAP удостоверяване да успее със старите настройки по подразбиране, да се провали с новите настройки по подразбиране и да успее при използване на TLS/LDAPS.
Интегрираното удостоверяване на Windows (IWA) също е тествано от VMware Engineering. IWA използва GSSAPI и Kerberos за удостоверяване и не изпраща ясно идентификационни данни. IWA обаче използва неподписан LDAP зад кулисите, за да позволи търсене на потребители и групи, и това ще спре да работи. Това може да повлияе на възможността за добавяне на потребители & групи към конфигурации за удостоверяване. VMware KB 78644 обсъжда част от това и VMware проучва промени, които могат да подобрят тази ситуация.
Тези проблеми са пряк резултат от промените на Microsoft в Windows. Въпреки че ние от VMware се ангажираме да помагаме на нашите клиенти да се справят с проблеми като тези, ние ви молим да изпратите обратна връзка относно промените в Windows & актуализации на самите Microsoft. Конфигурирането на източници за удостоверяване във vSphere е документиран & поддържана дейност, с която професионалистите от VMware Global Support Services (GSS) могат да помогнат, но това идва с предпоставката вашият източник за удостоверяване да е използваем и съвместим. Моля, свържете се с поддръжката на Microsoft за съдействие при преконфигуриране и всички аспекти на Microsoft Active Directory.
Тези проблеми засягат всяка система, използваща LDAP за достъп до Active Directory и не се ограничават до VMware vSphere. Трябва да проверите и останалите си системи. Като част от документацията за тези промени Microsoft изброява начини за одит на връзки с ясен текст към вашата инфраструктура на Active Directory, което може да бъде полезно.
Всички екранни снимки в тази публикация са на vSphere 6.7 Update 3 и HTML5 vSphere Client. Опитът трябва да е подобен за vSphere 6.0 и 6.5.
Всички тестове и документация на vSphere предполагат директна връзка между vSphere и източниците за удостоверяване. Ако вашите източници за удостоверяване са прокси или зад балансиращо натоварване на приложения, ще трябва да оцените независимо как сте засегнати от тези промени. Моля, консултирайте се с документацията и доставчиците на тези продукти и системи.
Ако активирате одит на внедряването на Active Directory, моля, прегледайте документацията на Microsoft за това какво означава запис в регистъра на събитията, кога ще се появи и каква информация се събира в записа в регистъра на събитията, преди да отворите случай за поддръжка с Microsoft или VMware.
Ако сте конфигурирали vCenter Server за достъп до Active Directory през LDAP с TLS (LDAPS) или Identity Federation, няма да бъдете засегнати от това. Можете да проверите това, като прегледате своите източници на идентичност във vSphere клиента:
Червеният & зелен текст е добавен от нас като илюстрация. Източниците, използващи LDAP (ldap://, порт 389), вероятно ще бъдат засегнати. Източниците, използващи LDAPS (ldaps://, порт 636), вероятно са добри, ако са директни връзки, а не чрез прокси сървъри или балансьори на натоварването.
Източниците, изброяващи техния тип като „Active Directory (интегрирано удостоверяване на Windows)“, ще продължат да се удостоверяват, но способността им да търсят в Active Directory потребители и & групи ще се разпадне, тъй като използва неподписан LDAP за това. Това може да повлияе на възможността за добавяне на потребители & групи към конфигурации за удостоверяване. VMware KB 78644 обсъжда част от това и VMware проучва промени, които могат да подобрят тази ситуация.
Без проактивни действия от ваша страна, след като Microsoft пусне тези актуализации и те бъдат приложени, засегнатите източници на самоличност ще спрат да работят. Това ще се появи като неуспешно влизане във vSphere клиента:
както и грешки при опит за добавяне или преконфигуриране на източник на самоличност:
Препоръчваме да тествате, за да се запознаете с тези актуализации. Microsoft пусна насоки как да активирате тези настройки:
Документът за активиране на LDAP подписване в Windows Server 2008 показва, че трябва да промените „Политиката за домейн по подразбиране“, но за да бъде ефективна за домейн контролерите, трябва също да редактирате „Политиката за домейн контролери по подразбиране“ или която и да е друга важи за домейн контролерите, ако сте задали нов. Процедурата в този документ също изглежда приложима за всички версии на Windows, а не само за 2008. След като редакциите на груповите правила са налице, можете да изчакате, докато груповите правила се обновят автоматично или да използвате обвивка на ниво администратор, за да издадете „gpupdate / сила”.
Имайте предвид, че актуализирането на груповите правила засяга други контролери на домейн & членове също. vCenter Server може да конфигурира множество LDAP & LDAPS източници за удостоверяване и може да посочи конкретни контролери на домейн, така че препоръчваме да създадете нов & изолиран екземпляр на Active Directory за тестване (можете да видите моята тема за селскостопански животни за тестови домейни и гори в тази публикация, която е отделна от основния ми източник за удостоверяване).
За да проверите дали настройките са влезли в сила, използвайте помощната програма „ldp.exe“ (Start->Run->ldp) от самия домейн контролер. От менюто Connection изберете Connect и въведете „localhost“ и порт 389:
Оттам се върнете в менюто Connection и изберете „Bind“. Въведете идентификационните данни на вашия домейн и изберете „Опростено свързване“, както е показано тук:
Трябва да получите грешката „Грешка 0x2028 Изисква се по-сигурен метод за удостоверяване за този сървър“, както е показано по-долу, което показва, че правилно сте деактивирали LDAP свързванията с чист текст.
Ако не получите тази грешка с тази процедура, промените не са влезли в сила!
Оттук можете да тествате свързаността на vCenter Server към Active Directory, наблюдавайки поведението, наблюдавано в началото на тази публикация. Както бе споменато по-рано, VMware vCenter Server може да има конфигурирани множество екземпляри на Active Directory, така че се препоръчва тестване с изолиран екземпляр на Active Directory. По подобен начин се препоръчва внедряването на тестово устройство vCenter Server. Направете моментна снимка на средата и можете да я възстановите, ако всичко се обърка. Средите за вложена виртуализация като цяло са отличен начин за тестване на функционални промени като тази. Уилям Лам разполага с обширни ресурси в своя личен блог за вложен ESXi.
За още по-голяма изолация при тестване, ако първо разположите Windows Active Directory VM и конфигурирате AD DNS, можете да го използвате като DNS сървър за тестово внедряване на vCenter Server.
С оглед на сигурността, първият & най-добрата препоръка е да защитите удостоверяването си с TLS. Като въпрос на практика всички комуникации в мрежата трябва да бъдат криптирани. Това важи особено за трафика за удостоверяване. Моля, вижте документацията на Microsoft за конфигуриране на услугите за сертификати на Active Directory и издаване на сертификати към услугите на домейн контролера на Active Directory.
Конфигурирането на vCenter Server за използване на LDAPS е лесно и добре документирано на docs.vmware.com. Има един обрат: ще ви е необходим сертификат за домейн контролера. Можете да го експортирате от Windows, но ако имате достъп до OpenSSL, инсталиран на компютър с Windows или вграден в Linux/UNIX хост, тази примерна команда често е по-лесна:
ехо | openssl s_client -showcerts -connect cows-ad-a1.cows.local:636
ще покаже сертификата, от който се нуждаете, между редовете „—–НАЧАЛО НА СЕРТИФИКАТА—–“ и „—–КРАЙ НА СЕРТИФИКАТА—–“. Копирайте тези редове и всичко между тях в текстов файл и го използвайте, когато бъдете подканени. Заменете моите тестови FQDN на селскостопански животни с собственото DNS име на домейн контролера, към който се свързвате, разбира се!
Възможно е да се грижите за сигурността, като вземете решение, което може да повлияе негативно на сигурността, може да бъде трудно. Има обаче много повече за сигурността на информацията от просто промяна на настройките на системния регистър. Специалистите по информационна сигурност използват „триадата на ЦРУ“ — поверителност, цялост и достъпност — за внимателно преценяване на риска от дадена конфигурация, а кратките времеви рамки и естеството на тези промени могат сериозно да повлияят на наличността. Ако вече сте работили в тази конфигурация, вероятно имате компенсиращи контроли на място, като изолация (защитни стени, отделни мрежи), за защита срещу някой, който наблюдава трафика за удостоверяване.
Microsoft заяви, че тези предстоящи корекции ще променят настройките по подразбиране. Въпреки че не са го казали директно, това означава, че можете проактивно да зададете тези настройки на текущите по подразбиране, като използвате същите тези процеси (задайте ключа на регистъра LdapEnforceChannelSigning на 0, задайте груповите правила на „Няма“). Това предполага, че Microsoft няма да ги презапише с корекцията, което вероятно е разумно, но всички ние ще искаме да проверим това, след като корекциите са налични.
Трябва ли да направите това? Това може да е най-лесният начин за напред, но не подобрява сигурността и вероятно си заслужава разговор с вашия CISO.
Не е добра идея да забавяте значително корекцията. Корекцията е ЕДИНСТВЕНИЯТ начин за премахване на уязвимост от система и това е начин №1 организациите и отделните лица да се защитят (начин №2 са страхотни пароли и хигиена на акаунта). Microsoft прави тази голяма промяна с причина и все още не знаем какво се е променило след първоначалното разкриване на уязвимостта през 2017 г. Много е вероятно след няколко месеца да научим повече за това какво води до това. Това няма да е добра новина, каквато и да е. Чрез забавяне или пропускане на корекции вие забавяте неизбежното и увеличавате риска си както от хакери, така и от добронамерени хора, случайно прилагащи кумулативни актуализации.
Какъвто и начин на действие да изберете, това е страхотна възможност да се уверите, че знаете и/или можете да извлечете паролата за администраторския акаунт на вашия vCenter Server SSO инстанция (често administrator@vsphere.local).
Active Directory е чудесен с това, че е мулти-главна, репликираща се, разпределена база данни, с вградени функции за наличност и възстановяване. Използвайте това във ваша полза и планирайте поетапно внедряване както за този проблем, така и като бъдеща стратегия за коригиране. По същия начин не забравяйте гъвкавостта, която vCenter Server има при насочване към конкретни домейн контролери, както и способността да прилага групови правила към конкретни домейн контролери.
Както винаги, благодарим ви, че сте клиент на VMware. Оценяваме ви и се надяваме, че, подобно на нашите продължаващи насоки относно уязвимостите на процесора, това е било полезно при навигирането в тези по-големи промени в цялата индустрия.
За въпроси и обратна връзка относно Active Directory, актуализации на Windows и тези актуализации на Microsoft, моля, свържете се директно с Microsoft. Обичаме обратната връзка, но ако става въпрос за Active Directory и Windows, най-доброто, което ще можем да направим, е да ви съчувстваме. Обратната връзка е най-мощна, когато е директна от потребител към отговорния доставчик.
За оперативни проблеми с продуктите на VMware, моля, свържете се с отдела за глобална поддръжка на VMware, който е на разположение 24×7, за да ви помогне. Ако има други неща, с които можем да помогнем, или имате въпроси или обратна връзка относно продуктите на VMware, моля, свържете се с екипа на вашия акаунт или с техническия мениджър на акаунта. За проблеми, пряко свързани с тази публикация, моля, оставете коментар по-долу.
Последно нещо – абонирайте се за този блог и ни следвайте в Twitter или във Facebook! Ние пишем много статии с техническа насоченост като тази, обхващащи новини и актуални теми, и ще се радваме да сте с нас.
Благодаря ви!
PREV: Виртуални хостове
NEXT: Хоствайте множество сайтове на един сървър с помощта на Apache | Течна мрежа
![[Решен] Не може да се свърже с MySql сървър на localhost (10061) (Вижте темата) * Форум на общността на Apache OpenOffice](http://website-google-hk.oss-cn-hongkong.aliyuncs.com/drawing/26/2022-3-1/7051.jpeg "[Решен] Не може да се свърже с MySql сървър на localhost (10061) (Вижте темата) * Форум на общността на Apache OpenOffice")
