J'ai lu que Kerberos est utilisé pour authentifier les utilisateurs qui souhaitent accéder aux services sur divers serveurs dans un réseau d'entreprise, mais je ne comprends toujours pas le but de Kerberos. Pourquoi l'administrateur système ne crée-t-il pas simplement un compte d'utilisateur pour chaque utilisateur sur chaque serveur, afin que les utilisateurs puissent utiliser leur nom d'utilisateur et leur mot de passe pour accéder aux ressources auxquelles ils souhaitent accéder? Pourquoi un protocole d'authentification aussi élaboré est-il nécessaire?
Pourquoi l'administrateur système ne crée-t-il pas simplement un compte d'utilisateur pour chaque utilisateur sur chaque serveur, afin que les utilisateurs puissent utiliser leur nom d'utilisateur et leur mot de passe pour accéder aux ressources auxquelles ils souhaitent accéder?
Imaginez que vous avez 50 utilisateurs et 50 serveurs. Par souci de simplicité, supposons que les 50 utilisateurs sont censés avoir accès aux 50 serveurs, ils ont tous les mêmes privilèges sur tous les serveurs, et nous n'avons jamais à modifier ces privilèges. Il s'agit de 2500 entrées de mot de passe au total qui doivent être créées.
Ajout d'un nouvel utilisateur
Lorsque vous ajoutez un nouvel utilisateur, l'administrateur doit accéder aux 50 serveurs et ajouter cet utilisateur à chacun d'eux. Cela nécessiterait que l'administrateur exécute la commande create user sur les 50 serveurs. Ce bit peut être automatisé, mais la partie qui ne peut pas être automatisée en toute sécurité est que l'utilisateur devra entrer son mot de passe 50 fois, une fois par serveur.
Pourquoi ce dernier problème? Parce que les systèmes d'authentification par mot de passe sont conçus pour ne pas conserver de copie du mot de passe , pas même une copie cryptée. Ainsi, lorsque l'utilisateur entre son nouveau mot de passe sur le serveur n ° 1, ce serveur oublie immédiatement le mot de passe, il devra donc le saisir à nouveau pour le serveur n ° 2 et n ° 3, etc.
Ajout d'un nouveau serveur
Peut-être que maintenant vous pensez que vous pourriez écrire un script qui:
C'est un peu douteux, mais même si vous y allez, vous vous retrouvez avec un autre problème plus important. Supposons que votre entreprise achète un nouveau serveur et que nous ayons maintenant besoin que nos 50 utilisateurs y aient accès. Eh bien, étant donné qu'aucun des serveurs ne contient une copie des mots de passe des utilisateurs, l'administrateur devrait aller à chaque utilisateur et leur faire entrer un mot de passe pour leur compte dans le nouveau serveur. Et il n'y a pas moyen de contourner cela à moins que vous ne conserviez des copies des mots de passe des utilisateurs, ce qui est encore une pratique peu sûre .
Base de données de mots de passe centralisée
Pour résoudre ces problèmes, vous avez vraiment besoin que votre base de données d'utilisateurs/mots de passe soit centralisée en un seul endroit et que tous les serveurs consultent cette base de données pour authentifier les noms d'utilisateur et les mots de passe. C'est vraiment le strict minimum dont vous avez besoin pour un environnement multi-utilisateur/multiserveur gérable. Maintenant:
Il existe une variété de mécanismes pour ce faire, bien qu'ils soient encore à court de ce que Kerberos offre.
Kerberos
Une fois que vous avez une telle base de données centralisée, il est logique de la renforcer avec plus de fonctionnalités, à la fois pour une gestion facile et pour plus de commodité. Kerberos ajoute la possibilité que, lorsqu'un utilisateur s'est connecté avec succès à un service, ce service "se souvienne" du fait et puisse "prouver" à d'autres services que cet utilisateur s'est connecté avec succès. Ainsi, ces autres services, présentés avec une telle preuve, permettront à l'utilisateur d'entrer sans lui demander de mot de passe.
Cela offre un mélange de commodité et de sécurité:
Ce dernier est important car il minimise ou tue une pratique non sécurisée mais trop courante: les programmes automatisés qui vous obligent à mettre des copies des noms d'utilisateur et des mots de passe dans les fichiers de configuration. Encore une fois, une idée clé de la gestion sécurisée des mots de passe est ne stockez pas de copies de mots de passe, pas même des copies cryptées.
Autrement dit, ce serait un cauchemar administratif.
Kerberos permet aux administrateurs d'avoir un nombre illimité d'employés utilisant les mêmes informations d'identification pour se connecter aux ressources de leur domaine.
Disons que cela n'existait pas dans un simple réseau.
Vous avez eu l'idée. Ne pas utiliser Kerberos signifie que l'utilisateur doit conserver des mots de passe pour tous les serveurs auxquels les services d'hébergement dont il a besoin d'accéder. Ce serait un casse-tête pour les utilisateurs et les administrateurs. La plupart des politiques d'entreprise stipulent que les utilisateurs doivent changer leur mot de passe tous les X jours. Pouvez-vous imaginer être un utilisateur final et avoir besoin de changer votre mot de passe sur 5 serveurs chaque fois que vous en avez besoin?
Du point de vue de la sécurité, l'administrateur obtient toutes ses tentatives de connexion (réussies et échouées) en un seul endroit au lieu d'être connecté sur 5 serveurs différents. Cela aide à la fois à résoudre les problèmes de connexion (c'est-à-dire les verrouillages) et facilite l'audit des journaux.
Kerberos n'est pas là pour plus de commodité, c'est une mesure de sécurité renforcée. La commodité est un avantage secondaire.
Une bonne explication est Conception d'un système d'authentification: une boîte de dialogue en quatre scènes
Fondamentalement, au lieu de simplement passer un jeton magique (c'est-à-dire votre mot de passe), vous obtenez un "ticket", qui est signé par une source fiable de vérité (c'est-à-dire Kerberos KDC, Microsoft AD, etc.). Votre ticket indique aux services qui sont et à quels groupes de droits vous appartenez. Pensez-y comme acheter un billet d'entrée dans un parc d'attractions par rapport à donner de l'argent à un accompagnateur à chaque trajet dans un parc.
Pour éviter une escalade latérale .
La complexité administrative de la gestion des mots de passe peut être réduite en utilisant une base de données de mots de passe centralisée, telle que LDAP. Cependant, cela crée un risque d'escalade latérale. Si un attaquant prend le contrôle d'un serveur, il peut rester silencieusement présent, en reniflant les mots de passe. Ces mots de passe peuvent ensuite être utilisés pour compromettre d'autres serveurs - escalade latérale.
Kerberos tente de résoudre ce problème: les utilisateurs n'envoient pas leur mot de passe à chaque serveur; ils l'envoient uniquement au serveur d'authentification et présentent un ticket aux autres serveurs. Ces derniers temps, quelques défauts ont été identifiés qui sont exploités par des outils comme mimikatz. Cependant, au moins Kerberos est conçu pour empêcher l'escalade latérale; LDAP ne fait rien pour l'arrêter.
Le principal avantage de Kerberos est de permettre la synchronisation immédiate du changement de compte et du changement de mot de passe.
J'ai des solutions à portée de main pour l'administration centralisée des comptes distribués et des agents de mot de passe côté client qui répondent à 99% des invites de mot de passe après la connexion, mais tous supposent que le changement de mot de passe de l'utilisateur est rare et que nous pouvons attendre le travail par lots de nuit pour que le changement de mot de passe prenne effet. Il en va de même avec les changements de permission dans la plupart des cas; si nous avons besoin d'un changement de permission pour prendre effet maintenant, les petits outils ne peuvent pas le faire.
Kerberos répertorie dans ses capacités la possibilité d'authentifier en toute sécurité les connexions sans les chiffrer. Cela s'avère moins que souhaitable dans la pratique et cette capacité ne doit pas être invoquée. Voler des tickets Kerberos était l'essence d'une attaque contre SMB il y a un an qui fournirait tous les accès en tant qu'utilisateur à condition que l'utilisateur utilise n'importe quel partage réseau n'importe où.