Archívum

Archive for the ‘Windows Server’ Category

Windows 10 Fall Creators Update vs WannaCry & Petya

június 28, 2017 4 hozzászólás

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.

Reklámok

Törölhetetlen OU

június 7, 2017 Hozzászólás

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.

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

február 1, 2017 3 hozzászólás

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 és Network Level Authentication

október 1, 2016 14 hozzászólás

Bár úgy rémlik, hogy régebben már írtam az NLA-ról (s most nem a Network Location Awareness-ről beszélek 🙂 ), hirtelen nem találtam meg a cikket. Ez a Windows Vista/2008-tól bevezetett lehetőség azt a célt szolgálja, hogy legalább RDP 6.0 protokollt használó kliensek esetén még a munkamenet létrehozása előtt bekérje a hitelesítő adatokat. Az oka egyszerű: elrejti a szerver/hálózat adatait, így növelve a biztonságot. Régebbi (nem NLA-képes) kliensek esetén az alábbi hibaüzenet fogad:

„The remote computer requires authentication for you to connect. Verify the authentication settings and try again.”

networklevelauth

Nos, alapból a Win10 (is) úgy érkezik, hogy a Távoli asztal engedélyezésekor az NLA be van kapcsolva. Ebben nem lenne semmilyen hiba, de sajnos a grafikus felületre kivezetett pipa nem segít, annak eltávolítása után sem tudunk régebbi RDP-kliensekkel csatlakozni. Ezt a bug-ot feature-t szerencsére registry-módosítással fel tudjuk oldani:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

kulcsban kell a SecurityLayer értéket 0-ra állítani.

Frissítés: Bár most csak TP5-el tudtam kipróbálni, valószínűleg a Win2016 RTM-ben is ugyanez a helyzet.

Frissítés2: Némi pontosítással élnék. Amíg a grafikus felületre kivezetett pipa nincs eltávolítva, addig időtúllépésre fut a kérés:

networklevelauth2

Tehát előbb azt ki kell kapcsoljuk, majd utána registry-t is módosítsuk (sorrend fontos!), s utána lehetséges csatlakozni.

Split-DNS vs .local

május 9, 2016 2 hozzászólás

Az utóbbi időben két olyan rendezvényen is részt vettem, ahol felmerült a belső tartományi név TLD-kérdésköre: local vs. publikus (split DNS-el). Egyik helyen elfogadták JoeP-el közösen kinyilvánított álláspontunkat, másik helyen kevésbé. Nos, a tanfolyamokon el szoktam mondani ezzel kapcsolatosan a véleményem, a tapasztalataimra alapozva – de ez mindenképp mérlegelés kérdése. Pontosabban csak akkor, ha nem kis cégről beszélünk; ugyanis ahol SBS-t telepítenek, ott „gyárilag” eldöntik helyettünk (ez most az utolsó verziókra vonatkozik, régebben ott is megvolt a döntési szabadságunk).

A válasz ugyanis nagyon nem egyértelmű, ki-ki maga kell eldöntse, hogy mit választ, de ne én mondjam meg a tutit, itt van egy összefoglaló egy MVP-től (maga a cikk régi, de időnként frissítve van új információkkal, s itt felhívnám a figyelmet a legutolsó, 2014-es bejegyzésre, így talán egyértelműbb a kategóriába való besorolás oka is):

http://blogs.msmvps.com/acefekay/2009/09/07/what-s-in-an-active-directory-dns-name-choosing-a-domain-name/

Kategóriák:PKI, Windows Server Címke: ,

Alvó szerver

április 21, 2016 2 hozzászólás

Egy „legendás” „piros gombos” segítségkérés során az volt a kérdés, hogy egy Windows 2012 R2 kiszolgáló miért elérhetetlen időnként. Ráadásul egy olyan környezetben, ahol 1 kiszolgáló van, a felhasználók száma is minimális, és látszólag semmi nem indokolja a szerver leállását.

A hibakeresés szerencsére aránylag hamar feltárta az okot, az eseménynapló rengeteget segített, a System-ben ez volt:

Kernel-power 42

The system is entering sleep.

Sleep Reason: Application API

Nos, nem gyakori, hogy egy szervert elküldenek aludni. Ha meg igen, akkor lehet, hogy célszerűbb inkább leállítani, majd amikor szükséges, akkor újból indítani, nulláról betölteni – de jellemzően nem ekkora cégről beszélünk ilyen esetekben, hiszen az „ébresztéshez” valószínűleg egy másik kiszolgálót használunk. No meg, 1 kiszolgáló esetén önmaga a DC is, amit meg tényleg nincs miért leállítani – s még lehetne sorolni a különböző érveket.

No de menjünk tovább, nézzük az Application naplót a kérdéses időpontokban – hiszen ő is arra hivatkozik, hogy egy alkalmazás állította le, reméljük olyan, amelyik készít naplózást. Máris két bejegyzés kerül elénk, egy hiba meg egy információs fokozatú (idő szerinti sorrendben):

APC UPS Service 61503:

Internal Communication Fault with your battery backup.

APC UPS Service 177:

PowerChute causing PC to hibernate.

Ez már egy nyom, amin el lehet indulni. Tehát valamiért megszakadt a kapcsolat a szünetmentessel, emiatt pedig az alkalmazás kiadta a hibernálási utasítást. Eleve rossz gondolatnak tartom, hogy egy kapcsolat-szakadás miatt ilyen döntést hozzon az alkalmazás, de sajnos az alkalmazás beállításainál nincs erre vonatkozó szabályozási lehetőség.

Rendben, feltártuk a hibát, nézzük, milyen lehetőségünk van a megszüntetésre. Mivel az alkalmazás verziója a legfrissebb, s nincs benne erre vonatkozó állítás, a szünetmentes USB-n keresztül csatlakozik a kiszolgálóhoz, sok esélyünk nincs, így a gyártóhoz fordultam.

A gyártóval történt levelezgetés után kiderült, hogy hol történt az elhibázott döntés:

„A PCBE csak SMART UPS termékekkel működik.

A PCPE csak BACK UPS termékekkel működik.

A Windows 2012  operációs rendszerrel nem fog működni csak a PCBE; ebben az esetben egy SMART UPS-re van szüksége.”

Tekintettel arra, hogy az UPS vásárlásakor egy XP volt „a szerver”, s a „kolléga” nem gondolkozott elég éretten (vagy anyagi megfontolásból), egy olyan terméket vásároltak, amelyik nem kiszolgáló-oldali célfelhasználásra van kitalálva (mondjuk jó pont, hogy egyáltalán gondolt szünetmentesre). Emiatt a szerverre is csak a PCPE telepítése során lehetett az eszközzel felvenni a kapcsolatot, ami „nagy vonalakban” jól működik – de „apróbb” hibák előfordulnak. Pl, hogy időnként hibernálja a szervert. Random időpontokban.

p.s. Nemrég kaptam a képet, hogy ha letiltásra kerül a hibernálás a kiszolgálón (milyen eretnek gondolat, brr…), akkor a program panaszkodik:

Kategóriák:General, Windows Server Címke: , , ,

GPO tervezés

január 21, 2016 Hozzászólás

Úgy látszik, idén előjönnek a házirendes hibák. A múltkor írtam egy AD-replikációs hibáról, most egy másik helyen volt szükség a házirendek rendbetételére – pontosabban tervezési hiba kiküszöbölésére.

A kollégák a GPMC-ben található Modelling segítségével keresték a problémát adott házirend érvényesítésének hiányára. A modellezés azt mutatta ki, hogy nem lép életbe, „Inaccessible” indokkal, sőt, a házirend neve helyett is csak az azonosítója (GUID) jelent meg. Amire nem figyeltek, hogy a gépen a gpresult viszont simán mutatta a házirend érvényesülését (a benne levő beállítások hiánya viszont egy rosszul megírt script volt, mint utólag kiderítettük).

Röviden egy kis összefoglaló a házirendekről, mielőtt túlzottan belemélyednénk. Minden GPO-nak két összetevője van: GPC és GPT. A GPT helye a \\Tartomány\Sysvol\Policies, míg a GPC-t az AD tárolja, akár ADUC-al szerkeszthető (természetesen Advanced View bekapcsolása után) a System\Policies ágon. Amennyiben valamelyik összetevő nem elérhető (általában jogosultság hiánya miatt), máris megkaphatjuk az előbbi hibaüzenetet.

Első körben tehát ezt a két helyet ellenőriztem, s itt (pl. GPT.ini) az NTFS jogosultsági fülön már látszott is a probléma. A megértéshez viszont a kollégáknak a házirenden mutattam meg, a Delegation fül Advanced opciójával: a gond ott volt, hogy az adott házirendet nem akarták érvényesíteni a szerverekre, minden más gépre igen. Tekintettel a már létező OU-kialakításra, amit nem akartak módosítani, úgy próbálták megoldani, hogy az adott házirendhez felvették a szervereket tartalmazó csoportot, de nem csak az Apply-ra adtak Deny jogot, hanem a Read-re is. Így a szerverek (beleértve a DC-ket is) nem tudták még olvasni sem a házirendet, nem, hogy a modellezésbe belevegyék. Amint engedélyeztük a hozzáférést, máris előrébb voltunk – bár, mint jeleztem, a teljes megoldás a script helyretétele után született meg 🙂

Kategóriák:Windows Server Címke: ,