AD Certificates

Reading time: 9 minutes

Wprowadzenie

Składniki certyfikatu

• Podmiot certyfikatu oznacza jego właściciela.
• Klucz publiczny jest sparowany z kluczem prywatnym, aby powiązać certyfikat z jego prawowitym właścicielem.
• Okres ważności, określony przez daty NotBefore i NotAfter, oznacza czas obowiązywania certyfikatu.
• Unikalny Numer seryjny, dostarczony przez Urząd Certyfikacji (CA), identyfikuje każdy certyfikat.
• Wydawca odnosi się do CA, który wydał certyfikat.
• SubjectAlternativeName pozwala na dodatkowe nazwy dla podmiotu, zwiększając elastyczność identyfikacji.
• Podstawowe ograniczenia identyfikują, czy certyfikat jest dla CA czy podmiotu końcowego oraz definiują ograniczenia użytkowania.
• Rozszerzone zastosowania kluczy (EKU) określają konkretne cele certyfikatu, takie jak podpisywanie kodu czy szyfrowanie e-maili, za pomocą identyfikatorów obiektów (OID).
• Algorytm podpisu określa metodę podpisywania certyfikatu.
• Podpis, stworzony za pomocą klucza prywatnego wydawcy, gwarantuje autentyczność certyfikatu.

Specjalne uwagi

• Nazwy alternatywne podmiotu (SAN) rozszerzają zastosowanie certyfikatu na wiele tożsamości, co jest kluczowe dla serwerów z wieloma domenami. Bezpieczne procesy wydawania są niezbędne, aby uniknąć ryzyka podszywania się przez atakujących manipulujących specyfikacją SAN.

Urzędy Certyfikacji (CA) w Active Directory (AD)

AD CS uznaje certyfikaty CA w lesie AD poprzez wyznaczone kontenery, z których każdy pełni unikalne role:

• Kontener Certification Authorities przechowuje zaufane certyfikaty root CA.
• Kontener Enrolment Services zawiera szczegóły dotyczące Enterprise CA i ich szablonów certyfikatów.
• Obiekt NTAuthCertificates zawiera certyfikaty CA autoryzowane do uwierzytelniania AD.
• Kontener AIA (Authority Information Access) ułatwia walidację łańcucha certyfikatów z certyfikatami CA pośrednimi i krzyżowymi.

Pozyskiwanie certyfikatu: Proces żądania certyfikatu klienta

1. Proces żądania rozpoczyna się od znalezienia przez klientów Enterprise CA.
2. Tworzony jest CSR, zawierający klucz publiczny i inne szczegóły, po wygenerowaniu pary kluczy publiczno-prywatnych.
3. CA ocenia CSR w odniesieniu do dostępnych szablonów certyfikatów, wydając certyfikat na podstawie uprawnień szablonu.
4. Po zatwierdzeniu, CA podpisuje certyfikat swoim kluczem prywatnym i zwraca go do klienta.

Szablony certyfikatów

Zdefiniowane w AD, te szablony określają ustawienia i uprawnienia do wydawania certyfikatów, w tym dozwolone EKU oraz prawa do rejestracji lub modyfikacji, co jest kluczowe dla zarządzania dostępem do usług certyfikacyjnych.

Rejestracja certyfikatu

Proces rejestracji certyfikatów inicjuje administrator, który tworzy szablon certyfikatu, który następnie jest publikowany przez Enterprise Certificate Authority (CA). Umożliwia to klientom rejestrację, co osiąga się poprzez dodanie nazwy szablonu do pola certificatetemplates obiektu Active Directory.

Aby klient mógł zażądać certyfikatu, muszą być przyznane prawa rejestracji. Prawa te są określone przez deskryptory zabezpieczeń na szablonie certyfikatu oraz samym Enterprise CA. Uprawnienia muszą być przyznane w obu lokalizacjach, aby żądanie mogło być skuteczne.

Prawa rejestracji szablonów

Prawa te są określone za pomocą wpisów kontroli dostępu (ACE), szczegółowo opisujących uprawnienia, takie jak:

• Prawa Certificate-Enrollment i Certificate-AutoEnrollment, każde związane z określonymi GUID.
• ExtendedRights, pozwalające na wszystkie rozszerzone uprawnienia.
• FullControl/GenericAll, zapewniające pełną kontrolę nad szablonem.

Prawa rejestracji Enterprise CA

Prawa CA są określone w jego deskryptorze zabezpieczeń, dostępnym za pośrednictwem konsoli zarządzania Urzędem Certyfikacji. Niektóre ustawienia pozwalają nawet użytkownikom o niskich uprawnieniach na zdalny dostęp, co może stanowić zagrożenie dla bezpieczeństwa.

Dodatkowe kontrole wydawania

Mogą obowiązywać pewne kontrole, takie jak:

• Zatwierdzenie menedżera: Umieszcza żądania w stanie oczekiwania do zatwierdzenia przez menedżera certyfikatów.
• Agenci rejestracji i autoryzowane podpisy: Określają liczbę wymaganych podpisów na CSR oraz niezbędne identyfikatory polityki aplikacji OID.

Metody żądania certyfikatów

Certyfikaty można żądać za pośrednictwem:

1. Windows Client Certificate Enrollment Protocol (MS-WCCE), używając interfejsów DCOM.
2. ICertPassage Remote Protocol (MS-ICPR), przez potoki nazwane lub TCP/IP.
3. interfejsu internetowego rejestracji certyfikatów, z zainstalowaną rolą Web Enrollment Urzędu Certyfikacji.
4. Usługi rejestracji certyfikatów (CES), w połączeniu z usługą polityki rejestracji certyfikatów (CEP).
5. Usługi rejestracji urządzeń sieciowych (NDES) dla urządzeń sieciowych, używając prostego protokołu rejestracji certyfikatów (SCEP).

Użytkownicy systemu Windows mogą również żądać certyfikatów za pośrednictwem GUI (certmgr.msc lub certlm.msc) lub narzędzi wiersza poleceń (certreq.exe lub polecenia Get-Certificate PowerShell).

# Example of requesting a certificate using PowerShell
Get-Certificate -Template "User" -CertStoreLocation "cert:\\CurrentUser\\My"

Uwierzytelnianie za pomocą certyfikatów

Active Directory (AD) obsługuje uwierzytelnianie za pomocą certyfikatów, głównie wykorzystując protokoły Kerberos i Secure Channel (Schannel).

Proces uwierzytelniania Kerberos

W procesie uwierzytelniania Kerberos, żądanie użytkownika o Ticket Granting Ticket (TGT) jest podpisywane za pomocą klucza prywatnego certyfikatu użytkownika. To żądanie przechodzi przez kilka weryfikacji przez kontroler domeny, w tym ważność, ścieżkę i status unieważnienia certyfikatu. Weryfikacje obejmują również potwierdzenie, że certyfikat pochodzi z zaufanego źródła oraz potwierdzenie obecności wystawcy w sklepie certyfikatów NTAUTH. Pomyślne weryfikacje skutkują wydaniem TGT. Obiekt NTAuthCertificates w AD, znajdujący się pod adresem:

CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=<domain>,DC=<com>

jest kluczowe dla ustanowienia zaufania w przypadku uwierzytelniania certyfikatów.

Uwierzytelnianie Secure Channel (Schannel)

Schannel ułatwia bezpieczne połączenia TLS/SSL, gdzie podczas handshake klient przedstawia certyfikat, który, jeśli zostanie pomyślnie zweryfikowany, upoważnia do dostępu. Mapowanie certyfikatu do konta AD może obejmować funkcję Kerberos S4U2Self lub Subject Alternative Name (SAN) certyfikatu, między innymi metody.

Enumeracja usług certyfikatów AD

Usługi certyfikatów AD można enumerować za pomocą zapytań LDAP, ujawniając informacje o Enterprise Certificate Authorities (CAs) i ich konfiguracjach. Jest to dostępne dla każdego użytkownika uwierzytelnionego w domenie bez specjalnych uprawnień. Narzędzia takie jak Certify i Certipy są używane do enumeracji i oceny podatności w środowiskach AD CS.

Polecenia do korzystania z tych narzędzi obejmują:

# Enumerate trusted root CA certificates and Enterprise CAs with Certify
Certify.exe cas
# Identify vulnerable certificate templates with Certify
Certify.exe find /vulnerable

# Use Certipy (>=4.0) for enumeration and identifying vulnerable templates
certipy find -vulnerable -dc-only -u john@corp.local -p Passw0rd -target dc.corp.local

# Request a certificate over the web enrollment interface (new in Certipy 4.x)
certipy req -web -target ca.corp.local -template WebServer -upn john@corp.local -dns www.corp.local

# Enumerate Enterprise CAs and certificate templates with certutil
certutil.exe -TCAInfo
certutil -v -dstemplate

Ostatnie podatności i aktualizacje zabezpieczeń (2022-2025)

Harmonogram wzmocnienia Microsoftu (KB5014754)

Microsoft wprowadził trzyetapowe wdrożenie (Kompatybilność → Audyt → Egzekwowanie), aby przenieść uwierzytelnianie certyfikatów Kerberos z słabych mapowań domyślnych. Od 11 lutego 2025, kontrolery domeny automatycznie przełączają się na Pełne Egzekwowanie, jeśli wartość rejestru StrongCertificateBindingEnforcement nie jest ustawiona. Administratorzy powinni:

1. Zainstalować łatki na wszystkich DC i serwerach AD CS (maj 2022 lub później).
2. Monitorować identyfikatory zdarzeń 39/41 w poszukiwaniu słabych mapowań podczas fazy Audytu.
3. Ponownie wydać certyfikaty uwierzytelniające klientów z nowym rozszerzeniem SID lub skonfigurować silne mapowania ręczne przed lutym 2025.

Ulepszenia wykrywania i wzmocnienia

• Defender for Identity AD CS sensor (2023-2024) teraz przedstawia oceny postawy dla ESC1-ESC8/ESC11 i generuje powiadomienia w czasie rzeczywistym, takie jak “Wydanie certyfikatu kontrolera domeny dla nie-DC” (ESC8) oraz “Zapobiegaj rejestracji certyfikatów z dowolnymi politykami aplikacji” (ESC15). Upewnij się, że czujniki są wdrożone na wszystkich serwerach AD CS, aby skorzystać z tych wykryć.
• Wyłącz lub ściśle ogranicz opcję “Dostarcz w żądaniu” we wszystkich szablonach; preferuj wyraźnie zdefiniowane wartości SAN/EKU.
• Usuń Jakikolwiek cel lub Brak EKU z szablonów, chyba że jest to absolutnie konieczne (dotyczy scenariuszy ESC2).
• Wymagaj zatwierdzenia menedżera lub dedykowanych przepływów pracy Agenta Rejestracji dla wrażliwych szablonów (np. WebServer / CodeSigning).
• Ogranicz dostęp do rejestracji internetowej (certsrv) oraz punktów końcowych CES/NDES do zaufanych sieci lub za uwierzytelnianiem certyfikatu klienta.
• Wymuś szyfrowanie rejestracji RPC (certutil –setreg CA\InterfaceFlags +IF_ENFORCEENCRYPTICERTREQ), aby złagodzić ESC11.

Odnośniki

• https://www.specterops.io/assets/resources/Certified_Pre-Owned.pdf
• https://comodosslstore.com/blog/what-is-ssl-tls-client-authentication-how-does-it-work.html
• https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16
• https://advisory.eventussecurity.com/advisory/critical-vulnerability-in-ad-cs-allows-privilege-escalation/