Hyper-V guest vs. USB

november 10, 2016 6 hozzászólás

Adott helyen ismét előkerült egy ősrégi probléma: Hyper-V vendéggépre szerették volna a gazdagép USB-portjára csatlakoztatott eszközt átvinni. Ez sajnos mindig egy fájó pont, kerülő-megoldásokkal próbáltuk itt is megoldani a problémát.

Egyrészt megoldás lehet a távoli asztali kapcsolat (RDP), hiszen annak beállításai között szerepel a helyi USB-erőforrások átadása. De mi van abban az esetben, ha (bármilyen okból kifolyólag) nem szeretnénk hálózattal ellátni a vendég-gépet? Ekkor az RDP bizony nem járható út.

Egy másik megközelítés a 2012 R2 óta létező korlátozott megoldás. Ehhez ugyanis Gen2 gépek szükségesek, s ebben az esetben a VMBus-on keresztül át tudjuk adni a legtöbb USB-eszköz kezelését a vendég-gépnek (természetesen bekapcsolt Enhanced Session Mode kapcsolóval). Sajnos a Gen2 gépeknek elég komoly korlátozásai vannak, a konkrét esetben 32-bites Win7 futtatására lett volna szükség – ez sajnos “duplán” megbukott (32-bit és Win7).

Mivel szerencsére itt a saját gépen megvalósítandó környezet elég (értsd: nem távoli szerveren, automatikusan induló virtuális gép, stb), így kipróbáltunk egy alternatív virtualizációs eszközt, a VirtualBox-ot is. Ez bizonyos dolgokat nem tud, amire egy “rendes” virtualizációs réteg képes, de erre a feladatra akár alkalmas lehet.

Hogy ott, adott környezetben annyira speciális USB-eszköz volt, hogy sem az RDP-s megközelítés, sem a VirtualBox nem hozott megoldást – hát, sajnos van ilyen…

Kategóriák:Virtual Server/Hyper-V 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.

Exchange mentések vs Hyper-V

szeptember 15, 2016 Hozzászólás

Adott helyen egy VM (történetesen egy Exchange) átkerült egy 2012-es gazdagépről egy 2012 R2-t futtató gépre. A mozgatás után látszólag minden rendben működött, így a rendszergazda kollégák nem bolygatták többet.

Egy bizonyos idő eltelte után a szerver nem volt hajlandó fogadni a leveleket, a monitorozó-rendszer erőforráshiányra panaszkodott. Megnézve a paramétereket, a kollégák egyből kiszúrták, hogy itt bizony merevlemez-kapacitás hiányzik, s tudjuk, hogy az Exchange-be épített Back-pressure hatására inkább visszautasítja a levelek fogadását, mint veszélyeztesse „saját épségét”. Tüneti kezelésként gyorsan felszabadítottak némi helyet, de természetesen nem hagyták annyiban a dolgot, biztos, ami biztos alapon segítséget is kértek.

Utánajárva, hogy miért lett tele a kötet, kiderült, hogy a naplók törlése nem történt meg (ez akkor történik meg, amikor egy teljes mentés készül az Exchange-ről). Kiderült, hogy magán a levelező szerveren nem volt beállítva mentés, de a gazdagépen viszont igen, mégpedig a teljes VM mentése. Ez „triggerelni” szokta az Exchange-logok törlését is, itt viszont nem történt meg. Az okot keresve elég hamar rátaláltunk, hogy mikor volt az utolsó teljes mentés (Exchange-konzol segítségével kiolvasható), majd mivel a jelzett dátum körül történt a mozgatás, nyilvánvalóvá vált, hogy ezzel függ össze. Szerencsére a gazdagép Hyper-V konzolját megnyitva egyből látszott a probléma: az Integration Services (itt írtam róla legutóbb) nem volt naprakész. A friss, 2012 R2-s kiegészítőket telepítve, majd a VM-et újraindítva a következő mentés egyből ismét helyreállította a rendet.

Tanúsítványok és Windows Phone / Mobile

augusztus 1, 2016 Hozzászólás

Egy jó ideje velünk van az IKEv2 típusú VPN, amit úgy szoktunk „reklámozni”, hogy a mobilokra lett kifejlesztve, s csak „másodlagosan” számítógépre. Nos, ezzel kapcsolatban osztanék meg két apróságot, amire érdemes figyelni:

– a Windows Phone (7 – 8.1) / Mobile (10) telefonokon nem lehet törölni a tanúsítványt (létezik egy Certificates app, de az csak megtekintésre jó)

– egyes helyeken olvasható az, hogy a VPN kiszolgálón a root tanúsítványok között csak a miénk legyen, ellenkező esetben minden mást is elfogad. Nos, ez nem állja meg a helyét, hiszen nem véletlenül kell a tanúsítvány tartalmazza a „Server Authentication” és „IP Security IKE intermediate” felhasználási módokat (EKU/AppPolicies*).

* Windows 2000-ig EKU, 2003-tól Application Policies néven található meg az utód, ami viszont MS-specifikus, s bár legtöbbször használatuk megegyezik, nem ugyanaz az EKU-val.

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

A lefoglalt vhd esete

július 19, 2016 7 hozzászólás

Egyik cégnél a kollégák már a hajukat tépték, amikor egy aznap délelőtt leállított virtuális gépet akartak ismét elindítani, s folyamatosan hibára futott. Az eseménynaplóban egy olyan hibaüzenetet találtunk csak:

VM-Név

Virtuális-gép-ID

VHD-útvonal.vhd

%%2147942432

0x80070020

The locale specific resource for the desired message is not present

Próbáltunk ennek alapján elindulni. A hibakód azt jelenti, hogy

2147942432: The process cannot access the file because it is being used by another process. (0x80070020).

Tehát próbáltuk kideríteni, hogy ki/mi használhatja ezt az állományt. Mivel a gép leállítása azért történt, mert egy újabb oprendszerű, de azonos nevű VM vette át a feladatát, első sorban erre gyanakodtunk – de a vhd nem volt hozzá csatolva.

Kiderült, hogy egy másik kolléga nem ezt a módszert választotta pár adat kinyeréséhez, hanem a gazdagépre csatolta fel közvetlenül a vhd állományt. Onnan leválasztva, máris elindult a virtuális gép…

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

Engedélyhez kötött tanúsítványok

június 6, 2016 3 hozzászólás

Ha bármely tanúsítványsablonon bekapcsoljuk, hogy valakinek kell engedélyeznie a tanúsítvány-kiállítást, akkor pár dologra érdemes figyelnünk az igénylés során. A legegyszerűbb, ha ilyenkor webes felületet használunk a kérelem benyújtásához, ugyanis elbírálás után ugyanezen a felületen tudjuk lekérni a kapott tanúsítványt.

Amennyiben mégis mmc-t (vagy bármilyen más módszert) használunk, akkor a kliens-gépen ott lesz a Request, de az engedélyezés után kapott tanúsítvány kézhezvételéhez a leggyakrabban használt módszerek:

  1. exportáljuk a CA-n,
  2. kliensen kérjük le a tanúsítványt, a certreq segítségével (Figyelem: bármelyik tanúsítványt le tudjuk kérni a CA-tól, ha tudjuk a CA-ban található RequestID azonosítóját, így mindenképp jegyezzük meg, hogy melyiket akarjuk letölteni)
  • interaktív módon:

          certreq -retrieve RequestID

ezután kiválasztjuk a CA-t, illetve, hogy milyen néven/hova kerüljön mentésre a tanúsítvány, alapértelmezetten .cer lesz

  • automata üzemmódban:

          certreq.exe -retrieve -config <CAConfig> <RequestID> <OutPutCertFile.cer>

ekkor fontos, hogy a paraméterek ilyen sorrendben legyenek (az ID-t ne tegyük a -config elé, ne tegyük paraméter-megnevezési sorrendbe), a CAConfig pedig lehet pl. Server_Neve\CA_Neve (de certreq -retrieve /? természetesen mindig súg😉 )

Amennyiben sikerült megkapnunk a tanúsítványt, az igénylő gépen importáljuk (akár grafikus felületen, dupla klikkel, akár certreq -accept <OutPutCertFile.cer> paranccsal), itt összerendelődik a privát kulccsal, így „teljessé” válik a tanúsítvány.

Bár néhány internetes fórumon szoktak rájuk hivatkozni, de a tanúsítvány-áttöltéshez se a „certutil -pulse” nem járható út, se a házirendben engedélyezett Auto-enrollment (User Configuration / Windows Settings / Security Settings / Public Key Policies / Certificate Services Client – Auto-Enrollment – erről majd egy következő cikkben még ejtek szót) nem hatásos, mint a hivatalos cikk is jelzi.