VMware vSphere & Microsoft LDAP-kanavan sidonta ja allekirjoitus...

Päivitys (13.5.2020): Tämä viesti on päivitetty vastaamaan tämän aiheen tämänhetkisiä ohjeita ja että tämä muutos vaikuttaa integroituun Windowsin todennukseen. Tässä viestissä on hyvää tietoa, mutta lisätietoja löytyy viestistä "vSphere Authentication, Microsoft Active Directory LDAP ja Event ID 2889".

--

Päivitys (6.2.2020): Microsoft muutti 4.2.2020 maaliskuun 2020 Windows-päivityksiä koskevia ohjeitaan ilmoittaakseen, että oletusasetukset EIVÄT muutu kyseisessä päivityksessä.

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

Jätämme tämän viestin aktiiviseksi viitteeksi, mutta karsimme kommentit merkitäksemme ja/tai vähentääksemme ei-tuettuja & vaarallisia neuvoja ja keskustelua.

Toistamme edelleen, että tuetut VMware vSpheren versiot toimivat oikein molempien LDAP-sidosasetusten kanssa. Suosittelemme aina käyttämään salausta verkon lennon aikana tapahtuvien tietojen suojaamiseen, ja vSpheren vaihtaminen VMware Global Support Services -palvelun ohjeiden ulkopuolella ei ole suositeltu tai suvaitsevainen ja saattaa vaikuttaa tuotteen toimivuuteen ja tuettavuuteen.

--

Päivitys (16.1.2020): Päivitykset, jotka vastaavat integroidun Windows-todennuksen testauksen tuloksia.

Microsoft on äskettäin julkaissut varoituksia asiakaskunnalleen, että se aikoo maaliskuun 2020 Windows-päivityksissä muuttaa Active Directory -asennukseen kuuluvien Microsoftin LDAP-palvelimien oletuskäyttäytymistä. Nämä muutokset tekevät suojatusta LDAP-kanavan sitomisesta ja LDAP-allekirjoituksesta oletusvaatimuksen käytettäessä Microsoft Active Directorya LDAP:n tai LDAPS:n avulla. Nämä muutokset ovat vastaus CVE-2017-8563:ssa dokumentoituun tietoturvaongelmaan, jossa huonot toimijat voivat korottaa oikeuksiaan, kun Windows palaa käyttämään NTLM-todennusprotokollia.

Tämä muutos vaikuttaa negatiivisesti kaikkiin järjestelmiin, jotka muodostavat yhteyden Active Directoryyn LDAP:n kautta ilman TLS:ää. Tämä sisältää VMware vSpheren. Jos käytät salaamatonta LDAP:tä (ldap://, ei ldaps://) tai integroitua Windows-todennusta vSpheren yhdistämiseen Microsoft Active Directoryyn, lue lisää.

VMware Engineering on vahvistanut, että kaikki tuetut VMware vSpheren versiot toimivat odotetusti näiden muutosten jälkeen. Odotamme salaamattoman LDAP-todennuksen onnistuvan vanhoilla oletusasetuksella, epäonnistuvan uusilla oletusasetuksilla ja onnistuvan käytettäessä TLS/LDAPS:ia.

VMware Engineering on myös testannut Integrated Windows Authentication (IWA). IWA käyttää GSSAPI:ta ja Kerberosia todentamiseen eikä lähetä valtuustietoja selkeästi. IWA kuitenkin käyttää allekirjoittamatonta LDAP:tä kulissien takana mahdollistaakseen käyttäjien ja ryhmien haun, ja tämä lakkaa toimimasta. Tämä saattaa vaikuttaa mahdollisuuteen lisätä käyttäjiä & ryhmät todennuskokoonpanoihin. VMware KB 78644 käsittelee joitakin näistä, ja VMware tutkii muutoksia, jotka voivat parantaa tätä tilannetta.

Tärkeitä huomautuksia

Nämä ongelmat ovat suoraan seurausta Microsoftin Windows-muutoksista. Vaikka me VMwarella olemme sitoutuneet auttamaan asiakkaitamme selviytymään tällaisista ongelmista, pyydämme sinua antamaan suoraa palautetta Windowsin muutoksista & päivityksiä Microsoftille itselleen. Todennuslähteiden määrittäminen vSpheressä on dokumentoitu & tuettu toiminta, jossa VMware Global Support Services (GSS) -ammattilaiset voivat auttaa, mutta sen edellytyksenä on, että todennuslähde on käyttökelpoinen ja yhteistyökykyinen. Ota yhteyttä Microsoftin tukeen saadaksesi apua uudelleenmäärityksessä ja kaikissa Microsoft Active Directoryn osissa.

Nämä ongelmat vaikuttavat kaikkiin järjestelmiin, jotka käyttävät Active Directoryyn LDAP:tä, eivätkä rajoitu VMware vSphereen. Sinun on tarkistettava myös muut järjestelmäsi. Osana näiden muutosten dokumentaatiota Microsoft luettelee tapoja tarkastaa Active Directory -infrastruktuurin selkeätekstiyhteyksiä, joista voi olla apua.

Kaikki tämän viestin kuvakaappaukset ovat vSphere 6.7 -päivityksestä 3 ja HTML5 vSphere Client -ohjelmasta. Kokemuksen pitäisi olla samanlainen vSphere 6.0:ssa ja 6.5:ssä.

Kaikki vSpheren testaukset ja dokumentaatio edellyttävät suoraa yhteyttä vSpheren ja todennuslähteiden välillä. Jos todennuslähteesi ovat välityspalvelimessa tai sovelluksen kuormituksen tasapainottajan takana, sinun on arvioitava itsenäisesti, miten nämä muutokset vaikuttavat sinuun. Tutustu näiden tuotteiden ja järjestelmien asiakirjoihin ja toimittajiin.

Jos otat Active Directory -toteutuksen tarkastuksen käyttöön, tarkista Microsoftin dokumentaatiosta, mitä tapahtumalokimerkintä tarkoittaa, milloin se tapahtuu ja mitä tietoja tapahtumalokimerkintään kerätään, ennen kuin avaat tukitapauksen Microsoftin tai VMwaren kanssa.

Ketä tämä koskee?

Jos olet määrittänyt vCenter Serverin käyttämään Active Directorya LDAP:n kautta TLS:n (LDAPS) tai Identity Federationin avulla, tämä ei vaikuta sinuun. Voit tarkistaa tämän tarkastelemalla identiteettilähteitäsi vSphere Client -ohjelmassa:

Punainen & olemme lisänneet vihreää tekstiä kuvaksi. Tämä vaikuttaa todennäköisesti LDAP:tä käyttäviin lähteisiin (ldap://, portti 389). LDAPS:ää käyttävät lähteet (ldaps://, portti 636) ovat todennäköisesti hyviä, jos ne ovat suoria yhteyksiä eivätkä välityspalvelinten tai kuormantasainten kautta.

Lähteet, joiden tyyppi on "Active Directory (Integrated Windows Authentication)", todentavat edelleen, mutta niiden kyky etsiä Active Directorysta käyttäjiä & ryhmät katkeavat, koska se käyttää allekirjoittamatonta LDAP:ta. Tämä saattaa vaikuttaa mahdollisuuteen lisätä käyttäjiä & ryhmät todennuskokoonpanoihin. VMware KB 78644 käsittelee joitakin näistä, ja VMware tutkii muutoksia, jotka voivat parantaa tätä tilannetta.

Mitä tapahtuu

Ilman ennakoivia toimia, kun Microsoft julkaisee nämä päivitykset ja ne on otettu käyttöön, vaikuttaneet identiteettilähteet lakkaavat toimimasta. Tämä näkyy kirjautumisvirheinä vSphere Client -sovelluksessa:

sekä virheet yritettäessä lisätä tai määrittää uudelleen identiteettilähdettä:

Huomautukset & Testausehdotuksia

Suosittelemme testaamista, jotta voit tutustua näihin päivityksiin. Microsoft on julkaissut ohjeet näiden asetusten ottamisesta käyttöön:

Asiakirja LDAP-sisäänkirjautumisen käyttöönotosta Windows Server 2008:ssa osoittaa, että sinun on muutettava "Oletustoimialueen käytäntöä", mutta jotta se olisi tehokas toimialueen ohjaimissa, sinun on myös muokattava "Oletustoimialueen ohjaimien käytäntöä" tai mitä tahansa käytäntöä. koskee toimialueen ohjaimia, jos olet määrittänyt uuden. Tuossa asiakirjassa esitetty menettely näyttää myös soveltuvan kaikkiin Windows-versioihin, ei vain 2008:aan. Kun ryhmäkäytäntömuokkaukset on tehty, voit odottaa, kunnes ryhmäkäytäntö päivittyy automaattisesti, tai antaa järjestelmänvalvojan tason komentotulkki "gpupdate / pakottaa" komento.

Muista, että ryhmäkäytännön päivittäminen vaikuttaa muihin toimialueen ohjaimiin & myös jäseniä. vCenter Server voi määrittää useita LDAP & LDAPS-todennuslähteet ja voivat määrittää tietyt toimialueen ohjauskoneet, joten suosittelemme uuden & eristetty Active Directory -esiintymä testausta varten (näet kotieläinteemani testialueille ja metsille tässä viestissä, joka on erillinen päätodennuslähteestäni).

Testaa asetusten voimaantulo käyttämällä itse toimialueen ohjaimen "ldp.exe"-apuohjelmaa (Start->Run->ldp). Valitse Yhteys-valikosta Yhdistä ja kirjoita "localhost" ja portti 389:

Sieltä palaa Yhteys-valikkoon ja valitse "Sido". Syötä verkkotunnuksesi tunnistetiedot ja valitse "Yksinkertainen sidos" kuten tässä näkyy:

Sinun pitäisi saada alla näkyvä virheilmoitus "Virhe 0x2028 Tälle palvelimelle tarvitaan turvallisempi todennusmenetelmä", joka osoittaa, että olet poistanut selkeän tekstin LDAP-sidokset oikein käytöstä.

Jos et saa tätä virheilmoitusta tällä toimenpiteellä, muutokset eivät ole tulleet voimaan!

Täältä voit testata vCenter Server -yhteyden Active Directoryyn, mikä todistaa tämän viestin alussa havaitun toiminnan. Kuten aiemmin mainittiin, VMware vCenter Serverissä voi olla määritettynä useita Active Directory -esiintymiä, joten on suositeltavaa testata yksittäistä Active Directory -esiintymää. Samoin suositellaan vCenter Server -testilaitteiston käyttöönottoa. Ota tilannekuva ympäristöstä ja voit palauttaa sen, jos kaikki menee pieleen. Sisäkkäiset virtualisointiympäristöt ovat yleensä erinomainen tapa testata tämän kaltaisia ​​toiminnallisia muutoksia. William Lamilla on henkilökohtaisessa blogissaan laajat resurssit sisäkkäistä ESXi:stä.

Jos otat ensin käyttöön Windows Active Directory -virtuaalikoneen ja määrität AD DNS:n, voit käyttää sitä DNS-palvelimena vCenter Serverin testiasennuksessa, jotta testaus voidaan eristää entistä paremmin.

Mahdollinen toimintatapa #1: Ota TLS käyttöön Active Directoryssa (LDAPS)

Turvallisuusnäkökulmasta ensimmäinen & paras suositus on suojata todennus TLS:llä. Käytännössä kaikki verkon viestintä tulee salata. Tämä koskee erityisesti todennusliikennettä. Lisätietoja Active Directory -varmennepalveluiden määrittämisestä ja varmenteiden myöntämisestä Active Directory -toimialueen ohjainpalveluille on Microsoftin ohjeissa.

VCenter Serverin määrittäminen käyttämään LDAPS:ia on yksinkertaista ja hyvin dokumentoitua osoitteessa docs.vmware.com. Siinä on yksi käänne: tarvitset toimialueen ohjaimen varmenteen. Voit viedä sen Windowsista, mutta jos sinulla on pääsy OpenSSL:ään, joko asennettuna Windows-tietokoneeseen tai sisäänrakennettuna Linux/UNIX-isäntään, tämä esimerkkikomento on usein helpompi:

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

näyttää tarvitsemasi varmenteen rivien "—–ALKUVARMISTUS—–" ja "-–END CERTIFICATE—–" välissä. Kopioi nämä rivit ja kaikki niiden välillä tekstitiedostoon ja käytä sitä pyydettäessä. Korvaa kotieläintestin FQDN-tunnukset luonnollisesti sen verkkotunnuksen ohjaimen alkuperäisellä DNS-nimellä, johon muodostat yhteyden!

Mahdollinen toimintatapa 2: Määritä nämä asetukset ennakoivasti alkuperäisiksi oletusasetuksiin

Turvallisuusnäkökulmasta turvallisuuteen kielteisesti vaikuttavien päätösten tekeminen voi olla vaikeaa. Tietoturvaan liittyy kuitenkin paljon muutakin kuin pelkkä rekisteriasetusten muuttaminen. Tietoturva-ammattilaiset käyttävät "CIA-kolmiota" - luottamuksellisuutta, eheyttä ja saatavuutta - punnitakseen harkitusti kokoonpanon riskejä, ja näiden muutosten lyhyet aikakehykset ja luonne voivat vaikuttaa vakavasti saatavuuteen. Jos olet jo käyttänyt tätä kokoonpanoa, sinulla on todennäköisesti käytössä kompensoivia säätöjä, kuten eristys (palomuurit, erilliset verkot), jotta joku ei tarkkaile todennusliikennettä.

Microsoft on ilmoittanut, että nämä tulevat korjaustiedostot muuttavat oletusasetuksia. Vaikka he eivät ole sanoneet sitä suoraan, tämä tarkoittaa, että voit asettaa kyseiset asetukset ennakoivasti nykyisiin oletusasetuksiin käyttämällä samoja prosesseja (määritä LdapEnforceChannelSigning-rekisteriavaimeksi 0, aseta ryhmäkäytännöiksi Ei mitään). Tämä olettaa, että Microsoft ei korvaa niitä korjaustiedostolla, mikä on luultavasti järkevää, mutta me kaikki haluamme varmistaa, että kun korjaustiedostot ovat saatavilla.

Pitäisikö sinun tehdä tämä? Se saattaa olla helpoin tapa edetä tällä hetkellä, mutta se ei paranna turvallisuutta, ja se on todennäköisesti keskustelun arvoinen CISO:n kanssa.

Muita huomioita

Ei ole hyvä idea viivyttää korjausta merkittävästi. Paikkaus on AINOA tapa poistaa haavoittuvuus järjestelmästä, ja se on paras tapa organisaatiot ja yksityishenkilöt turvata itsensä (toinen tapa on hyvät salasanat ja tilihygienia). Microsoft tekee tämän suuren muutoksen syystä, emmekä vielä tiedä, mikä on muuttunut alkuperäisen vuoden 2017 haavoittuvuuden paljastamisen jälkeen. On hyvin todennäköistä, että muutaman kuukauden kuluttua opimme lisää siitä, mikä tähän vaikuttaa. Se ei ole hyvä uutinen, oli se sitten mikä tahansa. Viivyttämällä tai jättämällä pois korjaustiedostoja lykkäät väistämätöntä ja lisäät riskiäsi, sekä hakkereilta että hyvää tarkoittavista ihmisistä, jotka vahingossa asentavat kumulatiivisia päivityksiä.

Valitsetpa minkä tahansa toimintatavan, tämä on loistava tilaisuus varmistaa, että tiedät ja/tai pystyt hakemaan vCenter Server SSO -esiintymän järjestelmänvalvojan tilin salasanan (usein administrator@vsphere.local).

Active Directory on upea siinä mielessä, että se on monipäällikkö, replikoituva, hajautettu tietokanta, jossa on sisäänrakennetut saatavuus- ja palautettavuusominaisuudet. Käytä tätä hyödyksesi ja suunnittele vaiheittainen käyttöönotto sekä tälle ongelmalle että tulevaksi korjausstrategiaksi. Älä myöskään unohda vCenter Serverin joustavuutta tiettyihin toimialueen ohjauskoneisiin kohdistamisessa sekä kykyä soveltaa ryhmäkäytäntöjä tiettyihin toimialueen ohjauskoneisiin.

Kiitos

Kuten aina, kiitos, että olet VMware-asiakas. Arvostamme sinua ja toivomme, että kuten jatkuvat CPU-haavoittuvuuksia koskevat ohjeemme, tämä on auttanut navigoimaan näissä laajoissa alan laajuisissa muutoksissa.

Jos sinulla on kysyttävää ja palautetta Active Directorystä, Windows-päivityksistä ja näistä Microsoft-päivityksistä, ota yhteyttä suoraan Microsoftiin. Rakastamme palautetta, mutta jos kyse on Active Directorystä ja Windowsista, voimme parhaiten olla myötätuntoisia kanssasi. Palaute on tehokkainta, kun se tulee suoraan käyttäjältä vastuulliselle toimittajalle.

VMware-tuotteiden toimintaongelmissa ota yhteyttä VMwaren maailmanlaajuisiin tukipalveluihin, jotka ovat käytettävissä 24/7 auttamaan. Jos voimme auttaa muissa asioissa tai sinulla on kysyttävää tai palautetta VMware-tuotteista, ota yhteyttä tilitiimiisi tai tekniseen tilivastaavaan. Jos sinulla on ongelmia, jotka liittyvät suoraan tähän viestiin, jätä kommentti alle.

Viimeinen asia – tilaa tämä blogi ja seuraa meitä Twitterissä tai Facebookissa! Kirjoitamme paljon tämän kaltaisia ​​teknisesti suuntautuneita artikkeleita, jotka kattavat uutisia ja ajankohtaisia ​​aiheita, ja toivoisimme sinut kanssamme.

Kiitos!