Différences

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

--- 320kerberos:60_plus [le 01/03/2010 à 21:37] – 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.
-Une démonstration rapide ?
-Soit un serveur distant, qui va bientôt nous servir pour la cerise sur le gâteau. Il s'appèle ''squid3.eme.org'', son nom prendra tout son sens plus tard. Cet hôte est mu par une Debian Squeeze, il est intégré à un domaine Microsoft (Windows 2008, ''Samba'' est notre alliée pour cette manœuvre), et dispose de :
-  * un serveur OpenSSH configuré pour accepter les authentifications GSSAPI ;
-  * une clé ''host/squid3.eme.org@EME.ORG'' partagée avec le KDC de Windows 2008.
-Soit un utilisateur ''root'' qui dispose :
-  * d'un compte local sur ''squid3.eme.org'' ;
-  * d'un compte dans le domaine AD ''eme.org'' (pas forcément avec le même mot de passe d'ailleurs, ni même avec les mêmes privilèges d'administration) ;
-Soit une station de travail (Ubuntu Karmic Koala nommée ''karmicvirt''), disposant des outils kerberos ''krb5-user''. Notre cobaye (chris) a ouvert une session sur ce poste de travail et souhaite accéder à ''proxy3.eme.org'' :
-<code>
-chris@karmicvirt:~$ klist
-klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_1000_f9ItDE)
-</code>
-Aucun principal ni aucun ticket ne sont présents dans le cache.
-<html><pre class="code">
-chris@karmikvirt:~$ ssh -v root@proxy3.eme.org
-OpenSSH_5.1p1 Debian-6ubuntu2, OpenSSL 0.9.8g 19 Oct 2007
-debug1: Reading configuration data /etc/ssh/ssh_config
-debug1: Applying options for *
-debug1: Connecting to proxy3.eme.org [192.168.0.137] port 22.
-debug1: Connection established.
-...
-<span class="hly">debug1: Authentications that can continue: <b>publickey,gssapi-keyex,gssapi-with-mic,password</b>
-debug1: Next authentication method: gssapi-keyex
-debug1: No valid Key exchange context
-debug1: Next authentication method: gssapi-with-mic
-debug1: Unspecified GSS failure.  Minor code may provide more information
-Credentials cache file '/tmp/krb5cc_1000_f9ItDE' not found
-debug1: Unspecified GSS failure.  Minor code may provide more information
-Credentials cache file '/tmp/krb5cc_1000_f9ItDE' not found
-debug1: Unspecified GSS failure.  Minor code may provide more information
-debug1: Next authentication method: publickey
-debug1: Trying private key: /home/chris/.ssh/identity
-debug1: Trying private key: /home/chris/.ssh/id_rsa
-debug1: Trying private key: /home/chris/.ssh/id_dsa
-debug1: Next authentication method: password
-root@proxy3.eme.org's password: </span>
-</pre></html>
-Notre client n'a pas de clé publique à présenter, il n'a pas de ticket kerberos non plus, il va devoir utiliser le mot de passe de son compte ''root'' sur ''proxy3''.
-<code>
-chris@karmikvirt:~$ kinit -V root@EME.ORG
-Password for root@EME.ORG:
-Authenticated to Kerberos v5
-chris@jauntyvirt:~$ klist
-Ticket cache: FILE:/tmp/krb5cc_1000_f9ItDE
-Default principal: root@EME.ORG
-Valid starting     Expires            Service principal
-/01/10 22:27:43  03/02/10 05:07:43  krbtgt/EME.ORG@EME.ORG
-</code>
-Maintenant, ''chris'' dispose d'un principal pour ''root''
-<html><pre class="code">
-chris@karmicvirt:~$ ssh -v root@proxy3.eme.org
-OpenSSH_5.1p1 Debian-6ubuntu2, OpenSSL 0.9.8g 19 Oct 2007
-debug1: Reading configuration data /etc/ssh/ssh_config
-debug1: Applying options for *
-debug1: Connecting to proxy3.eme.org [192.168.0.137] port 22.
-debug1: Connection established.
-...
-debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
-debug1: Next authentication method: gssapi-keyex
-debug1: No valid Key exchange context
-<span class="hly">debug1: Next authentication method: gssapi-with-mic
-debug1: Authentication succeeded (gssapi-with-mic).
-debug1: channel 0: new [client-session]
-debug1: Requesting no-more-sessions@openssh.com
-debug1: Entering interactive session.
-debug1: Sending environment.
-debug1: Sending env LANG = fr_FR.UTF-8
-Linux proxy3 2.6.32-trunk-686 #1 SMP Sun Jan 10 06:32:16 UTC 2010 i686
-The programs included with the Debian GNU/Linux system are free software;
-the exact distribution terms for each program are described in the
-individual files in /usr/share/doc/*/copyright.
-Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
-permitted by applicable law.
-Last login: Mon Mar  1 16:15:32 2010 from 192.168.0.68
-proxy3:~# </span>
-</pre></html>
-le SSO a fonctionné.
-<code>
-chris@karmicvirt:~$ klist
-Ticket cache: FILE:/tmp/krb5cc_1000_f9ItDE
-Default principal: root@EME.ORG
-Valid starting     Expires            Service principal
-/01/10 22:27:43  03/02/10 05:07:43  krbtgt/EME.ORG@EME.ORG
-/01/10 22:29:49  03/02/10 05:07:43  host/proxy3.eme.org@
-/01/10 22:29:49  03/02/10 05:07:43  host/proxy3.eme.org@EME.ORG
-</code>
-Sur le poste client, ''chris'' dispose maintenant des tickets nécessaires pour s'authentifier en tant que ''root'' sur le service ''host/proxy3.eme.org@EME.ORG''
 ===== Proxy Squid =====
@@ Ligne 183: / 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.