Archívum

Archive for the ‘Windows 10’ 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

BitLocker kulcsok házirendben szabályozva

április 19, 2017 Hozzászólás

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é.

Windows 10 Mobile RS1 vs FM rádió

január 10, 2017 2 hozzászólás

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 😉 ).

Windows frissítés

december 12, 2016 4 hozzászólás

Nem azt mondom, hogy ez az első olyan kumulatív Windows-frissítés, ami problémás, de mindenképp figyelemre méltó, hogy mekkora galibát tud okozni. A mostani, valamiért rendkívüli, dec. 9-i KB3201845 frissítésről van szó, ami a javítási listában semmi hálózattal kapcsolatos dolgot nem említ, de vannak, akik panaszkodnak, hogy a számítógépük a telepítés után nem csatlakozik a hálózathoz. Az ok egyszerű: valamiért a gépek APIPA-címet kapnak, nem a rendes, DHCP-kiszolgálótól kapott címet. A megoldás kétféle is lehet: egyrészt átállítani fix IP-címre (no igen, egy nagymamának ezt telefonon elmondani, hogy miként lehet), illetve egy újraindítás a frissítés telepítése után.

S itt ismét előjön az a kérdés, amivel már gyakorlatban is sokszor találkozom: nem ugyanaz a leállítás, majd indítás, mint az újraindítás. Ennek okáról mintha már írtam volna: az újabb oprendszerek leállítás során nem végeznek „teljes” munkát, pont azért, hogy indításnál gyorsabban induljon a számítógép. Ez végső soron a felhasználók kényelmi funkciója, de néha nem árt egy „valódi” újraindítás. Aki meg nem szeretne újraindítani, annak egy pipa-lehetősége van, kikapcsolni ezt a szolgáltatást.

Ha meg belegondolunk, az ilyenek fényében nem biztos, hogy jó dolog volt átállítani a régi (Win7…) gépek frissítését is összesítő frissítésekre. Értem én a dolog technikai oldalát, de akkor is 😦

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

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.

Windows 10 Start menü

július 7, 2016 Hozzászólás

Egyik kolléga jelezte, hogy váltott Windows 7-ről, s kissé más a Start menü kezelése az állomány-struktúrában. Ahhoz, hogy megértsük a működését, tudnunk kell, hogy rengeteget változott: csak a parancsikonokat (.lnk) és hardlink-eket (utóbbiról itt írtam) látjuk, ráadásul csak az első szintű mappában felsorolva (a további mappa-struktúrát elrejti, azaz úgy mutatja, mintha minden közvetlenül a „Programs” alatt található mappában lenne). Természetesen itt is két helyről szedi össze a parancsikonokat, a közös és a felhasználói profilban található adatokból.

Úgy kell felfognunk, hogy a Start menü „felépítése” nem csak idézőjelekben értendő, ez valóban egy „építkezés” eredménye: egy kereséssel teszi össze a linkekből álló listát. Ha ez megvan, akkor tegyük hozzá Cortana-t – s kiderül, hogy ez ugyanaz a kereső, mint a Keresés (SearchBar).

Ahhoz, hogy tudjuk, hova nyúljunk, nézzük meg a lehetőségeket. Egyrészt van a saját felhasználói fióknak egy Start menüje, másrészt pedig a közös Start menü. Ez utóbbi helyét keresve megnézhetjük a „régi” helyén, a C:\Users mappában, de egy jó ideje már nem itt van tárolva: egy dir /a segítségével láthatjuk, hogy a szokásos „All Users” mappa egy szimbólikus link a C:\ProgramData-ra, míg a „Default User” egy Junction az ugyanitt található Default mappára.

Tehát mindenki Start menüjének a helye: C:\ProgramData\Microsoft\Windows\Start Menu\Programs.

A saját Start menünk helye természetesen a profilunkban van, a C:\Users\[profilnév]\Start Menu, pontosabban ez is Junction, célja C:\Users\[profilnév]\AppData\Roaming\Microsoft\Windows\Start Menu\Programs, mint ahogy a C:\Users\[profilnév]\Application Data is junction a felhasználó AppData\Roaming könyvtárára.

Most, hogy megvannak a tárolási útvonalak, még bonyolítsunk egyet rajta. Ha létrehozunk egy könyvtárat a fenti útvonalak bármelyikén, a benne található .lnk állományok csak akkor jelennek meg, ha azok nem találhatóak meg másik könyvtárban.

Zárszóként még egy útvonalat jegyezzünk meg, a felhasználó által a tálcára kitűzött alkalmazások parancsikonjának helyét: C:\Users\[profilnév]\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar.

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

Cisco VPN vs. Win 10 TH2

március 7, 2016 2 hozzászólás

Nemrég ismét előkerült a múltkori probléma, hogy Cisco VPN-t kellene használni. Nos, a Windows 10 esetén RTM-el még úgy-ahogy elment, de TH2 esetén már egyértelműen nem tetszik a rendszernek a „hekkelés”. Szerencsére nem kell teljes egészében kidobni a már létező infrastruktúrát (addig, amíg lecserélésre kerül), mert a ShrewSoft-nak a VPN-alkalmazása csont nélkül képes volt megenni a Cisco-konfigurációt, sőt, gyorsabban építi fel a VPN-kapcsolatot is. Igen, tudom, nem mai az utolsó fejlesztés dátuma, de az ügyfél igényeinek teljesen eleget tesz.

Ja, s mennyire fontos az „önismeret” 🙂 Eddig meg voltak győződve, hogy a VPN-jük teljesen különleges, „Cisco” – de végre sikerült elfogadniuk, hogy igaziból egy IpSec VPN van náluk kialakítva…

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