La Configuration du Pare-feu pour le Protocole d’Authentification Kerberos

Nomé d’après Cerbère, le chien à trois têtes gardant les portes des enfers dans les mythes de la Grèce antique, 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 à 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 l’écoute clandestine grâce à la cryptographie à clé secrète partagée. Le but principal de Kerberos est d’éviter la transmission de mots de passe chiffrés à travers le réseau. Il élimine la menace des analyseurs de paquets et améliore la sécurité globale du réseau.

Bien que le fournisseur de support de sécurité Kerberos traite efficacement les menaces de sécurité sévères, sa mise en œuvre peut être difficile en raison de diverses 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 concerné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.
• Dans le cas où la cryptographie symétrique est utilisée, une compromission de l’infrastructure d’authentification permettrait à 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 son propre ensemble de clés Kerberos.

Comment Fonctionne l’Authentification Kerberos

Le 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 Ticket.

1. L’utilisateur entre son nom d’utilisateur et son mot de passe. L’ID utilisateur en clair est envoyé au Serveur d’Authentification (AS) avec une demande de services au nom de l’utilisateur.
2. L’AS vérifie si le nom d’utilisateur est dans la base de données. S’il y a des informations sur cet utilisateur, l’AS peut générer la clé secrète du client en fonction de l’ID et du mot de passe de l’utilisateur. L’AS envoie à l’utilisateur :
   • Clé de session Client/TGS (chiffrée avec la clé secrète du client) ;
   • TGT incluant l’ID utilisateur, l’adresse réseau et la période de validité du ticket + clé de session Client/TGS (chiffrée avec la clé secrète du TGS).
3. L’utilisateur décode le premier message mais ne peut pas décoder le second, car il n’a pas la clé secrète du TGS. Le client envoie un message au TGS :
   • TGT reçu de l’AS + ID du serveur + clé secrète TGS/Client (chiffrée avec la clé secrète du TGS) ;
   • Authentificateur incluant l’ID du client et le timestamp (chiffré avec la clé de session Client/TGS).
4. Le TGS décrypte le premier message, obtient le TGT + la clé de session TGS/Client, avec laquelle 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 le timestamp n’excède pas la période de validité du ticket. Si tout est correct, le TGS envoie à l’utilisateur :
   • ID utilisé, adresse réseau, période de validation du ticket + clé de session Client/Serveur (chiffrée avec la clé secrète du serveur) ;
   • Clé de session Client/Serveur (chiffrée avec la clé secrète Client/TGS).
5. Le client envoie les informations suivantes au serveur auquel il essaie d’accéder :
   • ID utilisé, adresse réseau, période de validation du ticket + clé de session Client/Serveur (chiffrée avec la clé secrète du serveur) ;
   • Authentificateur incluant l’ID et le timestamp (chiffré avec la clé de session Client/Serveur).
6. Le serveur ciblé décrypte les messages de l’utilisateur, vérifie si les ID utilisateur des deux messages ont 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é :
   • Timestamp + 1 (chiffré avec la clé de session Client/Serveur)

Le client vérifie si la valeur du timestamp est timestamp + 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 pare-feu pour travailler avec le protocole d’authentification Kerberos

Le pare-feu de base de données DataSunrise prend en charge le protocole d’authentification Kerberos. Certains paramètres doivent être modifiés pour permettre les opérations Kerberos, ils peuvent varier en fonction du produit SGBD utilisé. Dans cet article, nous allons montrer comment personnaliser Kerberos sur MS SQL Server.

L’autorisation des utilisateurs dans Active Directory se fait via l’Interface de Fournisseur de Support de Sécurité (SSPI). Il existe deux protocoles qui peuvent être utilisés : NTLM et Kerberos. NTLM est un protocole plus lent et moins sécurisé, nous allons donc contempler la personnalisation de Kerberos uniquement. Afin d’activer Kerberos, plusieurs conditions doivent être remplies :

1. La délégation pour les utilisateurs et ordinateurs Active Directory doit être activée.
   • Accédez aux Utilisateurs et Ordinateurs Active Directory.
   • Trouvez le compte d’ordinateur où DataSunrise est installé.
   • Accédez à l’onglet Délégation et passez à l’état “Faire confiance à cet ordinateur pour la délégation à tout service.”
2. L’adresse proxy doit correspondre au SPN enregistré du service MSSQLSvc. Utilisez l’outil SetSPN pour enregistrer 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 SPN proxy, exécutez la commande suivante :

   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 sera conforme au schéma d’authentification utilisé par le serveur : SQL, NTLM ou KERBEROS.

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