Test du module mod_auth_sspi

Remarque : Ce billet n'a pas vocation a explicité ni le protocole NTLM ni le mod_auth_sspi mais simplement à présenter un mémento des différentes directives, de leurs mises en œuvre et indiquer quelques pièges dans lesquels il est préférable de ne pas tomber.

Mod_auth_SSPI, c'est quoi ?

Mod_auth_SSPI est un module pour le serveur Apache HTTPD qui permet de réaliser une authentification NTLM. Le module mod_auth_sspi permet d'éviter de saisir un login/mot de passe depuis un poste Microsoft Windows et de réaliser une authentification sur la base de l'identité transmise par le navigateur.

Pour que cela fonctionne, il faut tout d'abord vérifier que le navigateur est en capacité de transmettre l'identité de l'utilisateur ayant ouvert une session de travail Windows.

Plusieurs éléments sont à vérifier :

1. que le système d'exploitation soit configuré pour transmettre l'identité NTLM,
2. que le navigateur soit configuré pour transmettre l'identité NTLM.

Vérifier que le système d'exploitation est configuré pour transmettre l'identité NTLM ?

1. Sur le poste de l'utilisateur, Ouvrir le "Panneau de configuration", puis les "Outils d'administration" et enfin la "Stratégie de sécurité locale",
2. Rechercher la stratégie réseau "Niveau d'authentification Lan Manager",
3. Vérifier quelle soit configurée à "Envoyer les réponses LM et NTLM".

Vérifier que le navigateur est configuré pour transmettre l'identité NTLM ?

Sous Firefox,

1. Ouvrir la page de configuration "about:config",
2. Définir le paramètre "network.automatic-ntlm-auth.trusted-uris" en indiquant les URL des sites vers lesquels l'identité NTLM doit être transmises.

Sous Internet Explorer,

1. Ouvrir la fenêtre d'options,
2. Sélectionner l'onglet "Avancé",
3. Vérifier que le paramètre "Activer l'authentification Windows intégrés" soit correctement positionné.
4. Sélectionner l'onglet "Sécurité" et Sélectionner la zone de sécurité dans laquelle le site à accéder est attachée,
5. Personnaliser cette zone en activant le paramètre "Authentification de l'utilisateur" / "Connexion" / "Connexion automatique avec le nom d'utlisateur et le mot de passe actuel".

Le poste client étant correctement paramétré, il faut maintenant installer et configurer le module mod_auth_sspi.

Pour cela :

1. Télécharger le fichier suivant :http://sourceforge.net/projects/mod-auth-sspi/
2. Dé-zipper le contenu dans le répertoire "modules" du serveur Apache.
3. Configurer le fichier conf/httpd.conf en ajoutant les lignes suivantes :

AuthName "Accès sécurisé"

AuthType SSPI

SSPIAuth On

SSPIAuthoritative On

#SSPIOfferBasic Off

#SSPIBasicPreferred Off

SSPIDomain <WINDOWS_DOMAINE_NAME>

SSPIOmit Domain On

SSPIUsernameCase lower

require valide-user

Et voilà...

Un petit memento

Parce qu'il est difficile de trouver de la documentation, voici donc un petit memento des directives :

• require valide-user

Si la directive "require valide-user" n'est pas positionnée, alors le ticket NTLM n'est pas transmis.
L'ordre de configuration de la directive "require valide-user" avant ou après la configuraiton SSPI semble ne pas modifier le comportement du module.

• SSPIOmitDomain

En cas de succès lors de la phase d'authentification, cette directive permet d'identifier l'utilisateur par un nom du type DOMAIN\USER lorsque la directive est positionnée à "Off", ou par USER lorsqu'elle est positionnée à "On".
Cette directive n'a aucun impact sur la manière dont l'authentification est effectuée.

• SSPIUsernameCase

En cas de succès lors de la phase d'authentification, cette directive permet d'identifier l'utilisateur en miniscule ("lower") ou majuscule ("upper").
Cette directive n'a aucun impact sur la manière dont l'authentification est effectuée.

• SSPIAuth

Positionnée à "On", cette directive permet d'activer le module SSPI.

• SSPIAuthoritative

Positionnée à "On", cette directive permet de communiquer l'identité de l'utilisateur à d'autres modules d'authentification lorsque l'authentification SSPI a échouée.

• SSPIOfferSSPI

cf. SSPIAuthoritative.

Avis général

 

Globalement, le module fonctionne, mais je dois avouer rencontrer quelques difficultés à le mettre en place dans un environnement de production. En effet, dans un certain nombre de cas, une fenêtre de demande de login/mot de passe s'affiche; il ne répond donc pas à mon besoin.

De nombreux tests ont été effectué sans jamais pouvoir dégager une régle de gestion fiable expliquant le comportement. Il faudrait probablement analyser le code source pour cerner au mieux les raisons d'un tel comportement.

Néanmoins, voici en vrac, quelques unes des constations effectuées :

En cas de saisie d'un login et mot de passe, celui-ci doit être saisie sous la forme DOMAIN\USER (sous firefox). Internet Explorer (8) semble supporter la saisie directement du login USER.

ATTENTION 

 

Sous firefox :

• Fonctionne lorsque le nom du serveur est localhost.
• Ne fonctionne pas avec l'adresse IP 127.0.0.1, l'identifiant résolu est "".
• Ne fonctionne pas avec l'adresse IP public du serveur, l'identifiant résolu est "".
• Ne fonctionne pas avec un nom DNS résolu par le fichier hosts.

Sous Internet Explorer :

• Ne fonctionne pas lorsque le nom du serveur est localhost, erreur 403.
• Ne fonctionne pas avec l'adresse IP 127.0.0.1, erreur 403.
• Fonctionne avec l'adresse IP public du serveur.
• Ne fonctionne pas avec un nom DNS résolu par le fichier hosts.

 

Dernière minute

- L'ajout de l'URL du serveur (ou l'IP) dans la zone de confiance du navigateur Internet Explorer semble résoudre le problème du login/mot de passe demandé malgré la configuration des directives ci-dessus.
- L'ajout du hostname windows dans le fichier host semble débloquer la situation décrite dans le paragraphe "ATTENTION".