avec Active Directory

Si votre réseau est un peu important, que vous avez à gérer de nombreux utilisateurs, il se peut que vous ayez déjà une base de donnée contenant des couples user / password quelque part. L’idée serait alors excellente de vouloir configurer squid pour qu’il identifie les utilisateurs depuis cette base. Les annuairesLDAP sont très souvent utilisés dans ce but, et squid dispose de ce qu’il faut pour y arriver.

Nous allons voir comment faite dans le cas d’un annuaire LDAP un peu particulier.

Active Directory n’est autre, en effet, qu’un annuaire LDAP revu et compliqué (enrichi ?) par Microsoft. Il est utilisé dans les domaines Microsoft, entre autres choses, pour stocker la base de donnée des utilisateurs, permettant ainsi la gestion de leurs comptes de façon centralisée. Un protocole de type Kerberos est employé pour l’authentification de l’utilisateur lorsqu’il ouvre une session sur un hôte quelconque du domaine.

Les systèmes GNU/Linux disposent de tous les outils pour intégrer un hôte Linux à un domaine Microsoft. En effet, dans cette architecture, les hôtes disposent aussi d’un compte dans le domaine, ce dernier étant à rapprocher du concept de royaume (realm) de Kerberos.

Le pré requis sera donc d’intégrer notre proxy au domaine Microsoft. Une fois cette opération réalisée, il deviendra possible d’authentifier un utilisateur en s’appuyant sur Active Directory.

Nous arriverons à un mode de fonctionnement assez agréable, puisque les utilisateurs déjà authentifiés dans le domaine Microsoft n’auront pas besoin de se ré identifier pour être autorisés à passer le proxy. La procédure a été vérifiée sur des hôtes clients Windows XP, elle doit être également validée sur des hôtes clients Linux intégrés au domaine et dont les sessions des utilisateurs sont authentifiées par Actrive DIrectory, mais je ne l’ai pas expérimenté.

Il nous faut installer les utilitaires clients Kerberos 5, samba 3 et winbind :

apt-get install  krb5-user krb5-config samba-common samba winbind

Ne vous préoccupez pas trop de la configuration post installation, nous la reprendrons en tièrement par la suite.

N’étant pas spécialiste de kerberos, loin s’en faut, je me contenterai de vous donner une recette. Nous supposons que nous avons un domaine (Active Directory) qui dispose du nom domaine.mrs (et DOMAINE pour la compatibilité pré-2000) :

~# cat /etc/krb5.conf
[libdefaults]
        default_realm = DOMAINE.MRS
        dns_lookup_realm = false
        dns_lookup_kdc = false

[realms]
DOMAINE.MRS = {
         kdc = 192.168.0.1
         kdc = 192.168.0.2
        admin_server = 192.168.0.1
        default_domain = DOMAINE.MRS
}

[domain_realm]
        .domaine.mrs = DOMAINE.MRS
        domaine.mrs = DOMAINE.MRS

[logging]
        default = FILE:/var/log/krb5.log
        kdc = FILE:/var/log/krb5kdc.log
        admin-server = FILE:/var/log/krb5adm.log

[appdefaults]
        pam = {
                debug = false
                ticket_lifetime = 36000
                renew_lifetime = 36000
                forwardable = true
                krb4_convert = false
        }

• les adresses IP indiquées par kdc dans le paragraphe [realms] correspondent à vos contrôleurs de domaine Microsoft (vous en avez bien deux, n’est-ce pas ?) ;
• l’adresse IP indiquée par admin_server correspond au contrôleur « Maître d’opérations » (vous avez, n’est-ce pas, les 5 rôles « FSMO » attribués au même contrôleur ?).

La commande « kinit » va permettre de vérifier que l’on peut obtenir un ticket kerberos pour un utilisateur du domaine ActiveDirectory :

# kinit -V machin@DOMAINE.MRS
Password for machin@DOMAINE.MRS: 
Authenticated to Kerberos v5

La commande « klist » permet de lister les tickets obtenus :

# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: machin@DOMAINE.MRS

Valid starting     Expires            Service principal
11/15/07 10:36:18  11/15/07 20:36:22  krbtgt/DOMAINE.MRS@DOMAINE.MRS
        renew until 11/15/07 20:36:18

Kerberos 4 ticket cache: /tmp/tkt0
klist: You have no tickets cached

machin@domaine.mrs a bien été authentifié et le ticket kerberos a bien été reçu.

Non ? Alors revoyez votre configuration parce qu’habituellement, ça fonctionne bien.

# cat /etc/samba/smb.conf
[global]

        workgroup = DOMAINE
        realm = DOMAINE.EME
        security = ADS
        password server = 192.168.0.1 192.168.0.2
        client use spnego = yes 
        client ntlmv2 auth = yes
        syslog = 0
        log file = /var/log/samba/log.%m
        max log size = 1000
        announce version = 4
        announce as = NT Workstation
        dns proxy = No
        idmap uid = 167771-335549
        idmap gid = 167771-335549
        winbind use default domain = Yes
        invalid users = root

• Le workgroup correspond au nom « plat » du domaine Microsoft ;
• le realm correspond au royaume Kerberos ;
• la security = ADS (Active Directory Server) nécessite que la machine soit intégrée au domaine Microsoft et que le client kerberos soit installé et configuré, ce qui permettra d’utiliser ce protocole pour l’authentification des clients ;
• les password server sont bien entendu les contrôleurs de domaine Microsoft.

Les autres paramètres sont sans doute de moindre importance. Plongez-vous dans la lecture du manuel de smb.conf pour avoir tous les détails sur les divers paramètres.

Modifiez comme suit le fichier « /etc/nsswitch.conf » :

passwd:         compat winbind
group:          compat winbind
shadow:         compat
hosts:          files dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files

rpc:            db files

netgroup:       nis

Relancez samba et winbind :

# invoke-rc.d winbind restart
Stopping the Winbind daemon: winbind.
Starting the Winbind daemon: winbind.

# invoke-rc.d samba restart
Stopping Samba daemons: nmbd smbd.
Starting Samba daemons: nmbd smbd.

 net ads join -U <un login d'Administrateur du domaine> -S <adresse d'un contrôleur de domaine>

En principe, un message doit vous annoncer que l’opération s’est bien déroulée et vous devriez retrouver votre proxy dans les « computers » dans votre mmc de gestion de « Active Directory Users and Computers »

La commande « wbinfo » doit vous permettre de vérifier que vous avez correctement accès aux listes des utilisateurs et des groupes du domaine ActiveDirectory :

# wbinfo -u
invité
machin
administrateur
...

# wbinfo -g
BUILTIN/administrators
BUILTIN/users
ordinateurs du domaine
utilisa. du domaine
propriétaires créateurs de la stratégie de groupe
administrateurs du schéma
contrôleurs de domaine
invités du domaine
éditeurs de certificats
...

A ce moment, vous avez tout ce qu’il faut pour que squid puisse par la suite identifier les utilisateurs depuis ActiveDirectory.

N’hésitez pas à relancer winbind et samba si besoin est.

Squid va devoir utiliser le module ntlm_auth. Ici, il faut savoir quelque chose de plutôt important : Il existe deux modules ntlm_auth, l’un fourni avec samba et l’autre avec squid.

Bien que portant le même nom, ils ne fonctionnent pas de la même manière. Dans l’état actuel de ma machine de test :

• Samba: Version 3.0.28a ;
• winbindd: Version 3.0.28a ;
• Squid Cache: Version 3.0.STABLE4.

je n’ai pas trouvé de solution pour fonctionner avec le ntlm_auth fourni avec Squid.

Comme c’est celui qui vient avec samba qui est le mieux documenté, nous allons utiliser celui-ci.

Vérifions déjà de façon simple s’il est capable d’authentifier un utilisateur inscrit dans Active Directory :

# ntlm_auth --username=machin --password=epikoi
NT_STATUS_OK: Success (0x0)

Ça marche.

Bien entendu, dans Squid, ce sera un peu plus compliqué que ça. Nous devons ajouter dans squid.conf

auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp

Pour indiquer que nous utilisons une authentification ntlm avec le module /usr/bin/ntlm_auth (fourni par Samba) qui, lui même, utilisera le protocole squid-2.5-ntlmssp. Pourquoi squid-2.5-ntlmssp ? Il semble que rien n’ait changé depuis squid-2.5.

Comme ntlm_auth va être invoqué par l’utilisateur sous l’identité duquel squid est lancé (proxy pour Debian), il faudra que le répertoire /var/run/samba/winbindd_privileged soit accessible en lecture par l’utilisateur proxy. Voyons cela :

# ls -l /var/run/samba
total 604
...
drwxr-x--- 2 root winbindd_priv     17 mar 18 11:56 winbindd_privileged

Un moyen propre de résoudre le problème est d’ajouter l’utilisateur proxy au groupe winbindd_priv :

usermod -a -G winbindd_priv proxy

Nous pouvons aussi ajouter ces lignes dans squid.conf

auth_param ntlm children 5
auth_param ntlm keep_alive on

Le nombre de processus peut être augmenté suivant le nombre d’utilisateurs qui passent par notre proxy.

Bien sûr, nous avons toujours l’ACL acl password proxy_auth REQUIRED ainsi que l’autorisation d’accèshttp_access allow LocalNet password.

Au final :

auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp
auth_param ntlm children 5
auth_param ntlm keep_alive on
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl to_localhost dst 127.0.0.0/8
acl SSL_ports port 443
acl Safe_ports port 80		# http
acl Safe_ports port 21		# ftp
acl Safe_ports port 443		# https
acl Safe_ports port 70		# gopher
acl Safe_ports port 210		# wais
acl Safe_ports port 1025-65535	# unregistered ports
acl Safe_ports port 280		# http-mgmt
acl Safe_ports port 488		# gss-http
acl Safe_ports port 591		# filemaker
acl Safe_ports port 777		# multiling http
acl CONNECT method CONNECT
acl LocalNet src 192.168.0.0/24

acl password proxy_auth REQUIRED

http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost

http_access allow LocalNet password

http_access deny all
icp_access allow all
http_port 3128
hierarchy_stoplist cgi-bin ?
access_log /var/log/squid3/access.log squid
acl QUERY urlpath_regex cgi-bin \?
cache deny QUERY
refresh_pattern ^ftp:		1440	20%	10080
refresh_pattern ^gopher:	1440	0%	1440
refresh_pattern .		0	20%	4320
icp_port 3130
coredump_dir /var/spool/squid3

Normalement, en relançant squid tout ceci devrait fonctionner.

Si votre client est intégré au domaine et que l’utilisateur a donc ouvert une session authentifiée par un contrôleur de domaine, le navigateur (aussi bien IE que FireFox) devraient, s’ils sont configurés pour utiliser le proxy, envoyer automatiquement à Squid les informations nécessaires à l’authentification.

Autrement dit, l’utilisateur ne voit rien de particulier. L’administrateur, lui, verra dans les logs d’accès à Squid (/var/log/squid3/access.log) le nom de l’utilisateur qui a formulé les requêtes.

Imaginons qu’un utilisateur ait le droit de connecter son portable sur votre réseau, mais que ce portable n’est pas intégré au domaine Windows. Dans ce cas, un accès à Squid amènera une fenêtre de demande d’authentification. L’utilisateur devra alors disposer d’un compte sur le domaine Microsoft et indiquer son nom d’utilisateur « complet » :

DOMAINE\machin

Dans notre exemple.