Documentation

Authentification Kerberos

Un repository Kerberos est utilisé pour authentifier et identifier les utilisateurs d’un domaine. Il est ainsi possible de gérer les accès aux services de ce domaine via des tickets, délivrés par le KDC (Kerberos Domain Controler) auprès des utilisateurs de ce domaine après authentification.

Présentation

repo-kerberos

Le protocole d’authentification Kerberos est chargé d’authentifier, d’autoriser et de surveiller les utilisateurs voulant accéder aux ressources et services du réseau. Kerberos introduit également le principe de Single Sign-On (SSO), ainsi avec une authentification unique l’utilisateur aura accès aux services du réseau nécessitant une identification Kerberos.

Dans cet article nous présenterons comment créer et configurer un repository d’authentification Kerberos, afin de pouvoir gérer l’accès à une ou plusieurs applications en fonction des identifiants présents dans le KDC.

Pré-requis

Pour pouvoir configurer correctement un repository d’authentification Kerberos, il est nécessaire en tout premier lieu de disposer de :

  • Un serveur Kerberos,
  • Un “service” Kerberos, permettant de contacter le KDC (Kerberos Domain Controler) pour vérifier la validité des tickets fournis à Vulture,
  • La “keytab” de ce service, permettant d’authentifier celui-ci auprès du KDC sans avoir à taper de mot de passe.

ATTENTION : Le service utilisé par Vulture pour contacter le KDC devra être de la forme suivante :
HTTP/<nom_machine>.<domaine>@<ROYAUME>
Par exemple, la machine Vulture ayant le nom d’hôte “vulture.testing.tr”, appartenant au royaume “TESTING.TR”, le service à créer dans le KDC devra être :
HTTP/vulture.testing.tr@TESTING.TR

De plus, pour tester la validité de la keytab, il est recommandé d’utiliser la commande suivante :
kinit -k -t <keytab> <service> depuis une autre machine du royaume sur laquelle la configuration est correcte.

Ajout d’un repository Kerberos

Pour ajouter un repository Kerberos, il faut se rendre dans le menu, plus précisément dans la section “Repository”, puis “Kerberos”. Une fois sur la page, cliquer sur “Add an entry”.

Configuration du repository

repo-kerberos

  • Repository name : Nom permettant de désigner le repository. Ce nom sera utilisé ailleurs dans les interfaces de la GUI.
  • Kerberos realm : Royaume Kerberos des utilisateurs à authentifier/identifier
  • Kerberos domain realm : Domaine du royaume Kerberos
  • KDCs : Liste du/des Kerberos Domain Controler(s) de ce domaine
  • Admin server : Hôte sur lequel le service d’authentification (AS) kerberos est lancé
  • KRB5 service name : Service utilisé par Vulture pour contacter le KDC et vérifier les tickets
  • Service keytab : Keytab associée à ce service

A noter :
1. Contrairement aux autres repository, il est possible de sauvegarder celui-ci sans tester la connexion. En effet, la configuration Kerberos est générée lors de la sauvegarde, ainsi si vous voulez tout de même tester la connexion, il faudra le sauvegarder, puis le rééditer et tester.
2. De plus, lors de la sauvegarde, la keytab est testée par rapport à la configuration saisie ; il n’est donc pas possible d’importer une keytab invalide.

Résolution des problèmes de connexions

Dans le cas où des problèmes de connexions surviendraient, plusieurs éléments sont à vérifier :

  1. Les logs, notamment les fichier présents dans /var/log/Vulture/gui/, sont la première chose à vérifier lors de l’enregistrement du repository
  2. Le fichier /etc/krb5.conf étant généré de manière automatique par la GUI, il semble pertinent de vérifier son contenu
  3. La keytab, normalement importée dans le fichier /etc/krb5.keytab, est à vérifier en utilisant la commande suivante :
    kinit -k -t /etc/krb5.keytab HTTP/<service>@<ROYAUME> en remplaçant par le service saisi dans la GUI.
  4. Si ces 3 premiers points sont corrects, il est fort possible que le problème provienne de la configuration du KDC, ou du service dans le KDC, ou même de la keytab dans le KDC.

Authentification Kerberos sur une application

Pour configurer une application à utiliser Kerberos comme repository d’authentification, il faut éditer l’application en question, et se rendre dans l’onglet “Authentication”.

Le champ “Authentication type” propose 3 types d’authentification pour authentifier les utilisateurs :

  • HTML Form : présente un portail (formulaire) à l’utilisateur pour qu’il puisse saisir ses identifiants,
  • Basic Authentication : requière une authentification de type Basic,
  • Kerberos Authentication : requière un ticket kerberos qui est envoyé par le navigateur du client, s’il en possède un, à Vulture.

Dans le cas des 2 premiers, des identifiants (login+mot de passe) sont requis. Ceux-ci sont vérifiés auprès du KDC grâce à la commande kinit qui permet de récupérer un ticket à partir d’identifiants.

Dans le cas du troisième, un ticket est nécessaire. Ticket préalablement créé sur le poste du client souhaitant accéder à l’application protégée grâce à la commande kinit. Ce ticket est envoyé par le navigateur à Vulture qui se charge de vérifier celui-ci auprès du KDC en utilisant le service (et sa keytab) demandés lors de la configuration du repository (champ “KRB5 Service name”). De plus, pour pouvoir choisir cette option il faudra obligatoirement configurer un repository de type Kerberos en tant que “Authentication repository” ou/et “Authentication repository fallback”.

SSO Kerberos sur une application

Il est également possible de configurer le “Single Sign-On” (SSO) Kerberos sur une application, le principe étant le suivant :

repo-kerberos

  1. Le client demande le contenu de l’application protégée à Vulture
  2. Vulture requière une authentification
  3. Le client envoie ses identifiants
  4. Vulture demande un ticket au client grâce au identifiants
  5. Le KDC renvoie un ticket ou une erreur à Vulture
  6. Si le KDC a renvoyé un ticket, alors Vulture considère que les identifiants sont corrects et déclenche le SSO
  7. Vulture envoie le ticket précédemment créé à l’application Web nécessitant une authentification Kerberos
  8. L’application vérifie le ticket auprès du KDC
  9. Le KDC identifie le ticket et renvoie OK/NOK.
  10. Si tout s’est correctement déroulé, Vulture renvoie le contenu de la page demandée au client.

Pour pouvoir configurer une application dans Vulture à utiliser le SSO Kerberos, il faut éditer celle-ci et se rendre dans l’onglet “SSO Forward”. Dans cet onglet, le champ le plus important est le suivant :

  • “Select forward type” : Permet de choisir dans quel format les informations d’identification sont envoyées à l’application protégée.

Dans notre cas, la valeur de ce champ doit être “Kerberos Authentication”. De ce fait, différents champs sont présents :

  • “Kerberos service of the app” : Correspond au service utilisé par l’application pour vérifier les tickets auprès du KDC. Ne correspond pas au champ “KRB5 Service name” du repository Kerberos.
  • “Forward credentials” : Sert à définir quels identifiants sont envoyés, “using Autologon” permet d’envoyer à l’application les identifiants saisis par le client lors de l’authentification, “using SSO learning” permet de demander et de sauvegarder les identifiants à envoyer en fonction des identifiants saisis lors de l’authentification.

Les 3 derniers champs permettent de configurer de manière plus précise l’échange entre Vulture et l’application lors de l’envoi des identifiants :

  1. “Send Authorization header only to the login page” : Permet de n’envoyer le ticket qu’une seule fois, à l’url saisie
  2. “Follow the 301/2 redirection after SSO request” : Suivre une éventuelle redirection (code HTTP 301 ou 302) après l’envoi du ticket
  3. “Immediately return the SSO response” : Retourner immédiatement la réponse de l’application au client

ATTENTION : Dans le cas du SSO Kerberos, il ne faut pas désactiver la dernière option (“Immediately return the SSO response”) si l’option 1 (“Send Authorization header only to the login page”) est activée.
De plus, il est fortement conseillé sauf cas exceptionnel de désactiver la première option. En effet, une application Kerberos protégée par Vulture nécessite un ticket à chaque requête ; ainsi si l’option 1 est activée, toutes les pages sauf la première retourneront une erreur “Authentication Required”.