Comment authentifier les comptes Linux auprès d'un Active Directory et monter un partage Windows à la connexion ?

visiteur · Mars 17, 2026, 6:20

J’utilise Ubuntu 10.04 Server.

admin · Mars 17, 2026, 6:20

[Modification] J’ai depuis testé ceci avec la version finale de Ubuntu 10.04 Server (21/Mai/2010).

J’ai configuré mon Ubuntu 10.04 Server LTS résidant sur un réseau Windows pour authentifier les connexions en utilisant Active Directory, puis monter un partage Windows pour servir de répertoire personnel.

Voici ce que j’ai fait en partant de l’installation initiale d’Ubuntu.

Téléchargez et installez Ubuntu Server 10.04 LTS

Obtenez les mises à jour

# sudo apt-get update && sudo apt-get upgrade

Installez un serveur SSH (sshd)

# sudo apt-get install openssh-server

Certains diraient que vous devriez « sécuriser sshd » en désactivant les connexions root. Je pense que si vous êtes assez malin pour pirater une session SSH afin d’obtenir un mot de passe root, vous ne serez probablement pas arrêté par l’ajout de PermitRootLogin no dans le fichier /etc/ssh/sshd_config. Si vous êtes paranoïaque ou tout simplement pas convaincu, modifiez le fichier ou essayez ceci :

# (grep PermitRootLogin /etc/ssh/sshd_config && sudo sed -ri 's/PermitRootLogin ).+/\1no/' /etc/ssh/sshd_conifg) || echo "PermitRootLogin not found. Add it manually."

Installez les paquets requis

# sudo apt-get install winbind samba smbfs smbclient ntp krb5-user

Effectuez un peu de nettoyage réseau de base en préparation des configurations spécifiques de paquets à venir.

Déterminez le nom de votre domaine Windows, le nom du serveur DNS et l’adresse IP du serveur Active Directory (pour Samba). Par commodité, j’ai défini des variables d’environnement pour le domaine Windows et le serveur DNS. Pour moi, c’était (mon adresse IP AD était 192.168.20.11) :

# WINDOMAIN=mydomain.local && WINDNS=srv1.$WINDOMAIN && WINDNS_IP=192.168.20.11

Si vous voulez découvrir quel est votre domaine et votre serveur DNS (j’étais prestataire et ne connaissais pas le réseau), consultez cette référence utile.

Nous devons baptiser la machine Linux sur le nouveau réseau, cela se fait en modifiant le fichier hosts (remplacez le DNS par le FQDN du DNS Windows) :

# sudo sed -ri "s/^(127\.0\.[01]\.1[ \t]).*/\1$(hostname).$WINDOMAIN localhost $(hostname)/" /etc/hosts

Nous devons également indiquer aux services installés où trouver leur référent : certains réseaux auront des services de résolution de noms NetBIOS, mais par précaution, ajoutez une entrée explicite dans votre fichier /etc/hosts. Dans ma configuration, j’ai ajouté l’entrée à la troisième (3) ligne :

# sudo sed -ri "3 i $WINDNS_IP $WINDNS" /etc/hosts

Les processus d’authentification et de partage de fichiers pour les machines Windows et Linux ont besoin que leurs horloges soient synchronisées. Faites-le avec un service NTP. Sur la version serveur d’Ubuntu, le service NTP est installé et configuré avec un (1) serveur NTP. Ajoutez le vôtre avant celui d’Ubuntu (ou remplacez-le entièrement). Le réseau que je rejoignais avait le serveur DNS qui fournissait également le service NTP.

# sudo sed -ri "s/^(server[ \t]+)(.+)/\1$WINDNS\n\1\2/" /etc/ntp.conf

Redémarrez le démon NTP :

# sudo /etc/init.d/ntp restart

Configuration de Kerberos.

Les instructions qui suivent ne doivent pas être prises au pied de la lettre : les valeurs pour MYDOMAIN.LOCAL et srv1.mydomain.local doivent être remplacées par ce qui est approprié pour votre réseau lorsque vous modifiez les fichiers, mais notez bien que là où des MAJUSCULES sont utilisées, des MAJUSCULES sont nécessaires.

Si, lors de l’apt-get install de Kerberos, vous avez eu la clairvoyance de répondre correctement à la question sur le « domaine par défaut », tant mieux pour vous, sinon vous devrez faire ce qui suit.

Modifiez le fichier /etc/krb5.conf (installé précédemment ci-dessus).

Trouvez la section [libdefaults] et modifiez la paire clé-valeur :

[libdefaults]

default_realm = MYDOMAIN.LOCAL

Ajoutez ce qui suit à la section [realms] du fichier :

MYDOMAIN.LOCAL = {

`kdc = srv1.mydomain.local`

`admin_server = srv1.mydomain.local`

`default_domain = MYDOMAIN.LOCAL`

}

Ajoutez ce qui suit à la section [domain_realm] du fichier :

.mydomain.local = MYDOMAIN.LOCAL

mydomain.local = MYDOMAIN.LOCAL

Un bon test à ce stade est de vérifier si votre contrôleur AD vous délivrera un ticket Kerberos. Ce n’est pas nécessaire, mais cela peut ravir certains d’entre vous :

# kinit <some_windows_domain_user>

Puis pour voir le ticket :

# klist

Vous verrez des informations sur le cache de tickets, les expirations et les renouvellements. Une fois l’enthousiasme passé, vous pouvez aussi bien libérer/détruire le ticket :

# kdestroy

Configurez Samba.

Selon ce qui suit :
Il y a des cas où CIFS ne peut pas être utilisé ou un autre système de fichiers réseau est préférable. Si la prise en charge de l’authentification Kerberos (krb5/SPNEGO) est nécessaire pour une sécurité accrue, alors smbclient ou smbfs de Samba doivent être utilisés à la place de cifs

Hélas, la prise en charge de cifs dans le noyau pour Ubuntu 10.04 (basé sur la version du noyau 2.6.32.9) est à la version 1.61, et selon la documentation du noyau, une implémentation expérimentale de Kerberos est présente depuis la version 1.54.

Voilà. Je n’ai aucune idée si cifs fonctionnerait, je vous donne donc la configuration Samba :

Remplacez /etc/samba/smb.conf (rappelez-vous que je travaillais à partir d’une distribution propre d’Ubuntu, donc je ne m’inquiétais pas de casser quoi que ce soit) :

[global]

security = ads

realm = MYDOMAIN.LOCAL

password server = 192.168.20.11

workgroup = MYDOMAIN

idmap uid = 10000-20000

idmap gid = 10000-20000

winbind enum users = yes

winbind enum groups = yes

template homedir = /home/%U

template shell = /bin/bash

client use spnego = yes

client ntlmv2 auth = yes

encrypt passwords = yes

winbind use default domain = yes

restrict anonymous = 2

Démarrez et arrêtez divers services.

# sudo /etc/init.d/winbind stop

# sudo service smbd restart

# sudo /etc/init.d/winbind start

Configurez l’authentification.

Modifiez le fichier /etc/nsswitch.conf. J’ai pu exécuter la commande suivante pour obtenir ce dont j’avais besoin :

# sed -ri 's/(compat)/\1 winbind/' /etc/nsswitch.conf

Voici le contenu de mon fichier /etc/nsswitch.conf :

passwd: compat winbind

group: compat winbind

shadow: compat winbind

hosts: files dns

networks: files

protocols: db files

services: db files

ethers: db files

rpc: db files

Démarrez et arrêtez divers services.

# sudo /etc/init.d/winbind stop

# sudo service smbd restart

# sudo /etc/init.d/winbind start

Joignez l’ordinateur au domaine.
Je ne suis pas convaincu que cela soit nécessaire ; en particulier à cause de l’option de sécurité dans le fichier smb.conf (security = ads). Peut-être que quelqu’un pourra se prononcer à ce sujet…

# sudo net ads join -U any_domain_user_account

Vous pourriez obtenir une erreur DNS update failed!, mais vous serez joint au domaine.
Si vous obtenez une erreur indiquant l’impossibilité de trouver le serveur, vos enregistrements DNS doivent être modifiés. Lors de l’installation d’Ubuntu, le serveur de noms pointera souvent vers votre passerelle : la plupart des routeurs fournissent un service DNS. Les bonnes pratiques pour l’administration de Windows Server veulent que le contrôleur AD exécute également le DNS. Dans mon cas, mon fichier /etc/resolve.conf ressemble à ceci :

nameserver 192.168.20.11

nameserver 8.8.8.8

Le 8.8.8.8 est un DNS Google, une sauvegarde assez fiable en cas de panne du DNS Windows.

À ce stade, je pouvais me connecter (peut-être après un redémarrage), les répertoires personnels n’existaient pas, mais je pouvais me connecter.

Montage CIFS à la connexion

Cette étape suivante était la cerise sur le gâteau pour moi ; je ne voulais pas la responsabilité de sauvegarder les répertoires de travail de tout le monde, et la machine sur laquelle Ubuntu devait fonctionner était suspecte en termes de fiabilité. En procédant ainsi, les utilisateurs pouvaient se connecter et voir leur répertoire utilisateur Windows automagiquement.

Téléchargez le module pam_mount :

# sudo apt-get install libpam-mount

Je voulais que le point de montage soit à l’emplacement traditionnel /home/<user> : cette partie est configurée par le fichier /etc/samba/smb.conf (template homedir = /home/%U). Mais j’avais besoin qu’il traverse le partage et pointe vers leur propre répertoire Windows. Ceci est accompli en modifiant le fichier /etc/security/pam_mount.conf.xml (qui, malgré son intention, le XML n’est pas lisible par l’homme) :

Ajoutez ce qui suit à /etc/security/pam_mount.conf.xml et adaptez selon vos besoins :

<volume

user="*"

server="srv1.mydomain.local"

path="UserShares"

mountpoint="home"

fstype="cifs"

/>

<cifsmount>mount -t cifs //%(SERVER)/%(VOLUME)/%(USER) %(MNTPT)/%(USER) -o "user=%(USER),uid=%(USERUID),gid=%(USERGID)%(before=\",\" OPTIONS)"</cifsmount>

En raison de mon point de montage particulier, j’ai dû ajouter cette ligne aussi :

<umount>umount %(MNTPT)/%(USER)</umount>

Et pour que les répertoires utilisateurs (pour le point de montage) soient créés automatiquement, trouvez la ligne et modifiez-la ainsi :

<mkmountpoint enable="1" remove="false" />

Le remove="false" est très important : s’il est défini à true, pam_mount.so essaie de supprimer le point de montage du répertoire, ce qu’il ne peut pas faire si un utilisateur s’est connecté plusieurs fois. Ce que vous obtiendrez dans ce cas, ce sont de nombreux montages résiduels sur votre système.

***pam_mount.so ne fonctionne toujours pas tout à fait comme promis. Dans sa forme actuelle, les montages continuent de s’accumuler et les répertoires personnels ne sont pas créés. Quelque part entre ici et la version Beta 2 précédente de 10.04 Server, cela fonctionnait. Je ne peux pas le reproduire.

En attendant, pour la création des répertoires, je m’appuie sur pam_mkhomedir.so, et j’ai ajouté une ligne juste avant la ligne pam_mount.so pour compenser.

Je n’ai toujours pas résolu le problème des montages multiples. Mais en attendant que pam_mount.so soit corrigé, voici ce que j’ai dans mon fichier /etc/pam.d/common-session :***

session [default=1]     pam_permit.so
session requisite       pam_deny.so
session required        pam_permit.so
session required        pam_unix.so
session optional        pam_winbind.so
session required        pam_mkhomedir.so skel=/etc/skel/ umask=0022
session optional        pam_mount.so

C’est tout. Cela a fonctionné pour moi, et j’espère que vous le trouverez utile.

De nombreuses ressources ont été consultées pour que je puisse comprendre tout cela. Voici une courte liste (un certain nombre de ces liens pointent vers mes propres questions sur le sujet) :