Ceci est une ancienne révision du document !
Samba AD DC - Intégration de machines au domaine
Cette page détaille une possibilité d'intégration d'une machine Ubuntu dans un domaine Samba - Active Directory Domain Controller (AD DC). Pour l'exemple, le nom de la machine qui sera jointe au domaine est UBNWKS01.
Prérequis
Configuration du nom de machine
Il est recommandé de mettre le FQDN 1) de la machine dans le fichier /etc/hostname
- /etc/hostname
ubnwks01.example.com
Pour faciliter la résolution de nom sans passer par le serveur DNS, il faut également ajouter le FQDN dans le fichier /etc/hosts
- /etc/hosts
127.0.0.1 localhost 127.0.1.1 ubnwks01.example.com ubnwks01 # The following lines are desirable for IPv6 capable hosts ::1 localhost ip6-localhost ip6-loopback ff02::1 ip6-allnodes ff02::2 ip6-allrouters
Les commandes hostname et hostname -f doivent retourner le même résultat, le FQDN de la machine, ubnwks01.example.com
Résolution de nom de domaine
Une bonne résolution de nom de domaine est indispensable au sein d'un domaine Samba AD DC. Dans le fichier /etc/resolv.conf, il faut retrouver un serveur DNS du domaine et le domaine de recherche.
- /etc/resolv.conf
nameserver 192.168.1.11 search example.com
Ces paramètres sont soit fournis par le serveur DHCP du réseau ou configurés de façon statique dans le fichier /etc/network/interfaces par l'intermédiaire du paquet resolvconf avec les commandes dns-nameservers et dns-search.
- /etc/network/interfaces
auto eth0 iface eth0 inet static address 192.168.1.101 netmask 255.255.255.0 gateway 192.168.1.1 dns-nameservers 192.168.1.11 dns-search example.com
Les tests suivant devraient renvoyer des résultats corrects (se référer à Samba AD DC - Tests du DNS)
dig ubndc01.example.com
dig -t SRV _kerberos._tcp.example.com
dig doc.ubuntu-fr.org
Synchronisation NTP
La synchronisation du temps entre les machines qui utilisent l'authentification Kerberos est indispensable. L'authentification Kerberos est une des fonctionnalités de Samba AD DC. Pour ce faire, il faut installer le paquet ntp
sudo apt-get install ntp
Configurer ntp pour qu'il se synchronise sur le DC. Voici un exemple de configuration simplifiée :
- /etc/ntp.conf
driftfile /var/lib/ntp/ntp.drift logfile /var/log/ntp # Specify one or more NTP servers. server ubndc01.example.com # By default, exchange time with everybody, but don't allow configuration. restrict default kod notrap nomodify nopeer mssntp limited # Local users may interrogate the ntp server more closely. restrict 127.0.0.1
Redémarrer le service ntp
sudo service ntp restart
Vérifier le bon fonctionnement de ntp
ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
192.168.1.11 10.240.242.252 10 u 887 1024 377 0.632 -0.919 2.476
Joindre la machine au domaine Samba AD DC
Installer samba
Il faut installer le paquet samba
sudo apt-get install samba
Configurer samba
La configuration de samba peut être réécrite comme suit :
- /etc/samba/smb.conf
# Global parameters [global] workgroup = EXAMPLE realm = EXAMPLE.COM netbios name = ubnwks01 security = ADS encrypt passwords = yes idmap config EXAMPLE:backend = ad idmap config EXAMPLE:schema_mode = rfc2307 idmap config EXAMPLE:range = 10000-39999 idmap config *:backend = tdb idmap config *:range = 40000-49999 winbind nss info = rfc2307 winbind trusted domains only = no winbind use default domain = yes winbind enum users = yes winbind enum groups = yes winbind refresh tickets = yes
Les lignes idmap config EXAMPLE … sont très importantes. Elles définissent le backend (méthode d'accès) AD (Active Directory), le schéma rfc2307 (contenant les extensions NIS utiles pour les systèmes Linux et UNIX) et la plage d'identifiants numériques pour les utilisateurs et groupes du domaine EXAMPLE. Cette plage doit être définie dans la politique du domaine. Afin d'éviter des usurpations d'identité et de droits, il faut garantir que ces numéros soient uniques. Ils ne peuvent donc pas être utilisés localement (sur aucune machine du domaine).
Les lignes idmap config *:… définissent le backend tdb (base de données locale) et la plage d'identifiants pour les utilisateurs et groupes venant d'autres domaines. On retrouve ici entre-autre les groupes venant de BUILTIN. Par défaut, une machine qui rejoint le domaine reçoit deux groupes locaux, BUILTIN\Administrators et BUILTIN\Users. Par défaut, le groupe EXAMPLE\Domain Admins est membre du groupe BUILTIN\Administrators et le groupe EXAMPLE\Domain Users est membre du groupe BUILTIN\Users. Les autres groupes qui seraient créés localement sur la machine auront la forme UBNWKS01\Nom du groupe.
Les lignes winbind … définissent d'autres options pour l'utilisation de winbind. Notamment, la ligne use default domain permet de ne pas devoir inscrire à chaque fois le nom du domaine pour un utilisateur ou un groupe appartenant au domaine par défaut.
Appliquer les modifications
Il faut arrêter et redémarrer les services smbd et nmbd.
sudo service smbd stop && sudo service nmbd stop sudo service smbd start && sudo service nmbd start
Joindre la machine au domaine
sudo net join -U Administrator Enter Administrator's password: Using short domain name -- EXAMPLE Joined 'UBNWKS01' to dns domain 'example.com' No DNS domain configured for ubnwks01. Unable to perform DNS Update. DNS update failed: NT_STATUS_INVALID_PARAMETER
"No DNS domain configure for ubnwks01. Unable to perform DNS Update. DNS update failed …"
On peut ajouter manuellement le record dans le DNS avec la commande samba-tool comme suit :
samba-tool dns add ubndc01 example.com ubnwks01 A 192.168.1.101 -U Administrator
Aucun problème rencontré, si /etc/hostname contient le FQDN et pas uniquement le nom et /etc/hosts adapté avec FQDN et nom simple. Les services smbd et nmbd étaient arrêtés. A ce moment, un record A est ajouté dans la zone DNS du domaine. Encore à vérifier…
Mettre en place winbind
Installer les paquets
Il faut installer libnss-winbind et libpam-winbind
sudo apt-get install libnss-winbind libpam-winbind
A ce stade, la commande wbinfo devrait déjà fonctionner mais pas getent pour les utilisateurs et groupes du domaine (correctement configurés).
wbinfo -u wbinfo -g
Configurer Name Service Switch
Il faut ajouter winbind aux possibilités passwd et group.
- /etc/nsswitch.conf
passwd: compat winbind group: compat winbind
A ce stade, la commande getent passwd devrait lister les utilisateurs du domaine (correctement configurés).
getent passwd ... administrator:*:10000:10000:Administrator:/home/example/administrator:/bin/bash ...
A ce stade, la commande getent group ne devrait pas lister les groupes du domaine (correctement configurés) à cause de la ligne winbind use default domain = yes présente dans /etc/samba/smb.conf. Mais, on peut obtenir les informations sur un groupe du domaine en spécifiant ce groupe à la commande getent
getent group "Domain Admins" domain admins:x:10000:administrator
La commande id peut également être utilisée pour lister l'identifiant d'un utilisateur du domaine (son UID), l'identifiant de son groupe principal (GID) et les identifiants des autres groupes auxquels il appartient tenant compte de l'héritage.
id administrator uid=10000(administrator) gid=10000(domain admins) groups=10000(domain admins),10005(schema admins),10007(group policy creator owners),10017(denied rodc password replication group),10004(enterprise admins),10003(domain users)
Tout ceci montre une situation correctement configurée c'est-à-dire que chaque utilisateur ou groupe de domaine possède un identifiant NIS unique. Dans le cas contraire, par exemple pas d'identifiant pour le groupe schema admins donnerait ce résultat avec la commande id
id administrator uid=10000(administrator) gid=10000(domain admins) groups=10000(domain admins),4294967295,10007(group policy creator owners),10017(denied rodc password replication group),10004(enterprise admins),10003(domain users)
net rpc group list -U Administrator Administrators Users sudo net cache flush sudo service winbind restart
Configurer PAM
Le module PAM de winbind gère le mécanisme d'authentification des utilisateurs. C'est celui-ci qui va permettre aux utilisateurs de se loguer sur la machine physiquement ou de façon distante. Par défaut, il ne faut rien faire. Cependant lorsqu'un utilisateur du domaine voudra se loguer sur la machine, son répertoire HOME n'existera probablement pas sur cette machine. Afin de remédier à ce problème, il faut créer un fichier /usr/share/pam-configs/mkhomedir qui va permettre de créer automatiquement le répertoire HOME de l'utilisateur qui se connecte.
- /usr/share/pam-configs/mkhomedir
Name: Create home directory during login Default: yes Priority: 900 Session-Type: Additional Session: required pam_mkhomedir.so umask=0077 skel=/etc/skel
Il faut finalement activer le module qui vient d'être créé
sudo pam-auth-update
Package configuration
┌─────────────────────────┤ PAM configuration ├──────────────────────────┐
│ PAM profiles to enable: │
│ │
│ [*] Create home directory during login │
│ [*] Unix authentication │
│ [*] Winbind NT/Active Directory authentication │
│ [*] Register user sessions in the systemd control group hierarchy │
│ [*] Inheritable Capabilities Management │
│ │
│ <Ok> <Cancel> │
└────────────────────────────────────────────────────────────────────────┘
On peut à présent tester l'authentification soit sur une autre console (Ctrl+F2), soit avec ssh
ssh administrator@localhost ... administrator@localhost's password: Creating directory '/home/example/administrator'. ... administrator@ubnwks01:~$ pwd /home/example/administrator
On voit que le répertoire HOME de l'utilisateur a été créé lors du processus de login (même par SSH).
Outils
Kerberos
Il pourra être utile d'installer les outils Kerberos (notamment kinit, klist, kdestroy, …) pour investiguer, tester et dépanner les problèmes relatifs à Kerberos.
sudo apt-get install krb5-user
Plus d'infos, se référer à Samba AD DC - Tests de Kerberos
Sudo
Afin de donner les droits superutilisateur local à un groupe du domaine (Domain Admins), il faut modifier avec la commande visudo le fichier /etc/sudoers.
sudo visudo
Et ajouter les lignes
- /etc/sudoers
... # Allow members of domain group "Domain Admins" to execute any command %domain\ admins ALL=(ALL:ALL) ALL ...
A présent, les membres du groupe "Domain Admins" peuvent exécuter toutes les commandes avec sudo.
Samba-tool
L'outil samba-tool peut être utilisé pour administrer à distance le domaine en ajoutant en fin de commande -H ldap://ubndc01.example.com. Ne pas mettre l'IP d'un serveur !
L'authentification peut se faire de façon traditionnelle pour tous les utilisateurs en ajoutant en fin de commande -U <domain username>
localuser@ubnwks01:~$ samba-tool user list -U Administrator -H ldap://ubndc01.example.com Password for [EXAMPLE\Administrator]: administrator krbtgt Guest
Ou sur base du ticket Kerberos en ajoutant en fin de commande -k yes pour un utilisateur du domaine correctement authentifié
administrator@ubnwks01:~$ samba-tool user list -k yes -H ldap://ubndc01.example.com administrator krbtgt Guest
Ou sur base du ticket Kerberos en ajoutant en fin de commande -k yes pour un utilisateur quelconque ayant demandé un ticket avec kinit pour le compte d'un utilisateur du domaine
localuser@ubnwks01:~$ kinit administrator@EXAMPLE.COM
Password for administrator@EXAMPLE.COM:
localuser@ubnwks01:~$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: administrator@EXAMPLE.COM
Valid starting Expires Service principal
10/31/2014 15:41:37 11/01/2014 01:41:37 krbtgt/EXAMPLE.COM@EXAMPLE.COM
renew until 11/01/2014 15:41:31
localuser@ubnwks01:~$ samba-tool user list -k yes -H ldap://ubndc01.example.com
administrator
krbtgt
Guest
localuser@ubnwks01:~$ kdestroy
Applications utilisant le ticket Kerberos
ssh
Pour activer l'utilisation de l'authentification par Kerberos pour SSH, il faut décommenter les lignes concernant GSSAPIAuthentication dans /etc/ssh/sshd_config (pour la partie serveur) et GSSAPIAuthentication et GSSAPIDelegateCredentials dans /etc/ssh/ssh_config (pour la partie cliente) et activer ces options en passant la valeur yes au lieu de no.
- /etc/ssh/sshd_config
... GSSAPIAuthentication = yes ...
- /etc/ssh/ssh_config
... GSSAPIAuthentication = yes GSSAPIDelegateCredentials = yes ...
La modification du fichier /etc/ssh/ssh_config doit se faire sur chaque machine à partir de laquelle un client essaye d'ouvrir une session SSH sur le serveur.
Pour que le serveur SSH puissent accepter l'authentification de l'utilisateur, il doit posséder lui-même un ticket Kerberos valide. Ce ticket sera le fichier /etc/krb5.keytab où sont stockées les clés de la machine lui permettant de s'authentifier auprès du serveur Kerberos. De par sa nature, cette information est sensible et donc protégée par des droits d'accès restreints (-rw------ root root).
Deux opérations sont nécessaires, la première consiste à demander un ticket Kerberos au nom de Administrator (un compte du domaine possédant les droits d'administration sur celui-ci) pour le superutilisateur root. La seconde interroge le DC, reçoit les clés et crée le fichier /etc/krb5.keytab sur la machine.
sudo kinit administrator Password for administrator@EXAMPLE.COM: sudo net ads keytab create -k Warning: "kerberos method" must be set to a keytab method to use keytab functions.
Se référer à man smb.conf
On peut vérifier le résultat avec
ls -l /etc/krb5.keytab -rw------- 1 root root 1057 Nov 4 19:37 /etc/krb5.keytab
sudo klist -ket Keytab name: FILE:/etc/krb5.keytab KVNO Timestamp Principal ---- ------------------- ------------------------------------------------------ 1 11/04/2014 19:37:24 host/ubnwks01.example.com@EXAMPLE.COM (des-cbc-crc) 1 11/04/2014 19:37:24 host/ubnwks01.example.com@EXAMPLE.COM (des-cbc-md5) 1 11/04/2014 19:37:24 host/ubnwks01.example.com@EXAMPLE.COM (aes128-cts-hmac-sha1-96) 1 11/04/2014 19:37:24 host/ubnwks01.example.com@EXAMPLE.COM (aes256-cts-hmac-sha1-96) 1 11/04/2014 19:37:24 host/ubnwks01.example.com@EXAMPLE.COM (arcfour-hmac) 1 11/04/2014 19:37:24 host/ubnwks01@EXAMPLE.COM (des-cbc-crc) 1 11/04/2014 19:37:24 host/ubnwks01@EXAMPLE.COM (des-cbc-md5) 1 11/04/2014 19:37:24 host/ubnwks01@EXAMPLE.COM (aes128-cts-hmac-sha1-96) 1 11/04/2014 19:37:25 host/ubnwks01@EXAMPLE.COM (aes256-cts-hmac-sha1-96) 1 11/04/2014 19:37:25 host/ubnwks01@EXAMPLE.COM (arcfour-hmac) 1 11/04/2014 19:37:25 UBNWKS01$@EXAMPLE.COM (des-cbc-crc) 1 11/04/2014 19:37:25 UBNWKS01$@EXAMPLE.COM (des-cbc-md5) 1 11/04/2014 19:37:25 UBNWKS01$@EXAMPLE.COM (aes128-cts-hmac-sha1-96) 1 11/04/2014 19:37:25 UBNWKS01$@EXAMPLE.COM (aes256-cts-hmac-sha1-96) 1 11/04/2014 19:37:25 UBNWKS01$@EXAMPLE.COM (arcfour-hmac)
A prèsent, un utilisateur du domaine utilisant une autre machine peut ouvrir une session SSH sur la machine ubnwks01 sans devoir introduire son mot de passe.
smb4k
Se référer à Monter des partages Windows sous KDE.
Dans smb4k, il existe l'option Essayer de s'authentifier avec Kerberos de l'onglet Paramètres généraux dans Configuration Smb4k / Samba qui sert lors de l'authentification de l'utilisateur vis-à-vis du serveur de fichier distant. Cependant, il faut utiliser l'option avancée Mode de sécurité de l'onglet Montage dans Configuration Smb4k / Samba et choisir Kerberos 5 authentication. Cette option permet de monter un partage Windows (CIFS) à partir du ticket Kerberos de l'utilisateur reçu lors de son login. Elle correspond exactement à l'option sec=krb5 de mount.cifs.
Ceci reviendrait à exécuter la commande :
sudo mount.cifs //server/share /mnt/point -o sec=krb5
Sous Trusty (14.04), lorsque l'utilisateur essaie de monter son partage ainsi, il reçoit le message d'erreur : "Mount error (126): Required key not available. Refer to the mount.cifs(8) manual page." Le problème vient de l'accès au ticket Kerberos. L'application mount.cifs, étant toujours exécutée par root via le setuid bit, cherche le ticket Kerberos de l'utilisateur root et non celui de l'utilisateur réel. Ne le trouvant pas, l'application renvoie l'erreur ci-dessus.
La solution à ce problème est de passer l'option cruid avec la valeur UID de l'utilisateur dans le champ Options supplémentaires de l'onglet Montage dans Configuration Smb4k / Samba, par exemple cruid=10000. Ceci résout le problème et permet d'accéder au partage.
Ceci reviendrait à exécuter la commande :
sudo mount.cifs //server/share /mnt/point -o sec=krb5,cruid=$UID
Cependant, l'utilisation de l'option cruid représente une faille de sécurité qui permet à un utilisateur d'encoder l'UID d'un autre utilisateur et ainsi d'obtenir les droits de cet utilisateur (CVE-2014-2581). Actuellement, Trusty (14.04) fourni le paquet smb4k en v1.0.9 sans appliquer une mise à jour de sécurité concernant cette faille. A partir de la version 1.1.1, le réglage du paramètre cruid est refusé par l'application smb4k. En arrière plan, l'application utilise ce paramètre avec la valeur UID de l'utilisateur réel. Il est donc recommandé d'utiliser la v1.1.2 disponible pour Utopic (14.10) parfaitement compatible d'un point de vue de ces dépendances avec Trusty (14.04).
Pour les utilisateurs de Trusty (14.04), la méthode la plus simple consiste à installer le paquet smb4k qui installera automatiquement les dépendances. Après, il faut désinstaller ce paquet mais pas ses dépendances. Il ne faut donc pas exécuter un autoremove. Et finalement, il faut télécharger le paquet depuis un dépôt officiel (attention au choix de l'architecture amd64 ou i386) et l'installer manuellement.
sudo apt-get install smb4k sudo apt-get remove smb4k wget http://archive.ubuntu.com/ubuntu/pool/universe/s/smb4k/smb4k_1.1.2-1_amd64.deb sudo dpkg -i smb4k_1.1.2-1_amd64.deb
Références
Contributeur principal : Qedinux