Kerberos

Kerberos est un système d'authentification réseau basé sur le principe d'un tiers de confiance. Les deux autres parties sont l'utilisateur et le service sur lequel l'utilisateur veut s'authentifier. Tous les services et applications ne savent pas utiliser Kerberos, mais pour ceux qui en sont capables, cela rapproche l'environnement réseau d'un système à authentification unique (Single Sign On ou SSO).

Cette section couvre l'installation et la configuration d'un serveur Kerberos, et propose quelques exemples de configurations de clients.

Aperçu

Si vous débutez avec Kerberos, il y a quelques termes qu'il est bon de comprendre avant de paramétrer un serveur Kerberos. La plupart des termes sont proches d'éléments qui peuvent vous être familiers dans d'autres environnements.

  • Donneur d'ordre : tous les utilisateurs, ordinateurs et services fournis par des serveurs doivent être définis comme « donneurs d'ordre » Kerberos.

  • Instances : sont utilisés pour les donneurs d'ordre de service et les donneurs d'ordre administratifs spéciaux.

  • Realms: the unique realm of control provided by the Kerberos installation. Think of it as the domain or group your hosts and users belong to. Convention dictates the realm should be in uppercase. By default, ubuntu will use the DNS domain converted to uppercase (EXAMPLE.COM) as the realm.

  • Centre de distribution de clé : (KDC) se compose de trois parties, une base de données de tous les donneurs d'ordre, le serveur d'authentification et le serveur accordant les tickets. Pour chaque domaine, il doit y avoir au moins un KDC.

  • Ticket d'octroi de ticket : émis par le serveur d'authentification (AS), le ticket d'octroi du ticket (TGT) est chiffré avec le mot de passe utilisateur qui n'est connu que par l'utilisateur et le KDC.

  • Serveur d'octroi de ticket : (TGS) génère sur demande des tickets de service aux clients.

  • Tickets : confirment l'identité des deux donneurs d'ordre. Un donneur d'ordre étant un utilisateur et l'autre un service demandé par l'utilisateur. Les tickets établissent une clé de chiffrage utilisée pour la communication sécurisée pendant la session authentifiée.

  • Fichiers Keytab : ce sont des fichiers extraits de la base de données KDC des « principals » et qui contiennent la clé de chiffrement pour un service ou un hôte.

To put the pieces together, a Realm has at least one KDC, preferably more for redundancy, which contains a database of Principals. When a user principal logs into a workstation that is configured for Kerberos authentication, the KDC issues a Ticket Granting Ticket (TGT). If the user supplied credentials match, the user is authenticated and can then request tickets for Kerberized services from the Ticket Granting Server (TGS). The service tickets allow the user to authenticate to the service without entering another username and password.

Serveur Kerberos

Installation

Pour cette discussion, nous allons créer un domaine MIT Kerberos avec les caractéristiques suivantes (les modifier en fonction de vos besoins) :

  • Domaine : EXEMPLE.COM

  • KDC primaire : kdc01.example.com (192.168.0.1)

  • KDC secondaire : kdc02.example.com (192.168.0.2)

  • Utilisateur principal : steve

  • Administrateur principal : steve/admin

It is strongly recommended that your network-authenticated users have their uid in a different range (say, starting at 5000) than that of your local users.

Before installing the Kerberos server a properly configured DNS server is needed for your domain. Since the Kerberos Realm by convention matches the domain name, this section uses the EXAMPLE.COM domain configured in Maitre primaire of the DNS documentation.

Also, Kerberos is a time sensitive protocol. So if the local system time between a client machine and the server differs by more than five minutes (by default), the workstation will not be able to authenticate. To correct the problem all hosts should have their time synchronized using the same Network Time Protocol (NTP) server. For details on setting up NTP see Synchronisation temporelle avec NTP.

La première étape dans la création d'un domaine Kerberos est d'installer les paquets krb5-kdc et krb5-admin-server. Dans un terminal saisissez :

sudo apt install krb5-kdc krb5-admin-server

You will be asked at the end of the install to supply the hostname for the Kerberos and Admin servers, which may or may not be the same server, for the realm.

Par défaut, le domaine est créé à partir du nom de domaine du KDC.

Ensuite, créez le nouveau domaine à l'aide de l'utilitaire kdb5_newrealm :

sudo krb5_newrealm

Configuration

The questions asked during installation are used to configure the /etc/krb5.conf file. If you need to adjust the Key Distribution Center (KDC) settings simply edit the file and restart the krb5-kdc daemon. If you need to reconfigure Kerberos from scratch, perhaps to change the realm name, you can do so by typing

sudo dpkg-reconfigure krb5-kdc
  1. Once the KDC is properly running, an admin user -- the admin principal -- is needed. It is recommended to use a different username from your everyday username. Using the kadmin.local utility in a terminal prompt enter:

    sudo kadmin.local
    Authentification en tant que donneur d'ordre root/admin@EXEMPLE.COM avec un mot de passe.
    kadmin.local: addprinc steve/admin
    WARNING: no policy specified for steve/admin@EXAMPLE.COM; defaulting to no policy
    Enter password for principal "steve/admin@EXAMPLE.COM": 
    Re-enter password for principal "steve/admin@EXAMPLE.COM": 
    Principal "steve/admin@EXAMPLE.COM" created.
    kadmin.local: quit
    

    In the above example steve is the Principal, /admin is an Instance, and @EXAMPLE.COM signifies the realm. The "every day" Principal, a.k.a. the user principal, would be steve@EXAMPLE.COM, and should have only normal user rights.

    Remplacez EXEMPLE.COM et steve par votre nom d'utilisateur de domaine et d'administrateur.

  2. Ensuite, le nouvel utilisateur admin a besoin des permissions ACL (Access Control List) appropriées. Les permissions sont configurées dans le fichier /etc/krb5kdc/kadm5.acl :

    steve/admin@EXAMPLE.COM        *
    

    This entry grants steve/admin the ability to perform any operation on all principals in the realm. You can configure principals with more restrictive privileges, which is convenient if you need an admin principal that junior staff can use in Kerberos clients. Please see the kadm5.acl man page for details.

  3. Redémarrez maintenant krb5-admin-server pour que les nouvelles ACL soient prises en compte :

    sudo systemctl restart krb5-admin-server.service
    
  4. Le nouveau « principal » d'utilisateur peut être testé en utilisant kinit utility :

    kinit steve/admin
    Mot de passe de steve/admin@EXAMPLE.COM :
    

    Après avoir saisi le mot de passe, utilisez klist pour afficher les informations du TGT (Ticket Granting Ticket, ticket d'octroi de tickets) :

    klist
    Credentials cache: FILE:/tmp/krb5cc_1000
            Principal: steve/admin@EXAMPLE.COM
    
      Issued           Expires          Principal
    Jul 13 17:53:34  Jul 14 03:53:34  krbtgt/EXAMPLE.COM@EXAMPLE.COM
    

    Where the cache filename krb5cc_1000 is composed of the prefix krb5cc_ and the user id (uid), which in this case is 1000. You may need to add an entry into the /etc/hosts for the KDC so the client can find the KDC. For example:

    192.168.0.1   kdc01.example.com       kdc01
    

    Replacing 192.168.0.1 with the IP address of your KDC. This usually happens when you have a Kerberos realm encompassing different networks separated by routers.

  5. La meilleure façon de permettre aux clients de déterminer automatiquement le KDC pour le domaine est d'utiliser les enregistrements DNS SRV. Ajoutez ce qui suit à /etc/named/db.exemple.com :

    _kerberos._udp.EXAMPLE.COM.     IN SRV 1  0 88  kdc01.example.com.
    _kerberos._tcp.EXAMPLE.COM.     IN SRV 1  0 88  kdc01.example.com.
    _kerberos._udp.EXAMPLE.COM.     IN SRV 10 0 88  kdc02.example.com. 
    _kerberos._tcp.EXAMPLE.COM.     IN SRV 10 0 88  kdc02.example.com. 
    _kerberos-adm._tcp.EXAMPLE.COM. IN SRV 1  0 749 kdc01.example.com.
    _kpasswd._udp.EXAMPLE.COM.      IN SRV 1  0 464 kdc01.example.com.
    

    Remplacez EXAMPLE.COM, kdc01, et kdc02 par vos noms de domaine, de serveur KDC primaire et secondaire.

    Consultez Service de nom de domaine (DNS) pour des instructions détaillées sur le paramétrage des DNS.

Votre nouveau domaine (realm) Kerberos est maintenant prêt à authentifier des clients.

KDC secondaire

Une fois que vous avez un centre de distribution de clés (KDC) sur votre réseau, il est conseillé d'avoir un KDC secondaire au cas où le principal deviendrait indisponible. En outre, si vous avez des clients Kerberos dans des réseaux différents (éventuellement séparés par des routeurs utilisant NAT), il est judicieux de placer un KDC secondaire dans chacun de ces réseaux.

  1. Tou d'abord, installez les paquets, et lors de la demande des noms de serveurs Kerberos et Admin, saisiissez le nom du serveur KDC primaire :

    sudo apt install krb5-kdc krb5-admin-server
    
  2. Une fois les paquets installés, créez un « principal » du KDC secondaire. Dans un terminal, saisissez :

    kadmin -q "addprinc -randkey host/kdc02.example.com"
    

    Ensuite, l'exécution de n'importe quelle commande kadmin nécessitera l'introduction du mot de passe du « principal » username/admin@EXAMPLE.COM.

  3. Extrayez le fichier keytab :

    kadmin -q "ktadd -norandkey -k keytab.kdc02 host/kdc02.example.com"
    
  4. Il devrait y avoir un fichier keytab.kdc02 dans le dossier actuel. Déplacez le vers /etc/krb5.keytab :

    sudo mv keytab.kdc02 /etc/krb5.keytab
    

    Si l'emplacement du fichier keytab.kdc02 est différent, adaptez le en conséquence.

    Vous pouvez également lister les « principals » d'un fichier Keytab à l'aide de klist, ce qui peut être utile au dépannage :

    sudo klist -k /etc/krb5.keytab
    

    L'option -k indique qu'il s'agit d'un fichier keytab.

  5. Ensuite, il doit exister un fichier kpropd.acl sur chaque KDC qui liste tous les KDC du domaine. Par exemple, sur les serveurs primaire et secondaire, créez le fichier /etc/krb5kdc/kpropd.acl :

    host/kdc01.example.com@EXAMPLE.COM
    host/kdc02.example.com@EXAMPLE.COM
    
  6. Créez une base de données vide sur le KDC secondaire :

    sudo kdb5_util -s create
    
  7. Lancez maintenant le démon kpropd, qui écoute les connexions depuis l'utilitaire kprop. kprop est utilisé pour transférer des fichiers de sauvegarde :

    sudo kpropd -S
    
  8. Depuis un terminal sur le KDC primaire, créez un fichier de sauvegarde de la base de données des « principals » :

    sudo kdb5_util dump /var/lib/krb5kdc/dump
    
  9. Décompressez le fichier keytab du KDC primaire et copiez le dans /etc/krb5.keytab :

    kadmin -q "ktadd -k keytab.kdc01 host/kdc01.example.com"
    sudo mv keytab.kdc01 /etc/krb5.keytab
    

    Assurez-vous qu'il y ait un hôte pour kdc01.example.com avant d'extraire le Keytab.

  10. L'utilitaire kprop envoie la base de données vers le serveur KDC secondaire :

    sudo kprop -r EXAMPLE.COM -f /var/lib/krb5kdc/dump kdc02.example.com
    

    Il devrait y avoir un message de succès si le transfert s'est bien passé. S'il y a un message d'erreur, vérifiez /var/log/syslog sur le KDC secondaire pour plus d'informations.

    Vous pouvez également créer une tâche cron pour mettre à jour périodiquement la base de données sur le KDC secondaire. Par exemple, ce qui suit va mettre à jour la base de données toutes les heures (notez que la grande ligne a été divisée pour l'adapter au format du document) :

    # m h  dom mon dow   command
    0 * * * * /usr/sbin/kdb5_util dump /var/lib/krb5kdc/dump && 
    /usr/sbin/kprop -r EXAMPLE.COM -f /var/lib/krb5kdc/dump kdc02.example.com
    
  11. De retour sur le KDC secondaire, créez un fichier stash qui contiendra la clé maître de Kerberos :

    sudo kdb5_util stash
    
  12. Finalement, démarrez le service krb5-kdc sur le KDC secondaire :

    sudo systemctl start krb5-kdc.service
    

The Secondary KDC should now be able to issue tickets for the Realm. You can test this by stopping the krb5-kdc daemon on the Primary KDC, then by using kinit to request a ticket. If all goes well you should receive a ticket from the Secondary KDC. Otherwise, check /var/log/syslog and /var/log/auth.log in the Secondary KDC.

Client Kerberos Linux

Cette section couvre la configuration d'un système Linux comme un client Kerberos. Ceci va autoriser l'accès à n'importe quel service gérant Kerberos une fois l'utilisateur correctement connecté au système.

Installation

Pour pouvoir s'authentifier sur un domaine Kerberos, les paquets krb5-user et libpam-krb5 sont nécessaires, ainsi que quelques autres qui ne sont pas obligatoires mais vous faciliteront la tâche. Pour installer ces paquets tapez la commande suivante dans un terminal :

sudo apt install krb5-user libpam-krb5 libpam-ccreds auth-client-config

Le paquet auth-client-config permet une configuration simple de PAM pour l'authentification depuis plusieurs sources. libpam-ccreds va mettre en cache les références de l'authentification pour vous permettre de vous connecter si le KDC (Key Distribution Center) n'est pas disponible. Ce paquet est également utile pour les portables qui s'identifient via Kerberos sur leur réseau professionnel, mais doivent également rester accessibles en dehors ce réseau.

Configuration

Pour configurer le client, tapez dans un terminal :

sudo dpkg-reconfigure krb5-config

Il vous sera alors demandé de donner le nom du domaine Kerberos. Si vous n'avez pas de DNS configuré avec des enregistrements SRV Kerberos, le menu vous demandera le nom de l'hôte KDC et du serveur d'administration du domaine.

dpkg-reconfigure ajoute des entrées au fichier /etc/krb5.conf pour votre domaine. Vous devriez avoir des entrées similaires à :

[libdefaults]
        default_realm = EXEMPLE.COM
...
[realms]
        EXEMPLE.COM = {
                kdc = 192.168.0.1
                admin_server = 192.168.0.1
        }

If you set the uid of each of your network-authenticated users to start at 5000, as suggested in Installation, you can then tell pam to only try to authenticate using Kerberos users with uid > 5000:

# Kerberos should only be applied to ldap/kerberos users, not local ones.
for i in common-auth common-session common-account common-password; do
 sudo sed -i -r \ 
 -e 's/pam_krb5.so minimum_uid=1000/pam_krb5.so minimum_uid=5000/' \ 
 /etc/pam.d/$i 
done 

Cela permettra d'éviter une demande de mot de passe (inexistant) Kerberos d'un utilisateur authentifié localement lors du changement de son mot de passe à l'aide de la commande passwd.

Vous pouvez tester la configuration en demandant un ticket à l'aide de kinit. Par exemple :

kinit steve@EXAMPLE.COM
Mot de passe pour steve@EXAMPLE.COM :

Lorsqu'un ticket a été accordé, les détails peuvent être affichés avec klist :

klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: steve@EXAMPLE.COM

Valid starting     Expires            Service principal
07/24/08 05:18:56  07/24/08 15:18:56  krbtgt/EXAMPLE.COM@EXAMPLE.COM
        renew until 07/25/08 05:18:57


Kerberos 4 ticket cache: /tmp/tkt1000
klist: You have no tickets cached

Ensuite, utilisez auth-client-config pour configurer le module libpam-krb5 pour demander un ticket lors de l'ouverture de session :

sudo auth-client-config -a -p kerberos_example

Vous devriez maintenant recevoir un ticket dès qu'une ouverture de session avec authentification est réussie.

Ressources