Pourquoi l'administrateur système ne crée-t-il pas simplement un compte 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 à changer ces privilèges. Il s'agit au total de 2 500 entrées de mot de passe à créer.

Ajout d'un nouvel utilisateur

Lorsque vous ajoutez un nouvel utilisateur, l'administrateur doit partir aux 50 serveurs et ajoutez cet utilisateur à tous. 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 être automatisée en toute sécurité est que l’utilisateur doit 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 de manière à ne pas conserver une copie du mot de passe, pas même une copie chiffrée. Ainsi, lorsque l'utilisateur saisit 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

Vous pensez peut-être maintenant que vous pourriez écrire un script qui:

1. S'exécute sur le serveur X;
2. Demande au nouvel utilisateur d'entrer son nouveau mot de passe;
3. Demande à l'administrateur son mot de passe;
4. Se connecte aux serveurs # 1 à # 50 et crée le compte utilisateur sur chacun d'eux avec le même mot de passe.

C'est un peu douteux, mais même si vous y allez, vous vous retrouvez toujours avec un autre problème plus grave. Supposons que votre entreprise achète un nouveau serveur et que nous ayons maintenant besoin de nos 50 utilisateurs pour avoir accès à ce serveur. Eh bien, étant donné qu'aucun des serveurs ne contient une copie des mots de passe des utilisateurs, l'administrateur devrait accéder à chaque utilisateur et leur demander de saisir un mot de passe pour leur compte sur le nouveau serveur. Et il est impossible de contourner ce problème à moins de conserver des copies des mots de passe des utilisateurs, ce qui, encore une fois, n'est pas une pratique 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 utilisateur / mot 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:

1. Lorsque vous ajoutez un nouvel utilisateur, tous les serveurs le récupèrent automatiquement dans la base de données centrale.
2. Lorsque vous ajoutez un nouveau serveur, il récupère automatiquement tout les utilisateurs de la base de données centrale.

Il existe une variété de mécanismes pour ce faire, même s'ils manquent encore de ce que propose Kerberos.

Kerberos

Une fois que vous avez une telle base de données centralisée, il est logique de la perfectionner avec plus de fonctionnalités, à la fois pour faciliter la gestion et pour plus de commodité. Kerberos ajoute la possibilité que, lorsqu'un utilisateur s'est connecté avec succès à un service, ce service "se souvient" du fait et est capable de "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é:

1. Les utilisateurs ne on ne leur demande pas encore et encore leur mot de passe lorsqu'ils l'ont déjà saisi une fois ce jour-là.
2. Lorsque des programmeurs écrivent des programmes qui accèdent à plusieurs serveurs et que ces serveurs nécessitent une authentification, les programmes peuvent désormais s'authentifier auprès de ces serveurs sans avoir à présenter de mot de passe, en réutilisant les informations d'identification du compte de serveur sous lequel ils s'exécutent.

Ce dernier est important car il minimise ou tue une pratique non sécurisée mais trop courante: des 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 de ne pas stocker de copies de mots de passe, pas même de copies chiffrées .

En termes simples, ce serait un cauchemar administratif.

Kerberos permet aux administrateurs de faire en sorte que n'importe quel nombre d'employés utilise les mêmes informations d'identification pour se connecter aux ressources de leur domaine.

Disons que cela n'existait pas dans un réseau simple.

1. L'utilisateur entre le mot de passe pour déverrouiller son ordinateur.
2. L'utilisateur souhaite mapper un lecteur réseau. Il doit maintenant saisir à nouveau son mot de passe
3. L'utilisateur souhaite alors recevoir un e-mail. Ils ouvrent Outlook et doivent ensuite entrer un autre mot de passe.
4. L'utilisateur doit alors se connecter à l'intranet de l'entreprise. C'est un autre mot de passe.

Vous voyez l'idée. Ne pas utiliser Kerberos signifie que l'utilisateur doit conserver les mots de passe de tous les serveurs hébergeant les services auxquels il doit 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 devez le faire?

Du point de vue de la sécurité, l'administrateur obtient toutes ses tentatives de connexion (réussies et échouées) dans un seul endroit au lieu d'être connecté sur 5 serveurs différents. Cela aide à la fois à résoudre les problèmes de connexion (par exemple, les verrouillages) et rend les journaux d'audit beaucoup plus faciles.

Kerberos n'est pas là pour des raisons de commodité, c'est une mesure de sécurité améliorée. La commodité est un avantage secondaire.

Une bonne explication est Concevoir un système d'authentification: un dialogue en quatre scènes

En gros, au lieu de simplement passer un jeton magique autour (c'est-à-dire votre mot de passe), vous obtenez un "ticket", qui est signé par une source fiable de vérité (par exemple 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 à un parc d'attractions ou donner de l'argent à un préposé à 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 présent en silence, 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. Récemment, certaines failles ont été identifiées et exploitées 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 toutes supposent que l'utilisateur change de mot de passe est rare et que nous pouvons attendre que le travail par lots de nuit pour que le changement de mot de passe prenne effet. Il en va de même pour les changements d'autorisation dans la plupart des cas; si nous avons besoin d'un changement d'autorisation pour prendre effet maintenant, les outils les plus petits ne peuvent pas le faire.

Kerberos énumère dans ses capacités la capacité 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 même 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ù.