Sur serveur Windows, cela est très simple grâce au module Apache SSPI. Il suffit de l’utiliser avec un minimum de configuration sur une machine déjà intégrée dans le domaine et c’est tout. C’est bien la première fois d’ailleurs que je parle de serveur Apache sur mon blog, mais cela est dû au fait que 1) certains clients l’utilisent malheureusement exclusivement, et 2) il faut avouer que certains de ses modules sont quand même bien efficaces, notamment celui-ci.

Bref passons, ce qui nous intéresse ici, c’est un poil plus complexe, c’est de le faire fonctionner ce maudit SSO sur machine Linux. Alors entrons dans le vif du sujet.

Prerequis

Bien entendu, il faut que la machine Linux soit déjà entrée dans le domaine Windows. Je ne parlerai pas de toute cette partie là dans cet article afin de le garder conçis. Vous pouvez vous réferer à ce tutoriel qui a l’air d’aborder proprement le sujet.

Tout ceci a été effectué sur machines RedHat 8. Pour les versions antérieures, il est possible de passer par le mod_auth_kerb qui semble bien plus simple à utiliser (et surtout plus verbeux quand vient le temps du debuggage).

Pour RedHat 8, nous allons avoir besoin d’installer le module GSSAPI, le tout sur un Apache 2.4.

Dans les exemple qui vont suivre, je vais utiliser un nom de domaine interne domaine.local au sein d’un domaine AD DOM.LOCAL. Je pars donc du principe que la conf krb5 de la machine Linux est déjà en place concernant DOM.LOCAL.

Côté domaine Active Directory

Côté domaine, il est nécessaire de créer un compte de service qui sera utilisé par Apache pour s’authentifier et communiquer avec Active Directory en utilisant le protocole Kerberos.

Il s’agit d’un utilisateur créé sur votre domaine, qu’il est de bon ton de dédier à ce service HTTP. Vous avez besoin de spécifier un mot de passe pour l’étape d’après. Pour l’exemple, cet utilisateur s’appellera sa12345 sur le domaine local.

En effet, la prochaine étape est la création du keytab. En deux mots, il s’agit d’un fichier permettant de décoder les informations venant d’Active Directory pour montrer patte blanche quant à la bonne gestion d’un service (via le TGS Kerberos envoyé par le client). Pour cela, se rendre sur un contrôleur de domaine et entrer dans un terminal une ligne de commande équivalente à :

ktpass.exe -princ HTTP/[email protected] -ptype KRB5_NT_PRINCIPAL -out domaine.local.keytab -crypto all -pass * -mapuser DOM\sa12345

Le mot de passe est alors demandé de façon interactive plutôt qu’affiché en clair sur le terminal. Il faut alors entrer celui positionné sur l’utilisateur compte de service créé plus haut.

Il faut maintenant créer un SPN (Service Principal Name) correspondant au principal spécifié sur le keytab juste au dessus, au sein du compte de service. Au moins deux façons de le faire :

• Le créer via l’AttributeEditor en ouvrant les propriétés du compte de service, dans le champ ServicePrincipalNames
• Utiliser la commande SetSPN dans un terminal sur un contrôleur de domaine:

setspn -a HTTP/domaine.local DOM\sa12345

Enfin, au niveau de l’utilisateur compte de service, il faut activer le support de Kerberos AES 256 bits. Là également, deux méthodes possibles :

• Cocher la case “This account supports Kerberos AES 256 bit encryption” dans les paramètre du compte de service sa12345 (onglet Account, de mémoire).
• via Powershell en utilisant la commande suivante (pas testée mais ça devrait fonctionner)

Set-ADUser -Identity sa12345 -KerberosEncryptionType AES256

Fiouu, on en a fini côté Active Directory ! Maintenant, passons à la partie serveur Linux

Coté serveur

Bien entendu, vous pouvez commencer par rappatrier le fichier keytab créé précédemment. Ayant une clé chiffrée, ce fichier peut être considéré comme sensible, donc lui appliquer les droits qui vont bien (chmod 400 par exemple)

Une fois le module mod_auth_gssapi activé sur Apache (la méthode dépend de votre distribution, je pense que si vous en êtes là, vous savez comment faire), une petite configuration comme celle-ci devrait faire l’affaire :

  <Location />
    AuthType GSSAPI
    AuthName "GSSAPI Single Sign On Login"
    GssapiCredStore keytab:/etc/httpd/domaine.local.keytab
    GssapiAllowedMech krb5
    Require valid-user

    GssapiUseSessions On
    Session on
    SessionCookieName gssapi_session path=/;httponly;secure;
    GssapiSessionKey key:ampkc2Jmeml1ZWZramtqaGZkb2V6b2llenplaHN1aW8=
  </Location>

La première partie de la configuration fait référence au type d’Auth, et surtout à la localisation de votre fichier keytab. Apache doit y avoir accès en lecture au moins.

La deuxième partie permet d’activer les sessions Apache. Celles-ci permettent d’éviter à l’utilisateur de s’authentifier à chaque requête HTTP. Cela est donc optionnel mais grandement recommandé ! La clé de session doit être de 32 octets et encodée en base64. Pour la créer vous même c’est très simple, depuis votre serveur :

echo $RANDOM | md5sum | head -c 32|base64

Au redémarrage de votre serveur HTTP, vous ne devriez avoir aucune erreur. En cas de souci, vous pourrez activer les logs Debug de votre VirtualHost/Conf apache, mais si le souci est purement Kerberos, vous risquez d’avoir du mal à debugger ça. La faute au module qui n’est pas très verbeux en cas d’erreur.

Côté client

Dernier détail et non des moindre, votre navigateur doit considérer le serveur Linux configuré précédemment comme de confiance. Sur feu Internet Explorer, ça se verbalisait soit par la zone de confiance (Trusted), soit par la zone Local Intranet, mais je crois que cela ne change pas sur Edge. Je n’ai aucune connaissance sur cette partie (bien) malheureusement.

En espérant que cette petite check-list ait pu vous permettre de mettre ce SSO en place plus rapidement qu’il m’ait été donnée de faire, faute de documentation de qualité sur le web. C’est un petit chemin semé d’embûches mais la satisfaction n’en est que plus grande une fois l’authentication transparente fonctionnelle !