Table of Contents

Kerberos

Présentation

This documentation will explain how to use Active Directory as Kerberos server, and provide transparent authentication for one or multiple AD domains.

You can use Kerberos in LL::NG with the following authentication modules:

Pré-requis

Valeurs d'exemple

Nous utilisons les valeurs suivantes dans nos exemples

Horloge des serveurs

Il est impératif que les serveurs LL::NG et AD soient à la même heure. Il est recommandé d'utilisé NTP à cet effet.

DNS

The auth.example.com must be registered in the DNS server (which is Active Directory). The reverse DNS of auth.example.com must return the portal IP.

If you have a SSO cluster, you must setup a Virtual IP in cluster and register this IP in DNS.

SSL

SSL is not mandatory, but it is strongly recommended. Your portal URL should be https://auth.example.com.

Configuration du navigateur web

Firefox

Aller à about:config dans un onglet et chercher trusted. Éditer la propriété network.negotiate-auth.trusted-uris et la mettre à la valeur example.com.

Internet Explorer

Ajouter https://auth.example.com comme site approuvé.

Vérifier dans les paramètres de sécurité que l'authentification Kerberos est autorisée.

Single AD domain

Configuration du client Kerberos

Sur le serveur LL::NG, éditer /etc/krb5.conf : 

[libdefaults]
 default_realm = EXAMPLE.COM
 dns_lookup_kdc = false
 dns_lookup_realm = no
 ticket_lifetime = 24h
 forwardable = yes
 renewable = true
 
[realms]
 EXAMPLE.COM = {
  kdc = ad.example.com
  admin_server = ad.example.com
 }
 
[domain_realm]
 .example.com = EXAMPLE.COM
 example.com = EXAMPLE.COM

On peut vérifier que Kerberos fonctionne en essayant d'obtenir un ticket pour un utilisateur du domaine (par exemple coudot) : 

kinit coudot@EXAMPLE.COM

Un mot-de-passe peut être demandé. Lister ensuite les tickets : 

klist -e

On doit trouver un ticket krbtgt : 

Valid starting     Expires            Service principal
06/04/15 15:43:24  06/05/15 01:43:29  krbtgt/EXAMPLE.COM@EXAMPLE.COM
        renew until 06/05/15 15:43:24, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96

On peut alors fermer la sessions Kerberos : 

kdestroy

Obtenir un fichier table de clef

Il faut lancer cette commande dans Active Directory: 

ktpass -princ HTTP/auth.example.com@EXAMPLE.COM -mapuser KERB_AUTH@EXAMPLE.COM -crypto DES-CBC-MD5 -ptype KRB5_NT_PRINCIPAL -mapOp set -pass <PASSWORD> -out c:\auth.keytab
Les valeurs passées dans -crypto et -ptype dépendent de la version d'Active Directory et de celle des stations de travail. On peut par exemple utiliser RC4-HMAC-NT comme protocole de chiffrement si DES n'est pas supporté par les stations de travail (c'est le cas par défaut sur Window 8 par exemple).

Le fichier auth.keytab doit ensuite être copié (par un média sûr) sur le serveur Linux (par exemple dans /etc/lemonldap-ng).

Changer les droits sur le fichier keytab : 

chown apache /etc/lemonldap-ng/auth.keytab
chmod 600 /etc/lemonldap-ng/auth.keytab

On peut vérifier la validité du fichier table de clefs en essayant de demander un ticket de service, et en le comparant au contenu de la table de clefs.

Ouvrir une session Kerberos (comme effectué dans l'étape précédente) : 

kinit coudot@example.com

Demander un ticket de service : 

kvno HTTP/auth.example.com@EXAMPLE.COM

Le résultat de la commande doit être : 

HTTP/auth.example.com@EXAMPLE.COM: kvno = 3

Lire le ticket de service : 

klist -e

On doit trouver un ticket de ce genre : 

06/04/15 16:28:49  06/05/15 02:28:11  HTTP/auth.example.com@EXAMPLE.COM
        renew until 06/05/15 16:28:07, Etype (skey, tkt): arcfour-hmac, arcfour-hmac

La session Kerberos peut être fermée : 

kdestroy

Comparer maintenant le résultat ci-dessus avec la même requête effectuée au travers de la table de clefs : 

klist -e -k -t /etc/lemonldap-ng/auth.keytab

Le résultat de la commande doit être : 

Keytab name: FILE:/etc/lemonldap-ng/auth.keytab
KVNO Timestamp         Principal
---- ----------------- --------------------------------------------------------
   3 01/01/70 01:00:00 HTTP/auth.example.com@EXAMPLE.COM (arcfour-hmac)

Les points importants à vérifier sont :

Multiple AD domains

Configuration du client Kerberos

Les deux domaines doivent être définis dans /etc/krb5.conf : 

[libdefaults]
 default_realm = EXAMPLE.COM
 dns_lookup_kdc = false
 dns_lookup_realm = no
 ticket_lifetime = 24h
 forwardable = yes
 renewable = true
 
[realms]
 EXAMPLE.COM = {
  kdc = ad.example.com
  admin_server = ad.example.com
  default_domain = EXAMPLE.COM
 }
 ACME.COM = {
  kdc = ad.acme.com
  admin_server = ad.acme.com
  }
 
[domain_realm]
 .example.com = EXAMPLE.COM
 example.com = EXAMPLE.COM
 .acme.com = ACME.COM
 acme.com = ACME.COM

On doit pouvoir ouvrir une session Kerberos dans chaque domaine : 

kinit coudot@EXAMPLE.COM
klist -e
kdestroy
kinit coudot@ACME.COM
klist -e
kdestroy

Obtenir un fichier table de clef

Il faut obtenir une table de clefs pour chaque nœud dans chaque domaine. Ce qui signifie que la commande ktpass doit être lancée dans les deux AD.

On a donc 2 tables de clefs pour chaque nœud, par exemple :

Il faut concaténer les 2 fichiers, merci à la commande ktutil : 

ktutil
ktutil: read_kt node1-example.keytab
ktutil: read_kt node1-acme.keytab
ktutil: write_kt /etc/lemonldap-ng/auth.keytab
ktutil: quit

On peut ensuite effacer les tables de clefs originales et protéger la table de clefs finale : 

chown apache /etc/lemonldap-ng/auth.keytab
chmod 600 /etc/lemonldap-ng/auth.keytab

Autres documents

Pour en savoir plus :