Archívum

Posts Tagged ‘Enroll’

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á)