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.

WSUS gondok

május 25, 2016 Hozzászólás

Az utóbbi időben elég sok 2012/2012 R2 oprendszeren futó WSUS-t kezelő rendszergazdának volt fejfájása. Az ok az, hogy kijött a KB3148812 frissítés, majd nem sok időre rá kijött a javítása, a KB3159706, s mindkét folt telepítése után a konzol használhatatlan lett; így első reakcióként (kerülőmegoldásként) a folt eltávolítása jött szóba. Az, hogy a folt telepítése után fellépő hibák kiküszöbölése érdekében mit kell még tenni, szokatlan módon csak a megjelenés után pár nappal jelent meg.

Nem teljesen szokványos, hogy egy frissítés telepítése után még további reszelést kelljen végrehajtani (bár nem mondhatni azt sem, hogy újdonság, pl. egyes Sharepoint termékek esetén már hagyomány). Ugyanakkor legtöbben azért használunk WSUS-t, hogy részben automatizáljuk a foltok kiszórását, most viszont pont a WSUS működésében lépett fel zavar.

Az elhárításhoz legalább két dolog szükséges:

– megtalálni, hogy mi okozta a hibát (ez nem egyszerű, ugyanis a konzolon a hibaüzenet sem segít, eseménynapló pedig teljesen már irányba visz el minket)

– ha kiderült, hogy a KB3159706, akkor azt elolvasva végrehajtani az ott leírt lépéseket.

S hogy miről is szól ez a folt, miért nem kihagyható? Nos, a Wsus-ban „Upgrades” kategóriába sorolt Windows 10 fejlesztések a Windows Update kiszolgálókon találhatóak titkosított formában már napokkal az élesítés előtt (annak biztosítása érdekében, hogy mindenhol egyszerre tudják kiengedni őket). A Windows 10 oprendszer fel tudja oldani a titkosítást (RTM óta), de a Wsus nem, ezért eddig a Wsus-ra való kiengedés előtt ezeket manuálisan kellett kikódolni, ami időigényes (és lehetséges hibaforrás) volt. A folt felvértezi a 2012/R2-t a kódolás feloldására (2016 már natívan támogatja), ami alapkövetelménye a Windows 10 Anniversary Update (és az őt követő) frissítések kiszórására.

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

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

SHA1 elavul

május 2, 2016 6 hozzászólás

Páran jelezték, hogy elég régóta nem írtam kedvenc témámról, a tanúsítványokról. Nos, kezdjük is egyből egy közérdekű közleménnyel: a Microsoft, eredeti terveihez képest, előbbre hozta az SHA1 nyugdíjazását: eredetileg 2017 januári hónapja volt becélozva az SHA1 kivonatolási (hash) mód elavult (deprecated) státuszba kerüléséhez, de már 2016 júniusától nem támogatott. A helyét az SHA2 (SHA256, SHA384, SHA512) veszi át – ehhez a CA kriptográfiai módszerének Key Storage Provider (KSP) kell legyen. Ha valaki Cryptographic Service Provider (CSP)-t használ, mivel az nem tud SHA2-t, szükség lesz még egy kis CA-átalakításra (KSP/CSP témát érintettük itt is, kissé más vonatkozásban; CNG (Cryptography Next Gen) érintett része itt).

Aki le akarja cserélni az új tanúsítványok kivonatolását, annak nincs nehéz dolga: egy emelt szintű parancssorban lefuttatja az alábbi sort, majd újraindítja a CA-kiszolgálót:

certutil -setreg ca\csp\CNGHashAlgorithm SHA256

net stop certsvc

net start certsvc

Fontos, hogy ez csak a mostantól kiállított tanúsítványokra fog vonatkozni, a meglévőkre (beleértve a CA sajátját is!) nem.

Mint látszik, nem a „szokásos” (Next-Next-Finish kategória) kivitelezés a gond, hanem a tervezés – ugyanis kivitelezés után egy pár operációs rendszer nem tudja majd kezelni az új tanúsítványokat: az XP SP3, illetve Win2003 (+patch)-től felfele tudja a Windows az SHA2-t. Ha van egy olyan hálózatunk, ami ennél régebbi oprendszereket (pl. Win2000) futtat, amelyek nem lecserélhetőek, akkor egyik kerülőút a két CA használata lehet.

Kategóriák:PKI Címke: , , ,
Követem

Értesítést küldünk minden új bejegyzésről a megadott e-mail címre.

Csatlakozz a 37 követőhöz