Différences

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

--- 320kerberos:60_plus [le 19/02/2010 à 17:51] – 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 51: / Ligne 51: @@
 Cette configuration présente certaines imperfections qui peuvent amener des comportements désagréables !
 </note>
-  * l'utilisateur **doit** disposer d'un compte local. S'il ne dispose que d'un principal kerberos, il ne pourra pas ouvrir de session sur la station de travail ;
+  * l'utilisateur **doit** disposer d'un compte local. S'il ne dispose que d'un principal kerberos, il ne pourra pas ouvrir de session sur la station de travail. Kerberos ne réalise que l'authentification, les autres informations nécessaires nécessiteraient par exemple LDAP en appui ;
   * un utilisateur change son mot de passe avec ''passwd'' :
     * le mot de passe kerberos sera également changé, mais si l'utilisateur a choisi un mot de passe trivial, la sécurité par défaut de la karmic va faire échouer le changement du pass local ;
@@ 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.
 ===== Proxy Squid =====
@@ Ligne 79: / 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 150: / 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, 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).