Connexion à un domaine NT ou Active Directory depuis un poste Linux
Je commence par la connexion au domaine NT :
netbios name = TEST2
workgroup = AD
wins server = 192.168.4.58
security = DOMAIN
idmap uid = 15000-20000
idmap gid = 15000-20000
winbind use default domain = Yes
client schannel = no
winbind separator = +
winbind cache time = 10
template shell = /bin/bash
template homedir = /home/%U
winbind uid = 10000-20000
winbind gid = 10000-20000
winbind enum users = yes
winbind enum groups = yes
Ici, nous avons une machine cliente Linux ou bien un serveur Linux et vous avez à disposition un serveur NT. Le principe, c'est de tout centraliser, les utilisateurs, les mots de passe, c'est pratique pour la maintenance et pour les modifications. Toutefois, sur un serveur NT, nous n'aurons pas de home directory, de shell,... alors que si nous avons une machine Linux, nous allons avoir besoin de ces informations. Comment fait-on ?
Deux possibilités :
- installer des extensions pour Windows pour que nous puissions spécifier le shell, le home directory, etc., sous Windows. C'est ce qu'on appelle "Service for Unix" disponible au téléchargement depuis le site de Microsoft (émule un serveur NIS et récupère les arguments en question) ;
- l'autre solution est plus intéressante, car souvent nous n'avons pas le droit de toucher au "sacro-saint" serveur NT ou Active Directory, c'est le winbind qui réalise un mappage pour se synchroniser : les utilisateurs vont être récupérés et les arguments vont être mappés. Un exemple typique est donné ci-dessus dont voici les points qui nous intéressent :
- template shell = /bin/bash
- template homedir = /home/%U
Pour l'uid et le gid, nous définission des plages, ainsi pour chaque utilisateur récupéré, il reçoit un uid et un gid dans cette plage-là et la correspondance entre le vrai et le pseudo uid/gid est stockée dans une table (située le plus souvent dans une base de données TDB ou dans un serveur LDAP) :
- winbind uid = 10000-20000
- winbind gid = 10000-20000
Donc, on récupère les utilisateurs mais l'authentification se fait avec le serveur NT à partir de données récupérées par mappage.
Sous Linux, la configuration classique, c'est libnss+PAM (que l'on configure un peu comme un annuaire LDAP) :
Dans le fichier nsswitch.conf :
passwd: compat ldap winbind
group: compat ldap winbind
shadow: compat ldap winbind
pam.d/XXX :
auth sufficient pam_ldap.so
auth sufficient pam_winbind.so use_first_pass
auth required pam_unix_auth.so use_first_pass
account sufficient pam_ldap.so
account sufficient pam_winbind.so
account required pam_unix.so
session required /lib/security/pam_mkhomedir.so skel=/etc/skel
Cela nous permet en gros la manoeuvre suivante : les utilisateurs ne sont pas listés dans /etc/passwd et /etc/group, car lorsqu'un utilisateur se connecte, il utilise directement le serveur NT, en effet, les logins et les mots de passe vont être stockées sur le serveur NT. C'est une possibilité qui existe par service, par exemple le faire uniquement pour le SMTP, le faire uniquement pour l'IMAP,... Donc finalement on récupère les utilisateurs pour Active Directory uniquement pour un service.
Petite astuce, nous pouvons créer un home pour un utilisateur avec pam_mkhomedir.so :
session required /lib/security/pam_mkhomedir.so skel=/etc/skel
Nous ne connaissons pas a priori l'utilisateur, la première fois qu'il va se loguer, cela va lui créer un répertoire personnel, éventuellement pris à partir d'un modèle dans le répertoire /etc/skel.
En gros, sur le principe, à la fin, vous faites :
# getent passwd
# getent group
et vous avez des utilisateurs qui apparaissent comme étant Unix alors qu'ils sont stockés sous Active Directory. Voici la diapositive relative à cet aspect :
winbind
# net rpc join UAdministrator%PASS
# wbinfo t
# wbinfo u
# wbinfo g
Éventuellement :
# wbinfo setauthuser=Administrator%PASS
Si tout se passe bien :
# getent passwd
# getent group
L'usage de winbind est considéré comme une "utilisation à l'ancienne", c'est-à-dire sans authentification centralisée avec kerberos (voir la suite du texte).
Le serveur Active Directory implémente le protocole LDAP, on peut plus ou moins faire des manipulations avec tout ça, mais je ne vais pas en parler. Ce que je vais envisager par contre, c'est la possibilité (sur les Windows à partir de 2000) d'utiliser l'option security = ADS pour une connexion ADS c'est-à-dire "Active Directory Serveur" que l'on active depuis le fichier smb.conf :
Connexion ADS (avec Kerberos)
security = ADS
realm = evolix.net
password server = krb.evolix.net
Kerberos (/etc/krb5.conf)
=> Utilisation de pam_krb5
Dans ce cas, nous utilisons Kerberos associé à pam (pam_krb5, version 5). Dès lors, nous utilisons des jetons kerberos, ce qui est beaucoup plus efficace qu'avec l'usage de winbind qui utilise des rpc, des appels distants pour tout ce qui est changement de mot de passe et authentification, et dans la pratique, parfois winbind ne marche pas avec certaines versions de Windows (rappel : Samba, c'est du reverse-engeering...). Par contre, Kerberos est quelque chose de beaucoup plus standard qui assure mieux de ce côté-là, et du point de vue de la sécruité, c'est meilleur à ce niveau-là.
Donc, au final, vous pouvez vous synchroniser avec un serveur Active Directory. Pour faire des tests, vous pouvez télécharger gratuitement la version de Windows serveur 2003, mais dont l'usage est limité dans le temps.
Attention, actuellement Samba n'émule pas complètement Active Directory, il émule uniquement les fonctionnalités qu'on a vues. Toutefois, la version 4 de Samba est destinée à émuler complètement Active Directory. À savoir notamment suite à des dispersions avec des développeurs de LDAP, cette nouvelle version intègre en interne un serveur LDAP. Vous avez toujours la possibilité d'utiliser OpenLDAP en backend pour garder une certaine compatibilité. La version LDAP en interne a pour but d'émuler encore plus de fonctionnalités que tout ce que l'on a vu.
En gros, LDAP doit être vu comme un backend pour Samba en principe dans deux types de réseau : soit un réseau où le serveur maître est un serveur Samba (c'est-à-dire un faux serveur Windows), soit un réseau où le serveur maître est Windows et nous devons nous adapter ; dans les deux cas, LDAP fonctionne avec toutes les versions de Windows jusqu'ici (2006).