Windows 10 Fall Creators Update vs WannaCry & Petya

Aki az IT világában él (sőt, akinek van számítógépe), biztosan tud a múlt havi WannaCry-járványról, ennek ráadásaként tegnap aktiválódott a Petya zsarolóvírus is. Mindkettő az SMB1 protokoll egyik hibáját használja ki, s ennek lassú kihalása okán kapták a már nem támogatott rendszerek is a javítófoltokat.

Ugyanakkor lassan, de biztosan elkezdtek csepegni infók a Win10 idei őszi frissítéséről. Az indító gondolathoz kapcsolódik az egyik friss és fontos információ is, aminek sokan nem fognak örülni: az említett frissítéstől kezdve megszűnik az SMB1, magyarul a Windows 2003 és régebbi rendszerekkel való kapcsolattartási lehetőség.

Tudom, sokan nem értik, hogy miért foglalkozom ilyen ősrégi rendszerekkel. Nos, egyszerűen azért, mert a magyar viszonyokat ismerve, nem egy cégnél található még ilyen oprendszer. Félig haladva a korral, vannak már Win10-es munkaállomások, de a szerver-csere még nem történt meg. Sőt, továbbmegyek, azok a régi nyomtatók/készülékek, melyek csak ezt a régi protokollt ismerik/használják, szintén ki fognak esni a játékból.

Természetesen kell haladni a korral. Hiszen mint említettem, a WannaCry/Petya is erre épül, ennek a sebezhetőségét használta ki. Általános (és kiterjesztett) támogatása is lejárt. Viszont hiába voltak a különböző fórumokon, médiákon elhangzott figyelmeztetések, áttérésre figyelmeztető oktató-videók, felhívások, sajnos továbbra is rengetegen vannak régi rendszerekkel – részben anyagi, részben más okok miatt. Érdemes az ottani rendszergazdáknak/informatikusoknak ismételten jelezni a vezetőség felé, hogy a kockázat folyamatosan nő…

ps. eredetileg egy hosszabb cikknek készült volna, de Petya áthúzta a tervem. Hogy mégse maradjon senki szakmai tartalom nélkül, egy elég jól összeállított MS-cikket linkelek be az SMB protokollokról.

Törölhetetlen OU

Adott helyen egy SBS2011-ről tértek át Windows Server 2012 R2 Foundation-re. A migrálás rendben lezajlott, viszont utána az AD-ban is rendet szerettek volna tenni, magyarul az SBS által létrehozott hierarchiát egyszerűsíteni.

Az útmutatást ekkor váltotta fel a gyakorlati segítségnyújtás: volt két szervezeti egység (OU), amit semmilyen módon nem tudtak törölni (a törlési opció nem is volt felajánlva a helyi menüben): az SBSComputers és SBSUsers. Ellenőrizték, hogy nincs betéve a „törlés-gátló” pipa, de a törlést továbbra sem tudták végrehajtani.

A megoldás megértéséhez kicsit vissza kell menjünk időben. A Windows 2003-ban (és 2003-as tartományi szinttől) jelent meg az a lehetőség, hogy a számítógép- és felhasználó-fiókok alapértelmezett helyét (Computers, illetve Users konténer) meg tudjuk változtatni (RedirCmp, RedirUsr). Az átirányítás során bekapcsolásra kerül a cél szervezeti egységeken az IsCriticalSystemObject attribútum is, ennek TRUE értéke okozza a törölhetetlenséget és az átnevezhetetlenséget. Az SBS ezt előszeretettel alkalmazza, az ominózus OU-kba irányítva a megfelelő fiókokat. (Csak egy apró megjegyzés, ha valaki nem SBS-en hajtja végre: a művelet végrehajtásához a PDC emulátor FSMO-szerepkörű géphez fog fordulni).

Igen ám, de miként tudjuk ellenőrizni, hogy hova is vannak irányítva? Nos, 2003-ban csak az ADSIEdit-el tudtuk megnézni, 2008-tól kezdve az „Advanced Features” bekapcsolásával az ADUC-ban is a tartomány tulajdonságainál, a WellKnownObjects attribútumban. Ez tartalmazza mindkét értéket (sőt, még mást is), számítógépek esetén a B:32:AA31 kezdetű, felhasználók esetén B:32:A9D1 kezdetű hexaérték után.

De már ez is a múlt. Windows Server 2008 R2 óta már Powershell segítségével is lekérdezhető:

Get-ADDomain | select ComputersContainer

Get-ADDomain | select UsersContainer

Amint megszüntettük a lokkolást (máshova irányítottuk), egyből megjelent a törlési lehetőség.

RDP tanúsítvány

Egy régi félkész cikket próbálok befejezni… A témát réges-rég is említettem, minimálisan, de azóta rengeteg víz lefolyt a Dunán 🙂

Nos, akkor kezdjük átismételni, mi történik, amikor RDP-vel csatlakozni próbálunk egy géphez (leírás, értékek). Első körben van egy biztonsági ellenőrzés, amelynek során a rendszer ellenőrzi a registry-ben, hogy van-e már mentett kapcsolatunk a távoli kiszolgálóhoz, s abban mit engedélyeztünk (HKCU\Software\Microsoft\Terminal Server Client\LocalDevices\<Név> – ha csak most engedélyezzük az elsőt, létrehozza a LocalDevices kulcsot is). Ennek fényében kapunk egy sárga, vagy, ha “online” csatlakozunk (nem RDP-állomány), akkor a változatosság kedvéért kék ablakot (hogy még bonyolultabb legyen, a kék ablak sem mindig pattan elénk, csak az 1, 2, 32 értékek hiányában):

 

A kék ablak (ha nem RDP-állományból, esetleg ha a LocalDevices értéke 12 (1100) – amennyiben betesszük a pipát, akkor az érték 77 (0100 1101) lesz):

Továbbjutva az első akadályon, máris egy másik registry-kulcs által szabályozott területre érünk. Ekkor a rendszer ellenőrzi a HKCU\Software\Microsoft\Terminal Server Client\Servers kulcs tartalmát, s amennyiben van, úgy alapértelmezés szerint felajánlja az itt található UsernameHint felhasználót s kéri a jelszavát. Amennyiben nincs, egy választó-ablakot dob fel, az aktuális felhasználónak kérve a jelszavát vagy lehetőséget adva másik felhasználónév/jelszó megadására. Ha van mentett jelszavunk, akkor természetesen kiolvastathatjuk a Hitelesítőadat-kezelőből is. Sikeres hitelesítés esetén megérkeztünk az aktuális témához, a második sárga ablakhoz:

Ennek megfejtése: szintén az előbb említett registry-kulcsban előfordulhat egy tanúsítvány-kivonat (hash) – ha ez érvényes, azaz megegyezik a gépen tárolt tanúsítvány lenyomatával, észrevétlenül csatlakozunk a kiszolgálóhoz – ellenkező esetben jön elő a jelzett, második sárga ablak. Ha utánajárunk az alapértelmezett, önaláírt tanúsítványnak, kiderül, hogy a számítógép tanúsítvány-tároló Remote Desktop mappájában található, így könnyen gondolhatnánk, hogy azt lecserélve hátradőlhetünk – de ez nem így van. Elkeseredésre azért nincs ok, mert azért a megoldás egyszerű: miután a “jó” tanúsítványt betesszük a számítógép tanúsítvány-tároló Personal mappájába , le kell cseréljük a WMI-ban tárolt tanúsítvány-kivonat értékét (szaknyelven a root\cimv2\TerminalServices névtér Win32_TSGeneralSetting osztály beállításaiban a SSLCertificateSHA1Hash értékét kell cserélni  ).  Visszalépni nem lehet (de minek is kellene?).

Biztos, ami biztos, előbb lekérdezzük a jelenlegi értéket:

wmic /namespace:\\root\cimv2\TerminalServices PATH Win32_TSGeneralSetting Get SSLCertificateSHA1Hash

Ugyanezt az eredményt kell találjuk a grafikus felületen megnyitott tanúsítvány ujjlenyomat-értékében is (“Thumbprint”).

Szintén pl. a grafikus felület segítségével kiderítjük a számítógép “rendes” tanúsítványának lenyomatát, majd a cseréhez a következő utasítást kell végrehajtani:

wmic /namespace:\\root\cimv2\TerminalServices PATH Win32_TSGeneralSetting Set SSLCertificateSHA1Hash=”THUMBPRINT”

Vagy aki inkább Powershell-t használna (Set-WmiInstance helyett lehetne swmi, hasonlóan a Get-WmiObject helyett gwmi):

# Lekérdezzük a jelenlegi lenyomatot

$TSGeneralSetting = Get-WmiObject -class “Win32_TSGeneralSetting” -Namespace root\cimv2\terminalservices -Filter “TerminalName=’RDP-tcp'”

# A számítógép tanúsítvány-tárából kiválasztjuk az SSL-tanúsítvány lenyomatát (ha több tanúsítványunk van, akkor ellenőrizzük a kapott eredményt)

$thumb = (gci -path cert:/LocalMachine/My | select -first 1).Thumbprint

# Beállítjuk az új értéket Set-WmiInstance -Path $TSGeneralSetting.__path -argument @{SSLCertificateSHA1Hash=”$thumb”}

Ezt tovább tudjuk fokozni, hogyha más néven csatlakoztunk, további adatok lesznek a sárga ablakon:

 

Ha viszont egy olyan kiszolgálóra csatlakozunk, amelyik nem támogatja az NLA-t (például alábbi esetben Windows 2003), akkor az alábbi ablakok jönnek:

 

Huhh, elég volt a sárga ablakokból. Uff.

BitLocker kulcsok házirendben szabályozva

Adott helyen felmerült a házirendből szabályozott BitLocker – pontosabban a visszaállítási kulcsok mentésének módja. Magyarul, nem szeretnénk azt, hogy ha bekapcsolják a titkosítást, akkor USB-kulcsra, állományba vagy nyomtatásra kerüljön a visszaállító kulcs, hanem az AD-t használjuk erre a célra. Ha nem régi rendszerekről van szó, aránylag kevés beállítást kell végrehajtanunk, hogy sikeresek legyünk:

1. Computer Configuration\Administrative Templates\System\Trusted Platform Module Services alatt engedélyezzük a Turn on TPM backup to Active Directory Domain Services opciót
2. Computer Configuration\Administrative Templates\Windows Components\BitLocker Drive Encryption alatt eldöntjük, hogy melyik ágon megyünk tovább: adatlemezre (beépített vagy eltávolítható) vagy rendszerlemezre szeretnénk alkalmazni a titkosítást. Döntés után a Choose how BitLocker-protected fixed drives can be recovered opcióba lépve, engedélyezve és a benne található lehetőségeket beállítva mondhatni készen is vagyunk.

(Aki Vista/2008 rendszereken szeretné, vagy bővebb információt olvasna, részletesebb leírás itt található).

Van viszont egy kapcsoló, amire szerintem nincs eléggé felhíva a figyelem, s kissé megkavarhatja az egyszerű rendszergazdát. Arról van szó, hogy ha nem pipáljuk be a „Omit recovery options from the BitLocker setup wizard” opciót, akkor a BitLocker bekapcsolásakor feldobja a hagyományos ablakot, hogy hova akarjuk menteni a visszaállító kulcsot – emiatt nem lehetünk biztosak benne, hogy a gép megkapta-e a házirendet (amiben beállítottuk, hogy AD-ba kerüljön). Ezt tehát mindenképp bepipálnám.

Ha kiadtuk a titkosítási parancsot, egy újraindítást fog kérni, majd utána a

manage-bde -status c:

parancs segítségével tudjuk lekérdezni a titkosítás állapotát.

Természetesen, utólag is van lehetőségünk a Control Panel/Bitlocker Drive Encryption menü segítségével a kulcs megszokott mentésére (USB-kulcs, állomány vagy nyomtatás). Amennyiben az AD-ból akarjuk mégis elővarázsolni, két lépést érdemes tennünk: feltelepítjük az RSAT-ból a „BitLocker Password Recovery Viewer”-t, majd a szükséges .dll állományt regisztráljuk:

regsvr32.exe BdeAducExt.dll

A fentiek hatására az ADUC-ban meg fog jelenni egy BitLocker Recovery fül, ami tartalmazni fogja a kívánt kulcsot.

u.i. Figyeljünk arra, hogy amennyiben úgy állítottuk be (ahogy a józan ész diktálja), hogy titkosítás előtt ellenőrizze az AD-kapcsolatot, úgy nem járható út, hogy napközben bekapcsoljuk a titkosítást, de nem indítjuk újra a gépet – ha ugyanis a kolléga leállítja, majd hazaviszi az eszközét, s otthon bekapcsolja, az AD-kapcsolat hiányában nem történik meg a várt művelet. Természetesen következő alkalommal (már AD-kapcsolattal) ismét lehet kérni a BitLocker bekapcsolását, ekkor az új kulcs is bekerül a másik mellé.

Házirendek csak hordozható gépekre

Adott helyen felmerült a kérdés, hogy miként lehet úgy kiszórni egy házirendet, hogy csak a hordozható eszközökre legyen érvényes.

Egyrészt természetesen maradhat a jól bevált módszer, amely szerint AD-csoportot hozunk létre, s csak arra érvényesítjük a házirendet (vagy fordítva, abba tesszük azokat a gépeket, amelyekre nem kell érvényesüljön, s „Apply group policy – Deny” opciót választunk). Ugyanakkor létezik „elegánsabb” módszer is, WMI-szűrő segítségével.

Nem fogok felsorolni minden lehetséges szűrést, ami alapján kétfelé tudjuk választani a gépeink, néhány ötletet adok csak:

1. a memória fizikai mérete alapján: tudjuk, hogy a hordozható eszközökbe SODIMM memória kerül, asztali társaikba pedig „normál” méretű DIMM. Előbbinek FormFactor értéke 12, így a szűrönk így néz ki:

Select * from Win32_PhysicalMemory WHERE (FormFactor = 12)

2. az akkumulátor jelenléte alapján (ha nincs, akkor értéke 0; bár mivel van, aki akku nélkül használja, fenntartással kezelném):

Select * from Win32_Battery WHERE (BatteryStatus <> 0)

3. ha tudjuk, hogy minden DMI adat ki van töltve (személy szerint igyekszem erre mindig figyelni), akkor a ház típusa (burkolat) alapján is lehet szűrni, az általában használt értékek itt vannak felsorolva (ebben az esetben természetesen granulárisabban tudunk szűrni):

Select * From Win32_SystemEnclosure Where ChassisTypes = “9”

p.s. régi kapcsolatommal, Tamással [Aida64 vezető fejlesztője] történt egyeztetésem kapcsán felmerült, hogy most már sok alaplap – főleg a Mini-ITX és Mini-STX kialakításúak –, valamint sok mini-PC is SO-DIMM foglalatos, így az első nem biztos, hogy teljes értékű megoldás. Viszont akinek a hálózatában ilyenek vannak, használhatja a többi (akár általam le nem írt) módszert 🙂

Hibakód szöveges értelmezése egy Win2016 ütemezett feladat kapcsán

Többször szokták tőlem kérdezni (tanfolyamokon is), hogy mi a legegyszerűbb módja egy hibakód „visszafejtésének”, azaz a hozzá tartozó szöveges hibaüzenet kiderítésének. S itt természetesen nem a „well-known” kódokról beszélek (pl. 0x80070005 Access denied) :).

Mivel kétféle módon jelenhetnek meg a hibakódok, kezdem a decimális formátummal (előtagja 0n) – ugyanis első lépésben úgyis hexává (előtagja 0x, a másik formátum) alakítjuk, s innentől már ugyanaz a menet. Tehát mit kell tudnunk, ha mondjuk egy 2147944189 számú hibaüzenetet meglátunk?

A megoldáshoz vegyünk elő egy számológépet, ami tudja a két számrendszert (Windows-on a számológépet pl. „Programozó” módba kell állítani). Kiválasztjuk a hibakód számrendszerét (decimális vagy hexadecimális), beírjuk az ismert értéket, majd megnézzük azt hexadecimális formában. Amennyiben az első négy karakter „8007”, akkor rendben vagyunk, ú.n. „Win32 Status Code” lesz a megfejtés, innentől csak a második négy karakter lesz érdekes.

Következő lépésként a második négy karaktert kell visszalakítsuk decimálissá. Ehhez a számológépbe beírjuk hexa formátumban, majd kiolvassuk decimálisban. Utolsó lépésként lefuttatjuk az alábbi parancsot, s meg is van a keresett szöveges hibaüzenet:

net helpmsg decimális_szám

Mivel az operációs rendszer nyelvén kapjuk vissza az üzenetet, a honosítások nem biztos, hogy visszaadják az eredeti értelmezést, így javaslatom szerint ezt mindenképp egy angol nyelvű gépen tegyük meg (utána könnyebb rákeresni is) – s reménykedünk benne, hogy nem visz tévútra.

S hogy miért pont ezt a konkrét hibakódot hoztam fel? Egy számomra eddig ismeretlen jelenség miatt: egy Windows 2016-on szerettem volna ütemezett feladatot beállítani, hogy egy technikai felhasználó nevében fusson – s ekkor örvendeztetett meg a rendszer a fenti kóddal. A felhasználónak volt elég joga, nem volt letiltva, nem volt zárolva – az egyedüli „hibája” az volt, hogy azon a gépen nem volt profilja (hiszen soha nem lépett be rajta). Az eddigi Windows-okon ez nem volt gond, legelső futtatásnál létrejött a profil – itt az idő szűkössége miatt leggyorsabb megoldás az volt, hogy bejelentkeztem a fiókkal, utána már csont nélkül elfogadta az ütemezett feladat hozzárendelését is.

Windows 10 Mobile RS1 vs FM rádió

Már itt a blogon is többször írtam arról, hogy egy Windows 10 Mobile-os okostelefonnal rendelkezem. Jellemzően elégedett vagyok vele, de mint szakmabeli, látom a korlátokat/hiányosságokat is.

Jelen morgásom arról szól, hogy eddig észre sem vettem, de az RS1-ben kivették a beépített alkalmazások közül a hagyományos FM-rádiót. Nem használom gyakran, de amikor viszont használtam, tetszett az egyszerű kezelhetőség, valamint az, hogy eleve az oprendszer tartalmazza. Aki ismer, tudja, hogy nem szeretem sokmillió programmal terhelni egyik eszközömet sem, ezért mindig adok egy esélyt a beépített alkalmazásoknak (még ha az nem is válik be, pl. asztali gépen az Edge mint PDF-olvasó, vagy az új, előzetes Skype).

Üsse kavics, kivették, az úton már nem volt időm/kedvem vacakolni egy megfelelő alkalmazás kiválasztásával, így későbbre tolódott ez a tevékenység. Amikor viszont nekiálltam keresni, egyrészt a stream-ek kezelésére való alkalmazások jöttek elő (miért hívják őket rádiónak??), másrészt végre találtam néhány valódi FM-rádió kezelő alkalmazást is. Többet is kipróbáltam, de mindegyik egy dolgon vérzett el, ami számomra alap-feltétel volt: nem tudják kihangosítani az adást a telefon hangszórójára. Amikor elkezdtem kutatni az okot, kiderült, hogy nem a fejlesztőkkel van a baj, hanem állítólag a MS nem valósította meg (implementálta) azt a csatolófelületet (API), amin keresztül ez megoldható lett volna. Szóval ez egy újabb fekete pont MS-nek 😦 (S mielőtt valakiben felmerül, attól még nem váltok készüléket 😉 ).