Archívum

Archive for the ‘PKI’ Category

Számítógép-tanúsítvány igénylése

december 28, 2020 Hozzászólás

Az utóbbi időben néhány cégnél beüzemelésre került pár tanúsítvány-kiszolgáló. Ezek kapcsán a kollégák feltettek néhány kérdést, amelyek közül kettőt megpróbálok egy-egy cikkben körbejárni.

Kezdjük azzal, hogy telepítés és konfigurálás után szeretnénk, ha minden számítógép kérne a CA-tól egy saját tanúsítványt. Fontos, hogy tudjuk, ha valaha történtek-e változtatások a sablonokon (ezek khm… boríthatnak mindent), hiszen ezek AD-ban kerülnek tárolásra; ezért a továbbiakban alap-telepítés, beállítást feltételezek – ebben kapunk alap v1 és v2 (sőt, egyetlen v3) sablonokat.

A kolléga arra kérdezett rá, hogy számára nem teljesen világos, hogy az alábbi két beállítás esetén melyik mit takar (zárójelben megjegyzés tőlem):

(Computer/User) Configuration\Windows Settings\Security Settings\Public Key Policies \ Certificate Service Client – Auto-enrollment (Windows 2003 idején Autoenrollment Settings)

és

Automatic Certificate Request Settings (“mappa”).

Röviden a későbbiekben CSC-AE és ACR -ként fogok rájuk hivatkozni. S még mielőtt válaszolnék a kérdésre, pár infó, amit érdemes tudni:

  • a tartományvezérlők esetén “hardveresen” bele van kódolva, hogy abban az esetben, ha az erdőbe telepítettünk egy CA-t, automatikusan igényeljenek maguknak egy “Domain Controller” tanúsítványt (természetesen akkor kapják meg, ha ez a sablon – mint alapból – publikálva van). Ez a működés megváltozik, amennyiben engedélyezzük akármelyik GPO-beállítást. Tehát a DC-k esetén nem 2, hanem 3 “módja” létezik: “beégetett”, hagyományos és aktuális.
  • az ACR a hagyományos (régebbi) verzió, nála csak v1-alapú tanúsítványokat lehet kiválasztani. Mivel V1 sablonok esetén nincs AutoEnroll jogosultság, a gépeknek Read és Enroll jogot kell adni – alapból ezek megvannak a (most érintett) két v1 sablonra az illetékes csoportoknak, tehát tartományvezérlők “Domain Controller”, minden más gép “Computer” sablonra jogosultak. V1-sablon alapú tanúsítvány-kiosztás esetén nincs “Superseded” (felülírt) mód, illetve (belegondolva, értelemszerűen) lokálisan nincs ilyen házirend-opció
  • a CSC-AE esetén minimum v2 sablonok játszanak, a két opció magyarázata:
    • Renew expired certificates, update pending certificates, and remove revoked certificates: bepipált állapotban azokat a tanúsítványokat újítja meg, amelyek
      nincsenek beállítva az automatikus regisztrációhoz, például amelyekhez több aláírás szükséges (pl. Enrollment Agent-et igényelnek), vagy amelyeknek a kérésben kell megadni a tanúsítvány tárgyának adatait (pl. webkiszolgálók). Ezenkívül ez a beállítás fogja betölteni a függőben lévő kérelmeket, amelyeket a CA-manager kellett elfogadjon (Figyelem: ha ez nincs bepipálva, s nem töltjük be a kiállított tanúsítványt (akár “manuálisan”), folyamatosan generálja az újabb kéréseket!).
    • Update certificates that use certificate templates: bepipált állapotban AutoEnroll joggal rendelkező sablonok alapján új és megújítási kérelmek jönnek létre a CA-n.
  • a “Superseded” (felülírt) állapot csak CSC-AE és AutoEnroll jogok közös metszetében értelmezendő, alapból a Domain Controller sablont csak Directory Email Replication és a Domain Controller Authentication írja felül, a Kerberos Authenticationokkal – nem!
  • a különböző jogosultságok szabályozzák, hogy mikor milyen tanúsítvány kerül kiosztásra, egy gép akár több tanúsítványt is kaphat egyszerre (s ez igaz a v1 sablon-alapúakra is, ott is tudunk plusz jogokat adni!)
  • egyes MS-cikkek (pl. ez) nem elég pontosak, ez elég lehet ugyanis egy DC esetén (sőt, lásd feljebb, még ez sem kell), de egy munkaállomáshoz nem

S akkor a válasz: mindkettő jó, ésszel használva, a CA beüzemelése után az alábbi lépések szükségesek:

  • hagyományos verzió:
    • felvesszük az ACR-be a kiosztandó sablon(oka)t
  • aktuális verzió, amikor is két dolgot kell tennünk:
    • beállítjuk a CSC-AE-t (érdemes mindkét pipát betenni)
    • engedélyezzük az AutoEnroll jogosultságot a szükséges sablonokon (pl. Workstation) és publikáljuk őket (alapértelmezetten a Directory Email Replication, Domain Controller Authentication, Kerberos Authentication sablonok már ilyenek)

A fentiek alapján összegezzük:

– a DC-k alapból vagy 1 (“beégetett” és hagyományos beállításkor), vagy 3 (a CSC-Auto-enrollment beállítása után), de automatikusan kapnak tanúsítványokat. Utóbbi esetben Domain Controller azért nem jár nekik, mert azt felülírja más sablon – de manuálisan természetesen kérhetünk.

– amennyiben engedélyezzük az AutoEnroll-t, a rá jogosultak keresni fogják (ugye, AD-ból tudják), tehát ne felejtsük publikálni is

Bár kicsit hosszú lett, végszóként nézzük kicsit a hibakeresést/naplózást. Ehhez érdemes létrehozni a registryben egy AEEventLogLevel duplaszót (értéke lehet 0), számítógép esetén HKLM (felhasználó esetén HKCU) \Software\Microsoft\Cryptography\Autoenrollment alatt, ezután minden sikeres vagy sikertelen esemény a kliens Alkalmazás naplójába hoz létre bejegyzést.

Ja, s természetesen ne felejtsük el, hogy kézzel miként “triggereljük” az automatikus tanúsítvány-igénylést: pl. házirend-frissítéssel* vagy certutil -pulse paranccsal.

*Bár a gpupdate parancsról általában mindenkinek a GPO-k újbóli érvényesítése ugrik be, tanúsítványoknál tudjuk, hogy nem kell feltétlenül GPO-nak léteznie (pl. Enterprise CA-k automatikus terítése, amit bár szintén ezzel a paranccsal lehet kierőltetni, GPO nem társul hozzá)


 

Saját CA által kiállított tanúsítványok vs böngészők

október 7, 2020 Hozzászólás

Nem új keletű a történet háttere, de gondolom az új Edge bevezetésével mind több helyen elő fog jönni, ezért úgy döntöttem, elébe megyek a dolgoknak.

Adott cégnél felmerült, hogy az eddigi http alapú intranet kommunikációt áthelyezik https-re. Ennek érdekében első körben történt egy CA-bevezetés, majd a kiszolgálóra igényeltek egy web-kiszolgálói tanúsítványt.

A tesztelés során kiderült, hogy azok, akik IE vagy “régi” Edge-ről töltik be az oldalt, nem tapasztalnak gondokat, viszont akik Chrome vagy Chromium alapú Edge-ből, azoknak

ERR_CERT_COMMON_NAME_INVALID

hibaüzenettel, a Firefox-ból vonulóknak pedig egy

SEC_ERROR_UNKNOWN_ISSUER

üzenettel kedveskedik a rendszer.

Itt akkor felmerült a kérdés: most akkor mi van? Jó a tanúsítvány vagy nem? Illetve miért függ egy tanúsítvány megítélése a böngészőtől?

Nos, Firefox esetén a böngészőnek saját tanúsítvány-tára (is) van, de esetében mondhatni könnyű dolgunk van: egy házirend segítségével megadjuk, hogy a böngésző az oprendszertől kérje el a megbízható tanúsítványok listáját. S tudjuk, hogy a CA automatikusan lekerült a gépekhez, tehát ez nem lehet gond (erre amúgy másodlagos bizonyíték az is, hogy az MS régebbi böngészői sem reklamálnak). Itt “csak” egy dolog nem teljesen világos számomra: miért szükséges, hogy egyes programok (pl. Adobe, Java, stb) saját tanúsítványtárat használjanak? Értem én, hogy így akár szolgáltatásonként külön tanúsítványt lehet használni – de személy szerint ezt már túlzásnak érzem…

A Chrome / Chromium alapú Edge esetében a megértéshez szükséges a Google böngészőjének működését figyelembe venni. Kb. 3 éve ugyanis a Chrome nem fogadja el a belső CA-k által kiállított tanúsítványokat, csak akkor, ha azok rendelkeznek érvényes SAN-mezővel. Ezzel a gondolattal lehet vitatkozni, ugyanis elvileg az RFC előírja, hogy másodlagos opcióként a CN-t is ellenőrizni kell – de ez figyelmen kívül van hagyva. Egy ideig egy registry-kulccsal lehetett egy kerülő-megoldást alkalmazni, viszont ezt a lehetőséget is már rég megszüntették. Jelen esetben megoldásként az a döntés született, hogy rendben, akkor létrehoznak egy új, célnak megfelelő tanúsítvány-sablont, majd azzal igényelnek tanúsítványt. Ennek szétszedése (Cert, Key, CA) már gond nélkül lezajlott, majd az élesítés után már valóban nem reklamált a böngésző. De hogy mit tesznek azok a cégek, ahol tömegesen használnak web-kiszolgálókat, saját CA-val, s tömegesen akarják lecserélni a tanúsítványokat az újabb sablonból eredőnek – hát, lehet, hogy nem mindenki lesz boldog.

Management konzol és tanúsítvány

augusztus 7, 2020 3 hozzászólás

Egy adott cégnél feltették adott (egyik általam is kedvelt) végpontvédelmi alkalmazás központi kezelőfelületét. A telepítés rendben lezajlott, viszont a következő lépés során hiába keresték a program nyilvántartásában a kliens-gépeket, a lista üres volt.

A hibafeltárás során először is megnéztük, hogy lefutott-e az AD-ból történő import. Mivel a feladat hibát jelzett, így egyértelmű lett, hogy “csak” ennyi a baj. No de miért futott hibára?

Nos, a nemrég, júniusban kiadott legújabb verzió tartalmaz egy elég fontos változást ezen a téren – így vélhetően lesznek még néhányan, akik konzol-frissítés után szintén belefuthatnak a sikertelen műveletbe. Kissé kettős érzéssel vagyok, ugyanis érzem, hogy az elképzelés, alapötlet nem rossz, de sajnos a kivitelezés nem sikerült a legjobban.

Hogy konkrétan az okot nézzük: bevezették, hogy az AD-import LDAPS segítségével történjen. Ez szuper, hiszen ez a biztonságot erősíti, nem? De igen, de mi van azoknál a cégeknél, ahol még nincs PKI rendszer bevezetve, a DC-knek nincs megfelelő tanúsítványa? Nos, itt csúszott el a történet. Idézem a támogatói oldal erre vonatkozó cikkét: a DC-n Server Manager segítségével telepítsük az AD CS szerepkört, azon belül a CA-t. Ezután a Helyi számítógép tanúsítványai ablakban jobb klikk segítségével kérjünk DC-tanúsítványt. S kész.

Aki nem foglalkozott soha tanúsítványokkal, talán az is érzi, hogy ez elég foghíjas. Kezdve attól, hogy egy tanúsítvány-kiszolgálót nem vezetünk “csak úgy” be egy tartományba, arról nem beszélve, hogy a binárisok telepítése (Server Manager, ugye) után még van a CA élesítése. Erről a cikk mélyen hallgat, tehát aki a varázslót lefuttatja, az törheti a fejét, hogy Enterprise (default) vagy Standard, Root (default) vagy Subordonate, új privát kulcs vagy nem (ennek minden finomságával) szükséges – vagy csak rányom a Next-Next-Finish gombra, de attól még nem tudja, hogy mit csinál.

Amennyiben sikerül a CA-t telepíteni, jöhet a következő lépés, ami valóban nem annyira bonyolult: a DC-nek tanúsítványt kérni. Még itt is elbizonytalanodhat a szomszéd Pistikéje, ugyanis két tanúsítvány-sablonban is szerepel a “Domain Controller” szópáros

Csak, hogy teljes legyen a lista, egy másik apróság is kibukott (ez már csak helyi “specialitás”): az előbbiek abszolválása után még mindig nem tudott a kiszolgáló LDAPS kapcsolatot létesíteni a DC-vel. Ennek okának kiderítése kicsit kacifántosabb volt, a semmitmondó hibaüzenet (ami ráadásul ugyanaz volt, mint a CA telepítése előtt) nem segített semmit. Bár tudjuk, hogy Ent CA esetén a kiszolgáló tanúsítványa automatikusan bekerül a megfelelő helyre, így nem GPO-val kell kiszórni a tartományi gépekre, adott gépen ez nem valósult meg, így kerülő-megoldásként kézzel került be a megfelelő konténerbe – ezzel végre kerekké (és sikeressé) téve a történetet.

A teljesség kedvéért meg kell említeni, hogy egy másik opció segítségével maradhatunk LDAP csatlakozásnál is, sőt, megfelelő sablon segítségével a szükséges Active Directory attribútumokat is ki tudjuk töltetni – de szerintem első körben elég lett volna egy pipa-beállítás, hogy aki szeretné, tudjon használni LDAPS-ot, majd később szigorítani, s alapértelmezetté tenni.

Kategóriák:General, PKI Címkék: ,

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ímkék: ,

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ímkék: ,

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ímkék: , , ,

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ímkék: ,

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ímkék: , ,