Förstå användningen av LDAP med Azure NetApp Files

  • Artikel

Lightweight Directory Access Protocol (LDAP) är ett standardprotokoll för katalogåtkomst som har utvecklats av en internationell kommitté som kallas IETF (Internet Engineering Task Force). LDAP är avsett att tillhandahålla en allmän nätverksbaserad katalogtjänst som du kan använda på heterogena plattformar för att hitta nätverksobjekt.

LDAP-modeller definierar hur du kommunicerar med LDAP-katalogarkivet, hur du hittar ett objekt i katalogen, hur du beskriver objekten i arkivet och den säkerhet som används för att komma åt katalogen. LDAP tillåter anpassning och tillägg av de objekt som beskrivs i arkivet. Därför kan du använda ett LDAP-arkiv för att lagra många typer av olika typer av information. Många av de första LDAP-distributionerna fokuserade på användningen av LDAP som katalogarkiv för program som e-post och webbprogram och för att lagra information om anställda. Många företag ersätter eller har ersatt Network Information Service (NIS) med LDAP som ett nätverkskatalogarkiv.

En LDAP-server tillhandahåller UNIX-användar- och gruppidentiteter för användning med NAS-volymer. I Azure NetApp Files är Active Directory den enda LDAP-server som stöds för närvarande och som kan användas. Det här stödet omfattar både Active Directory-domän Services (AD DS) och Microsoft Entra Domain Services.

LDAP-begäranden kan delas upp i två huvudåtgärder.

  • LDAP-bindningar är inloggningar till LDAP-servern från en LDAP-klient. Bindningen används för att autentisera till LDAP-servern med skrivskyddad åtkomst för att utföra LDAP-sökningar. Azure NetApp Files fungerar som en LDAP-klient.
  • LDAP-sökningar används för att fråga katalogen efter användar- och gruppinformation, till exempel namn, numeriska ID:n, hemkatalogsökvägar, inloggningsgränssnittssökvägar, gruppmedlemskap med mera.

LDAP kan lagra följande information som används i NAS-åtkomst med dubbla protokoll:

  • Användarnamn
  • Gruppnamn
  • Numeriska användar-ID:n (UID) och grupp-ID :n (GID)
  • Hemkataloger
  • Inloggningsgränssnitt
  • Netgroups, DNS-namn och IP-adresser
  • Gruppmedlemskap

För närvarande använder Azure NetApp Files endast LDAP för användar- och gruppinformation – ingen netgroup- eller värdinformation.

LDAP erbjuder olika fördelar för dina UNIX-användare och grupper som identitetskälla.

  • LDAP är framtidssäkert.
    När fler NFS-klienter lägger till stöd för NFSv4.x behövs NFSv4.x ID-domäner som innehåller en uppdaterad lista över användare och grupper som är tillgängliga från klienter och lagring för att säkerställa optimal säkerhet och garanterad åtkomst när åtkomst definieras. Att ha en identitetshanteringsserver som tillhandahåller en-till-en-namnmappningar för både SMB- och NFS-användare förenklar avsevärt livslängden för lagringsadministratörer, inte bara i nuet utan i många år framöver.
  • LDAP är skalbar.
    LDAP-servrar erbjuder möjligheten att innehålla miljontals användar- och gruppobjekt, och med Microsoft Active Directory kan flera servrar användas för att replikera över flera platser för både prestanda- och återhämtningsskala.
  • LDAP är säkert.
    LDAP erbjuder säkerhet i form av hur ett lagringssystem kan ansluta till LDAP-servern för att göra begäranden om användarinformation. LDAP-servrar erbjuder följande bindningsnivåer:
    • Anonym (inaktiverad som standard i Microsoft Active Directory, stöds inte i Azure NetApp Files)
    • Enkelt lösenord (oformaterade lösenord, stöds inte i Azure NetApp Files)
    • SASL (Simple Authentication and Security Layer) – Krypterade bindningsmetoder som TLS, SSL, Kerberos och så vidare. Azure NetApp Files stöder LDAP över TLS, LDAP-signering (med Kerberos), LDAP över SSL.
  • LDAP är robust.
    NIS, NIS+ och lokala filer erbjuder grundläggande information som UID, GID, lösenord, hemkataloger och så vidare. LDAP erbjuder dock dessa attribut och många fler. De ytterligare attribut som LDAP använder gör hantering med dubbla protokoll mycket mer integrerad med LDAP jämfört med NIS. Endast LDAP stöds som en extern namntjänst för identitetshantering med Azure NetApp Files.
  • Microsoft Active Directory bygger på LDAP.
    Som standard använder Microsoft Active Directory en LDAP-serverdel för sina användar- och gruppposter. Den här LDAP-databasen innehåller dock inte UNIX-formatattribut. Dessa attribut läggs till när LDAP-schemat utökas via Identitetshantering för UNIX (Windows 2003R2 och senare), Service for UNIX (Windows 2003 och tidigare) eller LDAP-verktyg från tredje part, till exempel Centrify. Eftersom Microsoft använder LDAP som serverdel gör det LDAP till den perfekta lösningen för miljöer som väljer att utnyttja volymer med dubbla protokoll i Azure NetApp Files.

    Kommentar

    Azure NetApp Files stöder för närvarande endast inbyggd Microsoft Active Directory för LDAP-tjänster.

Grunderna i LDAP i Azure NetApp Files

I följande avsnitt beskrivs grunderna i LDAP när det gäller Azure NetApp Files.

  • LDAP-information lagras i flata filer på en LDAP-server och organiseras via ett LDAP-schema. Du bör konfigurera LDAP-klienter på ett sätt som samordnar deras begäranden och sökningar med schemat på LDAP-servern.

  • LDAP-klienter initierar frågor via en LDAP-bindning, vilket i huvudsak är en inloggning till LDAP-servern med ett konto som har läsbehörighet till LDAP-schemat. LDAP-bindningskonfigurationen på klienterna är konfigurerad för att använda den säkerhetsmekanism som definieras av LDAP-servern. Ibland är de användarnamn och lösenordsutbyten i oformaterad text (enkel). I andra fall skyddas bindningar via enkla autentiserings- och säkerhetslagermetoder (sasl) som Kerberos eller LDAP över TLS. Azure NetApp Files använder SMB-datorkontot för att binda med SASL-autentisering för bästa möjliga säkerhet.

  • Användar- och gruppinformation som lagras i LDAP efterfrågas av klienter med hjälp av standardbegäranden för LDAP-sökning enligt definitionen i RFC 2307. Dessutom tillåter nyare mekanismer, till exempel RFC 2307bis, mer strömlinjeformade användar- och gruppsökningar. Azure NetApp Files använder en form av RFC 2307bis för sina schemasökningar i Windows Active Directory.

  • LDAP-servrar kan lagra användar- och gruppinformation och netgroup. Azure NetApp Files kan dock för närvarande inte använda netgroup-funktioner i LDAP i Windows Active Directory.

  • LDAP i Azure NetApp Files fungerar på port 389. Den här porten kan för närvarande inte ändras för att använda en anpassad port, till exempel port 636 (LDAP över SSL) eller port 3268 (sökningar i Active Directory Global Catalog).

  • Krypterad LDAP-kommunikation kan uppnås med LDAP via TLS (som körs via port 389) eller LDAP-signering, som båda kan konfigureras på Active Directory-anslutningen.

  • Azure NetApp Files stöder LDAP-frågor som inte tar längre än 3 sekunder att slutföra. Om LDAP-servern har många objekt kan tidsgränsen överskridas och autentiseringsbegäranden kan misslyckas. I sådana fall bör du överväga att ange ett LDAP-sökomfång för att filtrera frågor för bättre prestanda.

  • Azure NetApp Files har också stöd för att ange önskade LDAP-servrar för att påskynda begäranden. Använd den här inställningen om du vill se till att den LDAP-server som är närmast din Azure NetApp Files-region används.

  • Om ingen önskad LDAP-server har angetts, efterfrågas Active Directory-domännamnet i DNS för LDAP-tjänstposter för att fylla i listan över LDAP-servrar som är tillgängliga för din region i den SRV-posten. Du kan manuellt fråga LDAP-tjänstposter i DNS från en klient med hjälp av nslookup eller dig kommandon.

    Till exempel:

    C:\>nslookup
Default Server:  localhost
Address:  ::1

> set type=SRV
> _ldap._tcp.contoso.com.

Server:  localhost
Address:  ::1

_ldap._tcp.contoso.com   SRV service location:
          priority       = 0
          weight         = 0
          port           = 389
          svr hostname   = oneway.contoso.com
_ldap._tcp.contoso.com   SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = ONEWAY.Contoso.com
_ldap._tcp.contoso.com   SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = oneway.contoso.com
_ldap._tcp.contoso.com   SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = parisi-2019dc.contoso.com
_ldap._tcp.contoso.com   SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = contoso.com
oneway.contoso.com       internet address = x.x.x.x
ONEWAY.Contoso.com       internet address = x.x.x.x
oneway.contoso.com       internet address = x.x.x.x
parisi-2019dc.contoso.com        internet address = y.y.y.y
contoso.com      internet address = x.x.x.x
contoso.com      internet address = y.y.y.y

  • LDAP-servrar kan också användas för att utföra anpassad namnmappning för användare. Mer information finns i Mappning av anpassat namn med hjälp av LDAP.

  • Tidsgränser för LDAP-frågor

    Som standard överskrider LDAP-frågor tidsgränsen om de inte kan slutföras i tid. Om en LDAP-fråga misslyckas på grund av en timeout misslyckas användaren och/eller gruppsökningen och åtkomsten till Azure NetApp Files-volymen kan nekas, beroende på volymens behörighetsinställningar. Mer information om tidsgränsinställningar för Azure NetApp Files LDAP-frågor finns i Skapa och hantera Active Directory-anslutningar.

Namnmappningstyper

Regler för namnmappning kan delas upp i två huvudtyper: symmetriska och asymmetriska.

  • Symmetrisk namnmappning är implicit namnmappning mellan UNIX- och Windows-användare som använder samma användarnamn. Till exempel mappar Windows-användare CONTOSO\user1 till UNIX-användare user1.
  • Asymmetrisk namnmappning är namnmappning mellan UNIX- och Windows-användare som använder olika användarnamn. Till exempel mappar Windows-användare CONTOSO\user1 till UNIX-användare user2.

Som standard använder Azure NetApp Files regler för symmetrisk namnmappning. Om asymmetriska namnmappningsregler krävs kan du överväga att konfigurera LDAP-användarobjekten så att de används.

Anpassad namnmappning med hjälp av LDAP

LDAP kan vara en namnmappningsresurs om LDAP-schemaattributen på LDAP-servern har fyllts i. Om du till exempel vill mappa UNIX-användare till motsvarande Windows-användarnamn som inte matchar en-till-en (dvs . asymmetrisk) kan du ange ett annat värde för uid i användarobjektet än vad som har konfigurerats för Windows-användarnamnet.

I följande exempel har en användare ett Windows-namn och asymmetric måste mappa till en UNIX-identitet för UNIXuser. Om du vill uppnå det i Azure NetApp Files öppnar du en instans av Active Directory - användare och datorer MMC. Leta sedan upp den önskade användaren och öppna egenskapsrutan. (Om du gör det måste du aktivera attributredigeraren). Gå till fliken Attributredigerare och leta reda på UID-fältet, fyll sedan i UID-fältet med önskat UNIX-användarnamn UNIXuser och klicka på Lägg till och OK för att bekräfta.

Screenshot that shows the Asymmetric Properties window and Multi-valued String Editor window.

När den här åtgärden är klar ägs filer som skrivs från Windows SMB-resurser av Windows-användaren asymmetric av UNIXuser från NFS-sidan.

I följande exempel visas Windows SMB-ägare asymmetric:

Screenshot that shows Windows SMB owner named Asymmetric.

I följande exempel visas NFS-ägare UNIXuser (mappad från Windows-användare asymmetric med LDAP):

root@ubuntu:~# su UNIXuser
UNIXuser@ubuntu:/root$ cd /mnt
UNIXuser@ubuntu:/mnt$ ls -la
total 8
drwxrwxrwx  2 root     root   4096 Jul  3 20:09 .
drwxr-xr-x 21 root     root   4096 Jul  3 20:12 ..
-rwxrwxrwx  1 UNIXuser group1   19 Jul  3 20:10 asymmetric-user-file.txt

LDAP-scheman

LDAP-scheman är hur LDAP-servrar organiserar och samlar in information. LDAP-serverscheman följer vanligtvis samma standarder, men olika LDAP-serverleverantörer kan ha variationer i hur scheman visas.

När Azure NetApp Files frågar LDAP används scheman för att påskynda namnsökningar eftersom de gör det möjligt att använda specifika attribut för att hitta information om en användare, till exempel UID. Schemaattributen måste finnas på LDAP-servern för att Azure NetApp Files ska kunna hitta posten. Annars kan LDAP-frågor returnera inga data och autentiseringsbegäranden kan misslyckas.

Om till exempel ett UID-nummer (till exempel root=0) måste frågas av Azure NetApp Files används schemaattributet RFC 2307 uidNumber Attribute . Om det inte finns något UID-nummer 0 i LDAP i fältet uidNumber misslyckas uppslagsbegäran.

Schematypen som för närvarande används av Azure NetApp Files är en form av schema baserat på RFC 2307bis och kan inte ändras.

RFC 2307bis är en förlängning av RFC 2307 och lägger till stöd för posixGroup, som möjliggör dynamiska sökningar för hjälpgrupper med hjälp uniqueMember av attributet i stället för att använda memberUid attributet i LDAP-schemat. I stället för att bara använda namnet på användaren innehåller det här attributet det fullständiga unika namnet (DN) för ett annat objekt i LDAP-databasen. Grupper kan därför ha andra grupper som medlemmar, vilket möjliggör kapsling av grupper. Stöd för RFC 2307bis lägger också till stöd för objektklassen groupOfUniqueNames.

Det här RFC-tillägget passar bra in i hur Microsoft Active Directory hanterar användare och grupper via de vanliga hanteringsverktygen. Detta beror på att när du lägger till en Windows-användare i en grupp (och om den gruppen har en giltig numerisk GID) med hjälp av standardmetoderna för Windows-hantering, hämtar LDAP-sökningar nödvändig kompletterande gruppinformation från det vanliga Windows-attributet och hittar de numeriska GID:erna automatiskt.

Nästa steg