Accueil
Actualités Professionnelles
Configuration du protocole d’authentification Kerberos

Configuration du protocole d’authentification Kerberos

Nommer d’après un chien à trois têtes gardant les portes des Enfers dans les mythes grecs anciens, le protocole Kerberos offre un service d’authentification sécurisé pour les réseaux informatiques. Il réalise une authentification mutuelle entre l’utilisateur et le serveur à l’aide d’un Centre de Distribution de Clés (KDC) tiers de confiance qui fournit un service d’authentification et de délivrance de tickets. Tous les principaux systèmes d’exploitation, y compris Microsoft Windows, Linux, Apple OS X et FreeBSD, prennent en charge le protocole Kerberos.

Les messages du protocole Kerberos sont protégés contre les attaques par rejeu et les écoutes par le biais de la cryptographie à clé secrète partagée. Le principal objectif de Kerberos est d’éviter la transmission de mots de passe cryptés sur le réseau. Il élimine la menace des sniffers de paquets et renforce la sécurité globale du réseau.

Bien que le fournisseur de support de sécurité Kerberos traite efficacement les menaces de sécurité graves, sa mise en œuvre peut s’avérer difficile en raison d’une variété de limitations :

Si le serveur Kerberos est en panne, les utilisateurs ne peuvent pas se connecter. Le problème peut être résolu en utilisant des mécanismes d’authentification de secours et plusieurs serveurs Kerberos.
Les horloges des hôtes impliqués doivent être synchronisées. Sinon, l’authentification échouera, car les tickets Kerberos ont une période de validité limitée.
Kerberos ne peut pas être utilisé lorsque les utilisateurs souhaitent se connecter à des services depuis des systèmes non fiables.
En cas d’utilisation de la cryptographie symétrique, la compromission de l’infrastructure d’authentification permettra à un attaquant d’usurper l’identité de n’importe quel utilisateur.
Chaque service réseau nécessitant un nom d’hôte différent aura besoin de son propre ensemble de clés Kerberos.

Comment fonctionne l’authentification Kerberos

Un Centre de Distribution de Clés se compose d’un serveur d’authentification (AS) et d’un serveur de délivrance de tickets (TGS). TGT est un ticket de délivrance de tickets.

L’utilisateur saisit le login et le mot de passe. L’ID utilisateur en clair va au serveur d’authentification (AS) avec une demande de services au nom de l’utilisateur.
AS vérifie si le login de l’utilisateur est dans la base de données. Si des informations sur cet utilisateur sont disponibles, alors AS peut générer une clé secrète client selon l’ID et le mot de passe de l’utilisateur. AS envoie à l’utilisateur :
- La clé de session client/TSG (cryptée avec la clé secrète client) ;
- TGT incluant l’ID utilisateur, l’adresse réseau et la période de validité du ticket + clé de session client/TGS (cryptée avec la clé secrète TGS).
L’utilisateur décode le premier message mais ne peut pas décoder le second, car il ne possède pas la clé secrète TGS. Le client envoie un message à TGS :
- Le TGT reçu de AS + l’ID serveur + clé secrète TGS/client (cryptée avec la clé secrète TGS) ;
- L’authentificateur incluant l’ID client et l’horodatage (crypté avec la clé de session client/TSG).
TGS décrypte le premier message, obtient le TGT + clé de session TGS/client, avec laquelle il décrypte le second message. TGS vérifie si l’ID utilisateur du premier message correspond à l’ID du second message et si l’horodatage ne dépasse pas la période de validité du ticket. Dans le cas où tout est correct, TGS envoie à l’utilisateur :
- L’ID utilisé, l’adresse réseau, la période de validation du ticket + clé de session client/serveur (cryptée avec la clé secrète du serveur) ;
- La clé de session client/serveur (cryptée avec la clé secrète client/TGS).
Le client envoie les éléments suivants au serveur auquel il tente d’accéder :
- L’ID utilisé, l’adresse réseau, la période de validation du ticket + clé de session client/serveur (cryptée avec la clé secrète du serveur) ;
- L’authentificateur incluant l’ID et l’horodatage (crypté avec la clé de session client/serveur).
Le serveur cible déchiffre les messages de l’utilisateur, vérifie si l’ID utilisateur des deux messages a la même valeur et si la période de validité n’est pas dépassée, puis envoie au client le paramètre suivant pour confirmer son identité :
- Horodatage + 1 (crypté avec la clé de session client/serveur).

Le client vérifie si la valeur de l’horodatage est horodatage + 1, ce qui montre la véritable identité du serveur. Si c’est le cas, le client peut faire confiance au serveur et commencer à travailler avec lui.

Applications modernes de Kerberos

Kerberos reste vital dans les environnements d’entreprise d’aujourd’hui. Les fournisseurs de services cloud intègrent Kerberos avec leurs services d’identité. L’authentification multifactorielle renforce la posture de sécurité de Kerberos. Les solutions de connexion unique utilisent Kerberos pour un accès fluide. De nombreuses applications conteneurisées prennent en charge l’authentification Kerberos. Les pipelines DevOps utilisent Kerberos pour des workflows CI/CD sécurisés. Les systèmes de gestion des appareils mobiles incorporent les principes de Kerberos. Les architectures Zero Trust s’appuient souvent sur les bases de Kerberos. Les solutions d’identité fédérée étendent Kerberos au-delà des frontières organisationnelles. La gestion automatique des certificats simplifie la maintenance de Kerberos. Les implémentations modernes répondent à de nombreuses limitations traditionnelles de Kerberos.

Configurer le protocole d’authentification Kerberos

Pour configurer le protocole Kerberos, vous devez effectuer les opérations suivantes :

Créer un utilisateur Active Directory (vous pouvez en utiliser un existant à la place).
- Connectez-vous au serveur contrôleur de domaine, cliquez sur Démarrer → Outils d’administration, et lancez Utilisateurs et ordinateurs Active Directory.
- Si ce n’est pas déjà sélectionné, cliquez sur le nœud de votre domaine (domain.com).
- Faites un clic droit sur Utilisateurs, pointez sur Nouveau, puis cliquez sur Utilisateur.
- Dans la boîte de dialogue Nouvel Objet → Utilisateur, spécifiez les paramètres du nouvel utilisateur. Il peut s’agir d’un utilisateur régulier, il n’est pas nécessaire de fournir à l’utilisateur des privilèges supplémentaires. Le compte utilisateur doit être actif (la case Compte désactivé décochée), et le mot de passe pour le compte doit être perpétuel (la case Le mot de passe n’expire jamais cochée).

Attribuer les noms principaux avec les clés cryptées sur la machine contrôleur de domaine. Pour les machines sous Linux, créez un fichier keytab contenant des paires de noms principaux Kerberos et de clés cryptées. Un fichier keytab est utilisé pour s’authentifier sur différents systèmes distants à l’aide de Kerberos sans entrer de mot de passe.

Créer un keytab avec la première entrée en utilisant l’outil ktpass :

ktpass /princ user1_backend@DOMAIN.COM /mapuser user1_backend /pass  /crypto all /ptype KRB5_NT_PRINCIPAL /out C:\Users\user1\Desktop\datasunrise.keytab -setupn

/princ	Le nom du principal de service (SPN) au format suivant : @
/mapuser	Mappe le nom du principal Kerberos, spécifié par le paramètre princ, sur le compte de domaine spécifié.
/pass	Spécifie le mot de passe pour le nom d’utilisateur principal.
/ptype	Spécifie le type de principal. Utilisez KRB5_NT_PRINCIPAL.
/crypto	Spécifie les clés qui sont générées dans le fichier keytab.
/out	Attribuez un répertoire et un nom pour le fichier de sortie *.keytab.
-setupn	N’attribue pas le nom principal de l’utilisateur en même temps que le nom principal de service.

Créer une deuxième entrée dans le fichier keytab pour se connecter à la base de données en utilisant l’utilisateur Active Directory (AD). L’exemple donné est pour la création d’entrées keytab pour se connecter à une base de données Vertica à l’aide de l’utilisateur AD. Pour d’autres bases de données ou authentifications GUI, exécutez la même commande avec le nom de service correspondant dans le paramètre /princ. ktpass /out ./datasunrise.keytab /princ vertica/user1.domain.com@DOMAIN.COM /mapuser user1 /mapop set /pass /ptype KRB5_NT_PRINCIPAL /crypto RC4-HMAC-NT
Vous devrez transférer le fichier keytab sur la machine Linux.

Configurer la délégation Active Directory.
- Sur la machine contrôleur de domaine, allez dans Utilisateurs et ordinateurs Active Directory, localisez le compte de la machine que vous souhaitez configurer pour Kerberos.
- Dans la section Propriétés, allez à l’onglet Délégation et sélectionnez Faire confiance à cet ordinateur pour la délégation vers les services spécifiés uniquement puis cliquez sur Ajouter.
- Dans la fenêtre Utilisateurs et ordinateurs, spécifiez le compte utilisateur utilisé pour démarrer la base de données ou le nom du serveur où le SGBDR est installé.
- Optionnellement, vous pouvez utiliser Vérifier les noms pour vérifier si un utilisateur ou un ordinateur spécifié existe et cliquez sur OK, puis sélectionnez le service requis et cliquez sur OK.

Installer et configurer le client Kerberos sur votre machine. sudo apt-get install krb5-user libpam-krb5 libpam-ccreds auth-client-config

Modifiez le fichier /etc/krb5.conf pour ajouter le nom de domaine complet, le nom du contrôleur de domaine et le paramètre realm

Important : N’incluez aucun commentaire marqué par le signe “#” dans le fichier de configuration.

[libdefaults]
    default_realm       =           DOMAIN.COM    # paramètre spécifique au domaine (nom de domaine complet)
    clockskew           =           300
    ticket_lifetime     =           1d
    forwardable         =           true
    proxiable           =           true
    dns_lookup_realm    =           true
    dns_lookup_kdc      =           true

[realms]
    DOMAIN.COM = {
    kdc            =       hostname.domain.com   # paramètre spécifique au domaine (nom du contrôleur de domaine)
    admin_server   =       hostname.domain.com   # paramètre spécifique au domaine (nom du contrôleur de domaine)
    default_domain =       DOMAIN.COM            # paramètre spécifique au domaine (nom de domaine complet)
    }

[domain_realm]
    .domain.com = DOMAIN.COM  # paramètre spécifique au domaine (nom de domaine pour les noms DNS)
    domain.com = DOMAIN.COM   # paramètre spécifique au domaine (nom de domaine pour les noms DNS)

[appdefaults]
    pam = {
    ticket_lifetime         = 1d
    renew_lifetime          = 1d
    forwardable             = true
    proxiable               = false
    retain_after_close      = false
    minimum_uid             = 0
    debug                   = false
    }

Pour les machines sous Windows, il n’est pas nécessaire d’installer et de configurer le protocole Kerberos mais elles doivent être dans le domaine Active Directory. De plus, pour définir les noms principaux de service, la commande setspn est utilisée. Voici un exemple de configuration d’une machine Windows pour se connecter à la base de données MS SQL Server en utilisant les identifiants utilisateur AD.

L’adresse proxy doit correspondre au SPN enregistré pour le service MSSQLSvc. Utilisez l’outil SetSPN pour enregistrer les deux SPN requis pour le compte de l’ordinateur, pour lequel vous avez autorisé la délégation :

setspn -A MSSQLSvc/proxy-host:proxy-port proxy-host
setspn -A MSSQLSvc/full-fqdn-proxy-host:proxy-port proxy-host

La liste de tous les SPN enregistrés peut être obtenue avec la commande suivante :

setspn -L proxy-host

Pour supprimer le proxy SPN, faites ce qui suit :

setspn -D MSSQLSvc/proxy-host:proxy-port proxy-host

Pour tester le schéma d’autorisation, exécutez la commande suivante après vous être connecté au serveur :

select auth_scheme from sys.dm_exec_connections where session_id=@@spid

Le résultat correspondra au schéma d’authentification utilisé par le serveur : SQL, NTLM ou KERBEROS.

Si vous obtenez l’erreur “Cannot generate SSPI context”, reportez-vous aux instructions de support Microsoft pour savoir comment résoudre le problème avec l’interface de support de sécurité.

DataSunrise peut fonctionner comme un proxy d’authentification pour les bases de données cloud et sur site afin de minimiser les risques d’accès non autorisé aux utilisateurs tout en maintenant les politiques d’authentification de Microsoft Active Directory et du protocole Kerberos.

Votre base de données ou stockage basé sur le cloud contient-il des informations sensibles nécessitant une protection ? Avez-vous besoin de vous conformer aux réglementations GDPR, SOX ou HIPAA ? Découvrez les solutions de pointe de DataSunrise pour l’audit des bases de données, la sécurité et le masquage des données. Essayez notre logiciel gratuitement ou planifiez une démo en ligne dès aujourd’hui.