Activer l’authentification Active Directory sur SMB pour les clients Linux qui accèdent à Azure Files

Pour plus d’informations sur les options prises en charge et sur les éléments à prendre en compte, consultez Vue d’ensemble des options d’authentification basée sur l’identité Azure Files pour l’accès SMB.

Azure Files prend en charge l’authentification basée sur l’identité via SMB (Server Message Block) pour les machines virtuelles Linux à l’aide du protocole d’authentification Kerberos par le biais des méthodes suivantes :

• Windows Active Directory Domain Services (AD DS) en local
• Services de domaine Microsoft Entra

Pour utiliser AD DS, vous devez synchroniser votre AD DS à Microsoft Entra ID à l’aide de Microsoft Entra Connect.

Remarque

Cet article utilise Ubuntu pour les exemples d’étapes. Des configurations similaires fonctionnent pour les machines RHEL et SLES, ce qui vous permet de monter des partages de fichiers Azure à l’aide d’Active Directory.

S’applique à

Type de partage de fichiers	SMB	NFS
Partages de fichiers Standard (GPv2), LRS/ZRS
Partages de fichiers Standard (GPv2), GRS/GZRS
Partages de fichiers Premium (FileStorage), LRS/ZRS

Limitations du client SMB Linux

Vous ne pouvez pas utiliser l’authentification basée sur l’identité pour monter des partages de fichiers Azure sur des clients Linux au démarrage à l’aide d’entrées fstab, car le client ne peut pas obtenir le ticket Kerberos suffisamment tôt pour le montage au démarrage. Toutefois, vous pouvez utiliser une entrée fstab et spécifier l’option noauto. Cela ne montera pas le partage au moment du démarrage, mais cela permettra à un utilisateur de monter facilement le partage de fichiers après s’être connecté à l’aide d’une simple commande mount sans tous les paramètres. Vous pouvez également utiliser autofs pour monter le partage lors de l’accès.

Prérequis

Avant d’activer l’authentification AD via SMB pour des partages de fichiers Azure, assurez-vous que les conditions préalables suivantes sont remplies.

• Une machine virtuelle Linux fonctionnant sous Ubuntu 18.04+, ou une machine virtuelle RHEL ou SLES équivalente. Si elle est exécutée sur Azure, la machine virtuelle doit avoir au moins une interface réseau sur le réseau virtuel (VNET) contenant Microsoft Entra Domain Services. Si vous utilisez une machine virtuelle locale, votre système AD DS doit être synchronisé avec Microsoft Entra ID.
• Informations d’identification de l’utilisateur racine ou de l’utilisateur à un compte d’utilisateur local disposant de droits sudo complets (pour ce guide, localadmin).
• La machine virtuelle Linux ne doit avoir joint aucun domaine AD. S’il fait déjà partie d’un domaine, il doit d’abord quitter ce domaine avant de pouvoir rejoindre le nouveau domaine.
• Un tenant Microsoft Entra entièrement configuré, avec un utilisateur de domaine déjà configuré.

L’installation du package samba n’est pas strictement nécessaire, mais elle vous donne des outils utiles et apporte automatiquement d’autres packages, tels que samba-common et smbclient. Exécutez les commandes suivantes pour l’installer. Si vous êtes invité à entrer des valeurs pendant l’installation, laissez-les vides.

sudo apt update -y
sudo apt install samba winbind libpam-winbind libnss-winbind krb5-config krb5-user keyutils cifs-utils

L’outil wbinfo fait partie de la suite samba. Il peut être utile à des fins d’authentification et de débogage, notamment pour vérifier si le contrôleur de domaine est accessible, vérifier le domaine auquel une machine est jointe et rechercher des informations sur les utilisateurs.

Assurez-vous que l’hôte Linux maintient l’heure synchronisée avec le serveur de domaine. Reportez-vous à la documentation de votre distribution Linux. Pour certaines distributions, vous pouvez le faire à l’aide de systemd-timesyncd. Modifiez /etc/systemd/timesyncd.conf avec votre éditeur de texte favori pour inclure les éléments suivants :

[Time]
NTP=onpremaadint.com
FallbackNTP=ntp.ubuntu.com

Ensuite, redémarrez le service :

sudo systemctl restart systemd-timesyncd.service

Activer l’authentification Kerberos AD

Procédez comme suit pour activer l’authentification Kerberos AD. Cette documentation Samba peut être utile comme référence.

Vérifier que le serveur de domaine est accessible et détectable

1. Vérifiez que les serveurs DNS fournis contiennent les adresses IP du serveur de domaine.

systemd-resolve --status

Global 
          DNSSEC NTA: 10.in-addr.arpa
                      16.172.in-addr.arpa
                      168.192.in-addr.arpa
                      17.172.in-addr.arpa
                      18.172.in-addr.arpa
                      19.172.in-addr.arpa
                      20.172.in-addr.arpa
                      21.172.in-addr.arpa
                      22.172.in-addr.arpa
                      23.172.in-addr.arpa
                      24.172.in-addr.arpa
                      25.172.in-addr.arpa
                      26.172.in-addr.arpa
                      27.172.in-addr.arpa
                      28.172.in-addr.arpa
                      29.172.in-addr.arpa
                      30.172.in-addr.arpa
                      31.172.in-addr.arpa
                      corp
                      d.f.ip6.arpa
                      home
                      internal
                      intranet
                      lan
                      local
                      private
                      test 

Link 2 (eth0) 
      Current Scopes: DNS 
       LLMNR setting: yes 
MulticastDNS setting: no 
      DNSSEC setting: no 
    DNSSEC supported: no 
         DNS Servers: 10.0.2.5 
                      10.0.2.4 
                      10.0.0.41
          DNS Domain: domain1.contoso.com 

2. Si la commande a fonctionné, ignorez les étapes suivantes et passez à la section suivante.

3. Si elle n’a pas fonctionné, assurez-vous que les adresses IP du serveur de domaine réussissent le test ping.

ping 10.0.2.5

PING 10.0.2.5 (10.0.2.5) 56(84) bytes of data.
64 bytes from 10.0.2.5: icmp_seq=1 ttl=128 time=0.898 ms
64 bytes from 10.0.2.5: icmp_seq=2 ttl=128 time=0.946 ms

^C 

--- 10.0.2.5 ping statistics --- 
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 0.898/0.922/0.946/0.024 ms

4. Si le test ping ne fonctionne pas, revenez aux prérequis, puis vérifiez que votre machine virtuelle se trouve sur un réseau VNet ayant accès au tenant Microsoft Entra.

5. Si les adresses IP réussissent le test ping, mais que les serveurs DNS ne sont pas détectés automatiquement, vous pouvez ajouter les serveurs DNS manuellement. Modifiez /etc/netplan/50-cloud-init.yaml avec votre éditeur de texte favori.

# This file is generated from information provided by the datasource.  Changes
# to it will not persist across an instance reboot.  To disable cloud-init's
# network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
    ethernets:
        eth0:
            dhcp4: true
            dhcp4-overrides:
                route-metric: 100
            dhcp6: false
            match:
                macaddress: 00:22:48:03:6b:c5
            set-name: eth0
            nameservers:
                addresses: [10.0.2.5, 10.0.2.4]
    version: 2

Appliquez ensuite les modifications :

sudo netplan --debug apply 

6. Winbind part du principe que le serveur DHCP conserve les enregistrements DNS de domaine à jour. Toutefois, cela n’est pas vrai pour Azure DHCP. Pour configurer le client pour qu’il effectue des mises à jour DDNS, utilisez ce guide pour créer un script réseau. Voici un exemple de script qui réside dans /etc/dhcp/dhclient-exit-hooks.d/ddns-update.

#!/bin/sh 

# only execute on the primary nic
if [ "$interface" != "eth0" ]
then
    return
fi 

# When you have a new IP, perform nsupdate
if [ "$reason" = BOUND ] || [ "$reason" = RENEW ] ||
   [ "$reason" = REBIND ] || [ "$reason" = REBOOT ]
then
   host=`hostname -f`
   nsupdatecmds=/var/tmp/nsupdatecmds
     echo "update delete $host a" > $nsupdatecmds
     echo "update add $host 3600 a $new_ip_address" >> $nsupdatecmds
     echo "send" >> $nsupdatecmds

     nsupdate $nsupdatecmds
fi 

Se connecter à Microsoft Entra Domain Services, et vérifier que les services sont détectables

1. Assurez-vous que vous êtes en mesure d’effectuer un test ping sur le serveur de domaine par le nom de domaine.

ping contosodomain.contoso.com

PING contosodomain.contoso.com (10.0.2.4) 56(84) bytes of data.
64 bytes from pwe-oqarc11l568.internal.cloudapp.net (10.0.2.4): icmp_seq=1 ttl=128 time=1.41 ms
64 bytes from pwe-oqarc11l568.internal.cloudapp.net (10.0.2.4): icmp_seq=2 ttl=128 time=1.02 ms
64 bytes from pwe-oqarc11l568.internal.cloudapp.net (10.0.2.4): icmp_seq=3 ttl=128 time=0.740 ms
64 bytes from pwe-oqarc11l568.internal.cloudapp.net (10.0.2.4): icmp_seq=4 ttl=128 time=0.925 ms 

^C 

--- contosodomain.contoso.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3016ms
rtt min/avg/max/mdev = 0.740/1.026/1.419/0.248 ms 

2. Vérifiez que vous pouvez découvrir les services Microsoft Entra sur le réseau.

nslookup
> set type=SRV
> _ldap._tcp.contosodomain.contoso.com.

Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer: 

_ldap._tcp.contosodomain.contoso.com service = 0 100 389 pwe-oqarc11l568.contosodomain.contoso.com.
_ldap._tcp.contosodomain.contoso.com service = 0 100 389 hxt4yo--jb9q529.contosodomain.contoso.com. 

Configurer le nom d’hôte et le nom de domaine complet (FQDN)

1. À l’aide de votre éditeur de texte, mettez à jour le fichier /etc/hosts avec le nom de domaine complet final (après avoir joint le domaine) et l’alias de l’hôte. L’adresse IP n’a pas d’importance pour l’instant, car cette ligne sera principalement utilisée pour traduire le nom d’hôte court en nom de domaine complet. Pour plus d’informations, consultez Configuration de Samba en tant que membre de domaine.

127.0.0.1       contosovm.contosodomain.contoso.com contosovm
#cmd=sudo vim /etc/hosts   
#then enter this value instead of localhost "ubuntvm.contosodomain.contoso.com UbuntuVM" 

2. À présent, votre nom d’hôte doit être résolu. Vous pouvez ignorer l’adresse IP à laquelle il est résolu pour l’instant. Le nom d’hôte court doit être résolu en nom de domaine complet.

getent hosts contosovm

127.0.0.1       contosovm.contosodomain.contoso.com contosovm

dnsdomainname

contosodomain.contoso.com

hostname -f

contosovm.contosodomain.contoso.com 

Notes

Certaines distributions nécessitent l’exécution de la commande hostnamectl pour que le nom d’hôte -f soit mis à jour :

hostnamectl set-hostname contosovm.contosodomain.contoso.com

Configurer krb5.conf

1. Configurez /etc/krb5.conf afin que le centre de distribution de clés Kerberos (KDC) avec le serveur de domaine puisse être contacté pour l’authentification. Pour plus d’informations, consultez la documentation MIT Kerberos. Voici un exemple de fichier /etc/krb5.conf.

[libdefaults]
        default_realm = CONTOSODOMAIN.CONTOSO.COM
        dns_lookup_realm = false
        dns_lookup_kdc = true

Configurer smb.conf

1. Identifiez le chemin d’accès à smb.conf.

sudo smbd -b | grep "CONFIGFILE"

   CONFIGFILE: /etc/samba/smb.conf

2. Modifiez la configuration SMB pour qu’elle agisse en tant que membre de domaine. Pour plus d’informations, consultez Configuration de samba en tant que membre de domaine. Voici un exemple de fichier smb.conf.

Remarque

Cet exemple concerne Microsoft Entra Domain Services, pour lequel nous vous recommandons de définir backend = rid au moment de configurer idmap. Les utilisateurs AD DS locaux peuvent préférer choisir un autre serveur principal idmap.

[global]
   workgroup = CONTOSODOMAIN
   security = ADS
   realm = CONTOSODOMAIN.CONTOSO.COM

   winbind refresh tickets = Yes
   vfs objects = acl_xattr
   map acl inherit = Yes
   store dos attributes = Yes

   dedicated keytab file = /etc/krb5.keytab
   kerberos method = secrets and keytab

   winbind use default domain = Yes 

   load printers = No
   printing = bsd
   printcap name = /dev/null
   disable spoolss = Yes

   log file = /var/log/samba/log.%m
   log level = 1

   idmap config * : backend = tdb
   idmap config * : range = 3000-7999

   idmap config CONTOSODOMAIN : backend = rid
   idmap config CONTOSODOMAIN : range = 10000-999999

   template shell = /bin/bash
   template homedir = /home/%U 

3. Forcez winbind à recharger le fichier de configuration modifié.

sudo smbcontrol all reload-config

Joindre le domaine

1. Utilisez la commande net ads join pour joindre l’hôte au domaine Microsoft Entra Domain Services. Si la commande génère une erreur, consultez Résolution des problèmes liés aux membres du domaine samba pour résoudre le problème.

sudo net ads join -U contososmbadmin    # user  - garead

Enter contososmbadmin's password:

Using short domain name -- CONTOSODOMAIN
Joined 'CONTOSOVM' to dns domain 'contosodomain.contoso.com' 

2. Vérifiez que l’enregistrement DNS existe pour cet hôte sur le serveur de domaine.

nslookup contosovm.contosodomain.contoso.com 10.0.2.5

Server:         10.0.2.5
Address:        10.0.2.5#53

Name:   contosovm.contosodomain.contoso.com
Address: 10.0.0.8

Si les utilisateurs se connectent activement à des machines clientes ou des machines virtuelles et accèdent aux partages de fichiers Azure, vous devez configurer nsswitch.conf et configurer PAM pour winbind. Si l’accès est limité aux applications représentées par un compte d’utilisateur ou d’ordinateur qui a besoin d’une authentification Kerberos pour accéder au partage de fichiers, vous pouvez ignorer ces étapes.

Configurer nsswitch.conf

1. Maintenant que l’hôte est joint au domaine, vous devez placer les bibliothèques winbind dans les emplacements à rechercher lors de la recherche d’utilisateurs et de groupes. Pour ce faire, mettez à jour les entrées passwd et group dans nsswitch.conf. Utilisez votre éditeur de texte pour modifier /etc/nsswitch.conf et ajouter les entrées suivantes :

passwd:         compat systemd winbind
group:          compat systemd winbind

2. Activez le service winbind pour démarrer automatiquement au redémarrage.

sudo systemctl enable winbind

Synchronizing state of winbind.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable winbind

3. Ensuite, redémarrez le service.

sudo systemctl restart winbind
sudo systemctl status winbind

winbind.service - Samba Winbind Daemon
   Loaded: loaded (/lib/systemd/system/winbind.service; enabled; vendor preset: enabled)
   Active: active (running) since Fri 2020-04-24 09:34:31 UTC; 10s ago
     Docs: man:winbindd(8)
           man:samba(7)
           man:smb.conf(5)
 Main PID: 27349 (winbindd)
   Status: "winbindd: ready to serve connections..."
    Tasks: 2 (limit: 4915)
   CGroup: /system.slice/winbind.service
           ├─27349 /usr/sbin/winbindd --foreground --no-process-group
           └─27351 /usr/sbin/winbindd --foreground --no-process-group

Apr 24 09:34:31 contosovm systemd[1]: Starting Samba Winbind Daemon...
Apr 24 09:34:31 contosovm winbindd[27349]: [2020/04/24 09:34:31.724211,  0] ../source3/winbindd/winbindd_cache.c:3170(initialize_winbindd_cache)
Apr 24 09:34:31 contosovm winbindd[27349]:   initialize_winbindd_cache: clearing cache and re-creating with version number 2
Apr 24 09:34:31 contosovm winbindd[27349]: [2020/04/24 09:34:31.725486,  0] ../lib/util/become_daemon.c:124(daemon_ready)
Apr 24 09:34:31 contosovm systemd[1]: Started Samba Winbind Daemon.
Apr 24 09:34:31 contosovm winbindd[27349]:   STATUS=daemon 'winbindd' finished starting up and ready to serve connections 

4. Assurez-vous que les utilisateurs et les groupes de domaine sont découverts.

getent passwd contososmbadmin

contososmbadmin:*:12604:10513::/home/contososmbadmin:/bin/bash

getent group 'domain users'

domain users:x:10513: 

Si le paramètre ci-dessus ne fonctionne pas, vérifiez si le contrôleur de domaine est accessible à l’aide de l’outil wbinfo :

wbinfo --ping-dc

Configurer PAM pour winbind

1. Vous devez placer winbind dans la pile d’authentification afin que les utilisateurs de domaine soient authentifiés via winbind en configurant PAM (Pluggable Authentication Module) pour winbind. La deuxième commande garantit que homedir est créé pour un utilisateur de domaine lors de la première connexion à ce système.

sudo pam-auth-update --enable winbind
sudo pam-auth-update --enable mkhomedir 

2. Vérifiez que la configuration d’authentification PAM contient les arguments suivants dans /etc/pam.d/common-auth :

grep pam_winbind.so /etc/pam.d/common-auth

auth    [success=1 default=ignore]      pam_winbind.so krb5_auth krb5_ccache_type=FILE cached_login try_first_pass 

3. Vous devez maintenant être en mesure de vous connecter à ce système en tant qu’utilisateur du domaine, via ssh, su ou tout autre moyen d’authentification.

su - contososmbadmin
Password:

Creating directory '/home/contososmbadmin'.
contososmbadmin@contosovm:~$ pwd
/home/contososmbadmin
contososmbadmin@contosovm:~$ id
uid=12604(contososmbadmin) gid=10513(domain users) groups=10513(domain users),10520(group policy creator owners),10572(denied rodc password replication group),11102(dnsadmins),11104(aad dc administrators),11164(group-readwrite),11165(fileshareallaccess),12604(contososmbadmin) 

Vérifier la configuration

Pour vérifier que l’ordinateur client est joint au domaine, recherchez le nom de domaine complet du client sur le contrôleur de domaine et recherchez l’entrée DNS répertoriée pour ce client particulier. Dans de nombreux cas, <dnsserver> est identique au nom de domaine auquel le client est joint.

nslookup <clientname> <dnsserver>

Ensuite, utilisez la commande klist pour afficher les tickets dans le cache Kerberos. Il doit y avoir une entrée commençant par krbtgt qui ressemble à :

krbtgt/CONTOSODOMAIN.CONTOSO.COM@CONTOSODOMAIN.CONTOSO.COM

Si vous n’avez pas configuré PAM pour winbind, klist peut ne pas afficher l’entrée de ticket. Dans ce cas, vous pouvez authentifier manuellement l’utilisateur pour obtenir les tickets :

wbinfo -K contososmbadmin

Vous pouvez également exécuter la commande dans le cadre d’un script :

wbinfo -K 'contososmbadmin%SUPERSECRETPASSWORD'

Montage du partage de fichiers

Une fois que vous avez activé l’authentification Kerberos AD (ou Microsoft Entra ID), et que vous avez joint à un domaine votre machine virtuelle Linux, vous pouvez monter le partage de fichiers.

Pour obtenir des instructions de montage détaillées, consultez Monter le partage de fichiers Azure à la demande avec mount.

Utilisez l’option de mount supplémentaire suivante avec tous les modèles de contrôle d’accès pour activer la sécurité Kerberos : sec=krb5. Le nom d’utilisateur et le mot de passe doivent être omis lorsque sec=krb5 est en cours d’utilisation.

Remarque

Cette fonctionnalité prend uniquement en charge un modèle de contrôle d’accès appliqué au serveur à l’aide de listes de contrôle d’accès NT sans bits de mode. Les outils Linux qui mettent à jour les listes de contrôle d’accès NT étant minimes, mettez à jour les listes de contrôle d’accès via Windows. Les modèles de contrôle d’accès appliqué par le client (modefromsid,idsfromsid) et de contrôle d’accès traduit par le client (cifsacl) ne sont pas pris en charge actuellement.

Autres options de mount

Montage mono-utilisateur ou multi-utilisateur

Dans un cas d’utilisation de montage mono-utilisateur, le point de montage est accessible par un seul utilisateur du domaine AD et n’est pas partagé avec d’autres utilisateurs du domaine. Chaque accès aux fichiers se produit dans le contexte de l’utilisateur dont les informations d’identification krb5 ont été utilisées pour monter le partage de fichiers. Tout utilisateur sur le système local qui accède au point de montage empruntera l’identité de cet utilisateur.

Dans un cas d’utilisation de montage multi-utilisateur, il existe toujours un point de montage unique, mais plusieurs utilisateurs AD peuvent accéder à ce même point de montage. Dans les scénarios où plusieurs utilisateurs sur le même client accèdent au même partage et que le système est configuré pour Kerberos et monté avec sec=krb5, envisagez d’utiliser l’option multiuser de mount.

Autorisations de fichier

Les autorisations de fichier sont importantes, en particulier si les clients Linux et Windows accèdent au partage de fichiers. Pour convertir des autorisations de fichier en DACL sur des fichiers, utilisez une option de mount par défaut telle que file_mode=<>,dir_mode=<>. Les autorisations de fichier spécifiées en tant que file_mode et dir_mode sont appliquées uniquement au sein du client. Le serveur applique le contrôle d’accès en fonction du descripteur de sécurité du fichier ou du répertoire.

Propriété des fichiers

La propriété des fichiers est importante, en particulier si les clients Linux et Windows accèdent au partage de fichiers. Choisissez l’une des options de mount suivantes pour convertir l’UID/GID de propriété du fichier en SID de propriétaire/groupe sur la liste DACL de fichier :

• Utilisez une valeur par défaut telle que uid=<>,gid=<>
• Configurer le mappage UID/GID via RFC2307 et Active Directory (nss_winbind ou nss_sssd)

Cohérence du cache d’attributs de fichier

Les performances sont importantes, même si les attributs de fichier ne sont pas toujours précis. La valeur par défaut d’actimeo est 1 (seconde), ce qui signifie que les attributs de fichier sont extraits à nouveau du serveur si les attributs mis en cache datent de plus d’une seconde. L’augmentation de la valeur à 60 signifie que les attributs sont mis en cache pendant au moins 1 minute. Pour la plupart des cas d’usage, nous vous recommandons d’utiliser la valeur 30 pour cette option (actimeo=30).

Pour les noyaux plus récents, envisagez de définir les fonctionnalités d’actimeo de manière plus granulaire. Vous pouvez utiliser acdirmax pour la mise en cache de la revalidation de l’entrée de répertoire et acregmax pour la mise en cache des métadonnées de fichier, par exemple acdirmax=60,acregmax=5.

Étape suivante

Pour plus d’informations sur le montage d’un partage de fichiers SMB sur Linux, consultez :

• Monter un partage de fichiers SMB Azure sur Linux