Relation complexe Kerberos et LDAP

J'ai du mal à comprendre la relation entre LDAP et Kerberos (conceptuellement).

Je comprends que LDAP est un service d’annuaire et que Kerberos est un service d’authentification.

Nous savons également que LDAP est également capable de stocker des mots de passe, mais la conception de LDAP doit être un annuaire accessible au public et ne convient pas pour stocker des informations sensibles. C'est pourquoi il est préférable de déléguer l'authentification à un autre service, tel que Kerberos.

Maintenant, ce que je ne comprends pas, ce sont ces deux questions:

1. À quel serveur les clients envoient-ils leur demande lorsqu'un utilisateur tente de se connecter? Mon intuition me dit que ce doit être le serveur Kerberos. Si oui, où le serveur LDAP entre-t-il?
2. Où l'administrateur système définit-il les autorisations? Dans ce cas, mon intuition me dit LDAP. Je peux imaginer qu'il pourrait y avoir une entrée pour chaque système et / ou service, et les utilisateurs y auront accès par le biais des appartenances à un groupe ou directement. Si oui, cela signifie-t-il que le serveur LDAP (via une interface telle que phpLDAPadmin) définira les groupes et les utilisateurs en conséquence sur le serveur Kerberos?

Je suis particulièrement confus car je vois la connexion entre LDAP et Kerberos dans les deux documentations. Pourparlers LDAP sur la délégation de l' authentification Kerberos ici et parle Kerberos d'avoir LDAP comme backend ici .

Toutes les documentations que j'ai lues semblent être des pièces d'un casse-tête que je n'arrive pas à assembler. J'apprécie que quelqu'un puisse expliquer comment faire.

Oh, ça fait longtemps. Voyons ce que je peux me souvenir.

Oui, cela peut certainement être déroutant, car vous pouvez utiliser Kerberos pour vous authentifier pour LDAP et vous pouvez également demander à Kerberos d'utiliser LDAP en tant que serveur principal. Bien que ce ne soit pas la même chose, il est souvent difficile de différencier celui dont on parle lorsque vous essayez de le rechercher. Je ne peux parler que de LDAP utilisant Kerberos pour son authentification, car je n’ai aucune expérience de ce dernier.

1. Votre intuition a raison d’utiliser le serveur Kerberos. Si je comprends bien, le client demande un TGT au serveur Kerberos POUR le serveur LDAP (en utilisant le nom principal du service "ldap/hostname@DOMAIN.NAME" ou similaire). Le client peut ensuite l'utiliser pour se connecter au serveur LDAP, car il est capable de valider le ticket. Le mot de passe du client lui-même n'est jamais envoyé au serveur LDAP.
2. C’est si vous utilisez LDAP comme back-end pour Kerberos, j’imagine. Vous pouvez utiliser ici un annuaire LDAP pour enregistrer des attributs et des valeurs pour différentes choses. Bien entendu, vous n’êtes pas obligé d’utiliser LDAP en tant que back-end pour Kerberos.

Les choses deviennent encore plus compliquées quand ils commencent à parler de SASL car il est difficile de dire s'ils parlent de SASL au début ou à la fin de LDAP. En d'autres termes, est-il utilisé par les clients pour s'authentifier auprès de LDAP? Ou est-il utilisé par LDAP pour transmettre le mot de passe à une autre source d'authentification? Juste des mises en garde à surveiller.

De plus, il est possible d'utiliser une simple liaison avec LDAP, d'envoyer le mot de passe au serveur LDAP, qui le transmet ensuite à une autre source d'authentification (telle que Kerberos). Si vous faites quelque chose comme ça, c'est bien parce que le mot de passe lui-même n'est pas stocké dans LDAP, mais comme une simple liaison est un texte en clair, vous voulez vous assurer d'utiliser TLS entre le client et le serveur LDAP.

J'espère que cela aide un peu. On dirait que tu as fondamentalement la bonne idée.

Votre intuition est sur la bonne voie dans les deux cas. Prenons vos questions une par une.

1. Ici, le service Kerberos est le système d' authentification . Le client recevra un ticket chiffré du serveur Kerberos (après authentification bien sûr), puis le présentera au serveur pour lui montrer qu'il est authentifié.
2. Ici, le service LDAP est le système d' autorisation . Les informations utilisateur sont stockées dans le répertoire (comme UID / GID, etc.). Essentiellement, cela remplace les informations contenues dans / etc / passwd. Le serveur LDAP ne met à jour aucune information sur le serveur Kerberos.

Cela dépend vraiment de votre configuration. Je lutte avec cela depuis un petit moment, mais je ne suis pas un expert.

Pour un administrateur système, la relation entre LDAP et Kerberos peut être aussi simple qu’une machine utilisant les deux. Votre configuration pourrait être aussi simple que d’utiliser LDAP en tant que source pour / etc / passwd et / etc / group via nsswitch.conf (et un plugin du type nss-pam-ldapd du référentiel archlinux), en laissant l’attribut userPassword dans LDAP en tant qu’exclamation. point ou astérisque (ce qui signifie pas de mot de passe et pas de possibilité de se connecter).

Un KDC Kerberos fournissant l’authentification par mot de passe pour les machines de votre choix, l’intégration de la connexion système différant en fonction du service offert. Par exemple, s'il s'agit d'une machine distante ne nécessitant qu'un accès via ssh, LDAP fournit toujours les mêmes informations qu'ailleurs, mais Kerberos n'a besoin que de quelques lignes dans les fichiers de configuration ssh. Sur un autre système où l'intégration de la connexion complète est requise, cela pourrait s'avérer être un énorme problème, car cela nécessite de nombreuses modifications de la configuration des PAM. Ceci est facile pour les clients RHEL avec authconfig, mais attendez-vous à ce que vous ayez très mal à la tête ailleurs, à moins que vous ne soyez à l'aise avec PAM. L’avantage de l’utiliser avec PAM, c’est que la plupart des programmes (comme ssh) peuvent utiliser PAM, vous n’avez donc plus à vous soucier de la configuration ssh.

En d'autres termes, si le KDC est en panne, le système n'acceptera jamais votre mot de passe correctement (mais il sait que vous êtes un utilisateur à cause de LDAP) et si le serveur LDAP est en panne, le système pensera que votre nom d'utilisateur ne le permet pas. t existent.