Archive

Archive for the ‘PKI’ 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.

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

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.

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

Sikertelen NPS hitelesítés

június 26, 2014 2 hozzászólás

Adott ügyfélnél a sikertelen hitelesítések sora kezdett gyűlni az NPS-kiszolgálón. Az eseménynaplóban sajnos eléggé semmitmondó üzenet volt, így segítséget kértek a probléma behatárolása érdekében.

Nézzük a naplóbejegyzést (kivonatoltam):

Network Policy Server discarded the request for a user.

Contact the Network Policy Server administrator for more information.

Authentication Details:

            EAP Type:                               –

            Account Session Identifier:                    –

            Reason Code:                           1

            Reason:                                               An internal error occurred. Check the system event log for additional information.

Ha megnézzük a listában a hibakódot, továbbra sem leszünk okosabbak, hiszen az üzenettel ellentétben nem a kiszolgálóval van baj, hanem csak bizonyos hitelesítések esetében van gond (erre még visszatérünk).

Semmi gond, nézzük tovább. Az NPS saját logállománya talán segít – reméltem. Ez a remény azonban hamarosan szétfoszlott, amint belenéztem, s gyakorlatilag a sikeres és sikertelen sorok között nem láttam érdemi különbséget.

Maradt a nyomozás. „Természetesen” semmi nem változott, semmi nem került telepítésre/eltávolításra. Az egyetlen nyom az volt, hogy a munkaállomások kivétel nélkül sikeresen hitelesítettek, egyedül a multi-funkciós készülékek (MFP) hasaltak el.

A megértéshez annyit érdemes tudni, hogy az ügyfélnél beállításra került az MFP-k tanúsítvánnyal történő hitelesítése. Ennek alapján a készülékek bekapcsoláskor egy intelligens hálózati eszköz segítségével bemutattak a Radius-kiszolgálónak egy érvényes tanúsítványt, ekkor kaptak „rendes” ip-címet, ellenkező esetben egy másik alhálózat tagjai lettek.

Nos, ez a hitelesítés hasalt el. Ideiglenesen kikapcsoltuk a Radius-hitelesítés igényét (hogy kapjon megfelelő ip-címet), s megnéztük az MFP-beállításait. Ekkor derült ki, hogy a bemutatásra feltöltött tanúsítvány járt le, ezért futott hibára. Ezt maga az MFP nem képes megújítani, így manuálisan kell feltölteni az újat – természetesen a régi lejárta előtt – s máris helyreáll a béke. De hogy ezt miért nem lehet egy rendes hibakóddal/üzenettel/naplóbejegyzéssel jelezni, nem értem 😦

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

Certificate Services 2012

május 20, 2014 5 hozzászólás

Úgy tűnik, lassan ki tudok evickélni a felszínre, így folytathatom a bloggolást 🙂

„Kezdetnek” legyen egyből egy rövid kivonat, egyik kedvenc témámról, a tanúsítványkezelésről, pontosabban a 2012 újdonságairól e téren.

Mint más területen is, itt is összevonták a Standard és Enterprise tudását, magyarul, bármelyik funkciót tudjuk használni 2012 Std esetén is (emlékszünk, korábbi verziók esetén bizonyos feladatköröket csak Ent SKU esetén használhattunk).

A következő, szerintem jelentős (várható) lépés az volt, hogy végre lehet Core verzióra is telepíteni. Ez sem szorul további magyarázatra, hiszen a terhelés minimális volta, meg az előző Core verziókra is részlegesen telepíthető IIS előrevetítette ezen kívánság megvalósulásának lehetőségét.

Mint megszoktuk, újabb Windows verziók/családok esetén újabb tanúsítvány-sablonokat is kapunk, így a soron következő 4. verzió egyértelmű volt. Ez a verzió természetesen nem csak számozásában több, mint elődjei, de képes pl. ugyanazon kulcs használatával megújítani a sablonon keresztül igényelt tanúsítványt (ehhez legalább Win8/2012 szükséges) – ezt is érintette a kis eszmefuttatás. Szintén v4 fejlesztés, hogy egyszerre tudja használni a Cryptographic Service Provider (CSP) és Key Storage Provider (KSP)-ket (v2 esetén a „Request handling” fülön lehetett az  előbbieket, míg v3 esetén a „Cryptography” fülön utóbbiakat), itt most egy fülön rendezhetjük ezek sorrendjét is. Ami szintén érdekesség, hogy mostantól sablon másolása esetén nem verziót kell megadnunk, hanem a kompatibilitási fülön a kiszolgáló/igénylő operációs rendszereit kiválasztva tudjuk meghatározni a sablonon elérhető funkciók listáját, ebből állapítja meg a CA a mentendő sablon verzióját.

A nyalánkságok közül kiemelném a CA-val folytatott tanúsítvány-igénylés menetének titkosítását, mely most már alapértelmezetten bekapcsolt állapotban van (eddig is lehetett, de alapból ki volt kapcsolva). Fontos, hogy az XP-k még nem tudják így kérni a tanúsítványokat, így ilyen esetben ki kell kapcsolni ezt a titkosítást.

Mivel már 2008-ra is létezett egy folt a CA-kiszolgáló privát kulcsainak mentésére (KB2603469), ez itt természetesen alapból megoldott, így ezt csak megemlítem. A Server manager és PowerShell szinte kötelező jellegű fejlesztés, ami viszont hasznos, az a tanúsítvány lejáratának figyelmeztetése. Ráadásul testre szabhatóan, egy hordozható gép akkujának merüléséhez hasonlóan, mi tudjuk házirendből szabályozni, hogy százalékban kifejezve milyen szintű „élettartam” (hasonlatban „töltöttség”) esetén kezdjen riasztani. Ezeket az eseménynaplóban jelentkező riasztásokat viszont már úgy kezeljük, ahogy akarjuk (pl. emailt küldünk).

A teljes változás-listát itt találjuk.

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