Data Domain : présentation de NFSv4

Plusieurs facteurs peuvent influer sur le choix de NFSv4 ou NFSv3 :
● Prise en charge
du client NFSCertains clients NFS peuvent uniquement prendre en charge NFSv3 ou NFSv4, ou fonctionner mieux avec une version.
● Exigences
opérationnelles Une entreprise peut être strictement standardisée pour utiliser NFSv4 ou NFSv3.
● Sécurité
Si vous avez besoin d’une sécurité renforcée, NFSv4 fournit un niveau de sécurité plus élevé que NFSv3, y compris l’ACL et la configuration étendue du propriétaire et
du groupe.
● Exigences
relatives aux fonctionnalités Si vous avez besoin d’un verrouillage à plage d’octets ou de fichiers UTF-8, vous devez choisir NFSv4.
● Sous-montages
NFSv3 Si votre configuration existante utilise des sous-montages NFSv3, NFSv3 peut être le choix approprié.

NFSv4 comparé à NFSv3
NFSv4 offre des fonctionnalités améliorées par rapport à NFSv3.
Le tableau suivant compare les fonctionnalités de NFSv3 à celles de NFSv4.

Table NFSv4 comparé à NFSv3

Ports
NFSv4Vous pouvez activer ou désactiver NFSv4 et NFSv3 indépendamment. En outre, vous pouvez déplacer des versions NFS vers différents ports.
Les versions n’ont pas besoin d’occuper le même port.
Avec NFSv4, vous n’avez pas besoin de redémarrer le système de fichiers si vous changez de port. Seul un redémarrage NFS est requis dans de tels cas.
Comme NFSv3, NFSv4 s’exécute sur le port 2049 par défaut s’il est activé.
NFSv4 n’utilise pas portmapper (port 111) ou mountd (port 2052).

Présentation
du mappage d’IDNFSv4 identifie les propriétaires et les groupes au moyen d’un format externe commun, tel que joe@example.com. Ces formats courants sont les suivants :
connus sous le nom d’identifiants, ou d’ID.
Les identifiants sont stockés dans un serveur NFS et utilisent des représentations internes telles que l’ID 12345 ou l’ID S-123-33-667-2. Lla
La conversion entre les identifiants internes et externes est connue sous le nom de mappage d’ID.
Les ID sont associés aux éléments suivants :
● Propriétaires de fichiers et de répertoires
● Groupes de propriétaires de fichiers et de répertoires
● Entrées dans les listes de contrôle d’accès (ACL)
Les systèmes de protection utilisent un format interne commun pour les protocoles NFS et CIFS/SMB, ce qui permet de
partager des fichiers et des répertoiresentre NFS et CIFS/SMB. Chaque protocole convertit le format interne en son propre format externe avec son propre ID
Cartographie.
 

Formats
externesLe format externe des identifiants NFSv4 respecte les normes NFSv4 (par exemple, RFC-7530 pour NFSv4.0). En outre,
des formats supplémentaires sont pris en charge pour l’interopérabilité.

Formats d’identificateurs standard

Standard external identifiers for NFSv4 have the format identifier@domain. This identifier is used for NFSv4 owners,
owner-groups, and access control entries (ACEs). The domain must match the configured NFSv4 domain that was set using the
nfs option command.
The following CLI example sets the NFSv4 domain to mycorp.com for the NFS server:
nfs option set nfs4-domain mycorp.com
See client-specific documentation you have for setting the client NFS domain. Depending on the operating system, you might
need to update a configuration file (for example, /etc/idmapd.conf) or use a client administrative tool.
NOTE: If you do not set the default value, it will follow the DNS name for the protection system.
NOTE: The file system must be restarted after changing the DNS domain for the nfs4-domain to automatically update.
ACE extended identifiers
For ACL ACE entries, protection system NFS servers also support the following standard NFSv4 ACE extended identifiers
defined by the NFSv4 RFC:
● OWNER@, The current owner of the file or directory
● GROUP@, the current owner group of the file or directory.
● The special identifiers INTERACTIVE@, NETWORK@, DIALUP@, BATCH@, ANONYMOUS@, AUTHENTICATED@,
SERVICE@.

Formats
alternatifsPour permettre l’interopérabilité, les serveurs NFSv4 sur les systèmes de protection prennent en charge certains formats d’ID alternatifs pour l’entrée et la sortie.
● Identifiants numériques ; par exemple, « 12345 ».
● Identifiants de sécurité (SID) compatibles avec Windows exprimés sous la forme « S-NNN-NNN-... »
Voir les sections sur le mappage d’entrée et le mappage de sortie pour plus d’informations sur les restrictions de ces formats.

Formats
d’identificateurs internesLe système de fichiers DD stocke les identifiants avec chaque objet (fichier ou répertoire) du système de fichiers. Tous les objets ont un utilisateur
numériqueID (UID) et ID de groupe (GID). Ceux-ci, ainsi qu’un ensemble de bits de mode, permettent l’identification et l’accès
traditionnels à UNIX/LinuxContrôles.
Les objets créés par le protocole CIFS/SMB, ou par le protocole NFSv4 lorsque les ACL NFSv4 sont activées, disposent également d’une extension
descripteur de sécurité (SD). Chaque SD contient les éléments suivants :
● Un identifiant de sécurité du propriétaire (SID)
● Un SID de groupe depropriétaires● Une ACL discrétionnaire (DACL)
● (Facultatif) Une ACL système (SACL)
Chaque SID contient un ID relatif (RID) et un domaine distinct de la même manière que les SID Windows.
Reportez-vous à la section sur NFSv4 et
Interopérabilité CIFS pour plus d’informations sur les SID et le mappage des SID.
Lorsque le mappage d’ID se produit
Le serveur NFSv4 du système de protection effectue le mappage dans les cas suivants :
● Mappage
d’entrée Le serveur NFS reçoit un identifiant d’un client NFSv4. 
● Mappage de sortie :
un identifiant est envoyé du serveur NFS au client NFSv4. 
● Mappage
des informations d’identification : les informations d’identification du client RPC sont mappées à une identité interne pour le contrôle d’accès et d’autres opérations.

Mappage
d’entréeLe mappage d’entrée se produit lorsqu’un client NFSv4 envoie un identifiant au serveur NFSv4 du système de protection, par exemple en configurant le propriétaire
ou le groupe de propriétaires d’un fichier. Le mappage d’entrée est distinct du mappage des informations d’identification.
Les identifiants de format standard tels que joe@mycorp.com sont convertis en UID/GID interne en fonction de la configuration
règles de conversion. Si les ACL NFSv4 sont activées, un SID est également généré, en fonction des règles de conversion configurées.
Les identifiants numériques (par exemple, « 12345 ») sont directement convertis en UID/GID correspondants si le client n’utilise pas Kerberos
Authentification. Si Kerberos est utilisé, une erreur est générée, comme recommandé par la norme NFSv4. Si les ACL NFSv4 sont
activé, un SID sera généré en fonction des règles de conversion.
Les SID Windows (par exemple, « S-NNN-NNN -... ») sont validés et directement convertis en SID correspondants. Un UID/GIDsera généré en fonction des
règles de conversion.

Mappage de sortie

Output mapping occurs when the NFSv4 server sends an identifier to the NFSv4 client; for example, if the server returns the
owner or owner-group of a file.
1. If configured, the output might be the numeric ID.
This can be useful for NFSv4 clients that are not configured for ID mapping (for example, some Linux clients).
2. Mapping is attempted using the configured mapping services, (for example, NIS or Active Directory).
3. The output is a numeric ID or SID string if mapping fails and the configuration is allowed.
4. Otherwise, nobody is returned.
The nfs option nfs4-idmap-out-numeric configures the mapping on output:
● If nfs option nfs4-idmap-out-numeric is set to map-first, mapping will be attempted. On error, a numeric string
is output if allowed. This is the default.
● If nfs option nfs4-idmap-out-numeric is set to always, output will always be a numeric string if allowed.
● If nfs option nfs4-idmap-out-numeric is set to never, mapping will be attempted. On error, nobody@nfs4-
domain is the output.
If the RPC connection uses GSS/Kerberos, a numeric string is never allowed and nobody@nfs4-domain is the output.
The following example configures the protection system NFS server to always attempt to output a numeric string on output. For
Kerberos the name nobody is returned:
nfs option set nfs4-idmap-out-numeric always

Mappage des
informations d’identificationLe serveur NFSv4 fournit les informations d’identification du client NFSv4.
Ces informations d’identification remplissent les fonctions suivantes :
● Déterminez la stratégie d’accès pour l’opération, par exemple, la possibilité de lire un fichier.
● Déterminez le propriétaire et le groupe de propriétaires par défaut des nouveaux fichiers et répertoires.
Les informations d’identification envoyées par le client peuvent être des john_doe@mycorp.com ou des informations d’identification système telles que UID=1000, GID=2000.
Les informations d’identification du système spécifient un UID/GID, ainsi que des ID de groupe auxiliaire.
Si les listes ACL NFSv4 sont désactivées, l’UID/GID et les ID de groupe auxiliaire sont utilisés pour les informations d’identification.

Si les listes ACL NFSv4 sont activées, les services de mappage configurés sont utilisés pour créer un descripteur de sécurité étendu pour l'
Pouvoirs:
● SID du propriétaire, du groupe propriétaire et du groupe auxiliaire mappés et ajoutés au descripteur de sécurité (SD).
● Les privilèges d’informations d’identification, le cas échéant, sont ajoutés au SD.
Interopérabilité
de NFSv4 et CIFS/SMBLes descripteurs de sécurité utilisés par NFSv4 et CIFS sont similaires du point de vue du mappage d’ID, bien qu’il existe des différences.
Vous devez tenir compte des points suivants pour garantir une interopérabilité optimale :
● Active Directory doit être configuré pour CIFS et NFSv4, et le mappeur d’ID NFS doit être configuré pour utiliser Active
Directory pour le mappage d’ID.
● Si vous utilisez les ACL CIFS de manière intensive, vous pouvez généralement améliorer la compatibilité en activant également les ACL NFSv4.
○ L’activation des ACL NFSv4 permet de mapper les informations d’identification NFSv4 au SID approprié lors de l’évaluation de l’accès DACL.
● Le serveur CIFS reçoit les informations d’identification du client CIFS, y compris l’ACL par défaut et les privilèges d’utilisateur.
○ En revanche, le serveur NFSv4 reçoit un ensemble plus limité d’informations d’identification et construit les informations d’identification à l’exécution à l’aide de son
mappeur d’ID. Pour cette raison, le système de fichiers peut voir des informations d’identification différentes.

Intégration Active Directory CIFS/SMB

The protection system NFSv4 server can be configured to use the Windows Active Directory configuration that is set with the
protection system CIFS server.
The system is mapped to use Active Directory if possible. This functionality is disabled by default, but you can enable it using the
following command:
nfs option set nfs4-idmap-active-directory enabled

DACL par défaut pour NFSv4
NFSv4 définit une DACL (liste de contrôle d’accès discrétionnaire) par défaut différente de la DACL par défaut fournie par CIFS.
Seuls OWNER@, GROUP@ et EVERYONE@ sont définis dans la DACL NFSv4 par défaut. Vous pouvez utiliser l’héritage ACL pour
:ajouter automatiquement des ACE significatives CIFS par défaut, le cas échéant.
SID par défaut du
systèmeLes fichiers et répertoires créés par NFSv3 et NFSv4 sans ACL utilisent le domaine système par défaut, parfois appelé
domaineDomaine UNIX par défaut :
● Les SID utilisateur du domaine système sont au format S-1-22-1-N, où N est l’UID.
● Les SID de groupe du domaine système sont au format S-1-22-2-N, où N est le GID.
Par exemple, un utilisateur portant l’UID 1234 aurait un SID propriétaire S-1-22-1-1234.
ID communs dans les ACL et SID de
NFSv4L’ID EVERYONE@ et d’autres identifiants spéciaux (tels que BATCH@, par exemple) dans les ACL NFSv4 utilisent l’équivalent
CIFS SID et sont compatibles.
Les identificateurs OWNER@ et GROUP@ n’ont pas de correspondance directe dans CIFS ; ils apparaissent en tant que propriétaire actuel et
groupe propriétaire du fichier ou du répertoire.
 

Renvois
NFSLa fonctionnalité de parrainage permet à un client NFSv4 d’accéder à une exportation (ou à un système de fichiers) dans un ou plusieurs emplacements. Les emplacements peuvent être sur
sur le même serveur NFS ou sur différents serveurs NFS, et utilisez le même chemin ou un autre chemin pour accéder à l’exportation.
Étant donné que les références sont une fonctionnalité NFSv4, elles s’appliquent uniquement aux montages NFSv4.
Les références peuvent être effectuées vers n’importe quel serveur qui utilise NFSv4 ou une version ultérieure, y compris les suivants :
● Un système de protection exécutant NFS avec NFSv4 activé
● Autres serveurs prenant en charge NFSv4, notamment les serveurs Linux, les appliances NAS et les systèmes VNX.
Une référence peut utiliser un point d’exportation NFS avec ou sans chemin sous-jacent actuel dans le système de fichiers DD.
Les exportations NFS avec les références peuvent être montées via NFSv3, mais les clients NFSv3 ne seront pas redirigés, car les références sont NFSv4
Fonction. Cette caractéristique est utile dans les systèmes scale-out pour permettre la redirection des exportations au niveau de la gestion des fichiers.

Emplacements
de référenceLes renvois NFSv4 ont toujours un ou plusieurs emplacements.
Ces emplacements sont les suivants :
● Un chemin d’accès sur un serveur NFS distant vers le système de fichiers référencé.
● Une ou plusieurs adresses réseau de serveur qui permettent au client d’accéder au serveur NFS distant.
En général, lorsque plusieurs adresses de serveur sont associées au même emplacement, ces adresses se trouvent sur le même NFS
Serveur.
Noms des
emplacements de référenceVous pouvez nommer chaque emplacement de référence dans une exportation NFS. Vous pouvez utiliser le nom pour accéder à la référence ainsi que pour modifier ou
Supprimez-le.
Un nom de parrainage peut contenir un maximum de 80 caractères des jeux de caractères suivants :
● a-z
● A-Z
● 0-9
● « . »
● « ,"
● « _"
● « -« 
REMARQUE : Vous pouvez inclure des espaces tant que ces espaces sont incorporés dans le nom. Si vous utilisez des espaces incorporés, vous
doit placer le nom entier entre guillemets doubles.
Les noms qui commencent par « . » sont réservés à la création automatique par le système de protection. Vous pouvez supprimer ces noms, mais vous ne pouvez pas
impossible de les créer ou de les modifier à l’aide de l’interface de ligne de commande (CLI) ou des services de gestion des systèmes (SMS).
 

Références et systèmes
scale-outLes références et les emplacements NFSv4 peuvent améliorer l’accès si vous faites évoluer vos systèmes de protection.
Étant donné que votre système peut déjà contenir un espace de nommage global, les deux scénarios suivants décrivent la façon dont vous
Peut utiliser des références NFSv4 :
● Votre système ne contient pas d’espace de nommage global.
○ Vous pouvez utiliser les références NFSv4 pour créer cet espace de noms global. Les administrateurs système peuvent créer ces espaces de nommage globaux, ou
vous pouvez utiliser des références de création d’éléments Smart System Manager (SM) si nécessaire.
● Votre système dispose déjà d’un espace de nommage global.
○ Si votre système dispose d’un espace de nommage global avec des structures MTree placées dans des nœuds spécifiques, des références NFS peuvent être créées pour rediriger
l’accès à ces structures MTree vers les nœuds ajoutés au système scale-out. Vous pouvez créer ces parrainages ou les
avoirexécutée automatiquement dans NFS si les informations SM ou de gestionnaire de fichiers (FM) nécessaires sont disponibles.

NFSv4 et haute disponibilité
Avec NFSv4, les exportations de protocole (par exemple, /data/col1/<mtree>) sont mises en miroir dans une configuration haute disponibilité (HA). Cependant
Les exportations de configuration telles que /ddvar ne sont pas mises en miroir.
Le système de fichiers /ddvar est unique à chaque nœud d’une paire HA. Par conséquent, les exportations /ddvar et leur accès
client associéLes listes ne sont pas mises en miroir sur le nœud en veille dans un environnement HA.
Les informations contenues dans /ddvar deviennent obsolètes lorsque le nœud actif bascule sur le nœud en veille. Toutes les autorisations client accordées
vers /ddvar sur le nœud actif d’origine doit être recréé sur le nœud nouvellement actif après un basculement.
Vous devez également ajouter toutes les exportations /ddvar supplémentaires et leurs clients (par exemple, /ddvar/core) qui ont été créés sur le
Nœud actif d’origine au nœud nouvellement actif après un basculement.
Enfin, toutes les exportations /ddvar souhaitées doivent être démontées du client, puis remontées après un basculement.

Espaces
de noms globaux NFSv4Le serveur NFSv4 fournit une arborescence de répertoires virtuelle appelée pseudo-FS pour connecter les exportations NFS à un ensemble de chemins pouvant faire l’objet d’une recherche.
L’utilisation d’un pseudo-système de fichiers distingue NFSv4 de NFSv3, qui utilise le protocole auxiliaire MOUNTD.
Dans la plupart des configurations, le passage de NFSv3 MOUNTD à l’espace de nommage global NFSv4 est transparent et géré automatiquement
par le client et le serveur NFSv4.
 

Espaces de noms globaux NFSv4 et sous-montages
NFSv3Si vous utilisez des sous-montages d’exportation NFSv3, les espaces de nommage globaux caractéristiques de NFSv4 peuvent empêcher les sous-montages d’être visibles
sur le montage NFSv4.
Exportations principales NFSv3 et exportations
de sous-montagesSi NFSv3 dispose d’une exportation principale et d’une exportation de sous-montage, ces exportations peuvent utiliser les mêmes clients NFSv3, mais ont des niveaux différents de
Accès:

Tableau : exportations principales NFSv3 et exportations de sous-montage 

Dans le tableau précédent, les éléments suivants s’appliquent à NFSv3 :
● Si client1.example.com monte /data/col1/mt1, le client obtient un accès en lecture seule.
● Si client1.example.com monte /data/col1/mt1/subdir, le client obtient un accès en lecture-écriture.
NFSv4 fonctionne de la même manière en ce qui concerne les chemins d’exportation de niveau supérieur. Pour NFSv4, client1.example.com navigue dans le
NFSv4 PseudoFS jusqu’à ce qu’il atteigne le chemin d’exportation de niveau le plus élevé, /data/col1/mt1, où il obtient un accès en lecture seule.
Toutefois, étant donné que l’exportation a été sélectionnée, l’exportation de sous-montage (Mt1-sub) ne fait pas partie du PseudoFS pour le client et
L’accès en lecture-écriture n’est pas accordé.

Bonnes pratiques
Si votre système utilise des sous-montages d’exportation NFSv3 pour accorder au client un accès en lecture-écriture basé sur le chemin de montage, vous devez en tenir compte
avant d’utiliser NFSv4 avec ces exportations de sous-montage.
Avec NFSv4, chaque client dispose d’un PseudoFS individuel.

Exportation de sous-montage NFSv3 dans le tableau 
 

NFSv4 Configuration

The default protection system configuration only enables NFSv3. To use NFSv4, you must first enable the NFSv4 server.
Enabling the NFSv4 Server
Steps
1. Enter nfs enable version 4 to enable NFSv4:
# nfs enable version 4
NFS server version(s) 3:4 enabled.
2. (Optional) If you want to disable NFSv3, enter nfs disable version 3.
NOTE: Do not disable NFSv3 on systems integrated with Avamar.
# nfs disable version 3
NFS server version(s) 3 disabled.
NFS server version(s) 4 enabled.
Next steps
After the NFSv4 server is enabled, you might need to perform additional NFS configuration tasks specifically for your site. These
tasks can include:
● Setting the NFSv4 domain
● Configuring NFSv4 ID mapping
● Configuring ACL (Access Control Lists)
Setting the default server to include NFSv4
About this task
The NFS command option default-server-version controls which NFS version is enabled when you enter the nfs
enable command without specifying a version.
Steps
Enter the nfs option set default-server-version 3:4 command:
# nfs option set default-server-version 3:4
NFS option 'default-server-version' set to '3:4'.

Mise à jour des exportations existantes

You can update existing exports to change the NFS version used by your protection system.
Steps
Enter the nfs export modify all command:
# nfs export modify all clients all options version=version number
To ensure all existing clients have either version 3, 4, or both, you can modify the NFS version to the appropriate string. The
following example shows NFS modified to include versions 3 and 4:
#nfs export modify all clients all options version=3:4
For more information about the nfs export command, see the DDOS Command Reference Guide for more information.

Kerberos et NFSv4
NFSv4 et NFSv3 utilisent le mécanisme d’authentification Kerberos pour sécuriser les informations d’identification de l’utilisateur.
Kerberos empêche l’usurpation des informations d’identification de l’utilisateur dans les paquets NFS et les protège contre la falsification en route vers le
système de protection.
Il existe différents types de Kerberos sur NFS :
● Kerberos 5 (sec=krb5)
Utilisez Kerberos pour les informations d’identification.
● Kerberos 5 avec intégrité (sec=krb5i)
Utilisez Kerberos et vérifiez l’intégrité de la charge utile NFS à l’aide d’une somme de contrôle chiffrée.
● Kerberos 5 avec sécurité (sec=krb5p)
Utilisez Kerberos 5 avec intégrité et chiffrez l’intégralité de la charge utile NFS.
REMARQUE : krb5i et krb5p peuvent tous deux entraîner une dégradation des performances en raison d’une surcharge de calcul supplémentaire sur les
deuxNFS et le système de protection.
 

Configuration de Kerberos avec un KDC basé sur Linux
 

Prerequisites
You should ensure that all your systems can access the Key Distribution Center (KDC).
If the systems cannot reach the KDC, check the domain name system (DNS) settings.
About this task
The following steps allow you to create keytab files for the client and the protection system:
● In Steps 1-3, you create the keytab file for the protection system.
● In Steps 4-5, you create the keytab file for the client.
Steps
1. Create the nfs/<ddr_dns_name>@<realm> service principal.
kadmin.local: addprinc -randkey nfs/ddr12345.<domain-name>@<domain-name>
2. Export nfs/<ddr_dns_name>@<realm> to a keytab file.
kadmin.local: ktadd –k /tmp/ddr.keytab nfs/ddr12345.corp.com@CORP.COM
3. Copy the keytab file to the protection system at the following location:
/ddr/var/krb5.keytab
4. Create one of the following principals for the client and export that principal to the keytab file:
nfs/<client_dns_name>@<REALM>
root/<client_dns_name>@<REALM>
5. Copy the keytab file to the client at the following location:
/etc/krb5.keytab
NOTE: It is recommended that you use an NTP server to keep the time synchronized on all entities.

Configuration de Kerberos avec un KDC basé sur Linux
 

Configuring the protection System to Use Kerberos Authentication
Steps
1. Configure the KDC and Kerberos realm on the protection system by using the authentication command:
# authentication kerberos set realm <realm> kdc-type unix kdcs <kdc-server>
2. Import the keytab file:
# authentication kerberos keytab import
3. (Optional) Configure the NIS server by entering the following commands:
# authentication nis servers add <server>
# authentication nis domain set <domain-name>
# authentication nis enable
# filesys restart
4. (Optional) Make the nfs4-domain the same as the Kerberos realm using the nfs option command:
nfs option set nfs4-domain <kerberos-realm>
5. Add a client to an existing export by adding sec=krb5 to the nfs export add command:
nfs export add <export-name> clients * options version=4,sec=krb5

Configuration de Kerberos avec un KDC basé sur Linux
 

Configuring Clients
Steps
1. Configure the DNS server and verify that forward and reverse lookups are working.
2. Configure the KDC and Kerberos realm by editing the /etc/krb5.conf configuration file.
You might need to perform this step based on the client operating system you are using.
3. Configure NIS or another external name mapping service.
4. (Optional) Edit the /etc/idmapd.conf file to ensure it is the same as the Kerberos realm.
You might need to perform this step based on the client operating system you are using.
5. Verify the keytab file /etc/krb5.keytab contains an entry for the nfs/ service principal or the root/ principal.
[root@fc22 ~]# klist -k
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
3 nfs/fc22.domain-name@domain-name
6. Mount the export using the sec=krb5 option.
[root@fc22 ~]# mount ddr12345.<domain-name>:/data/col1/mtree1 /mnt/nfs4 –o
sec=krb5,vers=4

Activation d’Active Directory
 

About this task
Configuring Active Directory authentication makes the protection system part of a Windows Active Directory realm. CIFS clients
and NFS clients use Kerberos authentication.
Steps
1. Join an active directory realm using the cifs set command:
# cifs set authentication active-directory <realm>
Kerberos is automatically set up on the system, and the required NFS/ service principal is automatically created on the KDC.
2. Configure NIS using the authentication nis command:
# authentication nis servers add <windows-ad-server>
# authentication nis domain set <ad-realm>
# authentication nis enable
3. Configure CIFS to use NSS for ID mapping by using cifs commands:
# cifs disable
# cifs option set idmap-type nss
# cifs enable
# filesys restart
4. Set the nfs4-domain to be the same as the Active Directory realm:
# nfs option set nfs4-domain 5. Enable Active Directory for NFSv4 id mapping by using the nfs command: # nfs option set nfs4-idmap-active-directory enabled

Configuration d’Active Directory
 

Steps
1. Install the Active Directory Domain Services (AD DS) role on the Windows server.
2. Install the Identity Management for UNIX components.
C:\Windows\system32>Dism.exe /online /enable-feature /featurename:adminui /all
C:\Windows\system32>Dism.exe /online /enable-feature /featurename:nis /all
3. Verify the NIS domain is configured on the server.
C:\Windows\system32>nisadmin
The following are the settings on localhost
Push Interval : 1 days
Logging Mode : Normal
NIS Domains
NIS Domain in AD Master server NIS Domain in UNIX
---------------- ------------- ----------------
corp win-ad-server corp
4. Assign AD users and groups UNIX UID/GIDs for the NFSv4 server.
a. Go to Server Manager > Tools > Active Directory.
b. Open the Properties for an AD user or group.
c. Under the UNIX Attributes tab, fill in the NIS domain, UID, and Primary GID fields.