Différences

Ci-dessous, les différences entre deux révisions de la page.

--- 320kerberos:60_plus [le 01/03/2010 à 19:03] – prof
+++ 320kerberos:60_plus [le 30/06/2018 à 15:59] (Version actuelle) – prof
@@ Ligne 5: / Ligne 5: @@
 ===== Pam et kerberos =====
-Cette autre usine qu'est PAM permet d'employer un module spécifique à kerberos. Sur Debian (et donc Ubuntu), l'installation du paquet ''libpam-krb5''. La simple installation de ce paquet va modifier la configuration de PAM pour prendre en charge l'authentification kerberos.
+Cette autre usine qu'est PAM permet d'employer un module spécifique à kerberos. Sur Debian (et donc Ubuntu), la simple installation du paquet ''libpam-krb5'' va modifier la configuration de PAM pour prendre en charge l'authentification kerberos.
 Pour les spécialistes de PAM (ce que j'aimerais bien arriver à devenir un jour), voici, pour une Ubuntu « karmic », les modifications apportées, dans ''common-auth'' :
@@ Ligne 71: / Ligne 71: @@
 	renew until 02/20/10 18:32:32
 </code>
-Le TGT a bien été obtenu de façon transparente.
+Le TGT a bien été obtenu de façon transparente. Notons que ça ne fonctionne pas avec la connexion automatique à un compte par défaut. Comme cette pratique n'est pas recommandable dans un environnement « peu sûr » (c'est-à-dire dans tous les cas), nous ne pousserons pas plus avant les investigations.
-===== Ssh et kerberos =====
-Juste pour le fun, voici un moyen d'ouvrir une session ssh en utilisant kerberos au travers de GSSAPI. Soit un utilisateur disposant de :
-  * la possibilité d'ouvrir une session ssh sur l'hôte distant ;
-  * un principal (kerberos) qui l'authentifie dans le royaume kerberos.
-A la condition que l'hôte distant fasse partie du royaume et soit lui-même authentifié (clé partagée entre le KDC et l'hôte distant), alors cet utilisateur va pouvoir utiliser le SSO pour ouvrir sa session ssh sur l'hôte distant, sans saisie de mot de passe, et sans échange de clé publique.
 ===== Proxy Squid =====
@@ Ligne 84: / Ligne 81: @@
 Avantages :
-  * pas besoin d'utiliser samba, kerberos ne fait pas partie de CIFS ;
+  * pas besoin d'utiliser samba ni winbind, kerberos ne fait pas partie de CIFS ;
   * l'authentification est immédiate, économie de bande passante et de volume de logs ;
   * meilleure lisibilité des logs de Squid, par le fait.
-Inconvénient(s) :
+Inconvénient :
-  * si l'utilisateur ne dispose pas d'un TGT, le navigateur ne lui proposera pas une fenêtre de connexion ;
+  * si l'utilisateur ne dispose pas d'un TGT, le navigateur ne lui proposera pas une fenêtre de connexion son accès sera interdit tout simplement.
-  * la dernière version de la libkrb5-3, fournie dans Squeeze, semble incompatible avec le kerberos de Windows, même 2008 (vérifier pour 2008 r2).
-Fonctionne parfaitement en revanche avec le KDC du MIT.
 Voici rapidement comment faire.
@@ Ligne 155: / Ligne 149: @@
 </code>
 Ce fichier, s'il existe, est intégré à ''/etc/init.d/squid3''. Il suffit alors de relancer squid.
 ===== Et encore... =====
-Bien d'autres applications peuvent utiliser kerberos, à commencer par ''ssh'', en passant par Postfix, Dovecot, samba et sans doutes bien d'autres encore.
+Bien d'autres applications peuvent utiliser kerberos, grâce à GSSAPI. Postfix, Dovecot, samba etc. La fonction SSO étant probablement la plus intéressante, et Microsoft ne s'y est pas trompé, en intégrant kerberos à son système Active Directory. Ce que l'on peut regretter, c'est la façon opaque dont ça a été fait, mais c'est une marque de fabrique. Encore qu'un effort évident de documentation a été mené et que l'interopérabilité entre MS Windows et les systèmes libres Unix a quelques chances de progresser grâce à kerberos (et LDAP, mais ceci est une autre histoire).