Data Domain – Introduktion till NFSv4

Flera faktorer kan påverka om du väljer NFSv4 eller NFSv3:
● NFS-klientsupport
Vissa NFS-klienter kanske bara stöder NFSv3 eller NFSv4, eller fungerar bättre med en version.
● Operativa krav
: Ett företag kan vara strikt standardiserat för att använda antingen NFSv4 eller NFSv3.
● Säkerhet
Om du behöver större säkerhet ger NFSv4 en högre säkerhetsnivå än NFSv3, inklusive ACL och utökad ägar- och
gruppkonfiguration.
● Funktionskrav
Om du behöver byteintervalllåsning eller UTF-8-filer bör du välja NFSv4.
● NFSv3 undermonteringar
Om din befintliga konfiguration använder NFSv3-undermonteringar kan NFSv3 vara det lämpliga valet.

NFSv4 jämfört med NFSv3
NFSv4 ger förbättrade funktioner jämfört med NFSv3.
I följande tabell jämförs NFSv3-funktioner med dem för NFSv4.

Tabell NFSv4 jämfört med NFSv3

NFSv4-portar
Du kan aktivera eller inaktivera NFSv4 och NFSv3 oberoende av varandra. Dessutom kan du flytta NFS-versioner till olika portar; båda
Versioner behöver inte uppta samma port.
Med NFSv4 behöver du inte starta om filsystemet om du byter portar. Endast en NFS-omstart krävs i sådana fall.
Precis som NFSv3 körs NFSv4 på port 2049 som standard om den är aktiverad.
NFSv4 använder inte portmapper (port 111) eller monterad (port 2052).

Översikt över
ID-mappningNFSv4 identifierar ägare och grupper med ett gemensamt externt format, till exempel joe@example.com. Dessa vanliga format är
så kallade identifierare eller ID:n.
Identifierare lagras på en NFS-server och använder interna representationer som ID 12345 eller ID S-123-33-667-2. Metoden
konvertering mellan interna och externa identifierare kallas ID-mappning.
Identifierare är associerade med följande:
● Ägare av filer och kataloger
● Ägargrupper av filer och kataloger
● Poster i åtkomstkontrollistor (ACL:er)
Skyddssystem använder ett gemensamt internt format för NFS- och CIFS/SMB-protokoll, vilket gör att filer och kataloger kan
delas mellan NFS och CIFS/SMB. Varje protokoll konverterar det interna formatet till sitt eget externa format med sitt eget ID
Mappning.
 

Externa format
Det externa formatet för NFSv4-identifierare följer NFSv4-standarder (till exempel RFC-7530 för NFSv4.0). Dessutom
stöds kompletterande format för interoperabilitet.

Standardformat för identifierare

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

Alternativa format
För att möjliggöra samverkan stöder NFSv4-servrar på skyddssystem vissa alternativa identifierarformat för indata och utdata.
● Numeriska identifierare, till exempel "12345".
● Windows-kompatibla säkerhetsidentifierare (SID) uttryckta som "S-NNN-NNN-..."
Se avsnitten om indatamappning och utdatamappning för mer information om begränsningar för dessa format.

Format för intern identifierare
DD-filsystemet lagrar identifierare med varje objekt (fil eller katalog) i filsystemet. Alla objekt har en numerisk användare
ID (UID) och grupp-ID (GID). Dessa, tillsammans med en uppsättning lägesbitar, möjliggör traditionell UNIX/Linux-identifiering och åtkomst
Kontroller.
Objekt som skapas av CIFS/SMB-protokollet, eller av NFSv4-protokollet när NFSv4-ACL:er är aktiverade, har också en utökad
säkerhetsbeskrivning (SD). Varje SD innehåller följande:
● En säkerhetsidentifierare för ägare (SID)
● Ett SID
för ägargrupp● En godtycklig ACL (DACL)
● (valfritt) En system-ACL (SACL)
Varje SID innehåller ett relativt ID (RID) och en distinkt domän på ett liknande sätt som Windows SID. Se avsnittet om NFSv4 och
CIFS-interoperabilitet för mer information om SID och mappning av SID.
När ID-mappning sker
Skyddssystemet NFSv4-servern utför mappning i följande fall:
● Mappning
av indataNFS-servern tar emot en identifierare från en NFSv4-klient. 
● Utdatamappning:
En identifierare skickas från NFS-servern till NFSv4-klienten. 
● Mappning
av autentiseringsuppgifter: RPC-klientens autentiseringsuppgifter mappas till en intern identitet för åtkomstkontroll och andra åtgärder.

Mappning av
indataIndatamappning sker när en NFSv4-klient skickar en identifierare till skyddssystemets NFSv4-server, till exempel för att konfigurera ägare
eller ägargrupp för en fil. Indatamappning skiljer sig från mappning av autentiseringsuppgifter.
Standardformatidentifierare som joe@mycorp.com konverteras till ett internt UID/GID baserat på den konfigurerade
konverteringsregler. Om NFSv4-ACL:er är aktiverade genereras även ett SID baserat på de konfigurerade konverteringsreglerna.
Numeriska identifierare (till exempel "12345") konverteras direkt till motsvarande UID/GID om klienten inte använder Kerberos
Autentisering. Om Kerberos används genereras ett fel enligt rekommendationerna i NFSv4-standarden. Om NFSv4-ACL:er är
aktiverad genereras ett SID baserat på konverteringsreglerna.
Windows-SID (till exempel "S-NNN-NNN-...") verifieras och konverteras direkt till motsvarande SID. Ett UID/GID genereras
baserat på konverteringsreglerna.

Mappning 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

Mappning av
användaruppgifterNFSv4-servern tillhandahåller autentiseringsuppgifter för NFSv4-klienten.
Dessa autentiseringsuppgifter utför följande funktioner:
● Bestäm åtkomstpolicyn för operationen, till exempel möjligheten att läsa en fil.
● Bestäm standardägare och ägargrupp för nya filer och kataloger.
Inloggningsuppgifter som skickas från klienten kan vara john_doe@mycorp.com eller systemautentiseringsuppgifter som UID=1000, GID=2000.
Autentiseringsuppgifter för systemet anger UID/GID tillsammans med extragrupps-ID.
Om NFSv4-ACL:er är inaktiverade används UID/GID och extra grupp-ID:n för autentiseringsuppgifterna.

Om NFSv4-ACL:er är aktiverade används de konfigurerade mappningstjänsterna för att skapa en utökad säkerhetsbeskrivning för
Autentiseringsuppgifter:
● SID för ägaren, ägargruppen och hjälpgruppen mappas och läggs till i säkerhetsbeskrivningen (SD).
● Behörigheter, om sådana finns, läggs till i SD.
Kompatibilitet
mellan NFSv4 och CIFS/SMBSäkerhetsbeskrivningarna som används av NFSv4 och CIFS liknar varandra ur ett ID-mappningsperspektiv, även om det finns skillnader.
Du bör vara medveten om följande för att säkerställa optimal samverkan:
● Active Directory ska konfigureras för både CIFS och NFSv4, och NFS-ID-mappningen ska konfigureras för att använda Active
Directory för ID-mappning.
● Om du använder CIFS-ACL:er i stor utsträckning kan du vanligtvis förbättra kompatibiliteten genom att även aktivera NFSv4-ACL:er.
○ Genom att aktivera NFSv4 ACL:er kan NFSv4-autentiseringsuppgifter mappas till lämpligt SID vid utvärdering av DACL-åtkomst.
● CIFS-servern tar emot autentiseringsuppgifter från CIFS-klienten, inklusive standard-ACL och användarbehörigheter.
○ NFSv4-servern tar däremot emot en mer begränsad uppsättning autentiseringsuppgifter och skapar autentiseringsuppgifter vid körning med hjälp av sin
ID-mappare. På grund av detta kan filsystemet se olika autentiseringsuppgifter.

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 för NFSv4
NFSv4 anger en annan standard-DACL (diskretionär åtkomstkontrollista) än standard-DACL som tillhandahålls av CIFS.
Endast OWNER@, GROUP@ och EVERYONE@ definieras i standard-NFSv4 DACL. Du kan använda ACL-arv för att
Lägg automatiskt till ACE:er som är signifikanta för CIFS som standard om det är lämpligt.
Systemets standard-SID
Filer och kataloger som skapas av NFSv3 och NFSv4 utan ACL:er använder standardsystemdomänen, som
ibland kallasstandard-UNIX-domän:
● Användar-SID i systemdomänen har formatet S-1-22-1-N, där N är UID.
● Grupp-SID i systemdomänen har formatet S-1-22-2-N, där N är GID.
En användare med UID 1234 skulle till exempel ha ägar-SID på S-1-22-1-1234.
Vanliga identifierare i NFSv4 ACL och SID
Den EVERYONE@ identifieraren och andra särskilda identifierare (till exempel BATCH@) i NFSv4-ACL:er använder motsvarande
CIFS SIDS och är kompatibla.
Identifierarna OWNER@ och GROUP@ har ingen direkt motsvarighet i CIFS. De visas som aktuell ägare och aktuell
ägargrupp för filen eller katalogen.
 

NFS-hänvisningar
Med hänvisningsfunktionen kan en NFSv4-klient komma åt en export (eller filsystem) på en eller flera platser. Platser kan vara på
samma NFS-server eller på olika NFS-servrar och använd antingen samma eller en annan sökväg för att nå exporten.
Eftersom referenser är en NFSv4-funktion gäller de endast för NFSv4-monteringar.
Referenser kan göras till alla servrar som använder NFSv4 eller senare, inklusive följande:
● Ett skyddssystem som kör NFS med NFSv4 aktiverat
● Andra servrar som stöder NFSv4, inklusive Linux-servrar, NAS-enheter och VNX-system.
En referens kan använda en NFS-exportplats med eller utan en aktuell underliggande sökväg i DD-filsystemet.
NFS-exporter med referenser kan monteras via NFSv3, men NFSv3-klienter omdirigeras inte eftersom referenser är en NFSv4
Funktionen. Den här egenskapen är användbar i utskalningssystem så att exporter kan omdirigeras på filhanteringsnivå.

Referensplatser
NFSv4-hänvisningar har alltid en eller flera platser.
Dessa platser består av följande:
● En sökväg på en fjärr-NFS-server till det refererade filsystemet.
● En eller flera servernätverksadresser som gör att klienten kan nå fjärr-NFS-servern.
Vanligtvis när flera serveradresser är associerade med samma plats finns dessa adresser på samma NFS
Server.
Namn
på referensplatsDu kan namnge varje referensplats i en NFS-export. Du kan använda namnet för att komma åt hänvisningen samt för att ändra eller
Ta bort den.
Ett referensnamn kan innehålla högst 80 tecken från följande teckenuppsättningar:
● a-z
● A-Z
● 0-9
● "."
● ","
● "_"
● "-"
NOTERA: Du kan inkludera blanksteg så länge de är inbäddade i namnet. Om du använder inbäddade utrymmen kan du
måste omge hela namnet med dubbla citattecken.
Namn som börjar med "." är reserverade för automatisk generering av skyddssystemet. Du kan ta bort dessa namn, men du
Det går inte att skapa eller ändra dem med hjälp av kommandoradsgränssnittet (CLI) eller systemhanteringstjänster (SMS).
 

Referenser och utskalningssystem
NFSv4-hänvisningar och platser kan bättre aktivera åtkomst om du skalar ut dina skyddssystem.
Eftersom systemet kanske inte redan innehåller ett globalt namnområde beskriver följande två scenarier hur du
kan använda NFSv4-referenser:
● Systemet innehåller ingen global namnrymd.
○ Du kan använda NFSv4-referenser för att skapa det globala namnområdet. Systemadministratörer kan skapa dessa globala namnrymder, eller
Du kan använda SM-elementbyggnadshänvisningar (Smart System Manager) efter behov.
● Systemet har redan en global namnrymd.
○ Om systemet har ett globalt namnområde med MTrees placerade i specifika noder kan NFS-referenser skapas för att omdirigera
åtkomsten till dessa MTrees till noderna som lagts till i det utskalade systemet. Du kan skapa dessa hänvisningar eller ha dem
utförs automatiskt i NFS om nödvändig SM- eller filhanterarinformation (FM) finns tillgänglig.

NFSv4 och hög tillgänglighet
Med NFSv4 speglas protokollexporter (till exempel /data/col1/<mtree> i en HA-konfiguration (High Availability). Emellertid
Konfigurationsexporter som /ddvar speglas inte.
Filsystemet /ddvar är unikt för varje nod i ett HA-par. Det innebär att /ddvar-exporter och deras associerade klientåtkomst
listor speglas inte till väntelägesnoden i en HA-miljö.
Informationen i /ddvar blir inaktuell när den aktiva noden växlar över till väntelägesnoden. Alla klientbehörigheter som beviljas
to /ddvar på den ursprungliga aktiva noden måste återskapas på den nyligen aktiva noden efter att en redundansväxling har inträffat.
Du måste också lägga till eventuella ytterligare /ddvar-exporter och deras klienter (till exempel /ddvar/core) som har skapats på
Den ursprungliga aktiva noden till den nyligen aktiva noden efter att en redundansväxling har inträffat.
Slutligen måste alla önskade /ddvar-exporter demonteras från klienten och sedan återmonteras efter att en redundansväxling har inträffat.

NFSv4 globala namnområden
NFSv4-servern tillhandahåller ett virtuellt katalogträd som kallas PseudoFS för att ansluta NFS-exporter till en sökbar uppsättning sökvägar.
Användningen av en PseudoFS skiljer NFSv4 från NFSv3, som använder MOUNTD-hjälpprotokollet.
I de flesta konfigurationer är ändringen från NFSv3 MOUNTD till NFSv4 global namnrymd transparent och hanteras automatiskt
av NFSv4-klienten och servern.
 

NFSv4 globala namnområden och NFSv3 undermonteringar
Om du använder NFSv3-exportundermonteringar kan de globala namnrymdernas egenskaper för NFSv4 förhindra att undermonteringar visas
på NFSv4-monteringen.
NFSv3 huvudexport och submount-export
Om NFSv3 har en huvudexport och en undermonteringsexport kan dessa exporter använda samma NFSv3-klienter men ändå ha olika nivåer av
Tillgång:

Tabell NFSv3 huvudexporter och undermonteringsexporter 

I föregående tabell gäller följande för NFSv3:
● Om client1.example.com monterar /data/col1/mt1 får klienten skrivskyddad åtkomst.
● Om client1.example.com monterar /data/col1/mt1/subdir får klienten läs- och skrivåtkomst.
NFSv4 fungerar på samma sätt när det gäller exportvägar på högsta nivå. För NFSv4 navigerar client1.example.com i
NFSv4 PseudoFS tills den når exportsökvägen på den högsta nivån, /data/col1/mt1, där den får skrivskyddad åtkomst.
Men eftersom exporten har valts är undermonteringsexporten (Mt1-sub) inte en del av PseudoFS för klienten och
Läs- och skrivåtkomst ges inte.

Bästa praxis
Om systemet använder NFSv3-exportundermonteringar för att ge klienten läs- och skrivåtkomst baserat på monteringssökvägen måste du tänka på
detta innan du använder NFSv4 med dessa undermonteringsexporter.
Med NFSv4 har varje klient en enskild PseudoFS.

Tabell NFSv3-exporter av undermontering 
 

NFSv4-konfiguration

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

Uppdatera befintliga exporter

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 och NFSv4
Både NFSv4 och NFSv3 använder Kerberos-autentiseringsmekanismen för att skydda användarautentiseringsuppgifter.
Kerberos förhindrar att användarautentiseringsuppgifter förfalskas i NFS-paket och skyddar dem från manipulering på väg till
skyddssystem.
Det finns olika typer av Kerberos över NFS:
● Kerberos 5 (sec=krb5)
Använd Kerberos för användaruppgifter.
● Kerberos 5 med integritet (sec=krb5i)
Använd Kerberos och kontrollera integriteten för NFS-nyttolasten med hjälp av en krypterad kontrollsumma.
● Kerberos 5 med säkerhet (sec=krb5p)
Använd Kerberos 5 med integritet och kryptera hela NFS-nyttolasten.
Obs! krb5i och krb5p kan båda orsaka prestandaförsämring på grund av ytterligare beräkningskostnader på både
NFS-klienten och skyddssystemet.
 

Konfigurera Kerberos med en Linux-baserad 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.

Konfigurera Kerberos med en Linux-baserad 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

Konfigurera Kerberos med en Linux-baserad 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

Aktivera 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

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