Kerberos pour les développeurs : protocole et SSPI

Protocole Kerberos : Plongée en profondeur pour les développeurs

Kerberos résout le défi de l'usurpation d'identité : un service sur la machine A reçoit une requête d'un client distant et doit effectuer des opérations au nom de ce client, y compris l'accès aux ressources locales. Pour cela, un nouveau jeton d'accès est créé à partir des identifiants fournis. Sans Kerberos, le service utiliserait son propre jeton, bloquant l'accès aux fichiers nécessitant des privilèges élevés.

Dans un scénario de requêtes en chaîne, le service A requiert le service B. La délégation permet de choisir : usurper à partir de votre propre compte ou du client original. Kerberos transmet des tickets chiffrés contenant le SID de l'utilisateur, les groupes et le PAC (Certificat d'attributs de privilège).

Composants clés :

• Principal : une entité dotée d'un mot de passe (utilisateur, ordinateur, service).
• KDC (Centre de distribution de clés) : stocke les mots de passe, émet les TGT (Ticket d'octroi de tickets) et les tickets de service.
• SPN (Nom du principal de service) : identifiant de service, souvent associé au compte sous lequel le service s'exécute.

Kerberos distingue l'authentification de l'autorisation : le déchiffrement du ticket confirme l'identité, tandis que le jeton détermine les privilèges.

Structure des messages et transport

Les messages Kerberos utilisent ASN.1 (codage PER/DER selon la RFC 4120). Ils sont transmis via UDP/TCP sur le port 88. UDP convient aux paquets courts (TGT ~1-2 Ko), TCP pour les plus volumineux (avec PAC).

Le KDC dans Active Directory combine AS (Service d'authentification) et TGS (Service d'octroi de tickets). Les enregistrements SRV (_kerberos._tcp.<domaine>) pointent vers les contrôleurs de domaine.

Processus d'échange AS (Obtention du TGT) :

• Client → KDC : KRB_KDC_REQ (pré-authentification avec horodatage, chiffrée avec le mot de passe ou PKINIT).
• KDC → Client : KRB_KDC_REP (TGT, chiffré avec la clé à long terme du client ; clé de session dans la pré-authentification).
• Le client stocke le TGT dans LSA (Autorité de sécurité locale).

Échange TGS (Ticket de service) :

• Client → KDC : KRB_TGS_REQ (TGT + authentificateur + nom de service/SPN).
• KDC → Client : KRB_TGS_REP (ticket de service, clé de session de service).

L'AP-REQ (avec ticket de service) est encapsulé dans LDAP, HTTP Negotiate, SMB, RPC. Wireshark affiche GSS-WRAP avec jeton NTLM/Kerberos.

Chiffrement et clés

Le mot de passe est haché pour former une clé à long terme (AES-256-CTS sous Windows). Les clés de session sont temporaires, utilisées pour protéger les messages.

Exemple de code C++ pour le chiffrement AES Kerberos à l'aide de 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
    // Full code omitted for brevity

    BCryptCloseAlgorithmProvider(hAlg, 0);
    return status;
}

Le code démontre la configuration d'AES en mode CTS (Cipher Text Stealing), spécifique à Kerberos.

Types de délégation et tests

Kerberos prend en charge la délégation contrainte et non contrainte.

Options de délégation :

• Simple : aucune délégation (le service ne transmet pas les identifiants plus loin).
• Non contrainte : transfert complet du TGT (risqué, déprécié).
• Contrainte : S4U2Proxy — ticket de service uniquement pour SPN spécifié.
• Contrainte basée sur les ressources : côté service (Windows Server 2012+).

Tests sur une machine unique : utilisez klist, AcquireCredentialsHandle avec SSPI. Exemple pour U2U (User-to-User) :

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

Pour PKINIT : transmettez un certificat X.509 à AcquireCredentialsHandle avec SECPKG_CRED_CERTIFICATE. GSS-API est un wrapper pour SSPI sous Windows.

Authentification inter-domaines et SPN

Les comptes de confiance (nom = domaine) activent l'authentification inter-domaines. Un client du domaine A demande un TGT pour le principal de confiance dans le domaine B.

L'SPN n'a pas de mot de passe — il identifie l'hôte/utilisateur. Les SPN dupliqués pointent vers un principal unique. Le système détermine le type par le format : host/<fqdn>, HTTP/<fqdn>.

Gestion de plusieurs identifiants :

• ImpersonateHandleExplicit avec ouverture de session.
• Politique LSA pour SPN multi-utilisateur.
• Accepteur GSS personnalisé avec vérification de plusieurs clés.

Points clés

• Kerberos est la couche GSS-API pour l'authentification unique dans AD ; les tickets contiennent le PAC avec SIDs/groupes.
• La délégation est cruciale pour backend-à-backend ; contrainte minimise les risques.
• Testez SSPI : 3-5 lignes pour AcquireCredentialsHandle au lieu de code boilerplate.
• PKINIT et U2U étendent les scénarios sans mot de passe.
• ASN.1 + AES-CTS est le cœur du protocole ; surveillez dans Wireshark sur le port 88.

— Editorial Team