Data Domain – Introduksjon til NFSv4

Flere faktorer kan påvirke om du velger NFSv4 eller NFSv3:
● NFS-klientstøtte
Noen NFS-klienter støtter kanskje bare NFSv3 eller NFSv4, eller kan fungere bedre med én versjon.
● Operasjonelle krav
En bedrift kan være strengt standardisert for å bruke enten NFSv4 eller NFSv3.
● Sikkerhet
Hvis du trenger større sikkerhet, gir NFSv4 et større sikkerhetsnivå enn NFSv3, inkludert ACL og utvidet eier- og
gruppekonfigurasjon.
● Funksjonskrav
Hvis du trenger byte-range låsing eller UTF-8-filer, bør du velge NFSv4.
● NFSv3-undermonteringer
Hvis den eksisterende konfigurasjonen bruker NFSv3-undermonteringer, kan NFSv3 være det riktige valget.

NFSv4 sammenlignet med NFSv3
NFSv4 gir forbedret funksjonalitet og funksjoner sammenlignet med NFSv3.
Følgende tabell sammenligner NFSv3-funksjoner med funksjonene for NFSv4.

Tabellen NFSv4 sammenlignet med NFSv3

NFSv4-porter
Du kan aktivere eller deaktivere NFSv4 og NFSv3 uavhengig av hverandre. I tillegg kan du flytte NFS-versjoner til forskjellige porter; begge
delerVersjoner trenger ikke å oppta samme port.
Med NFSv4 trenger du ikke å starte filsystemet på nytt hvis du bytter port. Bare en NFS-omstart er nødvendig i slike tilfeller.
I likhet med NFSv3 kjører NFSv4 på port 2049 som standard hvis den er aktivert.
NFSv4 bruker ikke portmapper (port 111) eller montert (port 2052).

Oversikt
over ID-tilordningNFSv4 identifiserer eiere og grupper etter et felles eksternt format, for eksempel joe@example.com. Disse vanlige formatene er:
kjent som identifikatorer, eller ID-er.
Identifikatorer lagres på en NFS-server og bruker interne representasjoner som ID 12345 eller ID S-123-33-667-2. Den
Konvertering mellom interne og eksterne identifikatorer kalles ID-tilordning.
Identifikatorer er knyttet til følgende:
● Eiere av filer og kataloger
● Eiergrupper av filer og kataloger
● Oppføringer i tilgangskontrollister (ACL-er)
Beskyttelsessystemer bruker et felles internt format for NFS- og CIFS-/SMB-protokoller, som gjør det mulig å
dele filer og katalogermellom NFS og CIFS/SMB. Hver protokoll konverterer det interne formatet til sitt eget eksterne format med sin egen ID
Kartlegging.
 

Eksterne formater
Det eksterne formatet for NFSv4-identifikatorer følger NFSv4-standarder (for eksempel RFC-7530 for NFSv4.0). I tillegg
støttes tilleggsformater for interoperabilitet.

Standard identifikatorformater

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@.

Alternative formater
For å muliggjøre interoperabilitet støtter NFSv4-servere på beskyttelsessystemer noen alternative identifikatorformater for inndata og utdata.
● Numeriske identifikatorer, for eksempel "12345".
● Windows-kompatible sikkerhetsidentifikatorer (SIDer) uttrykt som "S-NNN-NNN-..."
Se delene om inndatatilordning og utdatatilordning hvis du vil ha mer informasjon om begrensninger for disse formatene.

Interne identifikatorformater
DD-filsystemet lagrer identifikatorer med hvert objekt (fil eller katalog) i filsystemet. Alle objekter har en numerisk bruker
ID (UID) og gruppe-ID (GID). Disse, sammen med et sett med modusbiter, tillater tradisjonell UNIX / Linux-identifikasjon og tilgang
Kontroller.
Objekter som er opprettet av CIFS/SMB-protokollen, eller av NFSv4-protokollen når NFSv4 ACL-er er aktivert, har også en utvidet
sikkerhetsbeskrivelse (SD). Hvert SD-kort inneholder følgende:
● En sikkerhetsidentifikator for eier (SID)
● En eiergruppe SID
● En skjønnsmessig ACL (DACL)
● (valgfritt) En system-ACL (SACL)
Hver SID inneholder en relativ ID (RID) og et distinkt domene på samme måte som Windows-SIDer. Se avsnittet om NFSv4 og
CIFS-interoperabilitet for mer informasjon om SID og kartlegging av SID.
Når ID-kartlegging skjer
Beskyttelsessystemet NFSv4-serveren utfører tilordning i følgende tilfeller:
● Tilordning
av inndataNFS-serveren mottar en identifikator fra en NFSv4-klient. 
● Utdatatilordning:
En identifikator sendes fra NFS-serveren til NFSv4-klienten. 
● Tilordning
av legitimasjonRPC-klientlegitimasjonen er tilordnet en intern identitet for tilgangskontroll og andre operasjoner.

Tilordning
av inndataInndatatilordning oppstår når en NFSv4-klient sender en identifikator til beskyttelsessystemets NFSv4-server, for eksempel ved å konfigurere eieren
eller eiergruppen av en fil. Inndatatilordning skiller seg fra legitimasjonstilordning.
Identifikatorer for standardformat, for eksempel joe@mycorp.com, konverteres til en intern UID/GID basert på den konfigurerte
konverteringsregler. Hvis NFSv4 ACL-er er aktivert, genereres det også en SID basert på de konfigurerte konverteringsreglene.
Numeriske identifikatorer (for eksempel "12345") konverteres direkte til tilsvarende UID/GIDer hvis klienten ikke bruker Kerberos
Godkjenning. Hvis Kerberos brukes, genereres en feil som anbefalt av NFSv4-standarden. Hvis NFSv4 ACL-er er
aktivert, genereres en SID basert på konverteringsreglene.
Windows-SID (for eksempel "S-NNN-NNN-...") valideres og konverteres direkte til tilsvarende SIDer. Et UID/GIF genereres
basert på konverteringsreglene.

Tilordning av utdata

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

Legitimasjonstilordning
NFSv4-serveren gir legitimasjon for NFSv4-klienten.
Denne legitimasjonen utfører følgende funksjoner:
● Bestem tilgangspolicyen for operasjonen; for eksempel muligheten til å lese en fil.
● Bestem standard eier og eiergruppe for nye filer og kataloger.
Legitimasjon som sendes fra klienten, kan være john_doe@mycorp.com eller systemlegitimasjon som UID=1000, GID=2000.
Systemlegitimasjon angir en UID/GID sammen med ekstra gruppe-IDer.
Hvis NFSv4 ACL-er er deaktivert, brukes UID/GID- og hjelpegruppe-ID-ene til legitimasjonen.

Hvis tilgangskontrollister for NFSv4 er aktivert, brukes de konfigurerte tilordningstjenestene til å bygge en utvidet sikkerhetsbeskrivelse for
Legitimasjon:
● SID for eieren, eiergruppen og hjelpegruppen tilordnet og lagt til i sikkerhetsbeskrivelsen (SD).
● Eventuelle legitimasjonsprivilegier legges til SD.
NFSv4 og CIFS/SMB-interoperabilitet
Sikkerhetsbeskrivelsene som brukes av NFSv4 og CIFS er like fra et ID-kartleggingsperspektiv, selv om det er forskjeller.
Du bør være oppmerksom på følgende for å sikre optimal interoperabilitet:
● Active Directory bør konfigureres for både CIFS og NFSv4, og NFS ID-tilordningen bør konfigureres til å bruke Active
Directory for ID-tilordning.
● Hvis du bruker CIFS ACL-er mye, kan du vanligvis forbedre kompatibiliteten ved også å aktivere NFSv4 ACL-er.
○ Hvis du aktiverer NFSv4 ACL-er, kan NFSv4-legitimasjon tilordnes riktig SID ved evaluering av DACL-tilgang.
● CIFS-serveren mottar legitimasjon fra CIFS-klienten, inkludert standard ACL og brukerrettigheter.
○ I motsetning til dette mottar NFSv4-serveren et mer begrenset sett med legitimasjon, og konstruerer legitimasjon ved kjøretid ved hjelp
avID-tilordneren. På grunn av dette kan filsystemet se annen legitimasjon.

CIFS/SMB Active Directory-integrering

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

Standard DACL-lister for NFSv4
NFSv4 angir en annen standard DACL (skjønnsmessig tilgangskontrolliste) enn standard DACL levert av CIFS.
Bare OWNER@, GROUP@ og EVERYONE@ er definert i standard NFSv4 DACL. Du kan bruke ACL-arven til å
:automatisk legge til CIFS-signifikante ACE-er som standard hvis det er aktuelt.
Standard SID-er
for systemetFiler og kataloger som er opprettet av NFSv3 og NFSv4 uten ACL-er, bruker standard systemdomene, noen ganger kalt
standard UNIX-domene:
● Bruker-SID i systemdomenet har formatet S-1-22-1-N, der N er UID.
● Gruppe-SID i systemdomenet har formatet S-1-22-2-N, når N er GID.
For eksempel vil en bruker med UID 1234 ha en eier-SID på S-1-22-1-1234.
Vanlige identifikatorer i NFSv4 ACL-er og SID-er
EVERYONE@-identifikatoren og andre spesielle identifikatorer (for eksempel BATCH@) i NFSv4 ACL-er bruker tilsvarende
CIFS krybbedød og er kompatible.
De OWNER@ og GROUP@ identifikatorene har ingen direkte korrespondanse i CIFS; de vises som nåværende eier og gjeldende
eiergruppe av filen eller katalogen.
 

NFS-henvisninger
Henvisningsfunksjonen gir en NFSv4-klient tilgang til en eksport (eller et filsystem) på ett eller flere steder. Steder kan være på
samme NFS-server eller på forskjellige NFS-servere, og bruk enten samme eller annen bane for å nå eksporten.
Siden henvisninger er en NFSv4-funksjon, gjelder de bare for NFSv4-monteringer.
Henvisninger kan sendes til alle servere som bruker NFSv4 eller nyere, inkludert følgende:
● Et beskyttelsessystem som kjører NFS med NFSv4 aktivert
● Andre servere som støtter NFSv4, inkludert Linux-servere, NAS-apparater og VNX-systemer.
En henvisning kan bruke et NFS-eksportpunkt med eller uten en gjeldende underliggende bane i DD-filsystemet.
NFS-eksporter med henvisninger kan monteres via NFSv3, men NFSv3-klienter vil ikke bli omdirigert siden henvisninger er en NFSv4
Funksjonen. Denne egenskapen er nyttig i skaleringssystemer for å tillate eksport å bli omdirigert på et filbehandlingsnivå.

Henvisningsplasseringer
NFSv4-henvisninger har alltid ett eller flere steder.
Disse plasseringene består av følgende:
● En bane på en ekstern NFS-server til det refererte filsystemet.
● En eller flere servernettverksadresser som lar klienten nå den eksterne NFS-serveren.
Når flere serveradresser er tilknyttet samme plassering, blir disse adressene vanligvis funnet på samme NFS
Server.
Henvisningsstedsnavn
Du kan navngi hvert henvisningssted i en NFS-eksport. Du kan bruke navnet for å få tilgang til henvisningen, samt å endre eller
Slett den.
Et henvisningsnavn kan inneholde maksimalt 80 tegn fra følgende tegnsett:
● a-z
● A-Z
● 0-9
● "."
● ","
● "_"
● "-"
MERK: Du kan inkludere mellomrom så lenge disse mellomrommene er innebygd i navnet. Hvis du bruker innebygde mellomrom, kan du
må sette hele navnet i doble anførselstegn.
Navn som begynner med "." er reservert for automatisk opprettelse av beskyttelsessystemet. Du kan slette disse navnene, men du
kan ikke opprette eller endre dem ved hjelp av kommandolinjegrensesnittet (CLI) eller systemadministrasjonstjenestene (SMS).
 

Henvisninger og utskaleringssystemer
NFSv4-henvisninger og -steder kan bedre aktivere tilgang hvis du skalerer ut beskyttelsessystemene dine.
Siden systemet kanskje ikke allerede inneholder et globalt navneområde, beskriver følgende to scenarier hvordan du
kan bruke NFSv4-henvisninger:
● Systemet inneholder ikke et globalt navneområde.
○ Du kan bruke NFSv4-henvisninger til å bygge det globale navneområdet. Systemadministratorer kan bygge disse globale navneområdene, eller
Du kan bruke henvisninger til Smart System Manager (SM) etter behov.
● Systemet ditt har allerede et globalt navneområde.
○ Hvis systemet ditt har et globalt navneområde med MTrees plassert i bestemte noder, kan NFS-henvisninger opprettes for å omdirigere
tilgang til disse MTrees til nodene som er lagt til det utskalerte systemet. Du kan opprette disse henvisningene eller få dem
utføres automatisk i NFS hvis nødvendig SM- eller filbehandlingsinformasjon (FM) er tilgjengelig.

NFSv4 og høy tilgjengelighet
Med NFSv4 speiles protokolleksporter (for eksempel /data/col1/<mtree> i et oppsett med høy tilgjengelighet (HA). Men
Konfigurasjonseksporter som /ddvar gjenspeiles ikke.
/ddvar-filsystemet er unikt for hver node i et HA-par. Resultatet er at /ddvar-eksporter og deres tilknyttede klienttilgang
Lister speiles ikke til ventemodusnoden i et HA-miljø.
Informasjonen i /ddvar blir foreldet når den aktive noden mislykkes over til ventemodusnoden. Alle klienttillatelser som er gitt
Til/ddvar på den opprinnelige aktive noden må opprettes på nytt på den nylig aktive noden etter at en failover oppstår.
Du må også legge til eventuelle ekstra /ddvar-eksporter og tilhørende klienter (for eksempel /ddvar/core) som ble opprettet på
Opprinnelig aktiv node til den nylig aktive noden etter at en failover oppstår.
Ønskede /ddvar-eksporter må demonteres fra klienten og deretter monteres på nytt etter at en failover oppstår.

Globale NFSv4-navneområder
NFSv4-serveren gir et virtuelt katalogtre kjent som en PseudoFS for å koble NFS-eksporter til et søkbart sett med baner.
Bruken av en PseudoFS skiller NFSv4 fra NFSv3, som bruker MOUNTD-tilleggsprotokollen.
I de fleste konfigurasjoner er endringen fra NFSv3 MOUNTD til NFSv4 globalt navneområde gjennomsiktig og håndteres automatisk
av NFSv4-klienten og -serveren.
 

Globale NFSv4-navneområder og NFSv3-underskjemaer
Hvis du bruker NFSv3-eksportundermonteringer, kan de globale navneområdene som er karakteristiske for NFSv4, forhindre at undermonteringer vises
på NFSv4-monteringen.
Hovedeksport og deleksport av
NFSv3Hvis NFSv3 har en hovedeksport og en submount-eksport, kan disse eksportene bruke de samme NFSv3-klientene, men likevel ha forskjellige nivåer av
Tilgang:

Tabell NFSv3 hovedeksport og deleksport 

I den forrige tabellen gjelder følgende for NFSv3:
● Hvis client1.example.com monterer /data/col1/mt1, får klienten skrivebeskyttet tilgang.
● Hvis client1.example.com monterer /data/col1/mt1/subdir, får klienten lese-/skrivetilgang.
NFSv4 opererer på samme måte med hensyn til eksportbaner på høyeste nivå. For NFSv4 navigerer client1.example.com i
NFSv4 PseudoFS til den når eksportbanen på høyeste nivå, /data/col1/mt1, der den får skrivebeskyttet tilgang.
Fordi eksporten er valgt, er imidlertid ikke submount-eksporten (Mt1-sub) en del av PseudoFS for klienten og
Lese-/skrivetilgang er ikke gitt.

Beste praksis
Hvis systemet bruker submounts for NFSv3-eksport for å gi klienten lese- og skrivetilgang basert på monteringsbanen, må du vurdere
dette før du bruker NFSv4 med disse submount-eksportene.
Med NFSv4 har hver klient en individuell PseudoFS.

Tabell for eksport av NFSv3-delmontering 
 

NFSv4-konfigurasjon

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'.

Oppdatere eksisterende eksporter

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 og NFSv4
Både NFSv4 og NFSv3 bruker Kerberos-godkjenningsmekanismen til å sikre brukerlegitimasjon.
Kerberos forhindrer at brukerlegitimasjon blir forfalsket i NFS-pakker, og beskytter dem mot manipulering på vei til
beskyttelsessystem.
Det finnes forskjellige typer Kerberos over NFS:
● Kerberos 5 (sec=krb5)
Bruk Kerberos som brukerlegitimasjon.
● Kerberos 5 med integritet (sec=krb5i)
Bruk Kerberos og kontroller integriteten til NFS-nyttelasten ved hjelp av en kryptert kontrollsum.
● Kerberos 5 med sikkerhet (sec=krb5p)
Bruk Kerberos 5 med integritet og krypter hele NFS-nyttelasten.
MERK: krb5i og krb5p kan begge forårsake ytelsesforringelse på grunn av ekstra beregningskostnader på begge
NFS-klient og beskyttelsessystemet.
 

Konfigurere Kerberos med en Linux-basert KDC
 

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.

Konfigurere Kerberos med en Linux-basert KDC
 

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

Konfigurere Kerberos med en Linux-basert KDC
 

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

Aktivere 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

Konfigurere 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.