Dela via

Förstå grunderna i LDAP (Lightweight Directory Access Protocol) i 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, inte 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 (Active Directory Global Catalog-sökningar).

  • 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 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 Förstå namnmappning 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. Om en LDAP-fråga misslyckas på grund av en tidsgräns 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.

Nästa steg