Wsus gondok Win 2022 upgrade után

Pár napja publikus lett a Windows 2022 (pl. VLSC*), de az “éles” ismerkedésünk nem indult valami jól. Az egy dolog, hogy szűz telepítésnél hogyan viselkedik, de tudjuk, hogy puding próbája az evés – így mondjuk például egy in-place upgrade már jobban kimutatja a problémákat. Természetesen a felmerülő kérdéseket nem szabad általánosítani, hiszen a helyi sajátosságok is közrejátszanak, majd a jövő megmutatja, hogy ez valóban lokális gond volt-e.

Adott cégnél próbálták ki az upgrade-et egy 2019-ről. Maga a telepítés sikeresen lezajlott, de utána máris kellett a segítségem, ugyanis pl. a Wsus upgrade-je sikertelen lett. Maga a hibaüzenet nem ismeretlen az IT-sok világa előtt, hiszen láttunk már ilyent:

Fatal Error: The schema version of the database is from a newer version of WSUS than currently installed. You must either patch your WSUS server to at least that version or drop the database.

Előbb természetesen megnéztem az adatbázis-verziót meg a post-Wsus konfigban szereplő verziót – egyezett (ellenkező esetben az alábbi parancsot érdemes lefuttatni):

C:\Program Files\Update Services\Database\UpdateSchemaVersion.sql

Mivel nem akartak sokat foglalkozni ezzel az adott cégnél, kérték, hogy akkor nulláról indítsuk. Így előbb megpróbáltam simán adatbázis törléssel (SQL Management Studio-ból) és ismételt létrehozással (anno máshol nem WID volt, így a jegyzeteimben ott volt még a szögletes zárójelbeli kiegészítés):

wsusutil.exe postinstall [SQL_INSTANCE_NAME=server\SQLEXPRESS]

Majd, amikor (látszólag) ez sem vezetett eredményre, letöröltük a WID instance-t és a WSUS szerepkört, majd újraindítás után újratelepítettük. Itt már biztossá vált, hogy nem ezzel volt baj, hiszen a WSUS konzol félig-betöltése továbbra is megmaradt.

A rend azután állt helyre, miután a 4GB memória növelésre került. Az eredeti elképzelés szerinti feladatokra lehet, hogy elég volt anno ez a mennyiség, de megnézve az aktuális terheltséget, szükség volt a +1GB-ra, főleg a kezdeti szinkronizációhoz (elég szűkös erőforrásokkal rendelkeznek…).

*VLSC: Ott is nagy változások történnek, hiszen az MS igyekszik kivezetni a “sima” fiókok használatát s “céges” fiókok irányába terelni. Ez részben jogos, hiszen általában a licenszek adott céghez/cégekhez kötődnek, így abban a cégben létre lehet hozni egy új felhasználót – még ha nem is kap licenszt igénylő postafiókot; ugyanakkor véleményem szerint ennek a műveletnek a szükségessége kaphatott volna nagyobb visszhangot.

CA tanúsítvány igénylése – parancssor

Rengeteg parancssori eszköz létezik, most a Windowsos beépített eszközök használatáról ejtek pár szót (pontosabban már létező .req file CA-nak való átadása a cikk témája). Már az elején tisztáznám, hogy Enterprise környezetben, tehát sablonokkal fogunk dolgozni, ezért tegyük tisztába a sablon “valódi” és megjelenített nevét (spoiler: ezt a tudást egy következő cikkben is fogjuk használni).

Természetesen grafikus felületen is a sablon-kezelő konzolon meg tudjuk nézni a sablonok nevét (“Template name”) (s itt nem a megjelenített névre (“Template display name”) gondolok!), de erre van lehetőségünk parancssorból is:

certutil -config “server.domain.local\CA-Name” -CATemplates

Ez azért fontos, mert amikor a certreq parancsot használjuk, akkor a sablonnak NE a megjelenített nevét használjuk, hanem a “valós”, valószínűleg a megjelenített név szóközök nélküli változatát.

certreq -submit -attrib “CertificateTemplate:Webserver” RequestFile.req

(Súgó: amennyiben a megjelenített nevet használjuk, akkor sajnos a CA nem pontos hibaüzenettel örvendeztet meg bennünket:

Certificate not issued (Denied) Denied by Policy Module 0x80094800, The request was for a certificate template that is not supported by the Active Directory Certificate Services policy: Web server.

The requested certificate template is not supported by this CA. 0x80094800 (-2146875392 CERTSRV_E_UNSUPPORTED_CERT_TYPE)

Hibakeresésnél természetesen ellenőrizzük, hogy létezik a sablon és jó jogokkal, de utána azt is nézzük meg, hogy milyen névvel hivatkoztunk rá 🙂 )

CA tanúsítvány igénylése – webes felület

Adott helyen bevezetésre került egy CA-infrastruktúra, létrehoztuk a sablonokat, majd felmerült, hogy miként lehet tanúsítványokat kérni egy adott sablon alapján, ha annak verziója >=3. Ez a kitétel azért fontos, mert felkerült a webes komponens is, így első körben böngészőből szerették volna kezelni.

Mivel ez a téma eddig csak érintve volt (a PKI-sorozatban: Public Key Infrastructure (PKI) 2. rész), megpróbálok pár gondolatot összeírni.

Egyik kolléga régebbi kérdésére szeretném tisztázni, hogy már az alap CA-szolgáltatás telepítésekor létrejön a CertEnroll mappa. Ha telepítjük a webes komponenst, akkor az IIS-ben a Default Web Site alatt is megjelenik, de a nevével ellentétben nem az igénylés célját szolgálja, abba a mappába (ami ráadásul fizikailag alapértelmezetten a CertSrv alatt van) általában a CA tanúsítványa, az alap CRL és a Delta-CRL (ahol a < DeltaCRLAllowed> engedélyezett volta esetén egy “+” jel látszik), illetve egy nsrev_CANév.asp állomány található (ami a Netscape (iPlanet) alkalmazás tanúsítvány-visszavonásához köthető).

Tehát akkor maradjunk a https://szervernév/CertSrv oldalon (alapból nincs 443 porton publikálva!), a “Request a certificate” link után kétféle felület fogadhat bennünket, kezdem az alapesettel:

,

majd az ACR-re történő kattintás után jön elő az alábbi:

vagy egyből az ACR-ben találjuk magunkat.

Ez utóbbi akkor történik, ha az adott felhasználónak nincs (vagy tiltva van) az “Enroll” jogosultság a “User” sablonhoz (akár közvetlenül, akár csoporton keresztül).

Technikailag, a weboldal kódja úgy van felépítve, hogy a “User” sablon elérhetőségétől függően a certrqad.asp vagy certrqus.asp (esetleg certrqxt.asp) oldal töltődjön be (=> URL-szerkesztéssel is be lehet hozni a kért oldalt 🙂 ):

If “Enterprise”=sServerType Then

    If IsUserTemplateAvailable()=False Then

    fShowRQAD = True %>

    <TD><LocID ID=locLblRequestCert><A Href=”certrqad.asp“><Font Face=”Arial”>Request a certificate</Font></A></LocID></TD>

<%    End If

End If

If fShowRQAD=False Then %>

    <TD><LocID ID=locLblRequestCert><A <%If “Text”=sBrowser Then%> Href=”certrqxt.asp” <%Else%> Href=”certrqus.asp” <%End If%>><Font Face=”Arial”>Request a certificate</Font></A><LocID></TD>

<%End If%>

Nézzük akkor tételesen az ACR oldalon található két linket.

A Submit oldalon egyértelmű a történet, egy már meglévő tanúsítvány-igényt tudunk beadni:

De adott helyen az első opció (Create and submit) volt fontos, ahol “lokálisan” tudjuk elkészíteni az igényt (tehát nem már létező req-et nyújtunk be):

Itt szerettek volna tanúsítványt igényelni – ehhez viszont szükséges, hogy megjelenjen a sablon. Ugyanis a bevezetőben említett sablon-verziók a webes részen nem jelennek meg.

Kerülő-megoldásként egyrészt megpróbálhatjuk a rendszert “átverni” – természetesen, mint ahogy a cikk is említi, fokozott figyelemmel és csomó teszteléssel, másrészt más (nem böngésző-alapú) módszert használunk tanúsítvány-igénylésre. Jelen cikk az előbbit járja körül: az “átverésnek” több módja is van, a végeredmény ugyanaz:

• létrehozunk egy v1 vagy v2 sablont, majd utólag módosítjuk “nagyobbra”
  
• egy már létrehozott sablon verzió-értékét írjuk át az AD-ban (mint a cikk teszi)
  

Nem lehet elégszer hangsúlyozni, hogy ezt tesztelni kell! Sőt, a weboldal bizonyos esetekben nem is töltődik be jól minden böngészőben, néha érdemes IE-t használni (nos igen, itt is látszik, hogy MS kicsit hanyagolja). Ráadásként IE-ben is lehetnek gondok, pl. ez.

Személy szerint van ennél jobban kedvelt igénylési módszerem (a grafikus mmc-konzol használata szinte gyerekjáték, ha tudjuk, hogy milyen tanúsítványt akarunk 🙂 ), de tervezem, hogy egy következő cikkben megnézzük az egyik leggyakrabban használt parancssoros opciót.

DNS zónák

Egy “nagytakarítás” során adott helyen felmerült, hogy az ADUC-ban miért látszanak egyes DNS-zónák, mások meg miért nem? Egyáltalán miért vannak ott?

Nos, kezdjük azzal, hogy AD-integrált zónák lévén mindenképp az AD-ban kell tárolódjanak, tehát bizonyos AD-kezelő eszközökkel látnunk kell őket. S bár abban “igazuk” volt, hogy a képen látható (és néhány, nem látható) zónák AD-integráltak, de nem mindegy, hogy kinek is replikálunk zónán belül.

Amennyiben Windows 2000-kompatibilis integráció lesz a kiválasztott, akkor megjelenik az ADUC-ban is (a szokásos DNS-kezelőn kívül), ellenkező esetben (szintén DNS-kezelőn kívül) csak ADSIEdit segítségével látjuk, csatlakozva a DC=DomainDNSZones,DC=tartomany,DC=hu partícióra (vagy, ha a legfelső opció, akkor értelemszerűen a DC=ForestDNSZones,DC=tartomany,DC=hu partícióra).

Mivel adott cégnél már nem volt szükség Windows-2000 kompatibilitásra, így át tudtuk állítani, s már nem zavarta őket, “eltűnt” (hétköznapi ember többet használ ADUC-ot, mint ADSIEdit-et 🙂 )

Számítógép-tanúsítvány igénylése

Az utóbbi időben néhány cégnél beüzemelésre került pár tanúsítvány-kiszolgáló. Ezek kapcsán a kollégák feltettek néhány kérdést, amelyek közül kettőt megpróbálok egy-egy cikkben körbejárni.

Kezdjük azzal, hogy telepítés és konfigurálás után szeretnénk, ha minden számítógép kérne a CA-tól egy saját tanúsítványt. Fontos, hogy tudjuk, ha valaha történtek-e változtatások a sablonokon (ezek khm… boríthatnak mindent), hiszen ezek AD-ban kerülnek tárolásra; ezért a továbbiakban alap-telepítés, beállítást feltételezek – ebben kapunk alap v1 és v2 (sőt, egyetlen v3) sablonokat.

A kolléga arra kérdezett rá, hogy számára nem teljesen világos, hogy az alábbi két beállítás esetén melyik mit takar (zárójelben megjegyzés tőlem):

(Computer/User) Configuration\Windows Settings\Security Settings\Public Key Policies \ Certificate Service Client – Auto-enrollment (Windows 2003 idején Autoenrollment Settings)

és

Automatic Certificate Request Settings (“mappa”).

Röviden a későbbiekben CSC-AE és ACR -ként fogok rájuk hivatkozni. S még mielőtt válaszolnék a kérdésre, pár infó, amit érdemes tudni:

• a tartományvezérlők esetén “hardveresen” bele van kódolva, hogy abban az esetben, ha az erdőbe telepítettünk egy CA-t, automatikusan igényeljenek maguknak egy “Domain Controller” tanúsítványt (természetesen akkor kapják meg, ha ez a sablon – mint alapból – publikálva van). Ez a működés megváltozik, amennyiben engedélyezzük akármelyik GPO-beállítást. Tehát a DC-k esetén nem 2, hanem 3 “módja” létezik: “beégetett”, hagyományos és aktuális.
  
• az ACR a hagyományos (régebbi) verzió, nála csak v1-alapú tanúsítványokat lehet kiválasztani. Mivel V1 sablonok esetén nincs AutoEnroll jogosultság, a gépeknek Read és Enroll jogot kell adni – alapból ezek megvannak a (most érintett) két v1 sablonra az illetékes csoportoknak, tehát tartományvezérlők “Domain Controller”, minden más gép “Computer” sablonra jogosultak. V1-sablon alapú tanúsítvány-kiosztás esetén nincs “Superseded” (felülírt) mód, illetve (belegondolva, értelemszerűen) lokálisan nincs ilyen házirend-opció
  
• a CSC-AE esetén minimum v2 sablonok játszanak, a két opció magyarázata:
  
  • Renew expired certificates, update pending certificates, and remove revoked certificates: bepipált állapotban azokat a tanúsítványokat újítja meg, amelyek
    nincsenek beállítva az automatikus regisztrációhoz, például amelyekhez több aláírás szükséges (pl. Enrollment Agent-et igényelnek), vagy amelyeknek a kérésben kell megadni a tanúsítvány tárgyának adatait (pl. webkiszolgálók). Ezenkívül ez a beállítás fogja betölteni a függőben lévő kérelmeket, amelyeket a CA-manager kellett elfogadjon (Figyelem: ha ez nincs bepipálva, s nem töltjük be a kiállított tanúsítványt (akár “manuálisan”), folyamatosan generálja az újabb kéréseket!).
    
  • Update certificates that use certificate templates: bepipált állapotban AutoEnroll joggal rendelkező sablonok alapján új és megújítási kérelmek jönnek létre a CA-n.
    
• a “Superseded” (felülírt) állapot csak CSC-AE és AutoEnroll jogok közös metszetében értelmezendő, alapból a Domain Controller sablont csak Directory Email Replication és a Domain Controller Authentication írja felül, a Kerberos Authentication – okkal – nem!
  
• a különböző jogosultságok szabályozzák, hogy mikor milyen tanúsítvány kerül kiosztásra, egy gép akár több tanúsítványt is kaphat egyszerre (s ez igaz a v1 sablon-alapúakra is, ott is tudunk plusz jogokat adni!)
  
• egyes MS-cikkek (pl. ez) nem elég pontosak, ez elég lehet ugyanis egy DC esetén (sőt, lásd feljebb, még ez sem kell), de egy munkaállomáshoz nem
  

S akkor a válasz: mindkettő jó, ésszel használva, a CA beüzemelése után az alábbi lépések szükségesek:

• hagyományos verzió:
  
  • felvesszük az ACR-be a kiosztandó sablon(oka)t
    
• aktuális verzió, amikor is két dolgot kell tennünk:
  
  • beállítjuk a CSC-AE-t (érdemes mindkét pipát betenni)
    
  • engedélyezzük az AutoEnroll jogosultságot a szükséges sablonokon (pl. Workstation) és publikáljuk őket (alapértelmezetten a Directory Email Replication, Domain Controller Authentication, Kerberos Authentication sablonok már ilyenek)
    

A fentiek alapján összegezzük:

– a DC-k alapból vagy 1 (“beégetett” és hagyományos beállításkor), vagy 3 (a CSC-Auto-enrollment beállítása után), de automatikusan kapnak tanúsítványokat. Utóbbi esetben Domain Controller azért nem jár nekik, mert azt felülírja más sablon – de manuálisan természetesen kérhetünk.

– amennyiben engedélyezzük az AutoEnroll-t, a rá jogosultak keresni fogják (ugye, AD-ból tudják), tehát ne felejtsük publikálni is

Bár kicsit hosszú lett, végszóként nézzük kicsit a hibakeresést/naplózást. Ehhez érdemes létrehozni a registryben egy AEEventLogLevel duplaszót (értéke lehet 0), számítógép esetén HKLM (felhasználó esetén HKCU) \Software\Microsoft\Cryptography\Autoenrollment alatt, ezután minden sikeres vagy sikertelen esemény a kliens Alkalmazás naplójába hoz létre bejegyzést.

Ja, s természetesen ne felejtsük el, hogy kézzel miként “triggereljük” az automatikus tanúsítvány-igénylést: pl. házirend-frissítéssel* vagy certutil -pulse paranccsal.

*Bár a gpupdate parancsról általában mindenkinek a GPO-k újbóli érvényesítése ugrik be, tanúsítványoknál tudjuk, hogy nem kell feltétlenül GPO-nak léteznie (pl. Enterprise CA-k automatikus terítése, amit bár szintén ezzel a paranccsal lehet kierőltetni, GPO nem társul hozzá)

 

A tesztelés fontossága

Adott helyen megkértek, hogy néhány fürtöt nézzünk át közösen, valamint azokon minimális módosításokat szeretnének. Ahogy haladtunk előre a munkával, dőltek ki a csontvázak a szekrényből, de a legnagyobb az utolsó fürt esetén jött elő.

Ez egy SQL-clusternek nevezett szolgáltatás volt. Az addigi tapasztalatok alapján, no meg a normális emberi gondolkodás szerint is, az első lépés az volt, hogy jelen állapotában teszteljük a működését. Ez azt jelentette, hogy a szolgáltatást a fürt egyik tagjáról átbillentsük a másikra. Nos, “természetesen” elhasalt. Ideiglenesen visszaállítottuk, s elkezdtük a hibakeresést, ami egy számomra teljesen szokatlan helyzetet mutatott ki: nem egy beállítás, nem egy pipa okozta a gondot, hanem az SQL-szerver telepítés hiánya. Előbbit még mondjuk így-úgy meg lehet magyarázni, hogy időközben állítódott el (persze, magától 😛 ), de egy egész SQL-telepítést? Ugye tanfolyamokon szoktunk viccelni, amikor idő szükséges, hogy semmi gond, addig telepítsünk egy SQL-t. Tudjuk jól, hogy nem 2 másodperc. S tudjuk jól, hogy legtöbb ember grafikus varázslóval megy rajta végig, akár telepítés, akár eltávolításról van szó. Szóval egy ilyen, rengeteg paramétert igénylő eltávolítást szerintem nem lehet “véletlenül” végrehajtani. De akkor mi történt?

Nos, valószínűleg emberi mulasztás. Lehet, hogy rohamtempóban kellett felhúzni a fürtöt, s nem volt idő a másik tagra telepíteni az SQL-t. Vagy valamilyen hiba következett be a telepítés során, amire elfelejtettek visszatérni. Vagy tudatlanság miatt: nem tudták, hogy mindkét kiszolgáló kell rendelkezzen telepített SQL-el. Vagy… lehetne sorolni a különböző forgatókönyveket.

A legnagyobb hiba viszont a végén van: átadás előtt tesztelni kellett volna. Hogy valóban átbillen-e, hogy valóban jól működik. S ha igen, csak akkor átadni használatra, ha nem, akkor jelezni, hogy pillanatnyilag működőképes, de NEM fürt. Ezáltal az érintettek is tudták volna, hogy mi is van a motorháztető alatt. Mi lett volna, ha mindez “élesben” derül ki, amikor az addig használt kiszolgáló ilyen-olyan okokból kifolyólag kidől?

Azok az Exchange 2003-as maradványok…

Nemrég egy elég ritkán felmerülő esetben segítettem, így – mivel Zolival ellentétben még nem szálltam ki az Exchange-ek világából – gondoltam megírom.

Az egész azzal kezdődött, hogy adott cégnél hibrid megoldást akartak bevezetni; a kolléga elkezdte az összes szükséges dolgot előkészíteni, majd megvalósítani. Adott ponton a varázsló módosítani akarja az alapértelmezett email-házirendet (Default Policy), ám adott esetben egy hibaüzenetet dobott:

HCW8097 – You must upgrade your Email Address Policy before running the Hybrid Configuration Wizard

Rákeresve a neten, mindenhol arra utalnak, hogy régebbi (értsd Exchange 2003-as) maradványok lehetnek a rendszerben, s ezt milyen módon lehet kiküszöbölni. Igen ám, de a javasolt módszerek, pl. ez:

Set-EmailAddressPolicy “Default Policy” -IncludedRecipients AllRecipients

vagy ez:

Get-EmailAddessPolicy | Update-EmailAddressPolicy

egyike sem vezetett eredményre.

A nyomozás során első körben mindenképp rákérdeztem, hogy valóban ez egy “görgetett” rendszer, s a pozitív válasz miatt próbáltam mindenféle módon kideríteni, hogy miért gondolja az Exchange, hogy a jelzett házirend régi típusú. Ebben az alábbi parancs segíthet:

Get-EmailAddressPolicy | Fl Name,RecipientFilterType,ExchangeVersion,HasMailboxManagerSetting

Ennek kimenetele általában kétféle verzió szokott lenni:

RecipientFilterType: Legacy

ExchangeVersion: 0.0 (6.5.6500.0)

HasMailboxManagerSetting: True

vagy

RecipientFilterType: Precanned

ExchangeVersion: 0.1 (8.0.535.0)

HasMailboxManagerSetting: False

Jelen esetben a második állapot jelentkezett, így egyértelmű volt, hogy (mint utólag kiderült, még ha részlegesen is, de) megtörtént az átállás. De akkor hol a hiba?

Egy nyomot kaptunk a Set-EmailAddressPolicy futtatása során kapott hibaüzenet formájában:

The recipient policy “Default policy” with mailbox manager settings cannot be managed by the current version of Exchange Management Console. Please use a management console with the same version as the object.

A rejtett kulcsszó három szócska: “with manager settings“. Azt jelenti, hogy a házirendhez még hozzá van rendelve valami, ami már nem kellene ott legyen. Igen ám, de már régóta nincs Exchange 2003-as konzoljuk, amivel GUI-alapon megszüntessük ezt a “manager settings“-et. Sebaj, mivel az Exchange (szinte) mindent AD-ban tárol, szüntessük meg ott, ADSIEdit segítségével, a Configuration partícióban:

“CN=Recipient Policies,CN=Org Name,CN=Microsoft Exchange,CN=Services,CN=Configuration”

Egyrészt – ha ott van, akkor – vegyük ki a True állapotot az alábbi attribútumból: MsExchMailboxManagerFolderSettings

A második, sokkal fontosabb viszont a msExchPolicyOptionList attribútum, ahol az alábbi két érték szokott lenni:

FC 1C 49 26 50 9E 57 48 86 1B 0C B8 DF 22 B5 D7 = Address List policy

EC 13 68 3B 89 CE BA 42 94 42 D8 7D 4A A3 0D BC = MailBox Manager Policy

Ezek közül a gond a második, ezt kell eltávolítani (jó esetben az első eleve ott van), majd megvárni, hogy érvényesüljön. Ha minden más beállítás stimmel, mint az adott helyen, a fentiek után már sikeresen lefut a varázsló.

Saját CA által kiállított tanúsítványok vs böngészők

Nem új keletű a történet háttere, de gondolom az új Edge bevezetésével mind több helyen elő fog jönni, ezért úgy döntöttem, elébe megyek a dolgoknak.

Adott cégnél felmerült, hogy az eddigi http alapú intranet kommunikációt áthelyezik https-re. Ennek érdekében első körben történt egy CA-bevezetés, majd a kiszolgálóra igényeltek egy web-kiszolgálói tanúsítványt.

A tesztelés során kiderült, hogy azok, akik IE vagy “régi” Edge-ről töltik be az oldalt, nem tapasztalnak gondokat, viszont akik Chrome vagy Chromium alapú Edge-ből, azoknak

ERR_CERT_COMMON_NAME_INVALID

hibaüzenettel, a Firefox-ból vonulóknak pedig egy

SEC_ERROR_UNKNOWN_ISSUER

üzenettel kedveskedik a rendszer.

Itt akkor felmerült a kérdés: most akkor mi van? Jó a tanúsítvány vagy nem? Illetve miért függ egy tanúsítvány megítélése a böngészőtől?

Nos, Firefox esetén a böngészőnek saját tanúsítvány-tára (is) van, de esetében mondhatni könnyű dolgunk van: egy házirend segítségével megadjuk, hogy a böngésző az oprendszertől kérje el a megbízható tanúsítványok listáját. S tudjuk, hogy a CA automatikusan lekerült a gépekhez, tehát ez nem lehet gond (erre amúgy másodlagos bizonyíték az is, hogy az MS régebbi böngészői sem reklamálnak). Itt “csak” egy dolog nem teljesen világos számomra: miért szükséges, hogy egyes programok (pl. Adobe, Java, stb) saját tanúsítványtárat használjanak? Értem én, hogy így akár szolgáltatásonként külön tanúsítványt lehet használni – de személy szerint ezt már túlzásnak érzem…

A Chrome / Chromium alapú Edge esetében a megértéshez szükséges a Google böngészőjének működését figyelembe venni. Kb. 3 éve ugyanis a Chrome nem fogadja el a belső CA-k által kiállított tanúsítványokat, csak akkor, ha azok rendelkeznek érvényes SAN-mezővel. Ezzel a gondolattal lehet vitatkozni, ugyanis elvileg az RFC előírja, hogy másodlagos opcióként a CN-t is ellenőrizni kell – de ez figyelmen kívül van hagyva. Egy ideig egy registry-kulccsal lehetett egy kerülő-megoldást alkalmazni, viszont ezt a lehetőséget is már rég megszüntették. Jelen esetben megoldásként az a döntés született, hogy rendben, akkor létrehoznak egy új, célnak megfelelő tanúsítvány-sablont, majd azzal igényelnek tanúsítványt. Ennek szétszedése (Cert, Key, CA) már gond nélkül lezajlott, majd az élesítés után már valóban nem reklamált a böngésző. De hogy mit tesznek azok a cégek, ahol tömegesen használnak web-kiszolgálókat, saját CA-val, s tömegesen akarják lecserélni a tanúsítványokat az újabb sablonból eredőnek – hát, lehet, hogy nem mindenki lesz boldog.

BIOS vs Hyper-V

Adott helyen egy tavaly vásárolt szerver mellé idén vettek egy másodikat, fürtözés céljából. Ebből a gondolatmenetből kifolyólag ugyanolyan gyártó, ugyanolyan típus lett véve, majd az újra is telepítették a Win2019-et.

Előkészítés után (tartományba léptetés, iSCSI beállítások, stb) után sikeresen létrehozták a fürtöt, majd következett a tesztelés: egy adott Hyper-V virtuális gép mozgatása. S itt jött az érdekes hibaüzenet:

System 21502:

Live migration of ‘Virtual Machine VM1’ failed.

Virtual machine migration operation for ‘VM1’ failed at migration destination ‘H1’.

The virtual machine ‘VM1’ is using processor-specific features not supported on physical computer ‘H1’. To allow for migration of this virtual machine to physical computers with different processors, modify the virtual machine settings to limit the processor features used by the virtual machine.

Ekkor nyomták meg a piros gombot.

A hibakeresés során természetesen ellenőriztük a gépek, azon belül kiemelten a procik adatait, amelyek megegyeztek. Időközben viszont jött az első tippjük és egyben kérésük: eszükbe jutott, hogy tavaly még Legacy (BIOS) módban történt a Windows telepítése, idén pedig már UEFI módban. Kérték, hogy mielőbb továbbmegyünk, lehetőség szerint tegyem át a régit is UEFI-módba. Szerencsére korszerű oprendszerrel dolgozva, nincs sok tennivalónk: egy teljes körű mentés után – kis üzemszünettel számolva – át tudjuk állítani.

Emelt szinten futtassuk az MBR2GPT parancsot, előbb csak validálás üzemmódban, megbizonyosodva, hogy valóban működhet a konverzió. Ha nincs gond, akkor futtassuk újra, most már élesben, s hamarosan jelzi, hogy a gép készen áll az újraindításra. Az oprendszer elindulásához ne felejtsük BIOS-ban átállítani a Boot-folyamatot UEFI módba, s jó esetben ki is pipálhatjuk ezt a kérdést.

Adott helyen a Windows sikeres indítása után volt még egy apró gond, ugyanis a VM-ek nem voltak hajlandóak elindulni:

“Virtual Machine could not be started because the hypervisor is not running”

Ellenőrizve a BCD-t, megtaláljuk a hibát, amit az alábbi sorral orvosoltunk:

bcdedit /set hypervisorlaunchtype Auto

Ezt is rendbetéve, jöhetett a valódi probléma körbejárása. Természetesen megoldhattuk volna úgy, hogy a VM-eknél egyesével bekapcsoljuk a processzornál a kompatibilitást, de akik ismernek, tudják, hogy szeretem körbejárni alaposan a problémát (B-tervnek természetesen ott van ez is).

Néhány célzott keresés vezetett erre a cikkre. Nos, ellenőrizve, igaz, hogy már a tavalyi gépen található BIOS sem volt régi, bőven a Spectre utáni, de azóta kijött még két verzió, amelyek az új gépre már felkerültek. Szerencsére a gyártó honlapján volt leírás a BIOS-verziók újdonságairól, így amikor azt láttam, hogy “Updated the Processor Microcode“, reménysugár csillant meg az alagút végén. A letöltés, majd telepítés után valóban megnyugodhattunk, ugyanis a problémás hibaüzenet már nem jelentkezett, a mozgatás is sikerült.

A kollégáknak is tanulság volt, hogy a driverek, javítófoltok stb mellett érdemes figyelni a BIOS-verziókra is – főleg egy fürt tagjai esetén, hiszen eltérő verziók esetén ilyen gond is felmerülhet 🙂

Management konzol és tanúsítvány

Egy adott cégnél feltették adott (egyik általam is kedvelt) végpontvédelmi alkalmazás központi kezelőfelületét. A telepítés rendben lezajlott, viszont a következő lépés során hiába keresték a program nyilvántartásában a kliens-gépeket, a lista üres volt.

A hibafeltárás során először is megnéztük, hogy lefutott-e az AD-ból történő import. Mivel a feladat hibát jelzett, így egyértelmű lett, hogy “csak” ennyi a baj. No de miért futott hibára?

Nos, a nemrég, júniusban kiadott legújabb verzió tartalmaz egy elég fontos változást ezen a téren – így vélhetően lesznek még néhányan, akik konzol-frissítés után szintén belefuthatnak a sikertelen műveletbe. Kissé kettős érzéssel vagyok, ugyanis érzem, hogy az elképzelés, alapötlet nem rossz, de sajnos a kivitelezés nem sikerült a legjobban.

Hogy konkrétan az okot nézzük: bevezették, hogy az AD-import LDAPS segítségével történjen. Ez szuper, hiszen ez a biztonságot erősíti, nem? De igen, de mi van azoknál a cégeknél, ahol még nincs PKI rendszer bevezetve, a DC-knek nincs megfelelő tanúsítványa? Nos, itt csúszott el a történet. Idézem a támogatói oldal erre vonatkozó cikkét: a DC-n Server Manager segítségével telepítsük az AD CS szerepkört, azon belül a CA-t. Ezután a Helyi számítógép tanúsítványai ablakban jobb klikk segítségével kérjünk DC-tanúsítványt. S kész.

Aki nem foglalkozott soha tanúsítványokkal, talán az is érzi, hogy ez elég foghíjas. Kezdve attól, hogy egy tanúsítvány-kiszolgálót nem vezetünk “csak úgy” be egy tartományba, arról nem beszélve, hogy a binárisok telepítése (Server Manager, ugye) után még van a CA élesítése. Erről a cikk mélyen hallgat, tehát aki a varázslót lefuttatja, az törheti a fejét, hogy Enterprise (default) vagy Standard, Root (default) vagy Subordonate, új privát kulcs vagy nem (ennek minden finomságával) szükséges – vagy csak rányom a Next-Next-Finish gombra, de attól még nem tudja, hogy mit csinál.

Amennyiben sikerül a CA-t telepíteni, jöhet a következő lépés, ami valóban nem annyira bonyolult: a DC-nek tanúsítványt kérni. Még itt is elbizonytalanodhat a szomszéd Pistikéje, ugyanis két tanúsítvány-sablonban is szerepel a “Domain Controller” szópáros

Csak, hogy teljes legyen a lista, egy másik apróság is kibukott (ez már csak helyi “specialitás”): az előbbiek abszolválása után még mindig nem tudott a kiszolgáló LDAPS kapcsolatot létesíteni a DC-vel. Ennek okának kiderítése kicsit kacifántosabb volt, a semmitmondó hibaüzenet (ami ráadásul ugyanaz volt, mint a CA telepítése előtt) nem segített semmit. Bár tudjuk, hogy Ent CA esetén a kiszolgáló tanúsítványa automatikusan bekerül a megfelelő helyre, így nem GPO-val kell kiszórni a tartományi gépekre, adott gépen ez nem valósult meg, így kerülő-megoldásként kézzel került be a megfelelő konténerbe – ezzel végre kerekké (és sikeressé) téve a történetet.

A teljesség kedvéért meg kell említeni, hogy egy másik opció segítségével maradhatunk LDAP csatlakozásnál is, sőt, megfelelő sablon segítségével a szükséges Active Directory attribútumokat is ki tudjuk töltetni – de szerintem első körben elég lett volna egy pipa-beállítás, hogy aki szeretné, tudjon használni LDAPS-ot, majd később szigorítani, s alapértelmezetté tenni.