Kerberos dla deweloperów: protokół i SSPI

# Protokół Kerberos: głęboka analiza dla programistów

Kerberos rozwiązuje problem impersonation: usługa na maszynie A otrzymuje żądanie od zdalnego klienta i musi wykonać operacje w imieniu tego klienta, w tym dostęp do lokalnych zasobów. W tym celu tworzony jest nowy access token na podstawie dostarczonych credentials. Bez Kerberos usługa używałaby własnego tokenu, co blokowałoby dostęp do plików wymagających podwyższonych uprawnień.

W scenariuszu z chained requests usługa A żąda usługi B. Delegacja pozwala wybrać: impersonation z własnego konta lub od pierwotnego klienta. Kerberos przekazuje zaszyfrowane bilety (tickets), zawierające SID użytkownika, grupy i PAC (Privilege Attribute Certificate).

Kluczowe komponenty:

• Principal: podmiot z hasłem (użytkownik, komputer, usługa).
• KDC (Key Distribution Center): przechowuje hasła, wystawia TGT (Ticket Granting Ticket) i bilety usług.
• SPN (Service Principal Name): identyfikator usługi, często wskazujący na konto, pod którym uruchomiona jest usługa.

Kerberos odróżnia uwierzytelnianie od autoryzacji: odszyfrowanie biletu potwierdza tożsamość, token określa uprawnienia.

Struktura wiadomości i transport

Wiadomości Kerberos wykorzystują ASN.1 (PER/DER encoding wg RFC 4120). Przesyłane przez UDP/TCP na porcie 88. UDP nadaje się do krótkich pakietów (TGT ~1-2 KB), TCP — do dużych (z PAC).

KDC w Active Directory łączy AS (Authentication Service) i TGS (Ticket Granting Service). Wpisy SRV (_kerberos._tcp.<domain>) wskazują na kontrolery domeny.

Proces AS-Exchange (uzyskanie TGT):

• Client → KDC: KRB_KDC_REQ (pre-auth z timestampem, zaszyfrowanym hasłem lub PKINIT).
• KDC → Client: KRB_KDC_REP (TGT, zaszyfrowany kluczem długoterminowym klienta; session key w pre-auth).
• Client przechowuje TGT w LSA (Local Security Authority).

TGS-Exchange (bilet usługi):

• Client → KDC: KRB_TGS_REQ (TGT + authenticator + nazwa usługi/SPN).
• KDC → Client: KRB_TGS_REP (bilet usługi, session key usługi).

AP-REQ (z biletem usługi) enkapsulowany w LDAP, HTTP Negotiate, SMB, RPC. Wireshark pokazuje: GSS-WRAP z tokenem NTLM/Kerberos.

Szyfrowanie i klucze

Hasło jest haszowane do klucza długoterminowego (AES-256-CTs dla Windows). Session keys — tymczasowe, do ochrony wiadomości.

Przykład kodu C++ do szyfrowania AES Kerberos z CNG (Cryptography API: Next Generation):

#include <windows.h>
#include <ncrypt.h>
#include <ntstatus.h>

NTSTATUS EncryptKerberosAES(
    PUCHAR key, ULONG keyLen,
    PUCHAR plaintext, ULONG ptLen,
    PUCHAR* ciphertext, ULONG* ctLen) {
    NCRYPT_ALG_HANDLE hAlg = NULL;
    BCRYPT_KEY_HANDLE hKey = NULL;
    NTSTATUS status;

    status = BCryptOpenAlgorithmProvider(&hAlg, BCRYPT_AES_ALGORITHM, NULL, 0);
    if (!NT_SUCCESS(status)) return status;

    status = BCryptSetProperty(hAlg, BCRYPT_CHAINING_MODE, (PUCHAR)BCRYPT_CHAIN_MODE_CTS, sizeof(BCRYPT_CHAIN_MODE_CTS), 0);
    // Kerberos uses AES-CTS

    status = BCryptGenerateSymmetricKey(hAlg, &hKey, NULL, 0, key, keyLen);
    // ... encrypt logic with IV from Kerberos spec
    // Polnyy code oprzegapen for kratkosti

    BCryptCloseAlgorithmProvider(hAlg, 0);
    return status;
}

Kod demonstruje konfigurację AES w trybie CTS (Cipher Text Stealing), specyficznym dla Kerberos.

Typy delegacji i testowanie

Kerberos obsługuje constrained i unconstrained delegation.

Warianty delegacji:

• Simple: bez delegacji (usługa nie przekazuje credentials dalej).
• Unconstrained: pełne przekierowanie TGT (ryzykowne, przestarzałe).
• Constrained: S4U2Proxy — bilet usługi tylko dla wskazanych SPN.
• Resource-based constrained: po stronie usługi (Windows Server 2012+).

Testowanie na jednej maszynie: użyj klist, AcquireCredentialsHandle z SSPI. Przykład dla U2U (User-to-User):

CredHandle cred;
TimeStamp expiry;
AcquireCredentialsHandle(NULL, L"Kerberos", SECPKG_CRED_OUTBOUND, NULL, NULL, NULL, NULL, &cred, &expiry);
// U2U: impersonate bez KDC, directlyy exchange

Dla PKINIT: przekazanie certyfikatu X.509 w AcquireCredentialsHandle z SECPKG_CRED_CERTIFICATE. GSS-API — wrapper dla SSPI w Windows.

Międzydomenowa autentykacja i SPN

Trust accounts (nazwa = domena) umożliwiają cross-domain. Client z domeny A żąda TGT dla trust principal w domenie B.

SPN nie ma hasła — identyfikuje host/użytkownika. Duplikaty SPN wskazują na jednego principal. System określa typ po formacie: host/<fqdn>, HTTP/<fqdn>.

Zarządzanie wieloma credentials:

• ImpersonateHandleExplicit z logowaniem.
• Polityka LSA dla wieloużytkownikowych SPN.
• Niestandardowy GSS acceptor z weryfikacją wielu kluczy.

Co ważne

• Kerberos — warstwa GSS-API dla single sign-on w AD; bilety zawierają PAC z SID/grupami.
• Delegacja kluczowa dla backend-to-backend; constrained minimalizuje ryzyka.
• Testuj SSPI: 3-5 linii dla AcquireCredentialsHandle zamiast boilerplate.
• PKINIT i U2U rozszerzają scenariusze bez hasła.
• ASN.1 + AES-CTs — rdzeń protokołu; monitoruj w Wireshark po porcie 88.

— Editorial Team