Inzicht in het gebruik van LDAP met Azure NetApp Files

Artikel
06/13/2024

Lightweight Directory Access Protocol (LDAP) is een standaard protocol voor adreslijsttoegang dat is ontwikkeld door een internationaal comité genaamd de Internet Engineering Task Force (IETF). LDAP is bedoeld om een algemene adreslijstservice voor algemeen gebruik te bieden die u op heterogene platforms kunt gebruiken om netwerkobjecten te vinden.

LDAP-modellen definiëren hoe u kunt communiceren met het LDAP-adreslijstarchief, hoe u een object in de map kunt vinden, hoe u de objecten in het archief beschrijft en de beveiliging die wordt gebruikt voor toegang tot de directory. LDAP maakt aanpassing en uitbreiding mogelijk van de objecten die in het archief worden beschreven. Daarom kunt u een LDAP-archief gebruiken om veel soorten diverse informatie op te slaan. Veel van de eerste LDAP-implementaties waren gericht op het gebruik van LDAP als adreslijstarchief voor toepassingen zoals e-mail- en webtoepassingen en voor het opslaan van werknemersgegevens. Veel bedrijven vervangen of hebben NIS (Network Information Service) vervangen door LDAP als netwerkmaparchief.

Een LDAP-server biedt UNIX-gebruikers- en groepsidentiteiten voor gebruik met NAS-volumes. Active Directory is in Azure NetApp Files de enige ondersteunde LDAP-server die kan worden gebruikt. Deze ondersteuning omvat zowel Active Directory-domein Services (AD DS) als Microsoft Entra Domain Services.

LDAP-aanvragen kunnen worden onderverdeeld in twee hoofdbewerkingen.

LDAP-bindingen zijn aanmeldingen bij de LDAP-server vanaf een LDAP-client. De binding wordt gebruikt om te verifiëren bij de LDAP-server met alleen-lezentoegang om LDAP-zoekopdrachten uit te voeren. Azure NetApp Files fungeert als een LDAP-client.
LDAP-zoekopdrachten worden gebruikt om een query uit te voeren op de directory voor gebruikers- en groepsgegevens, zoals namen, numerieke id's, basismappaden, aanmeldingsshellpaden, groepslidmaatschappen en meer.

LDAP kan de volgende informatie opslaan die wordt gebruikt in NAS-toegang met twee protocollen:

Gebruikersnamen
Groepsnamen
Numerieke gebruikers-id's (UID's) en groeps-id's (GID's)
Startmappen
Aanmeldingsshell
Netgroups, DNS-namen en IP-adressen
Groepslidmaatschap

Op dit moment gebruikt Azure NetApp Files alleen LDAP voor gebruikers- en groepsgegevens, geen netgroep- of hostgegevens.

LDAP biedt verschillende voordelen voor uw UNIX-gebruikers en -groepen als identiteitsbron.

LDAP is toekomstbestendig.
Naarmate meer NFS-clients ondersteuning toevoegen voor NFSv4.x, zijn NFSv4.x-id-domeinen met een up-to-date lijst met gebruikers en groepen die toegankelijk zijn vanaf clients en opslag nodig om optimale beveiliging en gegarandeerde toegang te garanderen wanneer toegang wordt gedefinieerd. Het gebruik van een server voor identiteitsbeheer die een-op-een-naamtoewijzingen biedt voor zowel SMB- als NFS-gebruikers vereenvoudigt het leven voor opslagbeheerders, niet alleen in de huidige versie, maar al jaren.
LDAP is schaalbaar.
LDAP-servers bieden de mogelijkheid om miljoenen gebruikers- en groepsobjecten te bevatten, en met Microsoft Active Directory kunnen meerdere servers worden gebruikt om te repliceren op meerdere sites voor zowel prestaties als tolerantieschaal.
LDAP is veilig.
LDAP biedt beveiliging in de vorm van hoe een opslagsysteem verbinding kan maken met de LDAP-server om aanvragen voor gebruikersgegevens te doen. LDAP-servers bieden de volgende bindingsniveaus:
- Anoniem (standaard uitgeschakeld in Microsoft Active Directory; niet ondersteund in Azure NetApp Files)
- Eenvoudig wachtwoord (wachtwoorden zonder opmaak; niet ondersteund in Azure NetApp Files)
- Eenvoudige verificatie en beveiligingslaag (SASL): versleutelde bindmethoden zoals TLS, SSL, Kerberos, enzovoort. Azure NetApp Files ondersteunt LDAP via TLS, LDAP-ondertekening (met behulp van Kerberos), LDAP via SSL.
LDAP is robuust.
NIS-, NIS+- en lokale bestanden bieden basisinformatie zoals UID, GID, wachtwoord, basismappen, enzovoort. LDAP biedt echter deze kenmerken en nog veel meer. De aanvullende kenmerken die LDAP gebruikt, maken beheer met twee protocollen veel beter geïntegreerd met LDAP versus NIS. Alleen LDAP wordt ondersteund als een externe naamservice voor identiteitsbeheer met Azure NetApp Files.
Microsoft Active Directory is gebouwd op LDAP.
Microsoft Active Directory maakt standaard gebruik van een LDAP-back-end voor de gebruikers- en groepsvermeldingen. Deze LDAP-database bevat echter geen UNIX-stijlkenmerken. Deze kenmerken worden toegevoegd wanneer het LDAP-schema wordt uitgebreid via Identity Management voor UNIX (Windows 2003R2 en hoger), Service voor UNIX (Windows 2003 en eerder) of LDAP-hulpprogramma's van derden, zoals Centrify. Omdat Microsoft LDAP als back-end gebruikt, is LDAP de perfecte oplossing voor omgevingen die ervoor kiezen om volumes met twee protocollen in Azure NetApp Files te gebruiken.

Notitie

Azure NetApp Files ondersteunt momenteel alleen systeemeigen Microsoft Active Directory voor LDAP-services.

Basisbeginselen van LDAP in Azure NetApp Files

In de volgende sectie worden de basisbeginselen van LDAP besproken, omdat deze betrekking heeft op Azure NetApp Files.

LDAP-gegevens worden opgeslagen in platte bestanden op een LDAP-server en worden geordend op basis van een LDAP-schema. U moet LDAP-clients zodanig configureren dat hun aanvragen en zoekopdrachten worden gecoördineerd met het schema op de LDAP-server.
LDAP-clients initiëren query's via een LDAP-binding. Dit is in feite een aanmelding bij de LDAP-server met een account dat leestoegang heeft tot het LDAP-schema. De LDAP-bindingsconfiguratie op de clients is geconfigureerd voor het gebruik van het beveiligingsmechanisme dat is gedefinieerd door de LDAP-server. Soms zijn het gebruikersnaam- en wachtwoorduitwisselingen in tekst zonder opmaak (eenvoudig). In andere gevallen worden bindingen beveiligd via eenvoudige verificatie- en beveiligingslaagmethoden (sasl) zoals Kerberos of LDAP via TLS. Azure NetApp Files maakt gebruik van het SMB-computeraccount om verbinding te maken met SASL-verificatie voor de best mogelijke beveiliging.
Gebruikers- en groepsgegevens die zijn opgeslagen in LDAP, worden door clients opgevraagd met behulp van standaard LDAP-zoekaanvragen zoals gedefinieerd in RFC 2307. Bovendien bieden nieuwere mechanismen, zoals RFC 2307bis, meer gestroomlijnde gebruikers- en groepszoekacties. Azure NetApp Files maakt gebruik van een vorm van RFC 2307bis voor de schemazoekacties in Windows Active Directory.
LDAP-servers kunnen gebruikers- en groepsgegevens en netgroup opslaan. Azure NetApp Files kan momenteel echter geen netgroup-functionaliteit gebruiken in LDAP in Windows Active Directory.
LDAP in Azure NetApp Files werkt op poort 389. Deze poort kan momenteel niet worden gewijzigd om een aangepaste poort te gebruiken, zoals poort 636 (LDAP via SSL) of poort 3268 (Zoekopdrachten in de globale catalogus van Active Directory).
Versleutelde LDAP-communicatie kan worden bereikt met LDAP via TLS (die via poort 389 werkt) of LDAP-ondertekening, die beide kunnen worden geconfigureerd op de Active Directory-verbinding.
Azure NetApp Files ondersteunt LDAP-query's die niet langer dan 3 seconden duren. Als de LDAP-server veel objecten heeft, kan deze time-out worden overschreden en kunnen verificatieaanvragen mislukken. In dergelijke gevallen kunt u een LDAP-zoekbereik opgeven om query's te filteren voor betere prestaties.
Azure NetApp Files biedt ook ondersteuning voor het opgeven van voorkeurs LDAP-servers om aanvragen sneller te maken. Gebruik deze instelling als u ervoor wilt zorgen dat de LDAP-server het dichtst bij uw Azure NetApp Files-regio wordt gebruikt.

Als er geen LDAP-voorkeursserver is ingesteld, wordt de Active Directory-domeinnaam in DNS opgevraagd voor LDAP-servicerecords om de lijst met LDAP-servers te vullen die beschikbaar zijn voor uw regio in die SRV-record. U kunt handmatig query's uitvoeren op LDAP-servicerecords in DNS vanaf een client met behulp van nslookup of dig opdrachten.

Voorbeeld:

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-servers kunnen ook worden gebruikt om aangepaste naamtoewijzingen voor gebruikers uit te voeren. Zie Aangepaste naamtoewijzing met LDAP voor meer informatie.
Time-outs voor LDAP-query's

Er treedt standaard een time-out op voor LDAP-query's als ze niet tijdig kunnen worden voltooid. Als een LDAP-query mislukt vanwege een time-out, mislukken de gebruikers- en/of groepszoekacties en kan de toegang tot het Azure NetApp Files-volume worden geweigerd, afhankelijk van de machtigingsinstellingen van het volume. Raadpleeg Active Directory-verbindingen maken en beheren om inzicht te hebben in time-outinstellingen voor Azure NetApp Files LDAP-query's.

Naamtoewijzingstypen

Naamtoewijzingsregels kunnen worden onderverdeeld in twee hoofdtypen: symmetrisch en asymmetrisch.

Symmetrische naamtoewijzing is impliciete naamtoewijzing tussen UNIX- en Windows-gebruikers die dezelfde gebruikersnaam gebruiken. Windows-gebruikers CONTOSO\user1 worden bijvoorbeeld toegewezen aan UNIX-gebruikers user1.
Asymmetrische naamtoewijzing is naamtoewijzing tussen UNIX- en Windows-gebruikers die verschillende gebruikersnamen gebruiken. Windows-gebruikers CONTOSO\user1 worden bijvoorbeeld toegewezen aan UNIX-gebruikers user2.

Azure NetApp Files maakt standaard gebruik van regels voor symmetrische naamtoewijzing. Als er asymmetrische regels voor naamtoewijzing zijn vereist, kunt u overwegen om de LDAP-gebruikersobjecten te configureren om ze te gebruiken.

Aangepaste naamtoewijzing met LDAP

LDAP kan een resource voor naamtoewijzing zijn als de LDAP-schemakenmerken op de LDAP-server zijn ingevuld. Als u bijvoorbeeld UNIX-gebruikers wilt toewijzen aan overeenkomende Windows-gebruikersnamen die niet overeenkomen met een-op-een (dat wil gezegd asymmetrisch), kunt u een andere waarde opgeven voor uid het gebruikersobject dan is geconfigureerd voor de Windows-gebruikersnaam.

In het volgende voorbeeld heeft een gebruiker een Windows-naam van asymmetric en moet deze worden toegewezen aan een UNIX-identiteit van UNIXuser. Open hiervoor in Azure NetApp Files een exemplaar van de Active Directory MMC. Zoek vervolgens de gewenste gebruiker en open het eigenschappenvak. (Hiervoor moet u de kenmerkeditor inschakelen). Ga naar het tabblad Kenmerkeditor en zoek het UID-veld, vul het UID-veld in met de gewenste UNIX-gebruikersnaam UNIXuser en klik op Toevoegen en OK om te bevestigen.

Nadat deze actie is uitgevoerd, zijn bestanden die zijn geschreven vanuit Windows SMB-shares door de Windows-gebruiker asymmetric eigendom UNIXuser van de NFS-zijde.

In het volgende voorbeeld ziet u de Eigenaar asymmetricvan Windows SMB:

In het volgende voorbeeld ziet u de NFS-eigenaar UNIXuser (toegewezen aan Windows-gebruiker asymmetric met 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

Lokale NFS-gebruikers met LDAP toestaan

Wanneer een gebruiker probeert toegang te krijgen tot een Azure NetApp Files-volume via NFS, wordt de aanvraag geleverd in een numerieke id. Standaard ondersteunt Azure NetApp Files uitgebreide groepslidmaatschappen voor NFS-gebruikers (om de standaardlimiet van 16 groepen te overschrijden). Als gevolg hiervan probeert Azure NetApp-bestanden die numerieke id te gebruiken en op te zoeken in LDAP in een poging om de groepslidmaatschappen voor de gebruiker op te lossen in plaats van de groepslidmaatschappen door te geven in een RPC-pakket. Als deze numerieke id niet kan worden omgezet naar een gebruiker in LDAP, mislukt de zoekopdracht en wordt de toegang geweigerd, zelfs als de aanvragende gebruiker gemachtigd is om toegang te krijgen tot het volume of de gegevensstructuur. De optie Lokale NFS-gebruikers met ldap toestaan in Active Directory-verbindingen is bedoeld om deze LDAP-zoekopdrachten voor NFS-aanvragen uit te schakelen door de uitgebreide groepsfunctionaliteit uit te schakelen. Het biedt geen 'lokale gebruiker maken/beheren' in Azure NetApp Files.

Wanneer de optie Lokale NFS-gebruikers met LDAP is ingeschakeld, worden numerieke id's doorgegeven aan Azure NetApp Files en wordt er geen LDAP-zoekactie uitgevoerd. Dit creëert verschillend gedrag voor verschillende scenario's, zoals hieronder wordt beschreven.

NFSv3 met UNIX-beveiligingsstijlvolumes

Numerieke id's hoeven niet te worden vertaald naar gebruikersnamen. De optie Lokale NFS-gebruikers met LDAP toestaan heeft geen invloed op de toegang tot het volume, maar kan van invloed zijn op de manier waarop het eigendom van gebruikers/groepen (naamomzetting) wordt weergegeven op de NFS-client. Als een numerieke id van 1001 bijvoorbeeld gebruiker1 is in LDAP, maar gebruiker2 is in het lokale passwd-bestand van de NFS-client, wordt 'gebruiker2' weergegeven als de eigenaar van het bestand wanneer de numerieke id 1001 is.

NFSv4.1 met UNIX-beveiligingsstijlvolumes

Numerieke id's hoeven niet te worden vertaald naar gebruikersnamen. NFSv4.1 gebruikt standaard naamtekenreeksen (user@CONTOSO.COM) voor de verificatie. Azure NetApp Files ondersteunt echter het gebruik van numerieke id's met NFSV4.1, wat betekent dat NFSv4.1-aanvragen met een numerieke id op de NFS-server binnenkomen. Als er geen numerieke id voor de vertaling van gebruikersnaam bestaat in lokale bestanden of naamservices zoals LDAP voor het Azure NetApp Files-volume, wordt de numerieke waarde aan de client gepresenteerd. Als een numerieke id wordt omgezet in een gebruikersnaam, wordt de naamtekenreeks gebruikt. Als de naamtekenreeks niet overeenkomt, verplettert de client de naam naar de anonieme gebruiker die is opgegeven in het bestand idmapd.conf van de client. Als u de optie Lokale NFS-gebruikers met LDAP toestaan inschakelt, heeft dit geen invloed op NFSv4.1-toegang, omdat deze terugvalt op het standaardgedrag van NFSv3, tenzij Azure NetApp Files een numerieke id kan oplossen naar een gebruikersnaam in de lokale NFS-gebruikersdatabase. Azure NetApp Files heeft een set standaard UNIX-gebruikers die problematisch kunnen zijn voor sommige clients en die kunnen worden verpletterd tot een 'niemand'-gebruiker als domein-id-tekenreeksen niet overeenkomen.

Lokale gebruikers zijn: root (0), pcuser (65534), niemand (65535).
Lokale groepen zijn: root (0), daemon (1), pcuser (65534), niemand (65535).

Meestal kan root onjuist worden weergegeven in NFSv4.1-clientkoppelingen wanneer de NFSv4.1-domein-id onjuist is geconfigureerd. Zie NFSv4.1 ID-domein configureren voor Azure NetApp Files voor meer informatie over het NFSv4.1-id-domein.

NFSv4.1 ACL's kunnen worden geconfigureerd met behulp van een naamtekenreeks of een numerieke id. Als numerieke id's worden gebruikt, is er geen naamomzetting vereist. Als een naamtekenreeks wordt gebruikt, is naamomzetting vereist voor de juiste ACL-omzetting. Wanneer u ACL's voor NFSv4.1 gebruikt, kan het inschakelen van lokale NFS-gebruikers met LDAP een onjuist NFSv4.1-ACL-gedrag veroorzaken, afhankelijk van de ACL-configuratie.

NFS (v3 en v4.1) met NTFS-beveiligingsstijlvolumes in configuraties met twee protocollen

UNIX-beveiligingsstijlvolumes maken gebruik van MACHTIGINGEN voor UNIX-stijlen (modus bits en NFSv4.1 ACL's). Voor deze typen volumes maakt NFS gebruik van alleen UNIX-verificatie met behulp van een numerieke id of een naamtekenreeks, afhankelijk van de bovenstaande scenario's. NTFS-beveiligingsstijlvolumes maken echter gebruik van NTFS-stijlmachtigingen. Deze machtigingen worden toegewezen met Behulp van Windows-gebruikers en -groepen. Wanneer een NFS-gebruiker probeert toegang te krijgen tot een volume met een MACHTIGING voor NTFS-stijl, moet er een UNIX-naar-Windows-naamtoewijzing plaatsvinden om de juiste toegangsbeheer te garanderen. In dit scenario wordt de numerieke NFS-id nog steeds doorgegeven aan het Azure NetApp Files NFS-volume, maar er is een vereiste dat de numerieke id moet worden omgezet in een UNIX-gebruikersnaam, zodat deze vervolgens kan worden toegewezen aan een Windows-gebruikersnaam voor initiële verificatie. Als bijvoorbeeld numerieke id 1001 probeert toegang te krijgen tot een NFS-koppeling met machtigingen voor NTFS-beveiligingsstijlen die toegang tot Windows-gebruiker 'gebruiker1' toestaan, moet 1001 in LDAP worden omgezet in de gebruikersnaam 'gebruiker1' om verwachte toegang te krijgen. Als er geen gebruiker met de numerieke id van '1001' bestaat in LDAP of als LDAP onjuist is geconfigureerd, wordt 1001@contoso.comde toewijzing van UNIX-naar-Windows-naam geprobeerd. In de meeste gevallen bestaan gebruikers met die naam niet, zodat verificatie mislukt en de toegang wordt geweigerd. Als de numerieke id 1001 op dezelfde manier wordt omgezet in de verkeerde gebruikersnaam (zoals gebruiker2), wordt de NFS-aanvraag toegewezen aan een onverwachte Windows-gebruiker en worden de machtigingen voor de gebruiker gebruikt voor de toegangsbeheer 'gebruiker2'.

Als u 'Lokale NFS-gebruikers met LDAP toestaan' inschakelt, worden alle LDAP-vertalingen van numerieke id's naar gebruikersnamen uitgeschakeld, waardoor de toegang tot NTFS-beveiligingsstijlvolumes effectief wordt verbroken. Daarom wordt het gebruik van deze optie met NTFS-beveiligingsstijlvolumes sterk afgeraden.

LDAP-schema's

LDAP-schema's zijn de wijze waarop LDAP-servers informatie organiseren en verzamelen. LDAP-serverschema's volgen over het algemeen dezelfde standaarden, maar verschillende LDAP-serverproviders kunnen variaties hebben op de manier waarop schema's worden gepresenteerd.

Wanneer Azure NetApp Files LDAP opvraagt, worden schema's gebruikt om naamzoekacties te versnellen, omdat ze het gebruik van specifieke kenmerken mogelijk maken om informatie over een gebruiker te vinden, zoals de UID. De schemakenmerken moeten aanwezig zijn op de LDAP-server voor Azure NetApp Files om de vermelding te kunnen vinden. Anders kunnen LDAP-query's geen gegevens retourneren en verificatieaanvragen mislukken.

Als bijvoorbeeld een UID-nummer (zoals root=0) moet worden opgevraagd door Azure NetApp Files, wordt het schemakenmerk RFC 2307 uidNumber Attribute gebruikt. Als er geen UID-nummer 0 bestaat in LDAP in het uidNumber veld, mislukt de opzoekaanvraag.

Het schematype dat momenteel door Azure NetApp Files wordt gebruikt, is een vorm van schema op basis van RFC 2307bis en kan niet worden gewijzigd.

RFC 2307bis is een uitbreiding van RFC 2307 en voegt ondersteuning toe voor posixGroup, waardoor dynamische zoekacties voor hulpgroepen mogelijk zijn met behulp van het uniqueMember kenmerk in plaats van het memberUid kenmerk in het LDAP-schema. In plaats van alleen de naam van de gebruiker te gebruiken, bevat dit kenmerk de volledige DN (DN) van een ander object in de LDAP-database. Daarom kunnen groepen andere groepen hebben als leden, waardoor het nesten van groepen mogelijk is. Ondersteuning voor RFC 2307bis voegt ook ondersteuning toe voor de objectklasse groupOfUniqueNames.

Deze RFC-extensie past goed in de manier waarop Microsoft Active Directory gebruikers en groepen beheert via de gebruikelijke beheerhulpprogramma's. Dit komt doordat wanneer u een Windows-gebruiker toevoegt aan een groep (en als die groep een geldige numerieke GID heeft) met behulp van de standaardbeheermethoden voor Windows, LDAP-zoekacties de benodigde aanvullende groepsinformatie ophaalt uit het gebruikelijke Windows-kenmerk en de numerieke GID's automatisch vindt.

Delen via