Cette documentation explique comment utiliser Active Directory comme serveur Kerberos, et fournir une authentification transparente aux utilisateurs du domaine AD à LL::NG.
On présente ici plusieurs architectures:
Nous utilisons les valeurs suivantes dans nos exemples
Il est impératif que les serveurs LL::NG et AD soient à la même heure. Il est recommandé d'utilisé NTP à cet effet.
Tous les noms doivent être enregistrés dans le serveur DNS (qui est Active Directory). Il est préférable que le DNS inverse soit capable de résoudre tous les noms.
Il est recommandé de créer un compte AD pour chaque serveur LL::NG. Chaque compte tiendra le nom principal de service (SPN) du serveur LL::NG.
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
.
Ajouter https://auth.example.com
comme site approuvé.
Vérifier dans les paramètres de sécurité que l'authentification Kerberos est autorisée.
Sur CentOS/RHEL :
yum install mod_auth_kerb
Sur Debian/Ubuntu :
apt-get install libapache2-mod-auth-kerb
Ce module doit être chargé par Apache (directive LoadModule).
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
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
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 :
See Kerberos authentication module or Apache authentication module configuration (deprecated).
La configuration du client Kerberos est la même qie pour un serveur LL::NG unique.
Les commandes sur Active Directory :
ktpass -princ HTTP/node1.example.com@EXAMPLE.COM -mapuser KERB_NODE1@EXAMPLE.COM -crypto DES-CBC-MD5 -ptype KRB5_NT_PRINCIPAL -mapOp set -pass <PASSWORD> -out c:\authnode1.keytab ktpass -princ HTTP/node2.example.com@EXAMPLE.COM -mapuser KERB_NODE2@EXAMPLE.COM -crypto DES-CBC-MD5 -ptype KRB5_NT_PRINCIPAL -mapOp set -pass <PASSWORD> -out c:\authnode2.keytab
Copier les tables de clefs générés sur chaque nœud (en la renommant en auth.keytab pour avoir la même configuration Apache sur chaque nœud).
Changer les droits sur le fichier keytab :
chown apache /etc/lemonldap-ng/auth.keytab chmod 600 /etc/lemonldap-ng/auth.keytab
La configuration est la même qie pour un serveur LL::NG unique.
Le seul chagement dans la configuration d'Apache est le the KrbServiceName
qui doit être mis à Any:
KrbServiceName Any
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
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
La configuration est la même qie pour un serveur LL::NG unique.
La configuration est la même que pour un domaine AD unique.
Pour en savoir plus :