Förstå säkerhetsstil och behörighetsbeteenden med dubbla protokoll i Azure NetApp Files
SMB och NFS använder olika behörighetsmodeller för användar- och gruppåtkomst. Därför måste en Azure NetApp-filvolym konfigureras för att uppfylla den önskade behörighetsmodellen för protokollåtkomst. För miljöer med endast NFS är beslutet enkelt – använd UNIX-säkerhetsformat. För SMB-miljöer använder du NTFS-säkerhetsformat.
Om NFS och SMB på samma datauppsättningar (dubbla protokoll) krävs bör beslutet fattas baserat på två frågor:
- Vilket protokoll hanterar användarna behörigheter från mest?
- Vilken är den önskade slutpunkten för behörighetshantering? Behöver användarna med andra ord möjlighet att hantera behörigheter från NFS-klienter eller Windows-klienter? Eller båda?
Volymsäkerhetsformat kan verkligen betraktas som behörighetsformat, där det önskade formatet för ACL-hantering är den avgörande faktorn.
Kommentar
Säkerhetsformat väljs när volymen skapas. När säkerhetsformatet har valts kan det inte ändras.
Om volymsäkerhetsformat för Azure NetApp Files
Det finns två huvudsakliga alternativ för volymsäkerhetsformat i Azure NetApp Files:
UNIX – UNIX-säkerhetsformatet ger UNIX-behörigheter, till exempel grundläggande POSIX-lägesbitar (ägar-/grupp-/alla-åtkomst med standardbehörigheter för läsning/skrivning/körning, till exempel 0755) och NFSv4.x-ACL:er. POSIX-ACL:er stöds inte.
NTFS – NTFS-säkerhetsstilen ger identiska funktioner som windows NTFS-standardbehörigheter, med detaljerade användare och grupper i ACL:er och detaljerade säkerhets-/granskningsbehörigheter.
I en NAS-miljö med dubbla protokoll kan endast ett säkerhetsbehörighetsformat vara aktivt. Du bör utvärdera överväganden för varje säkerhetsstil innan du väljer en.
| Säkerhetsformat | Att tänka på |
|---|---|
| UNIX | – Windows-klienter kan bara ange UNIX-behörighetsattribut via SMB:er som mappar till UNIX-attribut (endast läs-/skriv-/kör- och inga särskilda behörigheter). – NFSv4.x-ACL:er har inte GUI-hantering. Hanteringen utförs endast via CLI med hjälp av kommandona nfs4_getfacl och nfs4_setfacl. – Om en fil eller mapp har NFSv4.x-ACL:er kan fliken Säkerhetsegenskaper i Windows inte visa dem. |
| NTFS | – UNIX-klienter kan inte ange attribut via NFS via kommandon som chown/chmod. – NFS-klienter visar endast ungefärliga NTFS-behörigheter när du använder ls kommandon. Om en användare till exempel har en behörighet i en Windows NTFS-ACL som inte kan översättas rent till en POSIX-lägesbit (till exempel bläddreringskatalog) översätts den till närmaste POSIX-lägesbitvärde (till exempel 1 för körning). |
Valet av volymsäkerhetsformat avgör hur namnmappningen för en användare utförs. Den här åtgärden är kärnan i hur volymer med dubbla protokoll upprätthåller förutsägbara behörigheter oavsett vilket protokoll som används.
Använd följande tabell som beslutsmatris för att välja rätt volymsäkerhetsformat.
| Säkerhetsformat | Mestadels NFS | Mestadels SMB | Behov av detaljerad säkerhet |
|---|---|---|---|
| UNIX | X | - | X (med NFSv4.x ACL:er) |
| NTFS | - | X | X |
Så här fungerar namnmappning i Azure NetApp Files
I Azure NetApp Files autentiseras och mappas endast användare. Grupper mappas inte. Gruppmedlemskap bestäms i stället med hjälp av användaridentiteten.
När en användare försöker komma åt en Azure NetApp Files-volym skickar det försöket en identitet till tjänsten. Den identiteten innehåller ett användarnamn och en unik numerisk identifierare (UID-nummer för NFSv3, namnsträng för NFSv4.1, SID för SMB). Azure NetApp Files använder den identiteten för att autentisera mot en konfigurerad namntjänst för att verifiera användarens identitet.
- LDAP-sökning efter numeriska ID:n används för att leta upp ett användarnamn i Active Directory.
- Namnsträngar använder LDAP-sökning för att söka efter ett användarnamn och klienten och servern läser den konfigurerade ID-domänen för NFSv4.1 för att säkerställa matchningen.
- Windows-användare efterfrågas med vanliga Windows RPC-anrop till Active Directory.
- Gruppmedlemskap efterfrågas också och allt läggs till i en cache för autentiseringsuppgifter för snabbare bearbetning av efterföljande begäranden till volymen.
- För närvarande stöds inte anpassade lokala användare för användning med Azure NetApp Files. Endast användare i Active Directory kan användas med dubbla protokoll.
- För närvarande är roten och
nfsnobodyanvändaren de enda lokala användare som kan användas med volymer med dubbla protokoll.
När ett användarnamn har autentiserats och verifierats av Azure NetApp Files är nästa steg för volymautentisering med dubbla protokoll mappning av användarnamn för UNIX- och Windows-samverkan.
En volyms säkerhetsstil avgör hur en namnmappning sker i Azure NetApp Files. Windows- och UNIX-behörighetssemantik skiljer sig. Om det inte går att utföra en namnmappning misslyckas autentiseringen och åtkomsten till en volym från en klient nekas. Ett vanligt scenario där den här situationen inträffar är när NFSv3-åtkomst görs till en volym med NTFS-säkerhetsformat. Den första åtkomstbegäran från NFSv3 kommer till Azure NetApp Files som ett numeriskt UID. Om en användare med namnet user1 med ett numeriskt ID 1001 försöker komma åt NFSv3-monteringen anländer autentiseringsbegäran som numeriskt ID 1001. Azure NetApp Files tar sedan numeriskt ID 1001 och försöker matcha 1001 mot ett användarnamn. Det här användarnamnet krävs för mappning till en giltig Windows-användare, eftersom NTFS-behörigheterna på volymen innehåller Windows-användarnamn i stället för ett numeriskt ID. Azure NetApp Files använder den konfigurerade namntjänstservern (LDAP) för att söka efter användarnamnet. Om användarnamnet inte kan hittas misslyckas autentiseringen och åtkomst nekas. Den här åtgärden är avsiktlig för att förhindra oönskad åtkomst till filer och mappar.
Namnmappning baserat på säkerhetsformat
I vilken riktning namnmappningen sker i Azure NetApp Files (Windows till UNIX eller UNIX till Windows) beror inte bara på vilket protokoll som används utan även på säkerhetsstilen för en volym. En Windows-klient kräver alltid en Windows-till-UNIX-namnmappning för att tillåta åtkomst, men den behöver inte alltid ett matchande UNIX-användarnamn. Om det inte finns något giltigt UNIX-användarnamn på den konfigurerade namntjänstservern tillhandahåller Azure NetApp Files en standard UNIX-standardanvändare med det numeriska UID 65534 :t för att tillåta inledande autentisering för SMB-anslutningar. Därefter styr fil- och mappbehörigheter åtkomsten. Eftersom 65534 det vanligtvis motsvarar användaren är åtkomsten nfsnobody begränsad i de flesta fall. Omvänt behöver en NFS-klient bara använda en UNIX-till-Windows-namnmappning om NTFS-säkerhetsformatet används. Det finns ingen Standard Windows-användare i Azure NetApp Files. Om en giltig Windows-användare som matchar det begärande namnet inte kan hittas nekas åtkomst.
Följande tabell delar upp de olika namnmappningspermutationerna och hur de fungerar beroende på vilket protokoll som används.
| Protokoll | Säkerhetsformat | Namnmappningsriktning | Behörigheter som tillämpas |
|---|---|---|---|
| SMB | UNIX | Windows till UNIX | UNIX (lägesbitar eller NFSv4.x-ACL:er) |
| SMB | NTFS | Windows till UNIX | ACL:er för NTFS (baserat på Windows SID-åtkomstresurs) |
| NFSv3 | UNIX | Ingen | UNIX (lägesbitar eller NFSv4.x ACL:er*) |
| NFSv4.x | UNIX | Numeriskt ID till UNIX-användarnamn | UNIX (lägesbitar eller NFSv4.x-ACL:er) |
| NFS3/4.x | NTFS | UNIX till Windows | ACL:er för NTFS (baserat på mappat Windows-användar-SID) |
Kommentar
Namnmappningsregler i Azure NetApp Files kan för närvarande endast styras med hjälp av LDAP. Det finns inget alternativ för att skapa explicita regler för namnmappning i tjänsten.
Namnge tjänster med volymer med dubbla protokoll
Oavsett vilket NAS-protokoll som används använder volymer med dubbla protokoll begrepp för namnmappning för att hantera behörigheter korrekt. Därför spelar namntjänster en viktig roll för att upprätthålla funktioner i miljöer som använder både SMB och NFS för åtkomst till volymer.
Namntjänster fungerar som identitetskällor för användare och grupper som har åtkomst till NAS-volymer. Den här åtgärden omfattar Active Directory, som kan fungera som källa för både Windows- och UNIX-användare och -grupper som använder både standarddomäntjänster och LDAP-funktioner.
Namntjänster är inte ett hårt krav men rekommenderas starkt för Volymer med dubbla protokoll i Azure NetApp Files. Det finns inget koncept för att skapa anpassade lokala användare och grupper i tjänsten. Därför är LDAP en nödvändighet för att ha korrekt autentisering och korrekt information om användar- och gruppägare mellan protokoll. Om du bara har en handfull användare och du inte behöver fylla i korrekt användar- och gruppidentitetsinformation kan du överväga att använda tillåt lokala NFS-användare med LDAP för att få åtkomst till en volymfunktion med dubbla protokoll. Tänk på att om du aktiverar den här funktionen inaktiveras de utökade gruppfunktionerna.
När klienter, namntjänster och lagring finns i olika områden
I vissa fall kan NAS-klienter finnas i ett segmenterat nätverk med flera gränssnitt som har isolerade anslutningar till lagrings- och namntjänsterna.
Ett sådant exempel är om din lagring finns i Azure NetApp Files, medan dina NAS-klienter och domäntjänster alla finns lokalt (till exempel en hub-spoke-arkitektur i Azure). I dessa scenarier skulle du behöva tillhandahålla nätverksåtkomst till både NAS-klienterna och namntjänsterna.
Följande bild visar ett exempel på den typen av konfiguration.
Nästa steg
Feedback
Kommer snart: Under hela 2024 kommer vi att fasa ut GitHub-problem som feedbackmekanism för innehåll och ersätta det med ett nytt feedbacksystem. Mer information finns i: https://aka.ms/ContentUserFeedback.
Skicka och visa feedback för