Tanúsítvány visszavonás, egyszerűen

Egyre több helyen alkalmazzák, hogy a Wifi/VPN hitelesítés nem név/jelszó párossal (esetleg valamilyen MFA megoldással kombinálva) történik, hanem felhasználói tanúsítványokkal. Nagyon üdvözlendő! 🙂

Sok esetben viszont a “lifecycle” kezelése nincs átgondolva és megoldva. Azaz: a tanúsítványkiadás megy GPO-ból/Intune-ból, mint a karikacsapás, de hogyan kezeljük a visszavonást? Security szempontból mindenképpen érdemes a távozó dolgozó kiállított tanúsítványait visszavonni, nem csak az Active Directory accountját letiltani stb.

Az alábbi példában bemutatom, hogyan lehet a Certificate Authority felületéről és Powershellből célzottan tanúsítványt visszavonni. Fontos hangsúlyozni, hogy ez egy user decomission process része kell legyen!

Tanúsítvány visszavonása CA konzolból:

Jelentkezzünk be a CA szerverre és indítsuk el a Certificate Authority konzolt. Az Issued Certificate résznél találjuk az összes kiállított tanúsítványt (akár több ezer is lehet)

Az egyes felhasználó számára kiállított tanúsítványokat a View/Filter opcióval tudjuk leszűrni.

Állítsuk össze a szűrési feltételt:

Field: Issued Common Name

Operation: =

Value: a kívánt felhasználó AD-ben szereplő neve (pl. Kovács László)

Megkapjuk az összes, számára kiállított tanúsítványt:

Ezután a tanúsítványon jobb klikkel kiválaszthatjuk a Revoke Certificate opciót:

Megadhatjuk a Reason Code-ot:

Az egyes kódok jelentése:

  • KeyCompromise. The private key that is associated with the certificate is compromised and is in the possession of an unauthorized individual—for example, if a portable computer is stolen or a smart card is lost.
  • ■ CACompromise. The smart card or disk on which the CA’s private key is stored is compromised and is in the possession of an unauthorized individual. When a certificate manager revokes a CA’s certificate, all certificates issued by that CA are considered revoked.
  • ■ AffiliationChanged. An individual is terminated or has resigned from an organization. It is not necessary to revoke a certificate when an individual changes departments unless your security policy requires that each departmental CA should issue certificates to the individuals in that department.
  • ■ Superseded. A new certificate must be issued if a smart card fails or the legal name of a user has changed. The new certificate supersedes the previous certificate, which must be revoked.
  • ■ CessationOfOperation. If your organization decommissions a CA, use this revocation code to revoke the CA’s certificate. Do not revoke the certificate if the CA publishes CRLs for the currently issued certificates but does not issue new certificates.
  • ■ CertificateHold. A temporary revocation that indicates that a CA will not vouch for a certificate at a specific time. After a certificate is revoked by using CertificateHold, you can later unrevoke the certificate.

Tanúsítvány visszavonása Powershell segítségével

Ha egy felhasználónak több kiállított tanúsítványa van, a fenti konzolos megoldás fárasztó lehet. Itt tudjuk segítségül hívni a Powershellt.

Elérhető egy powershell csomag, amivel különböző PKI feladatokat tudunk elvégezni (https://www.powershellgallery.com/packages/PSPKI/3.7.2)

A telepítése egyszerű, a CA szerverre telepítsük fel admin powershellből:

Install-Module -Name PSPKI

Importáljuk be:

Import-Module PSPKI

Futtassuk le a lekérdezést, hogy pl. Kovács Lászlónak milyen kiadott tanúsítványai vannak:

Get-CertificationAuthority | Get-Issuedrequest -Filter “CommonName -eq Kovács László”

Ehhez már könnyen hozzá tudjuk fűzni a parancsot hogy vonja vissza a tanúsítványokat, “Certificate Hold” indoklással:

Get-CertificationAuthority | Get-Issuedrequest -Filter “CommonName -eq Kovács László” | Revoke-Certificate -Reason “CerfificateHold”

CRL publikálása

A tanúsítványok visszavonása után ne felejtsünk el új CRL-t publikálni:

(Megjegyzés: sok visszavont tanúsítvány esetén a CRL mérete túl nagy lehet, ami egyes szolgáltatásoknál gondot okoz (pl. időtúllépés a CRL letöltése során). Ezért érdemes figyelni rá, hogy időnként a már nem szükséges visszavont elemeket töröljük a Certificate Authority adatbázisából)

Always-on VPN IPSec policy Intune-ból

Aki már konfigurált AOVPN-t, az tudja, hogy illik az IPsec beállításokat az alapértelmezettnél erősebbé tenni.

Az alapértelmezett IPSec értékek a következők:

  • Encryption: 3DES
  • Authentication/Integrity: SHA-1
  • Key Size: DH Group 2 (1024 bit)

A javasolt beállítások:

  • Encryption: AES128
  • Authentication/Integrity: SHA-256
  • Key Size: DH Group 14 (2048 bit)

A VPN szerver oldalon ezt powershell paranccsal tudjuk módosítani:

Set-VpnServerConfiguration -CustomPolicy -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES128 -DHGroup Group14 -EncryptionMethod AES128 -IntegrityCheckMethod SHA256 -PFSgroup PFS2048 -SALifeTimeSeconds 28800 -MMSALifeTimeSeconds 86400 -SADataSizeForRenegotiationKilobytes 1024000

Utána szükséges a Remote Access service-t újraindítani:

Restart-Service RemoteAccess -PassThru

Ezzel a szerveroldali beállítások elkészültek. Szükséges viszont hogy a kliens oldalon is megegyezzenek az IPSec konfigurációk, itt is segítségül hívhatjuk a powershellt:

$connection = “[connection name]”
Set-VpnConnectionIPsecConfiguration -ConnectionName $connection -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES128 -DHGroup Group14 -EncryptionMethod AES128 -IntegrityCheckMethod SHA256 -PFSgroup PFS2048 -Force

Hogy néz ki mindez, ha Intune-ból akarjuk kiküldeni az IPSec policyt? Nos, elsőre nem feltétlenül egyértelmű, hogy a fenti parancsban definiált értékek hol vannak az Intune policyban:

Hogy ne kelljen sokat keresgélni, tesztelgetni, itt egy működő beállítás:

IKE Security Association Parameters

  • Encryption algorithm: AES-128
  • Integrity check algorithm: SHA2-256
  • Diffie-Hellman group: 14

Child Security Association Parameters

  • Cipher transform algorithm: CBC-AES-128
  • Authentication transform alorithm: HMAC-SHA256-128
  • Perfect forward secrecy (PFS) group: Use parent Diffie-Hellman group

Azure AD Certificate-based Authentication

2022 novemberében a Microsoft az Ignite konferencián bejelentette az Azure AD CBA szolgáltatás végleges (General Available) állapotba kerülését. Lássuk, mi ez és hogyan tudjuk beállitani.

Mi az Azure AD CBA?

A CBA lehetővé teszi, hogy különböző Microsoft alkalmazásokba és webes felületekre tanúsitvánnyal jelentkezzünk be. A tanúsitványt a saját PKI (public key infrastructure) környezetünkből kapjuk és az Azure AD ezt használja fel a hitelesitéshez. Ezzel egy úgynevezett phishing-resistent megoldást kapunk.

Hogyan működik a CBA?

A következő ábra bemutatja a bejelentkezési folyamatot:

Lássuk az egyes lépéseket:

  1. A felhasználó megnyitja a https://myapps.microsoft.com portált
  2. Ha nem volt eddig bejelentkezve, akkor a felhasználót elirányitja a https://login.microsoftonline.com oldalra
  3. A felhasználó megadja a nevét
  4. Az Azure AD ellenőrzni, hogy a tenantban be van-e állitva a CBA authentication. Ha igen, akkor megjelenik egy link “Use a certificate or smartcard” néven
  • 7. Az Azure AD ellenőrzni a tanúsitvány visszavonási listát (CRL), hogy nincs-e visszavonva
  • 8. Ha van Conditional Access policy, ami megköveteli az MFA-t, és ha az úgynevezett certificate authentication binding rule megfelel, akkor a belépés megtörténik.
  • 9. Az Azure AD elküldi a primary refresh tokent és a belépési process lezárul

Hogyan állitsuk be a CBA-t?

Előfeltételek:

  • Működő PKI rendszer (legalább egy root CA plusz egy intermediate CA)
  • Kiadott tanúsitvány a felhasználóknak (client authentication SKU)
  • A CA-nak legyen elérhető a CRL listája az internet felől (ennek hiányában az Azure AD nem fogja leellenőrizni a tanúsitvány érvényességét és nem blokkolja a belépést)

CA konfiguráció az Azure portálon

Lépjünk be a https://portal.azure.com/#view/Microsoft_AAD_IAM/SecurityMenuBlade/~/CertificateAuthorities portálra és töltsük fel a Root (és esetleg az intermediate CA) tanúsitványunk publikus kulcsát. Töltsük ki a CRL endpoint URL-jét is.

Engedélyezzük a CBA-at a tenantban

Lépjünk be a https://portal.azure.com/#view/Microsoft_AAD_IAM/AuthenticationMethodsMenuBlade/~/AdminAuthMethods portálra és engedélyezzük a Certificate-based authenticationt.

Beállithatjuk az user csoportokat vagy minden usert is, a configure részben pedig maradhatunk az alapbeállitásoknál.

A többi opciót (single vs multi-factor authentication, rules) a következő posztban fogom részletezni.

Összefoglaló:

Áttekintettük, hogy mi az Azure CBA, hogyan működik és hogyan lehet alapszinten bekonfigurálni.

Certificate Authority felderítése

Biztosan sokan futottak már bele olyan problémába, hogy egy ügyfél rendszerébe belépve szükség lenne a Certification Authority kiszolgálók felderítésére (pláne ha az ügyfél nem is tudja hogy van CA-ja és hol…)

Az alábbi rövid parancs ilyenkor segít nekünk. Futtassuk le cmd-ből bármelyik domain member gépről:

certutil -config – -ping

Megkapjuk a működő CA-k nevét illetve szerverét:

OneDrive- hozzáférés megtagadva

Egy gyors esetleírás.

Környzetet: a felhasználók használják az OneDrive-ot, és a Desktop/Documents/Pictures mappa is oda van irányítva (lásd cikk: OneDrive mint felhasználói backup | Zoltan Istvanffy’s IT Blog (istvanffyzoltan.com)

A gépek Microsoft Endpoint Management-tel (Intune) menedzseltek, Windows Information Protection policy beállítva.

Hibajelenség: nem lehet új file-t létrehozni az OneDrive folderekben, hozzáférés megtagadva hibaüzenettel.

Megoldás:

A WIP-policyben meghatározott Data Recover Agent tanúsítványa lejárt.

Cseréljük ki a DRA tanúsítványt, és újra működőképes lesz az OneDrive.

Certificate érvényességi idejének módosítása

Kezdő CA-üzemeltetőként belefutottam egy problémába:

Szerettem volna egy tanúsítványt 5 évre kiadni. Megnéztem a template-ek között, átállítottam a Validity Periodot, Apply, OK

A tanúsítványt kiállítottam, jött a meglepetés: az érvényességi ideje bizony csak 2 év lett, nem 5.

A megoldás persze triviális volt: mivel ez a CA nem egy CAPolicy.inf file segítségével lett telepítve, alapból 2 év az érvényessége a kiadott certeknek.

Ezt módosítani így lehet:

A CA-n át kell írni a lenti registry kulcsot:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\CertSvc\Configuration\<CAName>

ValidityPeriod értéke legyen Years

ValidityPeriodUnits értéke pedig a kívánt érték, pl 5

Kell még egy:        net stop certsvc
net start certsvc

Eután ha kiadjuk a tansúítványt, immár 5 évre fog szólni az érvényessége.

Nem egy nagy dolog, de bosszantó tud lenni 🙂

Bitlocker titkosítás smart card segítségével

A feladat adott volt: Bitlocker titkosítás a smart cardon elhelyezett tanúsítvány segítségével.

Első lépésben a Bitlocker Recovery Agentet definiáltam volna, ezen cikk alapján:

http://blogs.technet.com/b/askcore/archive/2010/10/11/how-to-use-bitlocker-data-recovery-agent-to-unlock-bitlocker-protected-drives.aspx

A problémába ott ütköztem, hogy sehol nem találtam a kiemelt Extended Key Usage értékeket a CA szerveren, miközben a certificate template-et szerkesztettem:

A megoldás, hogy miként csalogassuk elő a hiányzó EKU-kat…a CA szerverre (illetve arra gépre, ahonnan a certificate template-eket szerkesztjük) telepíteni kell a Windows Feature-ök közül a Bitlocker Drive Encryption modult.

Parancssoros adminoknak:

ServerManagerCmd -install BitLocker -restart

A reboot után a kívánt EKU-k elérhetőek lesznek a certificate templateben.