Accueil
Actualités Professionnelles
Configurer le Protocole d’Authentification Kerberos

Configurer le Protocole d’Authentification Kerberos

Nomé d’après un chien à trois têtes gardant les portes de l’Hadès dans les mythes grecs anciens, le protocole Kerberos fournit un service d’authentification sécurisé pour les réseaux informatiques. Il effectue une authentification mutuelle entre l’utilisateur et le serveur avec 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 systèmes d’exploitation majeurs, y compris Microsoft Windows, Linux, Apple OS X et FreeBSD, supportent le protocole Kerberos.

Les messages du protocole Kerberos sont protégés contre les attaques de répétition et l’écoute clandestine par le biais de la cryptographie à clé partagée. Le but principal de Kerberos est d’éviter la transmission de mots de passe cryptés sur le réseau. Il élimine la menace des renifleurs de paquets et améliore la sécurité globale du réseau.

Bien que le fournisseur de support de sécurité de Kerberos traite efficacement les menaces de sécurité graves, il peut être difficile à mettre en œuvre en raison de diverses limitations :

Si le serveur Kerberos est hors service, 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 certaine période de validité.
Kerberos ne peut pas être utilisé lorsque les utilisateurs souhaitent se connecter à des services à partir de systèmes non fiables.
En cas d’utilisation de la cryptographie symétrique, la compromission de l’infrastructure d’authentification permettra à un attaquant de se faire passer pour n’importe quel utilisateur.
Chaque service réseau nécessitant un nom d’hôte différent aura besoin de sa propre série 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). Le TGT est un Ticket Granting Ticket.

L’utilisateur entre le login et le mot de passe. L’identifiant utilisateur en clair est envoyé au Serveur d’Authentification (AS) avec une demande de services pour le compte 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 existent, 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 n’a pas la clé secrète TSG. Le client envoie un message au TGS :
- Le TGT reçu d’AS + ID du 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).
Le TGS décrypte le premier message, obtient le TGT + clé de session TGS/Client, avec lequel il décrypte le second message. Le 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. Si tout est correct, le TSG 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 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écrypte 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.

Configurer le protocole d’authentification Kerberos

Pour configurer le protocole Kerberos, vous devez faire ce qui suit :

Créer un utilisateur Active Directory (vous pouvez en utiliser un existant).
- Connectez-vous au serveur de contrôleur de domaine, cliquez sur Start → Administrative Tools, et lancez Active Directory Users and Computers.
- Si ce n’est pas déjà sélectionné, cliquez sur le nœud de votre domaine (domain.com).
- Cliquez avec le bouton droit sur Users, pointez sur New, puis cliquez sur User.
- Dans la boîte de dialogue New Object → User, spécifiez les paramètres du nouvel utilisateur. Il pourrait s’agir d’un utilisateur régulier, il n’est pas nécessaire de lui attribuer des privilèges supplémentaires. Le compte utilisateur doit être actif (la case Account is disabled ne doit pas être cochée), et le mot de passe du compte doit être perpétuel (la case Password never expires doit être cochée).

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

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

ktpass /princ [email protected] /mapuser user1_backend /pass  /crypto all /ptype KRB5_NT_PRINCIPAL /out C:\Users\user1\Desktop \datasunrise.keytab -setupn

/princ	Le nom de principal de service (SPN) au format suivant : @
/mapuser	Mappe le nom du principal Kerberos, qui est spécifié par le paramètre princ, au 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	Attribuer un répertoire et un nom pour le fichier *.keytab de sortie.
-setupn	Ne définit pas le nom de principal utilisateur avec le nom de 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 AD. L’exemple donné est pour créer des entrées de keytab pour se connecter à la base de données Vertica en utilisant l’utilisateur AD. Pour d’autres bases de données ou l’authentification via l’interface graphique, exécutez la même commande avec le nom de service correspondant dans le paramètre /princ. ktpass /out ./datasunrise.keytab /princ vertica/[email protected] /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 sur Active Directory Users and Computers, 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 Trust this computer for delegation to specified services only et cliquez sur Add.
- Dans la fenêtre Users and Computers, spécifiez le compte utilisateur qui a été utilisé pour lancer la base de données ou le nom du serveur où le SGBDR est installé.
- Optionnellement, vous pouvez utiliser Check names 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

Éditez 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 : Ne laissez aucun commentaire marqué par le signe “#” dans le fichier de configuration.

[libdefaults]
    default_realm       =           DOMAIN.COM    # paramètre spécifique au domaine (nom complet du domaine)
    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 complet du domaine)
        }
 
[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 OS, il n’est pas nécessaire d’installer et de configurer le protocole Kerberos, mais il doit ê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 de l’utilisateur AD.

L’adresse du proxy doit correspondre au SPN enregistré du 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 par la commande suivante :

setspn -L proxy-host

Pour supprimer le SPN proxy, 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.

En cas d’erreur “Cannot generate SSPI context”, référez-vous aux instructions de support Microsoft pour savoir comment résoudre le problème avec l’interface fournisseur 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é des utilisateurs tout en maintenant les politiques d’authentification de Microsoft Active Directory et du protocole Kerberos.

Votre base de données ou votre stockage 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, la sécurité, et le masquage des données. Essayez notre logiciel gratuitement ou planifiez une démo en ligne dès aujourd’hui.