Différences

Ci-dessous, les différences entre deux révisions de la page.

--- utilisateurs:qedinux:samba_ad_dc_nfs4_kerberized [Le 08/10/2015, 22:05]
Qedinux En cours de rédaction
+++ utilisateurs:qedinux:samba_ad_dc_nfs4_kerberized [Le 11/09/2022, 13:15] (Version actuelle)
moths-art Suppression des espaces en fin de ligne (détecté et corrigé via le bot wiki-corrector (https://forum.ubuntu-fr.org/viewtopic.php?id=2067892)
@@ Ligne 1: / Ligne 1: @@
-{{tag>brouillon samba administration windows réseau}}
+~~REDIRECT>tutoriel/samba_ad_dc_nfs4_kerberized~~
 ====== Samba AD DC - Partage NFSv4 avec authentification Kerberos ======
@@ Ligne 23: / Ligne 23: @@
 |  ubnws01  |  192.0.2.13  |  Machine client  |
-Le répertoire partagé sera le répertoire ///media/example/home// présent sur le serveur de fichier et contenant les répertoires //home// des utilisateurs du domaine. Ce répertoire sera monté sur chaque machine du domaine afin de permettre à chaque utilisateur d'accéder à son répertoire //home// depuis n'importe quelle machine du domaine.
+Le répertoire partagé sera le répertoire ///media/home/example// présent sur le serveur de fichier et contenant les répertoires //home// des utilisateurs du domaine. Ce répertoire sera monté sur chaque machine du domaine afin de permettre à chaque utilisateur d'accéder à son répertoire //home// depuis n'importe quelle machine du domaine.
 ===== Quelques notions à propos de Kerberos =====
@@ Ligne 41: / Ligne 41: @@
 <code>sudo apt-get install nfs-kernel-server</code>
 ==== Définition des partages NFS ====
-Avant de faire fonctionner NFS, il faut préparer le partage. NFSv4 base son partage sur une racine virtuelle définie. Bien qu'il soit possible d'utiliser des répertoires déjà existants, il est recommandé d'en créer un à la racine du système de fichier, par exemple ///export//. Ensuite pour chaque répertoire qui sera partagé, il faut créer un sous répertoire, par exemple ///export/home//. A ce stade, les données partagées le serait sur la partition //Root// ce qui n'est pas une bonne pratique. Afin de ne pas modifier le reste du serveur de fichier, il faut procéder à la jonction du répertoire ///export/home// avec le répertoire qui stockera réellement les données, ///media/example/home//.
+Avant de faire fonctionner NFS, il faut préparer le partage. NFSv4 base son partage sur une racine virtuelle définie. Bien qu'il soit possible d'utiliser des répertoires déjà existants, il est recommandé d'en créer un à la racine du système de fichier, par exemple ///export//. Ensuite pour chaque répertoire qui sera partagé, il faut créer un sous répertoire dans la structure NFS, par exemple ///export/home/example//.
+<code>sudo mkdir -p /export/home/example</code>
+A ce stade, les données partagées le seraient sur la partition //Root// ce qui n'est pas une bonne pratique. Afin de ne pas modifier le reste du serveur de fichier, il faut procéder à la jonction du répertoire ///export/home/example// avec le répertoire qui contiendra réellement les données, ///home/example//. Dans le cas où le répertoire contenant les données représente une partition entière, la partition peut alors être directement montée sur la structure NFS.
 En ligne de commande
-<code>sudo mount --bind /media/example/home /export/home</code>
+<code>sudo mount --bind /home/example /export/home/example</code>
 Ou en ajoutant une ligne dans le fichier ///etc/fstab// pour que l'opération soit effectuée à chaque redémarrage
 <file - /etc/fstab>
 # Export NFS4
-/media/example/home               /export/home          none       bind             0       0
+/home/example            /export/home/example        none       bind           0       0
 </file>
@@ Ligne 56: / Ligne 58: @@
 La configuration des partages se fait au travers du fichier ///etc/exports//
 <file - /etc/exports>
-/export        192.0.2.0/24(rw,sync,fsid=0,no_subtree_check,crossmnt,sec=krb5)
+/export                192.0.2.0/24(rw,sync,fsid=0,no_subtree_check,crossmnt,sec=krb5)
-/export/home   192.0.2.0/24(rw,sync,no_subtree_check,sec=krb5)
+/export/home/example   192.0.2.0/24(rw,sync,no_subtree_check,sec=krb5)
 </file>
-La première ligne avec l'option **//fsid=0//** (ou fsid=root) défint la racine virtuelle du système de fichier partagé. Ainsi, tout les fichiers et répertoires sous ///export// sont accessibles par le partage NFS.
+La première ligne avec l'option **//fsid=0//** (ou fsid=root) définit la racine virtuelle du système de fichiers partagés. Ainsi, tous les fichiers et répertoires sous ///export// sont accessibles par le partage NFS.
 L'option **//sec=krb5//** définit le niveau de sécurité exigé. Il en existe 3:
@@ Ligne 80: / Ligne 82: @@
 </file>
-Le service n'arrive pas à démarrer parce qu'il ne trouve pas son SPN (Service Principal Name) dans le fichier keytab par défaut (/etc/krb5.keytab) qui, par défaut, serait //nfs/ubnfs01.example.com@EXAMPLE.COM//. Plus clairement, le service ne trouve pas sa clé de chiffrement. Pour modifier le fichier //keytab//, il faut utiliser l'outil //net// avec les commandes //ads keytab//. Il faut également avoir les droits super-utilisateurs. Pour rappel, vu l'importance de ce fichier, les permissions sur celui-ci sont très restrictives //root:root 600//. Seul l'utilisateur //root// peut y accéder en lecture et écriture. Il faut également interagir avec le serveur Kerberos présent sur le DC. Pour cela, la meilleure façon de procéder consiste à s'authentifier avec un compte administrateur du domaine à chaque commande avec l'option //-U Administrator//.
+Le service n'arrive pas à démarrer parce qu'il ne trouve pas son SPN (Service Principal Name) dans le fichier keytab par défaut (/etc/krb5.keytab) qui, par défaut, serait //nfs/ubnfs01.example.com@EXAMPLE.COM//. Plus clairement, le service ne trouve pas son identité afin de s'authentifier. Pour modifier le fichier //keytab//, il faut utiliser l'outil //net// avec les commandes //ads keytab//. Il faut également avoir les droits super-utilisateurs. Pour rappel, vu l'importance de ce fichier, les permissions sur celui-ci sont très restrictives //root:root 600//. Seul l'utilisateur //root// peut y accéder en lecture et écriture. Il faut également interagir avec le serveur Kerberos présent sur le DC. Pour cela, la meilleure façon de procéder consiste à s'authentifier avec un compte administrateur du domaine à chaque commande avec l'option //-U Administrator//.
-<code>sudo net ads keytab flush -U Administrator
+<code>sudo net ads keytab add nfs -U Administrator
-Enter Administrator's password:
-sudo net ads keytab create -U Administrator
-Enter Administrator's password:
-sudo net ads keytab add nfs -U Administrator
 Enter Administrator's password:
@@ Ligne 99: / Ligne 95: @@
   arcfour-hmac-md5                            nfs/ubnfs01@EXAMPLE.COM
 </code>
-La commande //flush// vide le fichier //keytab// et supprime l'ensemble des SPN associés à la machine.
-La commande //create// crée le fichier //keytab// par défaut avec l'iUPN et l'eUPN, si l'attribut //userPrincipalName// a été définit, et les SPN host/<Hostname>@<Realm> et host/<FQDN>@<Realm>.
 La commande //add <service>// ajoute deux SPN au fichier //keytab// (un pour le //hostname// et un pour le //fqdn//). Parallèlement, deux attributs 'servicePrincipalName' sont ajoutés à l'object Active Directory représentant l'ordinateur (ubnfs01)  (<service>/<hostname> et <service>/<fqdn>)..
 La commande //list// liste les UPN et SPN présents dans le fichier //keytab//.
+La commande //flush// vide le fichier //keytab// et supprime l'ensemble des SPN associés à la machine.
+La commande //create// crée le fichier //keytab// par défaut avec l'iUPN et l'eUPN, si l'attribut //userPrincipalName// a été définit, et les SPN host/<hostname>@<REALM> et host/<fqdn>@<REALM>.
 ==== Conseils ====
-Le service //nfs-kernel-server// lorsqu'il démarre va lire le fichier de configuration ///etc/default/nfs-kernel-server//. Par défaut, il ne faut rien y changer. Cependant, si l'on veut augmenter la quantité d'informations envoyées dans le fichier log. On peut ajouter l'option très bavard au démon //rpc.svcgssd// (responsable de l'authentification de la machine vis-à-vis du serveur Kerberos)
+Le service //nfs-kernel-server// lorsqu'il démarre va lire le fichier de configuration ///etc/default/nfs-kernel-server//. Par défaut, il ne faut rien y changer. Cependant, si l'on veut augmenter la quantité d'informations envoyées dans le fichier log. On peut ajouter l'option "très bavard" au démon //rpc.svcgssd// (responsable de l'authentification de la machine vis-à-vis du serveur Kerberos)
 <file - /etc/default/nfs-kernel-server>
 RPCSVCGSSDOPTS="-vvv"
@@ Ligne 120: / Ligne 116: @@
 <code>sudo apt-get install nfs-common</code>
 ==== Montage du partage ====
-Le partage se monte avec la commande //mount// et le type //nfs4// qui va rediriger l'appel vers la commande spécifique //mount.nfs4//.
+Le partage se monte avec la commande //mount// et le type //nfs4// qui va rediriger l'appel vers la commande spécifique //mount.nfs4//. Afin de test l'accès au partage, le partage sera monté sur ///mnt/test// au lieu de ///home/example.com//
-<code>sudo mount -t nfs4 -o sec=krb5 ubnfs01.example.com:/home /mnt/home</code>
+<code>sudo mount -t nfs4 -o sec=krb5 ubnfs01.example.com:/home/example /home/example</code>
 L'option //sec=krb5// précise que le montage se fera avec authentification Kerberos.
 ==== Erreurs et solutions ====
-Le résultat de la commande //mount// ci-dessus devrait être : "Access denied by server while mounting ubnfs01.example.com:/home"
+Le résultat de la commande //mount// ci-dessus devrait être : "Access denied by server while mounting ubnfs01.example.com:/home/example"
-Les raisons sont multiples et vont être parcourrues ci-après
+Les raisons sont multiples et vont être parcourues ci-après
 === Activation du démon rpc.gssd ===
 Le démon //rpc.gssd// est responsable de l'authentification par Kerberos. Il faut donc le démarrer manuellement (via son script Upstart, ///etc/init/gssd.conf//)
@@ Ligne 134: / Ligne 130: @@
 NEED_GSSD="yes"
 </file>
 A la lecture du script Upstart du démon //rpc.gssd//, on constate que ce démon va charger plusieurs modules dont //rpcsec_gss_krb5// et que si le fichier ///etc/fstab// contient une ligne avec une option du type //sec=krb5//, le démon sera automatiquement démarré.
-Afin de faciliter le dépannage en cas de problème avec ce démon, il est possible d'activer son mode très, très bavard avec l'option "-vvv".
+Afin de faciliter le dépannage en cas de problème avec ce démon, il est possible d'activer son mode "très, très bavard" avec l'option "-vvv".
 <code>sudo stop gssd
 sudo rpc.gssd -vvv</code>
@@ Ligne 164: / Ligne 160: @@
 </code>
 === Absence d'identité ===
 Le démon //rpc.gssd// va chercher une identité dans le fichier ///etc/krb5.keytab// pour s'authentifier vis-à-vis du serveur Kerberos. Il essaie premièrement l'UPN de l'ordinateur <FQDN$>@<REALM> et ensuite les SPN root/<fqdn>@<REALM>, nfs/<fqdn>@<REALM> et host/<fqdn>@<REALM>.
 <file - /var/log/syslog>
 Oct  7 20:17:08 ubnws01 rpc.gssd[6173]: No key table entry found for UBNWS01.EXAMPLE.COM$@EXAMPLE.COM while getting keytab entry for 'UBNWS01.EXAMPLE.COM$@EXAMPLE.COM'
@@ Ligne 179: / Ligne 175: @@
 Oct  7 22:16:44 ubnws01 rpc.gssd[6173]: ERROR: No credentials found for connection to server ubnfs01.example.com
 </file>
-Le démon //rpc.gssd// est multi-usage. Dans le cas de NFSv4 avec Kerberos, il a besoin de l'UPN de l'ordinateur (cfr [[utilisateurs:qedinux:samba_ad_dc_nfs4_kerberized#quelques_notions_a_propos_de_kerberos|Notions Kerberos]]). Le fichier ///etc/krb5.keytab// possède déjà un UPN pour <HOSTNAME$>@<REALM> mais le démon //rpc.gssd// recherche l'UPN <FQDN$>@<REALM>. Il faut donc l'ajouter. Ceci consiste à ajouter l'attribut 'userPrincipalName' avec la valeur <FQDN$>@<REALM> à l'objet 'Ordinateur' de Active Directory pour les client NFS. Il y a une multitude de façon de procéder :
+Le démon //rpc.gssd// est multi-usage. Dans le cas de NFSv4 avec Kerberos, il a besoin de l'UPN de l'ordinateur (cfr [[utilisateurs:qedinux:samba_ad_dc_nfs4_kerberized#quelques_notions_a_propos_de_kerberos|Notions Kerberos]]). Le fichier ///etc/krb5.keytab// possède déjà l' iUPN (<HOSTNAME$>@<REALM>) mais le démon //rpc.gssd// recherche l'UPN <FQDN$>@<REALM>. Il faut donc ajouter l' eUPN équivalent à l'objet représentant la machine cliente dans l'Active Directory. Ceci consiste à ajouter l'attribut 'userPrincipalName' avec la valeur <FQDN$>@<REALM>. Il y a une multitude de façon de procéder :
   * Utiliser une machine Windows dans le domaine avec les outils d'administrations pour Active Directory.
   * Utiliser un logiciel avec une interface graphique proche de ce que Windows propose, par exemple Apache Directory Studio, qui n'est pas inclus dans la distribution Ubuntu.
-  * Utiliser les outils LDAP.
+  * Utiliser les outils LDAP
+    <code>ldapmodify -H ldap://ubndc01.example.com -U Administrator << EOF
+dn: cn=ubnws01,cn=computers,dc=example,dc=com
+changetype: modify
+add: userPrincipalName
+userPrincipalName: UBNWS01.EXAMPLE.COM\$@EXAMPLE.COM
+EOF</code>
+Cette méthode ne modifie pas les identités existantes de la machine. On peut alors ajouter la nouvelle identité (eUPN) au fichier keytab avec la commande
+<code>sudo net ads keytab add UBNWS01.EXAMPLE.COM\$ -U Administrator</code>
   * Utiliser la commande //net ads join// qui sert à joindre la machine au domaine.
 <code>sudo net ads join --createupn=UBNWS01.EXAMPLE.COM\$@EXAMPLE.COM -U Administrator</code>
-Ceci va créer de nouvelles versions des identités liées à la machines (iUPN, eUPN et 2 SPN host/...). Ses nouvelles identités sont ajoutées au fichier ///etc/krb5.keytab// mais les anciennes ne sont pas automatiquement supprimées. On peut sans craintes faire le ménage avec les commandes
+<note important>Ceci va créer de nouvelles versions des identités liées à la machines (iUPN, eUPN et 2 SPN host/...). Ses nouvelles identités sont ajoutées au fichier ///etc/krb5.keytab// mais les anciennes ne sont pas automatiquement supprimées. On peut faire le ménage avec les commandes mais ceci risque d’interrompre les processus qui utilisaient les anciennes identités.
 <code>sudo net ads keytab flush -U Administrator
-sudo net ads keytab create -U Administrator</code>
+sudo net ads keytab create -U Administrator</code></note>
-==== Eureka ====
+=== Eureka ===
-Après avoir résolu ces quelques problèmes, il est possible de monter le partage NFS.
+Après avoir résolu ces quelques problèmes, il est possible de monter le partage NFS et d'y accèder.
+==== Automatisation ====
+Deux approches sont possibles pour l'automatisation du montage des partages NFS.
+  * Ajouter une ligne dans le fichier ///etc/fstab//
+  * Utiliser //[[:autofs]]//
+La première possibilité implique que la machine doit avoir une connectivité réseau avant de procéder au montage. C'est typiquement le cas des serveurs mais pas des machines de bureau (fixes ou portables). De plus, il y a la problématique de la gestion des ressources. En effet, chaque partage monté consomme des ressources sur la machine cliente mais surtout sur la machine serveur. La seconde possibilité apporte donc une solution à ces deux problèmes.
+=== Mise en oeuvre avec /etc/fstab ===
+<file - /etc/fstab>
+ubnfs01:/home/example        /home/example        nfs4        sec=krb5        0        0
+</file>
+=== Mise en oeuvre sur base de autofs ===
+Installation du paquet **[[apt>autofs]]**
+<code>sudo apt-get install autofs</code>
+Ajout d'une entrée dans le fichier maître ///etc/auto.master//
+<file - /etc/auto.master>
+/home/example        /etc/auto.home        --timeout=90
+</file>
+Définition de la règle //auto.home//
+<file - /etc/auto.home>
+*        -fstype=nfs4,sec=krb5 ubnfs01.example.com:/home/example/&
+</file>
 ===== En résumé =====
+==== Sur le serveur DNS ====
+<note important>Les lignes de codes de ce paragraphe s'appliquent uniquement au serveur DNS interne de Samba. Pour réaliser ces opérations sur tout autre serveur DNS, il faut se référer à la documentation du serveur DNS</note>
+Créer une zone DNS inversé
+<code>samba-tool dns zonecreate ubndc01 2.0.192.in-addr.arpa
+Zone 2.0.192.in-addr.arpa created successfully</code>
+Ajouter un pointeur vers le serveur de fichier
+<code>samba-tool add ubndc01 2.0.192.in-addr.arpa 12 PTR ubnfs01.example.com
+Record added successfully</code>
+Redémarrer le contrôleur de domaine pour pallier au [[https://bugzilla.samba.org/show_bug.cgi?id=9404|Bug 9404]]
+<code>ssh ubndc01
+sudo service samba-ad-dc restart
+exit</code>
 ==== Sur le serveur de fichier ====
 Installation du paquets NFS server
 <code>sudo apt-get install nfs-kernel-server</code>
 Création de la structure de répertoire pour NFS
-<code>sudo mkdir -p /export/home</code>
+<code>sudo mkdir -p /export/home/example</code>
 Jonction du répertoire réel avec la structure NFS
 <file - /etc/fstab>
 # Export NFS4
-/media/example/home               /export/home          none       bind             0       0
+/home/example           /export/home/example        none       bind          0       0
 </file>
-<code>sudo mount /export/home</code>
+<code>sudo mount /export/home/example</code>
 Ajout du SPN dans le //keytab//
 <code>sudo net ads keytab add nfs -U Administrator</code>
 Lancement du service
 <code>sudo service nfs-kernel-server start</code>
+==== Sur les clients NFS ====
+Installation du paquet NFS client
+<code>sudo apt-get install nfs-common</code>
+S'il n'est pas déjà définit dans l'Active Directory, définir l'eUPN de l'ordinateur
+<code>ldapmodify -H ldap://ubndc01.example.com -U Administrator << EOF
+dn: cn=ubnws01,cn=computers,dc=example,dc=com
+changetype: modify
+add: userPrincipalName
+userPrincipalName: UBNWS01.EXAMPLE.COM\$@EXAMPLE.COM
+EOF</code>
+S'il n'est pas déjà présent dans le fichier ///etc/krb5.keytab//, ajouter l'eUPN au fichier
+<code>sudo net ads keytab add UBNWS01.EXAMPLE.COM\$ -U Administrator</code>
+Monter la ressource partagée manuellement
+<code>sudo mount -t nfs4 -o sec=krb5 ubnfs01.example.com:/home/example /home/example</code>
+__Ou__ automatiquement (cfr [[utilisateurs:qedinux:samba_ad_dc_nfs4_kerberized?do=#automatisation|Automatisation]])
 ===== Références =====