Anteckning
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
När en användare försöker komma åt en Azure NetApp Files-volym via NFS kommer begäran i ett numeriskt ID. Som standard stöder Azure NetApp Files utökade gruppmedlemskap för NFS-användare (för att överskrida standardgränsen på 16 grupper). Därför försöker Azure NetApp-filer ta det numeriska ID:t och leta upp det i LDAP (Lightweight Directory Access Protocol) i ett försök att lösa gruppmedlemskapen för användaren i stället för att skicka gruppmedlemskapen i ett RPC-paket. På grund av det här beteendet misslyckas sökningen och åtkomst nekas om det numeriska ID:t inte kan matchas mot en användare i LDAP. Detta nekande inträffar även om den begärande användaren har behörighet att komma åt volymen eller datastrukturen.
Alternativet Tillåt lokala NFS-användare med LDAP i Active Directory-anslutningar är avsett att inaktivera dessa LDAP-sökningar för NFS-begäranden genom att inaktivera den utökade gruppfunktionen. Den tillhandahåller inte "skapande/hantering av lokala användare" i Azure NetApp Files.
När alternativet "Tillåt lokala NFS-användare med LDAP" är aktiverat skickas numeriska ID:n till Azure NetApp Files och ingen LDAP-sökning sker. Detta skapar varierande beteende för olika scenarier, enligt beskrivningen nedan.
NFSv3 med volymer i UNIX-säkerhetsstil
Numeriska ID:n behöver inte översättas till användarnamn. Alternativet "Tillåt lokala NFS-användare med LDAP" påverkar inte åtkomsten till volymen. Det kan påverka hur användar-/gruppägarskap (namnöversättning) visas på NFS-klienten. Om ett numeriskt ID på 1001 till exempel är user1 i LDAP, men är user2 i NFS-klientens lokala passwd-fil, visar klienten "user2" som ägare till filen när det numeriska ID:t är 1001.
NFSv4.1 med UNIX-säkerhetsformatvolymer
Numeriska ID:n behöver inte översättas till användarnamn. Som standard använder NFSv4.1 namnsträngar (user@CONTOSO.COM) för sin autentisering. Azure NetApp Files stöder dock användning av numeriska ID:n med NFSV4.1, vilket innebär att NFSv4.1-begäranden kommer till NFS-servern med ett numeriskt ID. Om det inte finns något numeriskt ID för översättning av användarnamn i lokala filer eller namntjänster som LDAP för Azure NetApp Files-volymen visas det numeriska för klienten. Om ett numeriskt ID översätts till ett användarnamn används namnsträngen. Om namnsträngen inte matchar, mosar klienten namnet till den anonyma användare som anges i klientens idmapd.conf-fil. Om du aktiverar alternativet "Tillåt lokala NFS-användare med LDAP" påverkas inte NFSv4.1-åtkomsten. Åtkomsten återgår till standardbeteendet för NFSv3 om inte Azure NetApp Files kan matcha ett numeriskt ID till ett användarnamn i den lokala NFS-användardatabasen. Azure NetApp Files har en uppsättning UNIX-standardanvändare som kan vara problematiska för vissa klienter och krossa till en "ingen"-användare om domän-ID-strängarna inte matchar.
- Lokala användare inkluderar: root (0), pcuser (65534), ingen (65535).
- Lokala grupper är: rot (0), daemon (1), pcuser (65534), ingen (65535).
Vanligtvis kan roten visas felaktigt i NFSv4.1-klientmonteringar när domän-ID:t NFSv4.1 är felkonfigurerat. Mer information om NFSv4.1-ID-domänen finns i Konfigurera NFSv4.1 ID-domän för Azure NetApp Files.
ACL:er för NFSv4.1 kan konfigureras med antingen en namnsträng eller ett numeriskt ID. Om numeriska ID:n används krävs ingen namnöversättning. Om en namnsträng används krävs namnöversättning för korrekt ACL-lösning. När du använder NFSv4.1-ACL:er kan aktivering av "Tillåt lokala NFS-användare med LDAP" orsaka felaktigt ACL-beteende för NFSv4.1 beroende på ACL-konfigurationen.
NFS (NFSv3 och NFSv4.1) med NTFS-säkerhetsformatvolymer i konfigurationer med dubbla protokoll
UNIX-säkerhetsformatvolymer utnyttjar UNIX-formatbehörigheter (lägesbitar och NFSv4.1-ACL:er). För dessa typer av volymer utnyttjar NFS endast UNIX-autentisering med hjälp av ett numeriskt ID eller en namnsträng, beroende på de scenarier som anges ovan.
NTFS-säkerhetsformatvolymer använder dock NTFS-formatbehörigheter. Dessa behörigheter tilldelas med hjälp av Windows-användare och -grupper. När en NFS-användare försöker komma åt en volym med NTFS-formatbehörighet måste en UNIX-till-Windows-namnmappning utföras för att säkerställa rätt åtkomstkontroller. I det här scenariot skickas det numeriska NFS-ID:t fortfarande till Azure NetApp Files NFS-volymen, men det finns ett krav på att det numeriska ID:t ska översättas till ett UNIX-användarnamn så att det sedan kan mappas till ett Windows-användarnamn för inledande autentisering. Om till exempel det numeriska ID:t 1001 försöker komma åt en NFS-volym med NTFS-behörighetsstil som tillåter åtkomst för Windows-användaren "user1," måste 1001 lösas i LDAP till användarnamnet "user1" för att få förväntad åtkomst. Om det inte finns någon användare med det numeriska ID:t "1001" i LDAP, eller om LDAP är felkonfigurerat, slutför unix-till-Windows-namnmappningen försöket med 1001@contoso.com. I de flesta fall finns inte användare med det namnet. Därför misslyckas autentiseringen och åtkomst nekas. På samma sätt, om det numeriska ID 1001 matchar till fel användarnamn (till exempel user2) mappar NFS-begäran till den felaktiga Windows-användaren (i det här scenariot har user1 åtkomsten beviljad till användare2).
Om du aktiverar "Tillåt lokala NFS-användare med LDAP" inaktiveras alla LDAP-översättningar av numeriska ID:n till användarnamn. Den här åtgärden bryter effektivt åtkomsten till NTFS-säkerhetsformatvolymer. Därför rekommenderas inte användning av det här alternativet med NTFS-säkerhetsformatvolymer.