L'internet rapide et permanent

Outils pour utilisateurs

Outils du site

Vous êtes ici : L'internet rapide et permanent » Kerberos » Démonstration simple

Différences

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

Lien vers cette vue comparative

Les deux révisions précédentesRévision précédente
Prochaine révision		Révision précédente
320kerberos:10_manip_simple [le 10/02/2010 à 09:42] – prof320kerberos:10_manip_simple [le 30/06/2018 à 15:57] (Version actuelle) – prof
Ligne 2: Ligne 2:
 Voyons tout d'abord comment ça se présente du côté de l'utilisateur à peine averti, sur une plateforme de tests très rudimentaire. Voyons tout d'abord comment ça se présente du côté de l'utilisateur à peine averti, sur une plateforme de tests très rudimentaire.
 ===== Le décor de la scène ===== ===== Le décor de la scène =====
-Grâce aux avantages de KVM nous pouvons disposer d'autant de machines que nous le souhaitons, profitons-en. +Grâce aux avantages de KVM (([[http://www.linux-kvm.org/page/Main_Page|Kernel-based Virtual Machine]])) nous pouvons disposer d'autant de machines que nous le souhaitons, profitons-en. 
-  * un serveur ''kerberos.maison.mrs'' se charge de faire fonctionner l'usine à gaz ;+  * un serveur ''kerberos.maison.mrs'' se charge de faire fonctionner l'usine à gaz (AS et TGS, le tout appelé KDC comme Key Distribution Center) ;
   * un serveur ''apache-krb.maison.mrs'' est un serveur http tout bête, sauf qu'il n'autorise l'accès qu'aux personnes duement authentifiées par kerberos ;   * un serveur ''apache-krb.maison.mrs'' est un serveur http tout bête, sauf qu'il n'autorise l'accès qu'aux personnes duement authentifiées par kerberos ;
   * un client qui voudrait bien accéder au contenu de ''apache-krb.maison.mrs'' depuis un poste de travail qui dispose des outils nécessaires pour dialoguer avec ''kerberos.maison.mrs''.   * un client qui voudrait bien accéder au contenu de ''apache-krb.maison.mrs'' depuis un poste de travail qui dispose des outils nécessaires pour dialoguer avec ''kerberos.maison.mrs''.
Ligne 10: Ligne 10:
  
 ==== Ça ne marche pas ==== ==== Ça ne marche pas ====
-Première prise, l'utilisateur, qui s'appèle ''chris'', n'a pas fait risette à kerberos, et essaye d'accéder à ''%%http://apache-kerb.maison.mrs%%'' :+Première prise, l'utilisateur, qui s'appèle ''chris'', n'a pas fait risette au cerbère, et essaye d'accéder à ''%%http://apache-kerb.maison.mrs%%'' :
  
 {{ :320kerberos:err401.png?720 |No Ticket}} {{ :320kerberos:err401.png?720 |No Ticket}}
-Il se fait jeter...+Il se fait jeter dehors... 
 ==== Risette à kerberos ==== ==== Risette à kerberos ====
 Chris lit alors la notice où on lui explique qu'il doit d'abord s'authentifier auprès du cerbère en utilisant la commande ''kinit'' : Chris lit alors la notice où on lui explique qu'il doit d'abord s'authentifier auprès du cerbère en utilisant la commande ''kinit'' :
Ligne 23: Ligne 24:
 Confiant, il re essaye : Confiant, il re essaye :
  
-{{ :320kerberos:it-works.png?720|ça marche}}+{{ :320kerberos:it-works.png?720 |ça marche}}
  
-Et là, chris peut fermer son navigateur puis le ré-ouvrir, retourner sur la même page et ça marchera encore. +Et là, chris peut fermer son navigateur puis le ré-ouvrir, retourner sur la même page. Il sera automatiquement reconnu durant toute la validité de son ticket.
-=== Un peu de curiosité === +
-Notre utilisateur n'aimant pas utiliser les choses sans savoir comment elles fonctionnent, s'intéresse à cette commande ''kinit'' et découvre qu'elle est fournie par le paquet ''krb5-user'' qui fournit également d'autres commandes dont ''klist'' et ''kdestroy''. +
-<code> +
-chris@pchris:~$ klist +
-Ticket cache: FILE:/tmp/krb5cc_1000 +
-Default principal: chris@MAISON.MRS+
  
-Valid starting     Expires            Service principal 
-02/09/10 18:17:51  02/10/10 04:17:51  krbtgt/MAISON.MRS@MAISON.MRS 
- renew until 02/10/10 18:17:46 
-</code> 
  
-C'est pas forcément très compréhensible, mais on sent bien qu'on a un ticket avec le chien à trois têtes et que ça ne va pas durer éternellement (ce qui est peut-être rassurant). 
  
-<code> 
-chris@pchris:~$ kdestroy 
-chris@pchris:~$ klist 
-klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_1000) 
-</code> 
-On a perdu le ticket. Et bien sûr, une visite à ''%%http://apache-kerb.maison.mrs%%'' se traduit à nouveau par une page ''401 Authorization Required''. 
  
-Amusant ce truc... 
-<code> 
-chris@pchris:~$ kinit -V chris 
-Password for chris@MAISON.MRS:  
-Authenticated to Kerberos v5 
-chris@pchris:~$ klist 
-Ticket cache: FILE:/tmp/krb5cc_1000 
-Default principal: chris@MAISON.MRS 
  
-Valid starting     Expires            Service principal 
-02/09/10 19:21:03  02/10/10 05:21:03  krbtgt/MAISON.MRS@MAISON.MRS 
- renew until 02/10/10 19:20:57 
-</code> 
-On a de nouveau le ticket. Profitons-en pour visiter notre site favori, ça marche. 
-<code> 
-chris@pchris:~$ klist 
-Ticket cache: FILE:/tmp/krb5cc_1000 
-Default principal: chris@MAISON.MRS 
  
-Valid starting     Expires            Service principal 
-02/09/10 19:21:03  02/10/10 05:21:03  krbtgt/MAISON.MRS@MAISON.MRS 
- renew until 02/10/10 19:20:57 
-02/09/10 19:22:24  02/10/10 05:21:03  HTTP/apache-krb.maison.mrs@MAISON.MRS 
- renew until 02/10/10 19:20:57 
-</code> 
-Il y a du nouveau. Un truc en plus assez explicite à propos de notre site. On n'a rien demandé de spécial pourtant. Donc, le seul fait de visiter le site « kerbérisé » a fait que nous avons obtenu un ticket de plus. 
-===== Coup d'œil à la machinerie ===== 
-Si tout ceci fonctionne, c'est parce que : 
-  * ''kerberos.maison.mrs'' gère un « royaume » kerberos nommé ''MAISON.MRS''. Dans ce royaume, il y a : 
-    * des utilisateurs enregistrés (chris entre autres) ; 
-    * des services sur des hôtes (''HTTP/apache-krb.maison.mrs'') y sont aussi enregistrés ; 
-  * ''apache-krb.maison.mrs'' dispose d'un apache2 configuré pour authentifier les utilisateurs avec kerberos : 
-    * un module spécial, ''auth_kerb'' est chargé et utilisé dans la configuration de l'indien ; 
-    * un « tableau de clés » (keytab) a été placé sur ce serveur, de manière à ce qu'il sache à qui s'adresser pour que l'usine à gaz (kerberos) fonctionne sans fumées ni explosions. 
-  * le poste client quant-à-lui utilise les outils nécessaires à l'utilisateur et aussi ceux de l'administrateur du royaume, mais nous verrons ça plus loin). De plus, le navigateur, ici « Firefox » a été instruit de la procédure à suivre en cas de demande d'authentification kerberos. Ceci est réalisé diversement suivant les distributions. Voici la ligne concernée lorsque l'on utilise l'URI ''about:config'' : <html><br /></html>''network.negotiate-auth.trusted-uris;%%https://,http://%%''<html><br /></html>Ici, la négociation est demandée pour tout URI correspondant aux protocoles http et https. 
  
-Pour les trois protagonistes, il y a un fichier de configuration (le même sur les trois), qui définit la configuration du royaume kerberos qui, vous l'avez deviné, s'appelle ici ''MAISON.MRS''. Même nom que le domaine dns, mais en majuscules. +===== Faisons le point ===== 
- +Nous avons pu observer suffisamment de choses pour mieux comprendre le principe de kerberos et accessoirement pourquoi ce protocole a-t-il été appelé ainsi. 
-==== krb5.conf ==== +  * l'utilisateur doit disposer d'un ''principal'' dont il fait la demande à une entité nommée ''AS'', au moyen de la commande ''kinit''. Nous verrons plus loin que cette demande peut être automatisée lors de l'ouverture de la session par l'utilisateur. Cette procédure aboutit au fait que l'utilisateur en question a été authentifié par « l'AS » qui lui a transmis une « chose » (le ''TGT'') dont la validité est limitée dans le temps ; 
-C'est le fichier de configuration du royaume, commun ici à tous les protagonistes : +  * lorsque l'utilisateur souhaite utiliser un service soumis à une authentification par kerberos, sous réserve que l'application cliente qui doit communiquer avec ce service sache le faire, le client obtient silencieusement un « ticket de service » en faisant une requête non moins silencieuse au service TGS de kerberos, et que ce ticket de service lui ouvre les portes du service convoité.
-<code> +
-[realms] +
-MAISON.MRS = { +
-      kdc = 192.168.0.133          # kerberos.maison.mrs +
-      admin_server = 192.168.0.133 # kerberos.maison.mrs +
-      default_domain = MAISON.MRS +
-} +
- +
-[domain_realm] +
-      .maison.mrs = MAISON.MRS +
-       maison.mrs = MAISON.MRS +
- +
-[logging] +
-        default = FILE:/var/log/krb5.log +
-        kdc = FILE:/var/log/krb5kdc.log +
-        admin-server = FILE:/var/log/krb5adm.log +
- +
-[appdefaults] +
-        pam = { +
-                debug = true +
-                forwardable = true +
-                krb4_convert = false +
-        } +
-</code> +
-Pour l'instant, la partie ''[appdefaults]'' n'a pas d'utilité, mais si l'on y parle de ''pam'' c'est qu'il y a sans doute moyen d'utiliser kerberos pour les ouvertures de session... +
- +
-Le peu qu'il y a ici n'est pas très difficile à interpréter, nous passerons rapidement. La chose remarquable est que dans le royaume ''MAISON.MRS'', il y a un ''kdc'' et un ''admin_server''. Ils sont confondus ici sur la même machine (je n'ai que 4 Go de RAM), mais il est possible de placer ces deux fonctions sur des hôtes différents. Elles correspondent d'ailleurs à deux paquets différents : +
-  * ''krb5-kdc'' +
-  * ''krb5-admin-server'' +
-Les noms sont assez explicites. +
- +
-L'autre chose remarquable est que le nom dns du domaine est le même que celui du royaume kerberos. Ce n'est pas indispensable, mais souhaitable, d'autant que c'est ainsi dans Active Directory. +
- +
-En réalité, la définition des royaumes peut être plus complexe, un hôte peut appartenir à plusieurs royaumes et un utilisateur peut s'authentifier dans plusieurs royaumes, si nécessaire, mais ne compliquons pas inutilement les choses. +
- +
-==== le keytab d'apache ==== +
-Sur apache, nous avons un tableau de clés que l'on peut consulter avec la commande klist : +
-<code> +
-apache-krb:~# klist -k /etc/apache2/krb5.keytab  +
-Keytab name: FILE:/etc/apache2/krb5.keytab +
-KVNO Principal +
----- -------------------------------------------------------------------------- +
-   3 host/apache-krb.maison.mrs@MAISON.MRS +
-   3 host/apache-krb.maison.mrs@MAISON.MRS +
-   3 host/apache-krb.maison.mrs@MAISON.MRS +
-   3 host/apache-krb.maison.mrs@MAISON.MRS +
-   3 HTTP/apache-krb.maison.mrs@MAISON.MRS +
-   3 HTTP/apache-krb.maison.mrs@MAISON.MRS +
-   3 HTTP/apache-krb.maison.mrs@MAISON.MRS +
-   3 HTTP/apache-krb.maison.mrs@MAISON.MRS +
-</code> +
-Prenons-le comme tel pour le moment, nous comprendrons mieux plus tard. +
-==== configuration d'apache ==== +
-Il s'agit de la configuration par défaut du serveur par défaut à laquelle il a été ajouté les paramètres relatifs à l'authentification kerberos : +
-<html><pre class="code"> +
- &lt;Directory /var/www/&gt; +
-<span class="hly">         AuthName "Secure Access" +
-        AuthType Kerberos +
-         Krb5Keytab /etc/apache2/krb5.keytab +
-        KrbMethodK5Passwd off +
-         KrbSaveCredentials on +
-        require valid-user</span> +
- +
- Options Indexes FollowSymLinks MultiViews +
- AllowOverride None +
- Order allow,deny +
- allow from all +
- &lt;/Directory&gt; +
-</pre></html> +
-Pour ceux qui ont envie d'en savoir plus sur les paramètres que l'on peut passer au module, voyez [[http://modauthkerb.sourceforge.net/configure.html|le site dédié à ce projet]]. +
- +
-==== Le principal ==== +
-Dans l'usine kerberos, il a fallu que l'administrateur du royaume crée ce que l'on appelle des « principaux ». Cette liste est visible avec l'utilitaire kadmin, à condition que l'on s'identifie avec un compte d'administrateur du royaume. Notez bien la subtilité, ''chris'' n'est pas ''chris/admin''. D'ailleurs, nous allons retrouver dans la liste un « principal » pour chacun de ces utilisateurs du royaume. +
-<code> +
-root@pchris:~# kadmin -p chris/admin +
-Authenticating as principal chris/admin with password. +
-Password for chris/admin@MAISON.MRS:  +
-kadmin:  list_principals +
- +
-HTTP/apache-krb.maison.mrs@MAISON.MRS +
-K/M@MAISON.MRS +
-chris/admin@MAISON.MRS +
-chris@MAISON.MRS +
-host/apache-krb.maison.mrs@MAISON.MRS +
-host/kerberos.maison.mrs@MAISON.MRS +
-kadmin/admin@MAISON.MRS +
-kadmin/changepw@MAISON.MRS +
-kadmin/history@MAISON.MRS +
-kadmin/kerberos.maison.mrs@MAISON.MRS +
-krbtgt/MAISON.MRS@MAISON.MRS +
-</code>+
  
-Passons sur les détails, certains de ces principaux sont créés à l'installation de l'usine, d'autres ont été créés par l'administrateur : +Nous avons donc pu constater de façon subtile l'effet « SSO » de kerberos. Cet effet serait bien sûr beaucoup plus visible si en plus d'un service http, nous avions mis en place d'autres services, comme un système de fichier en réseau (NFS v4 par exemple), ssh, ftp voir aussi un proxy http comme squid.
-  * chris@MAISON.MRS +
-  * host/apache-krb.maison.mrs@MAISON.MRS +
-  * HTTP/apache-krb.maison.mrs@MAISON.MRS +
-entre autres. Nous retrouvons deux éléments qui figurent sur le tableau de clés de ''apache-krb.maison.mrs'' +
-===== Le snif d'enfer ===== +
-Notre utilisateur, qui a vraiment un niveau de curiosité aigu, a placé [[http://www.wireshark.org/|son sniffeur habituel]] sur le réseau et a observé des choses intéressantes. Nous n'entrerons pas dans le détail pour l'instant, mais voici quelques éléments remarquables : +
-<html><pre class="code"> +
-No.     Time        Source                Destination           Protocol Info +
-... +
-<span class="hly">      3 3.311180    192.168.0.16          192.168.0.133         KRB5     AS-REQ +
-      4 3.344897    192.168.0.133         192.168.0.16          KRB5     AS-REP</span> +
-... +
-      8 8.783804    192.168.0.16          192.168.0.134         HTTP     GET / HTTP/1.1  +
-... +
-<span class="bhlm">     10 8.784435    192.168.0.134         192.168.0.16          HTTP     HTTP/1.1 401 Authorization Required  (text/html)</span> +
-... +
-<span class="hlg">     12 18.798614   192.168.0.16          192.168.0.133         KRB5     TGS-REQ +
-     13 18.801013   192.168.0.133         192.168.0.16          KRB5     TGS-REP</span> +
-     14 18.803833   192.168.0.16          192.168.0.134         HTTP     GET / HTTP/1.1  +
-<span class="bhlg">     15 18.806722   192.168.0.134         192.168.0.16          HTTP     HTTP/1.1 200 OK  (text/html)</span> +
-... +
-</pre></html> +
-  * les lignes 3 et 4 sont générées par la commande ''kinit'', pour l'obtention du ''principal'' attribué à l'utilisateur ''chris'' ; +
-  * la ligne 10 représente la demande d'authentification faite par le serveur (192.168.0.134) au client (192.168.0.16), mais ceci ne se traduit pas par l'affichage de la page 401, car le navigateur, averti qu'il doit chercher l'existence d'un principal, va le faire silencieusement ; +
-  * les lignes 12 et 13 représentent une requête « TGS-REQ » que le client (192.168.0.16) fait au serveur kerberos (192.168.0.133), et la réponse du serveur kerberos ; +
-  * la suite montre que la requête http ''GET'' est à nouveau exécutée et que cette fois-ci le serveur apache répond favorablement.+
Démonstration simple: Dernière modification le: 10/02/2010 à 09:42 par prof