Archívum

Archive for the ‘PKI’ Category

Intermediate CA fontossága

május 23, 2022 Hozzászólás

Adott cégnél felmerült az a probléma, hogy a levelező-kliens egy tanúsítvánnyal aláírt levél esetén panaszkodott az aláírásra (mindamellett, hogy a láncolat fő-tanúsítványa érvényes is volt és telepítve is!)

   

A sárga háromszög az alábbi hibaüzenetet rejtette, itt a “Részletek” a fontos:


Ha megnyitottuk, akkor ez a hibaüzenet fogadta a felhasználót:

Hiba:

A rendszer nem tudja érvényesíteni az aláírás létrehozásához használt tanúsítványt, mert a tanúsítvány kibocsátójának hitelességi tanúsítványa nem érhető el vagy érvénytelen.

A rendszer nem tudja meghatározni, hogy az aláírás létrehozásához használt hitelességi tanúsítvány megbízható-e vagy sem.

Aláírta: xx@domain.com, módszer: RSA/SHA256 idő: .


Szokás szerint a Részletek segítenek, akkor az aláírásnál ez a hibaüzenet fogad:


Hiba: Problémák léptek fel az aláírás létrehozásához használt hitelességi tanúsítvány érvényesítésekor.

Ezek után jön a valódi megoldás: ha rámegyünk a “Tanúsítvány megtekintése” gombra, akkor a köztes CA (mivel megbízható Root CA-tól lett kiállítva) automatikusan bekerül a felhasználó-szintű köztes tanúsítvány-kiállító-tárolóba. Ha ilyenkor megnézzük a “Certificate path“-t, akkor azt tapasztaljuk, hogy minden csupa pipa – sőt, ha bezárjuk sorra az ablakokat, amiken keresztül idáig jutottunk, mindegyiknél megjelenik a pipa.

S hogy miként lehet ezt a sok-sok ablakot elkerülni? Például, ha a láncolat összes elemét előre felvesszük a tanúsítványtárba (ez ugye mehetne akár gép-szinten), hiszen így tudja ellenőrizni a hitelességet – ehhez pedig fel tudjuk használni az előző lépések során látott/kapott tanúsítványok exportjait 🙂

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

TLS 1.0 és 1.1

február 15, 2022 Hozzászólás

Mint azt régebben már tudtuk, a nemrég megjelent Edge/Chrome 98-as verziójával kezdve megszűnik a TLS 1.0 és 1.1 támogatása. Ezt azok fogják leginkább észrevenni, akik régebbi rendszereken “ragadtak” ilyen/olyan okból kifolyólag, s a protokollt sem frissítették.

Ilyen esetben az alábbi üzenet jelenik meg:

ERR_SSL_VERSION_OR_CIPHER_MISMATCH

Megoldás az természetesen kiszolgáló-függő, ha be lehet kapcsolni a TLS 1.2-t, akkor egy ideig meg lehet úszni a cseréjét, de ez mindenképp egy figyelmeztetés kell legyen az üzemeltetőnek. Sajnos elég sokan most kaptak észhez, s nyomják a piros gombot, amikor rájönnek, hogy most már telefonról/böngészőből nem használható az oldaluk/levelezésük…

Anélkül, hogy túlzottan belemennénk a részletekbe, a blogon már többször említett openssl-el ugyanakkor tudjuk tesztelni, hogy milyen titkosítási protokoll van támogatva:

openssl s_client -connect kiszolgalo.hu:443 -tls1

openssl s_client -connect kiszolgalo.hu:443 -tls1_1

openssl s_client -connect kiszolgalo.hu:443 -tls1_2

Amennyiben visszakapjuk a publikus tanúsítványt (meg a többi lekérdezett érték is jó), akkor a kiszolgáló támogatja a jelzett protokollt, ellenkező esetben vagy még “reszelnünk” kell rajta, vagy (ha annyira elavult) lecserélni egy korszerűbb változatra.


RDP tanúsítvány saját CA-val

november 7, 2021 2 hozzászólás

Régebben, amikor sárga ablakokról beszéltünk, nem ejtettünk szót egy másik megoldásról. Jellemzően, mi van, ha van belső CA-nk: lehet-e használni az általa kiállított tanúsítványokat az RDP-kapcsolatokhoz? Nos, igen, bár kell hozzá pár dolog (hacsak nem akarjuk kézzel, egyesével ujjlenyomat alapján hozzárendelni).

Egyrészt a tanúsítvány kell tartalmazza vagy a “Server Authentication” vagy a “Remote Desktop Authentication” EKU-t. Az első, egyértelmű – de a második nincs a listában. Ilyenkor megtehetjük az, hogy felvesszük “custom” meghatározásként, 1.3.6.1.4.1.311.54.1.2 értékkel.

(Ha véletlenül elgépeltük, vagy mondjuk át akarjuk nevezni, akkor ADSIEdit a barátunk, a konfigurációs konténer:

CN=OID,CN=Public Key Services,CN=Services,CN=Configuration )

Tapasztalatom alapján javasolt, hogy ne csak CN-ben, hanem SAN-ban is legyen benne a gép “igazi” FQDN-je (ha más névvel akarunk rá hivatkozni, természetesen az is benne lehet a SAN-ban). A tanúsítvány helyét ne bántsuk, maradjon a “Personal” tárolóban (ugye az alap önaláírt máshol van).

Ez még nem elég, még “élesítenünk” is kell.

Ehhez Computer Configuration> Policies >Administrative Templates > Windows Components > Remote Desktop Services >Remote Desktop Session Host > Security (régebbi rendszerek esetén “Remote Desktop Session Host” helyett csak “Session Host“) útvonalon a “Server Authentication certificate template” értékét kell kitölteni, a sablon nevével (tudjuk, ez a szóköz nélküli verzió 🙂 ) – extrémebbek a sablon OID-ját is használhatják 🙂 .

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

CA tanúsítvány igénylése – parancssor

július 22, 2021 1 hozzászólás

Rengeteg parancssori eszköz létezik, most a Windowsos beépített eszközök használatáról ejtek pár szót (pontosabban már létező .req file CA-nak való átadása a cikk témája). Már az elején tisztáznám, hogy Enterprise környezetben, tehát sablonokkal fogunk dolgozni, ezért tegyük tisztába a sablon “valódi” és megjelenített nevét (spoiler: ezt a tudást egy következő cikkben is fogjuk használni).

Természetesen grafikus felületen is a sablon-kezelő konzolon meg tudjuk nézni a sablonok nevét (“Template name”) (s itt nem a megjelenített névre (“Template display name”) gondolok!), de erre van lehetőségünk parancssorból is:

certutil -config “server.domain.local\CA-Name” -CATemplates

Ez azért fontos, mert amikor a certreq parancsot használjuk, akkor a sablonnak NE a megjelenített nevét használjuk, hanem a “valós”, valószínűleg a megjelenített név szóközök nélküli változatát.

certreq -submit -attrib “CertificateTemplate:Webserver” RequestFile.req

(Súgó: amennyiben a megjelenített nevet használjuk, akkor sajnos a CA nem pontos hibaüzenettel örvendeztet meg bennünket:

Certificate not issued (Denied) Denied by Policy Module 0x80094800, The request was for a certificate template that is not supported by the Active Directory Certificate Services policy: Web server.

The requested certificate template is not supported by this CA. 0x80094800 (-2146875392 CERTSRV_E_UNSUPPORTED_CERT_TYPE)

Hibakeresésnél természetesen ellenőrizzük, hogy létezik a sablon és jó jogokkal, de utána azt is nézzük meg, hogy milyen névvel hivatkoztunk rá 🙂 )

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

CA tanúsítvány igénylése – webes felület

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

Adott helyen bevezetésre került egy CA-infrastruktúra, létrehoztuk a sablonokat, majd felmerült, hogy miként lehet tanúsítványokat kérni egy adott sablon alapján, ha annak verziója >=3. Ez a kitétel azért fontos, mert felkerült a webes komponens is, így első körben böngészőből szerették volna kezelni.

Mivel ez a téma eddig csak érintve volt (a PKI-sorozatban: Public Key Infrastructure (PKI) 2. rész), megpróbálok pár gondolatot összeírni.

Egyik kolléga régebbi kérdésére szeretném tisztázni, hogy már az alap CA-szolgáltatás telepítésekor létrejön a CertEnroll mappa. Ha telepítjük a webes komponenst, akkor az IIS-ben a Default Web Site alatt is megjelenik, de a nevével ellentétben nem az igénylés célját szolgálja, abba a mappába (ami ráadásul fizikailag alapértelmezetten a CertSrv alatt van) általában a CA tanúsítványa, az alap CRL és a Delta-CRL (ahol a < DeltaCRLAllowed> engedélyezett volta esetén egy “+” jel látszik), illetve egy nsrev_CANév.asp állomány található (ami a Netscape (iPlanet) alkalmazás tanúsítvány-visszavonásához köthető).

Tehát akkor maradjunk a https://szervernév/CertSrv oldalon (alapból nincs 443 porton publikálva!), a “Request a certificate” link után kétféle felület fogadhat bennünket, kezdem az alapesettel:

,

majd az ACR-re történő kattintás után jön elő az alábbi:

vagy egyből az ACR-ben találjuk magunkat.

Ez utóbbi akkor történik, ha az adott felhasználónak nincs (vagy tiltva van) az “Enroll” jogosultság a “User” sablonhoz (akár közvetlenül, akár csoporton keresztül).

Technikailag, a weboldal kódja úgy van felépítve, hogy a “User” sablon elérhetőségétől függően a certrqad.asp vagy certrqus.asp (esetleg certrqxt.asp) oldal töltődjön be (=> URL-szerkesztéssel is be lehet hozni a kért oldalt 🙂 ):

If “Enterprise”=sServerType Then

    If IsUserTemplateAvailable()=False Then

    fShowRQAD = True %>

    <TD><LocID ID=locLblRequestCert><A Href=”certrqad.asp“><Font Face=”Arial”>Request a certificate</Font></A></LocID></TD>

<%    End If

End If

If fShowRQAD=False Then %>

    <TD><LocID ID=locLblRequestCert><A <%If “Text”=sBrowser Then%> Href=”certrqxt.asp” <%Else%> Href=”certrqus.asp” <%End If%>><Font Face=”Arial”>Request a certificate</Font></A><LocID></TD>

<%End If%>

Nézzük akkor tételesen az ACR oldalon található két linket.

A Submit oldalon egyértelmű a történet, egy már meglévő tanúsítvány-igényt tudunk beadni:

De adott helyen az első opció (Create and submit) volt fontos, ahol “lokálisan” tudjuk elkészíteni az igényt (tehát nem már létező req-et nyújtunk be):

Itt szerettek volna tanúsítványt igényelni – ehhez viszont szükséges, hogy megjelenjen a sablon. Ugyanis a bevezetőben említett sablon-verziók a webes részen nem jelennek meg.

Kerülő-megoldásként egyrészt megpróbálhatjuk a rendszert “átverni” – természetesen, mint ahogy a cikk is említi, fokozott figyelemmel és csomó teszteléssel, másrészt más (nem böngésző-alapú) módszert használunk tanúsítvány-igénylésre. Jelen cikk az előbbit járja körül: az “átverésnek” több módja is van, a végeredmény ugyanaz:

  • létrehozunk egy v1 vagy v2 sablont, majd utólag módosítjuk “nagyobbra”
  • egy már létrehozott sablon verzió-értékét írjuk át az AD-ban (mint a cikk teszi)

Nem lehet elégszer hangsúlyozni, hogy ezt tesztelni kell! Sőt, a weboldal bizonyos esetekben nem is töltődik be jól minden böngészőben, néha érdemes IE-t használni (nos igen, itt is látszik, hogy MS kicsit hanyagolja). Ráadásként IE-ben is lehetnek gondok, pl. ez.

Személy szerint van ennél jobban kedvelt igénylési módszerem (a grafikus mmc-konzol használata szinte gyerekjáték, ha tudjuk, hogy milyen tanúsítványt akarunk 🙂 ), de tervezem, hogy egy következő cikkben megnézzük az egyik leggyakrabban használt parancssoros opciót.

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