Archive

Archive for the ‘General’ Category

RDP tanúsítvány

május 24, 2017 Hozzászólás

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.

Házirendek csak hordozható gépekre

március 20, 2017 1 hozzászólás

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

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.

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

Synology HDD-csere

április 1, 2016 Hozzászólás

Pofonegyszerű. Vagy mégsem.

Adott a feladat: egy Synology 4-lemezes NAS-ban egyik lemezt nagyobbra kell cserélni. Hétköznapi esetben ekkor semmi gond nincs, hiszen alapértelmezés szerint SHR/Raid kötetben vannak a lemezek, egyesével kicserélve, majd újraépítve a tömböt „csak” időbe telik a stabil állapotba jutás. Ilyenkor a teljes lemezcserét egyesével elvégezve, s mindegyik csere után megvárva a tömb újraépítését, jutunk egy olyan állapotba, hogy a tömb méretét tudjuk növelni.

Jelen esetben itt volt egy csavar. A NAS ugyanis úgy lett kialakítva, hogy 3 lemez alkotott egy tömböt, a negyedik önmagában állt – legalábbis úgy tűnt, hogy az nem része semmilyen tömbnek (jobban utánajárva, igaziból az is tömbként van kezelve a NAS oprendszere által – de ez később derült ki). A kialakítás logikáját is el tudtam fogadni: a 3-lemezes kötet hibatűrő megoldással tartalmazta a fontos adatokat, a különálló kötet pedig a pótolható anyagokat (ez nem jelenti azt, hogy az eddig összegyűjtötteket ne kelljen átmásolni az új lemezre).

Az egyik legegyszerűbb módja az lenne, hogy egy köztes tárolóra kimásoljuk az anyagokat, lemez-csere, majd vissza, ez viszont egyrészt megfelelő tárhely-kapacitást igényel, másrészt dupla időt (attól függetlenül, hogy a NAS-ra kötjük az USB-lemezt vagy valamelyik helyi gépre) – viszont szerettem volna egy elegánsabb megoldást.

A feladat nehézségi fokát mindenki maga tudja megítélni (főleg Windows-os kollégákra gondolok). Azt tudtam, hogy a Synology oprendszere Linux-alapú, így egyértelműen az állományrendszer is ext3/ext4, ráadásként a Raid-tömb is nehezíti a feladatot – de szerencsére nem vette el a kedvem a kísérletezéstől.

Először próbáltam egy Linux-rendszerű állomány-kezelőt Windows alá*, pl. Ext2Read, Ext2Fsd (ez utóbbi ötletét innen merítettem), de egyikkel sem tudtam olvasni a lemez tartalmát.

A megoldáshoz egy másik megközelítést kellett válasszak: úgy tettem, mintha egy „tönkrement” Synology raid-kötetét szeretném kiolvasni, ehhez pedig itt található egy nagyon jó leírás.

A telepítés után az x64-es verziót tartalamzó USB-kulcsról több gépen sem volt hajlandó rendesen elindulni az oprendszer, képernyő-felbontásra panaszkodva, de azt sem fogadta el, hogy ideiglenesen másik felbontással induljon el. Ezért egy 32-bites verzió került letöltésre, azzal már csont nélkül elindult a gép.

Az első gond ott merült fel, amikor az Apt-get install mdadm parancsot akartam kiadni, ekkor

Package somePackage is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source

hibaüzenettel örvendeztetett meg. A megoldáshoz internetre kapcsoltam a gépet, majd apt-get update utasítással frissítettem a csomag-leírásokat és függőségeiket, utána már tovább tudtam lépni.

A leírás alapján végigmenve valóban felismerte a lemezt és tartalmát, így már csak annyit kellett tenni, hogy az új lemezt betenni a tárolóba, naprakész állapotba hozni, majd hálózaton keresztül átmásolni a régi lemez adatait.

Amennyiben ott szeretnénk hagyni „csak úgy” otthagyni a másolást, akkor érdemes előtte eltávolítani az @eaDir könyvtárakat (a Windows-os thumbnail-nek felelnek meg). Amennyiben a merevlemezt már kiszereltük a NAS-ból (s pl. USB-n csatlakoztattuk az Ubuntut futtató géphez), akkor annyi a teendőnk, hogy kereséssel kilistázzuk őket, majd tömegesen kijelölve töröljük őket. Ha még kiszerelés előtt eszünkbe jut, akkor használhatjuk egyik kolléga itt leírt módszerét.

A másolás sebessége természetesen minden résztvevő szereplőtől függ, de esetünkben az USB-kulcsról bootoló régi netbook, amire szintén USB-vel csatlakoztattuk a kiszerelt lemezt, majd az anyagot hálózaton küldtük a NAS-nak, nem okozott csalódást 🙂

* Még nem a Redstone Anniversary Update rendszerrel próbáltam 😉

Kategóriák:General Címke:

Értékeljenek mások

november 15, 2015 7 hozzászólás

Nem terveztem ezt a cikket folytatni, s nem is kimondottan szakmai kérdés, de ez kikívánkozik belőlem.

Nemrég fejeződött be egy tanfolyamom, s ahogy átfutottam az értékeléseket, megakadt a szemem egy hallgató egyik osztályozásán, ami a gyakorlati tapasztalatomról, illetve annak átadásáról szólt („Instructor’s ability to provide real world experiences and examples”). Nos, nem volt egy mélyszintű tanfolyam, ezért a hivatalos tananyagot bőven fűszereztem életből vett példákkal. Sőt, ahogy egy másik hallgatóval beszélgettem, ő is megerősítette, hogy egy másik, általa végigült tanfolyamhoz képest is valóban több gyakorlati példát mutattam be – sőt, áttételesen is (fél füllel odafigyelve egymás közti eszmecserére) és az értékelésekből is láttam/hallottam, hogy a többiek is hasonlóan gondolkoznak. Oktató-társaimmal is szoktunk beszélgetni, s tudjuk: nem minden kollégánk rendelkezik “éles” tapasztalattal (ráadásul tudjuk, hogy az előre megírt, többször letesztelt laborgyakorlatok és a valódi, életszagú esetek úgy viszonyulnak egymáshoz, mint az elmélet és a gyakorlat: nem mindig fedik egymást).

Olyan vagyok, hogy először mindig magamban keresem a hibát. Most viszont úgy gondolom, van akkora gyakorlati tapasztalatom, s ezt a tanfolyam során felhasználtam, hogy megkérdőjelezem az ominózus értékelést…

Kategóriák:General