Archívum

Archive for the ‘Windows Server’ Category

Újabb szög a Windows 2003 koporsójába

május 2, 2018 2 hozzászólás

A rendszergazda kollégák tudják, hogy egy vérbeli IT szaki nagyon ritkán van “kikapcsolt” állapotban – főleg abban az esetben, ha több rendszer is van a felügyelete/támogatása alatt. Sőt, továbbmegyek: mivel az informatikusok akkor dolgoznak, amikor a többiek pihennek (nem igazán lehet karbantartást végezni, miközben a kollégák végzik a munkájukat), a hosszú hétvége remek alkalom a teendők végrehajtására (pl. a végre kijött 1803 tesztelésére 😉 ).

Ennek fényében nem csodálkoztam, amikor egyik helyen a kollégák “megnyomták a piros gombot”: szerették volna a kezük alá tartozó rendszereket frissíteni, viszont adott cégnél meglepődve tapasztalták, hogy a Windows 2003 R2-re alapuló WSUS kiszolgáló március 30-án reggel még sikeresen, délután már sikertelenül csatlakozott a MS Update szerverekhez – s azóta folyamatosan sikertelen volt.

A hibaüzenet nem volt teljesen egyértelmű:

WebException: The underlying connection was closed: An unexpected error occurred on a send. —> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. at System.Web.Services.Protocols.WebClientProtocol.GetWebResponse(WebRequest request)

Igaz, hogy az MS saját leírásaiban sem teljesen következetes a WSUS működéséhez szükséges, tűzfalon kiengedendő portokat és célokat tekintve, a tapasztalat azt mutatja, hogy a sima http protokoll nem elég, szükséges a https is – itt viszont egy csavar kerül a történetbe, ami magyarázatot adhat a probléma gyökerére.

A https esetén nem csak a tanúsítvány állapotára kell figyelni, hanem a használt protokollra is. Nos, a Windows 2003 elég régi termék, csak az 1995-ben megjelent SSLv2, az 1996-os SSLv3, illetve az 1999-es SSLv3.1/IETF-féle TLS 1.0-t támogatja (a 2006-os TLS 1.1 és újabbakat nem). Nos, eredetileg 2018 június 30.-ra volt tervezve a régi protokollok kivezetése és a TLS1.1 alappá tétele, de ezt előbbre hozták, április 30.-ra. Fentiek fényében a WSUS azóta új frissítéseket nem tölt le, megoldás vagy egy proxy lehet, vagy természetesen egy korszerűbb rendszer.

Megj: bármikor nyitott vagyok privátban megvitatni azt, hogy valaki miért használ még elavult rendszereket, de itt szakmailag tárgyalom a témát…

Reklámok

Windows 10 Fall Creators Update vs WannaCry & Petya

június 28, 2017 5 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.

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: , , ,