Windows shares

Több mint 10 éve linux alapokon működött a szerverem. Akkor azért váltottam Windowsról, mert feltörték a rajta futó IIS szervert egy expolit-on keresztül (szégyen gyalázat), és úgy döntöttem, többet ilyen nem lesz. Az utóbbi pár évben, viszont semmi sem történt… Rájöttem, hogy már nem szórakoztat az ubuntu, minden működik, már a dist upgradek sem a régiek, hogy utána összeomlana a rendszer és újra össze kell rakni darabokból… Szóval egy hirtelen ötlettől vezérelve, arra gondoltam, hogy megpróbálom ugyanezt Microsoft alapon is, mert miért is ne.

A Microsoft azért nem aprózza el ezt a bemutatkozás, és felhasználói élmény dolgot, az első pár nap alatt feltépődtek a régi sebek, jöttek újak, annak ellenére, hogy a Windows 3.1 óta midnig Windowst használtam desktopra…

A szerverem az Raspberry térhódításával majdhogynem csak egy NAS-ra degradálódott, pár extra funkcióval. Gondoltam első körben megosztok pár dolgot, elvégre mégiscsak az Ms találta ki az smb protokollt. Na de az összes meghajtót ami a gépben van, azt viszont nagyon nem terveztem megosztani.  Ez volt az első dolog (a windows 10 update dialógus ablak után) ahol gyökeresen eltért a véleményünk a dolgok menetével kapcsolatban… A Windows szerint nincs is annál jobb dolog, mint az administrative shares (nem tudom ki találta ki, és az IT security hogy hagyhatta ezt produkcióba kerülni, és azóta is miért létezik ez még egyáltalán, de legalább a net send-et kivették… az is valami 🙂

Aki ki szeretné kapcsolni ezen remek funkciót a gépén nem kell mást tennie, mint létrehozni egy AutoShareWKS nevű DWORD(32) kulcsot az alábbi helyre:


HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Paramerts

Igen, még létre sincs hozva 1 értékkel, hogy csak át kelljen írni, és ezen infók fórumok útján terjednek…  Vannak dolgok, amik nem változnak, ekkor már éreztem, hogy megérkeztem 🙂

És természetesen a network credential-os bug-ot sem sikerült javítani az elmúlt ~20 év alatt. Pedig nem bonyolult reprodukálni. Fogunk egy szervert, ahol pár megosztás bárki számára lekérdezhető. Aztán belerakunk pár olyan megosztást, ami csak adott felhasználók számára elérhetőek. Amikor a windows authentikál először megpróbálja kérdés nélkül a bejelentkezett felhasználó adataival (Ez egyébként megint egy érdekes kérdés, miért történik így. Vajon csak nekem jutott eszembe, hogy egy speciális megosztással, és egy megfelelő rainbow táblával viszonylag egyszerűen megtudható az adott felhasználó jelszava?). Ha a windows egyszer sikeresen azonosította magát egy szerveren, akkor a felhasználó hiába ír be jó azonosító adatokat az idők végtelenségéig a privilegizált megosztáshoz, csak a lenti dialógusablakot fogja látni:

winAuth

Ilyenkor mindenki elkezdi keresni a szerveren a problémát, hiszen Access is denied, mi más lehet a probléma… Úgy gondolom, hogy az emberek többsége itt adja fel, de nézzük csak meg mi történik, ha ugyanezt tesszük parancssorból?

C:\Users\voji>net use \\192.168.1.10\openhab
The password is invalid for \\192.168.1.10\openhab.

Enter the user name for '192.168.1.10': openhab
Enter the password for 192.168.1.10:
System error 1219 has occurred.

Multiple connections to a server or shared resource by the same user, 
using more than one user name, are not allowed. 
Disconnect all previous connections to the server 
or shared resource and try again.

Minderről a GUI annyit mond, hogy Access is denied. Grafikus felületről akarsz csatlakozgatni mindenhova? Akkor úgysem értesz hozzá, minek is terhelne az operációs rendszer ezzel a sok felesleges információval… A “soft” mountokat GUI-ról szintén nem lehet látni, szóval amúgy is mindegy lenne… De ha már itt tartunk, akkor kicsit jobban megnézve, milyen share is van jelenleg “mountolva”:

C:\Users\voji>net use
New connections will be remembered.
Status Local Remote Network
-------------------------------------------------------------------------------
OK \\192.168.1.10\IPC$ Microsoft Windows Network
The command completed successfully.

Bizony, IPC (Inter Proces Communication), amit az RPC (Remote Procedure Call) használ. Egyszerűen hibátlan… És ha tudnátok, hogy az RPC-n belül még mennyi rövidítés van (EPM, COM+, BIT, RPCSS, és még csak a jéghegy csúcsát karcolgatjuk…)

A lényeg, hogy jelen probléma megoldására a bátrak használhatják az alábbi parancsot:

 net use * /d

Kevésbé bátrak beírhatják a * helyére a mount nevét is (ami a fenti példában: \\192.168.1.10\IPC$)

És ezek csak azok a dolgok amik NT4 óta így maradtak… Az újakba, mint pl. a fastboot még bele se mentünk… Pedig…

A microsoft kitalálta, hogy a kernel modulok, és driverek viszonylag ritkán változnak az operációs rendszer élete során, ezért ezeket felesleges is mindig nulláról betöltögetni. Ezért az új windows verziók esetében (8+) bevezették a fastboot-ot, ami annyit tesz, hogy amennyiben kikapcsoljuk a gépet, akkor valójában nem az történik, amire a felhasználó első körben számít. Ugyanis a windows fogja és hasonló dolgot csinál, mint amikor hibernate-t mondunk, egy különbséggel. Nem a teljes memóriát menti, hanem csak a futó szolgáltatások memóriaképét. Zseniális ötlet, akit érdekel, hogy működik, itt olvashat egy felületes cikket a témában: http://www.eightforums.com/tutorials/6320-fast-startup-turn-off-windows-8-a.html

A probléma nem is ezzel van, hisz mivel ez az alapbeállítás, a világ elég nagy részén így kapcsolják ki kedvenc operációs rendszerüket. Ellenben volt a windowsban egy funkció, amit elég gyakran használtam, mégpedig a Group Policy Editorban a startup / shutdown scripts. Ez pont annyit tud(ott), mint amit a neve is mond: megadható neki egy program, amit a rendszer Local System-ként végrehajt a rendszer indulása és leállása során. A fastboot viszont kicsit bekavart a képbe, mert a be/kikapcsolás már nem inicializálja a rendszert a megszokott módon, és ebben az esetben nem is fut le egyik megadott script se. Hogy ebből mit lát a végfelhasználó? Megírja a scriptet, restart, működik. Aztán shutdown, és nem fut az a script, ami az előbb még futott. Aztán előbb utóbb összerakja, hogy hát itt valaki nagyon vicces kedvében volt, mert a startup/shutdown script csak restart esetén fut. A megoldásra két lehetőség van: Vagy kikapcsoljuk a fastboot-ot tokkal-vonóval, és akkor működni fog a startup és shutdown script, vagy továbbra is használjuk a fastboot-ot, de akkor nincs lehetőségünk korrekt módon programokat futtatni a windows indulása/leállítása során (én legalábbis nem találtam, de ha valaki tud ilyet és megosztja velem, akkor jár neki a Mars szelet).

Aztán kipróbáltam még az új Storage Spaces Pool-t (gyk.: mdadm by microsoft). Azt még nem tudom, mi fog történni, ha összeomlik a RAID array, mert ezzel kapcsolatban a Microsoft azt mondja, hogy nem omlik, de ilyen apróságoktól nem szoktam megrettenni. Az mondjuk azért nem annyira bíztató, hogy a disk kivételéről még csak nem is zenélnek a grafikus felületen. A problémára a megoldást természetesen megint egy fórumban lehet megtalálni, vagy jobb esetben, a fórum alapján készült blogbejegyzésben 🙂

És a viccesebbnél viccesebb hibákról még nem is beszéltem. A mostani kedvencem a KB3053711 (user error-nak szoktam hívni). Tessék elolvasni a kapcsolódó knowledge base article-t és a javasolt megoldást… Igazából minden szava arany, csak azt sajnálom, hogy a kapcsolódó forráskódot nem mellékelték, mert ez már az a szint amit minden szakmabelinek látnia kellene…

A Microsoft egyértelműen utolérhetetlen a felhasználói élmény fokozásában… 🙂

Leave a Reply