Vad är LDAP?

organisationer har använt LDAP-protokollet för användarhantering, attribut och autentisering i nästan tre decennier. Under den tiden har protokollet expanderat och utvecklats för att möta förändrade IT-miljöer och affärsbehov.

den här bloggen täcker allt du behöver veta om LDAP, från dess ursprung till sin plats i den molndrivna affärsvärlden idag, och förklarar hur det fungerar, hur det används, hur man kommer igång och vilka LDAP-serverlösningar som kan vara rätt för dina behov.

LDAP-protokollet

LDAP (Lightweight Directory Access Protocol) är ett av kärnprotokollen som utvecklades för katalogtjänster (processen att säkert hantera användare och deras åtkomsträttigheter till IT-resurser), och de flesta katalogtjänster använder fortfarande LDAP idag, även om de också kan använda ytterligare protokoll som Kerberos, SAML, RADIUS, SMB, Oauth och andra.

i ett nötskal specificerar LDAP en metod för kataloglagring och underlättar autentisering och auktorisering av användare till servrar, filer, nätverksutrustning och applikationer, bland andra IT-resurser. LDAP utvecklades 1993 av Tim Howes och hans kollegor vid University of Michigan för att vara en lätt, låg-overhead version av X. 500 katalogtjänstprotokoll som användes vid den tiden, som DAP (directory access protocol).

X. 500 var svårt på både systemen (stort fotavtryck) och nätverket (bandbreddskrävande). Faktum är att många av systemen på människors skrivbord i början av 1990-talet inte kunde ansluta till en X. 500-katalogtjänst, så det var begränsat till specifika system (tänk mer som stordatorer, minidatorer eller mikrodatorer tillbaka på dagen – i allmänhet inte datorer).

LDAP löste dessa problem genom att tillåta autentisering och auktorisering av användare till servrar, filer och applikationer samtidigt som overhead, bandbreddsanvändning och efterfrågan på slutpunkter minskas.

som ett resultat av dessa effektivitetsvinster skulle LDAP hitta stor framgång och bli de facto Internet directory services authentication protocol för ganska ett tag. Faktum är att LDAPv3 (den tredje versionen av LDAP) föreslogs och accepterades som internetstandard för katalogtjänster 1997. Detta är den senaste och vanligaste versionen av LDAP idag.

efter denna milstolpe startade Kurt Zeilenga OpenLDAP-projektet med lanseringen av OpenLDAP 1.0 1998.

OpenLDAP 1.0 var den första helt öppna källkodssviten av klient-och serverapplikationer härledda från LDAPv3.3 och inkluderade avancerade säkerhetsfunktioner, uppdaterat plattformsstöd och buggfixar. Openldaps open source-natur gjorde det möjligt för IT-administratörer att ändra det för att bättre passa organisationens behov, vilket gjorde det till ett populärt LDAP-val. OpenLDAP har sedan dess drivits av Howard Chu och Symas-teamet.

ett år senare, 1999, släppte Microsoft Active Directory, som använde LDAP och Kerberos, samtidigt som de skapade egna tillägg för att hålla organisationer låsta i Microsofts ekosystem.

hur fungerar LDAP?

kort sagt, LDAP anger en metod för kataloglagring som gör det möjligt att lägga till, ta bort och ändra poster, och det gör det möjligt att söka efter dessa poster för att underlätta både autentisering och auktorisering av användare till resurser.

LDAP: s tre huvudfunktioner är:

Uppdatering: Detta inkluderar att lägga till, ta bort eller ändra kataloginformation.

fråga: Detta inkluderar sökning och jämförelse av kataloginformation.

autentisera: de viktigaste autentiseringsfunktionerna inkluderar bindning och bindning; en tredje funktion, överge, kan användas för att stoppa en server från att slutföra en operation.

LDAP-Katalogkomponenter

följande är några av de viktigaste elementen och begreppen i LDAP-protokollet och LDAP-baserad katalog. När du arbetar med en identitetsleverantör (IdP) händer mycket av detta bakom ett GUI; det kan dock vara bra att veta, både för att runda ut din förståelse och hjälpa till med anpassning och felsökning på vägen.

vidare möjliggör OpenLDAP Flexibel anpassning, men kräver mer invecklad kunskap om protokollet och dess användningsfall. I allmänhet görs dessa ändringar med kommandoraden, konfigurationsfilerna eller ibland genom att ändra den öppna källkodsbasen. Att förstå hur LDAP fungerar är särskilt viktigt för dem som använder OpenLDAP och för dem som är intresserade av att anpassa det till deras behov.

LDAP-Kataloginformationsträd

LDAP organiserar information i en hierarkisk trädstruktur, kallad ett kataloginformationsträd (DIT). LDAP DIT kan variera beroende på vilken programvara eller katalogtjänst du använder; LDAP-kataloger följer dock i allmänhet denna trädstruktur, där poster utan underordnade (till exempel användare) är löv och roten är den övergripande enheten som omfattar all information i katalogen.

denna rot är en katalog Server agent (DSA) specifik post (DSE), kallas roten DSE, och det ger information om katalogen.

post

poster använder attribut för att beskriva de verkliga objekt som lagras i katalogen, som en användare eller en maskin. Precis som i en telefonbok — eller, mer relatably, kontaktlistan i telefonen — användare finns som poster, som lagrar ytterligare information om användaren.

i LDAP hänvisas poster ofta till med deras vanliga namn (CN) — för användare är detta vanligtvis deras användarnamn eller för-och efternamn.

attribut

attribut beskriver en användare, server eller annat objekt som lagras i LDAP-katalogen. En användares attribut, till exempel, skulle vanligtvis innehålla deras fullständiga namn, e-postadress, användarnamn och lösenord, till att börja med. Attribut består av en typ och ett värde; dvs mail(type)[email protected](value).

de attribut som är tillgängliga att inkludera är fördefinierade av ett ObjectClass-attribut; organisationer kan använda mer än ett ObjectClass-attribut och skapa anpassade ObjectClass-attribut för att omfatta den information de vill lagra i sin LDAP-katalog, men det kan bara finnas en strukturell objektklass per post. (Det kan finnas ytterligare hjälpobjektklasser, men en huvudobjektklass, kallad strukturell objektklass, definierar varje post).

Schema

scheman definierar katalogen. Specifikt definierar ett schema parametrarna för katalogen, inklusive syntax, matchningsregler (dvs. matchar inmatningslösenordet katalogdata?), attributtyper och objektklasser.

LDAPv3 (den senaste iterationen av LDAP) erbjuder ett fördefinierat schema, och andra LDAP-erbjudanden ger schemavarianter eller iterationer, så olika leverantörer kan formatera sina LDAP-kataloger lite annorlunda. Att skapa ett anpassat schema är också möjligt för mer nyanserade och nischade användningsfall.

DN: Distinguished Name

Detta är den unika identifieraren för en LDAP-post, och den anger alla attribut som tilldelats objektet. Den kan innehålla flera datapunkter och består av relative distinguished names (RDN) i en sträng separerad med kommatecken.

DN-formatet fungerar som Geografiska koordinater, endast i omvänd ordning: det anger plats i katalogen genom att lista varje underavsnitt i ökande grader.

medan Geografiska koordinater startar allmänt och blir mer specifika börjar DN med objektets namn och fungerar upp till huvudkatalogkomponenten (till exempel din LDAP-serverns domän) och bildar en fullständig adress som pekar på postens plats i LDAP-trädet.

DNs formateras enligt följande:

RDN, RDN, RDN

för Peter Gibbons, en programmerare i IT-avdelningen på Initech, kan DN se ut så här:

cn=Peter Gibbons,ou=IT,ou=People,dc=Initech,dc=com

RDN: Relative Distinguished Name

dessa är strängar som tilldelar värden till attribut, som att tilldela en e-postadress till en användare. De bildas med ett lika tecken (=) i namnvärdespar. Formatet ser ut som följer:

attribut=värde

till exempel kan RDN för användaren Peter Gibbons e-postadress vara [email protected].

Multivalue RDNs

RDNs kan kombineras till en övergripande RDN med plustecken. Multivalue RDN behandlar två attributvärden som en och kan användas för att skilja mellan två RDN med samma värde (som två användare med samma namn – katalogen kan bifoga RDN för deras e-postadress till deras användarnamn för att skapa unika RDN för varje). En multivalue RDN skulle formateras enligt följande:

RDN + RDN

LDAP-servrar

en LDAP-katalog kan innehålla en eller flera servrar, men det måste finnas en rotserver (root DSE i diagrammet ovan). De viktigaste LDAP-servrarna körs på slapd-demonen, och de skickar ändringar till serverrepliker via slurpd-demonen.

traditionellt var LDAP-servrar värd on-prem och hanterades av organisationen internt, och Microsoft AD var den mest populära kommersiella lösningen för LDAP på marknaden. OpenLDAP är den mest populära open-source och pure-play LDAP-servern som finns tillgänglig idag.

nu använder dock organisationer oftare molnhostade katalogtjänster som lindrar bördan av intern serverhosting, säkerhet och hantering. Molnbaserade LDAP-servrar gör det också möjligt för organisationer att flytta sin infrastruktur till molnet, dra nytta av fjärrarbetsmöjligheter och minska kostnaderna. Se avsnittet LDAP och Active Directory i den här artikeln om du vill veta mer.

LDAP-autentisering och auktorisering

LDAP-protokollet både autentiserar och auktoriserar användare till sina resurser. Protokollet autentiserar användare med en bindningsåtgärd som gör det möjligt för användaren att kommunicera med en LDAP-katalog och auktoriserar sedan den autentiserade användaren till de resurser de behöver om deras inmatningsinloggningsinformation matchar vad som anges för dem i databasen.

LDAP-autentisering

LDAP-autentisering bygger på en klient/serverbindningsoperation, vilket gör att den LDAP-klara klienten, kallad directory user agent (Dua), och katalogservern, kallad directory system agent (DSA), kan kommunicera inom en säker, krypterad session.

vid autentisering mot en LDAP-server i ett försök att få tillgång till databasen uppmanas användaren att ange sitt användarnamn och lösenord.

om de värden som användaren matar in i klienten matchar det som finns i LDAP-databasen får användaren åtkomst av LDAP-servern till vilken IT-resurs som helst.

LDAP-behörighet

när en användare har autentiserats måste de ha behörighet till de begärda resurserna. Medan olika LDAP-instanser kan strukturera och koda detta något annorlunda, uppnås detta i huvudsak genom att tilldela behörigheter med grupper och roller i katalogen.

med OpenLDAP tillhör användare till exempel grupper som kan tilldelas olika behörigheter. Om den autentiserande användaren tilldelas rätt behörigheter för åtkomst till en viss resurs, kommer LDAP-protokollet att auktorisera dem till det; om inte, kommer protokollet att neka åtkomst.

vad används LDAP för?

LDAP-protokollet definierar en katalog som kan:

• lagra användardata på en central och tillgänglig plats.
• associera dessa användare med resurser de får komma åt.
• autentisera och auktorisera användare till deras tilldelade resurser, som inkluderar:
  • tekniska applikationer: Jenkins, Docker, OpenVPN, Atlassian suite och många andra autentisera bäst med LDAP.
  • serverinfrastruktur: Linux-servrar både on-prem och i molnet (som AWS) utnyttjar LDAP för att autentisera användare.
  • filservrar: filservrar som QNAP, Synology och FreeNAS stöder LDAP.
  • nätverksutrustning: även om detta kan överlappa RADIUS-protokollet, använder vissa organisationer LDAP för nätverksåtkomst via VPN, WiFi-åtkomstpunkter och annan nätverksutrustning.

tillbaka när LDAP har sitt ursprung var ovanstående funktioner mycket mer sofistikerade än andra tillgängliga användarhanteringsalternativ. När protokollet blev populärt blev fler IT-resurser LDAP-kompatibla och nya erbjudanden — inklusive cloud LDAP, andra autentiseringsprotokoll och fullständiga katalogtjänster — kom in i scenen för att stödja åtkomst till dessa IT-resurser.

nu kan IT-administratörer använda LDAP för att autentisera maskiner och hantera åtkomst till äldre applikationer, nätverk, NAS och andra komponenter både on-prem och i molnet. Med vissa molnkatalogtjänster som JumpCloud kan de kombinera denna funktionalitet med andra protokoll för att ge användarna tillgång till praktiskt taget alla sina IT-resurser.

LDAP och Active Directory

när LDAP blev ett core directory services-protokoll byggde Microsoft AD många av sina underlag på LDAP; AD är dock inte ett rent LDAP-verktyg.

medan AD kan använda LDAP, är det mer beroende av Kerberos för autentisering och är mindre flexibel än en öppen källkod LDAP-katalog. AD kräver domänkontrollanter och fungerar bäst med Microsoft Windows-baserade enheter och applikationer. Utforska dessa skillnader ytterligare i vår AD vs. LDAP jämförelse.

fram till nyligen fungerade katalogverktyg främst inom och tillgodoses on-prem Windows-baserade miljöer. AD: s framgång kom till stor del från dess fokus på Windows-centrerade, on-prem-miljöer, som var affärsstandarden i årtionden.

men det senaste decenniets övergång till molnet, som accelererade med den pandemidrivna massförskjutningen till fjärrarbete 2020, förändrade världens katalogbehov.

företag väljer nu molnbaserade, Mac-och Linux-vänliga katalogtjänster i stället för AD och andra on-prem katalogmodeller. Hoppa till avsnittet om LDAP: s plats i molnet för att läsa mer om hur LDAP-lösningar har utvecklats för att tillgodose dessa förändringar.

LDAP och Azure Active Directory

Azure Active Directory, ett molnvänligt tillägg till AD (inte en ersättning för AD) för Azure user management och webbapplikation single sign-on, använder inte LDAP inbyggt. Istället använder den andra protokoll och det underlättar LDAP-funktioner med Azure AD Domain Services (DS) eller en hybridannonsmiljö där LDAP är nödvändigt.

Azure AD DS faktureras som en domänkontrollant-as-a-service för virtuella datorer och Windows äldre program som distribueras i Azure. Det debiteras för timmen, och priset är baserat på antalet katalogobjekt.

för dem som vill använda LDAP med Azure AD, särskilt autentisera on-prem-applikationer eller lagringssystem, kan det vara ganska utmanande. Många IT-organisationer väljer att distribuera en ytterligare LDAP-server. I många fall distribueras denna LDAP-server i molnet via Jumpclouds LDAP-as-a-Service-lösning.

LDAP: S plats i molnet

de senaste skiftningarna till molnet och olika arbetsplatser har skapat behovet av mer flexibla kataloglösningar som kan fungera med molnresurser och rymma olika operativsystem; 55% av företagen är nu Mac-vänliga och 90% av världens molninfrastruktur fungerar på Linux. AD: s Microsoft Windows-och Azure-centrerade tillvägagångssätt är inte längre livskraftigt för många företag med OS-olika miljöer, och många förlitar sig på flera ytterligare integrerade lösningar för att hantera sin växande, diversifierande och spridande Infrastruktur. Dessa nya utmaningar med AD-och on-prem-kataloger har drivit företag att vända sig till cloud LDAP och i slutändan Directory-as-a-Service.

Cloud LDAP befriar företag från en hel del kataloghanteringsbörda, från att installera och underhålla kärnkataloginfrastrukturen till att integrera applikationer och system i deras LDAP-baserade IdP. Med cloud LDAP är servrarna redan där och redo för företag att rikta sina LDAP-anslutna slutpunkter till dem.

Cloud directory-tjänster tenderar också att använda andra protokoll, vilket ytterligare utvidgar deras omfattning och tillmötesgår ny teknik när de dyker upp samtidigt som behovet av en on-prem Active Directory-server elimineras.

vissa cloud LDAP-tjänster inkluderar också ett GUI och teknisk support, vilket eliminerar behovet av att utföra allt med vanlig textkod (även om vissa katalogtjänster fortfarande ger möjlighet till kommandoradsexekvering, vilket kan vara fördelaktigt för att utföra operationer i bulk) och erbjuda experthjälp vid behov.

är LDAP fortfarande Relevant?

om kataloger rör sig mot molnet och LDAP byggdes för att fungera i en on-prem-miljö, är LDAP fortfarande relevant?

när molnapplikationer blir affärsstandarden blir IT-nätverk mer decentraliserade och nya protokoll utvecklas för att möta dessa utvecklande behov, har vissa systemadministratörer börjat ifrågasätta LDAP: s relevans.

kataloger har börjat anta multiprotokollmetoder för att hantera moderna, decentraliserade affärsmiljöer. Multiprotokollkatalogen utnyttjar många protokoll-var och en för ett specifikt syfte.

resultatet är att varje protokoll används mindre ofta, men är mycket lämpat för dess användningsfall och förblir en kritisk komponent i en robust multiprotokollkatalog.

LDAP är inget undantag; medan det utgör en mindre andel av katalogens funktionalitet jämfört med äldre katalogmodeller, är det fortfarande en integrerad del av den moderna katalogen.

katalogtjänster för flera protokoll fortsätter att använda LDAP tillsammans med andra protokoll på grund av dess flexibilitet, open source-arv och stabilitet genom åren.

till exempel fortsätter många äldre applikationer som OpenVPN, Jenkins, MySQL, Jira och Confluence — tillsammans med tiotusentals andra applikationer, lagringssystem, nätverksenheter, servrar och mer — att använda LDAP.

hur du ställer in LDAP

LDAP-installationsstegen varierar beroende på vilket LDAP-erbjudande du använder, och stegen beror till stor del på om du använder en cloud LDAP-server eller står upp på egen hand.

innan du börjar på någon av vägarna bör dock det första steget till någon LDAP-implementering vara planering: ditt IT-team bör tänka noga över hur det vill organisera sin katalog innan du implementerar något.

detta inkluderar vilka resurser som ska inkluderas i katalogen, hur man separerar användargrupper och fördelar behörigheter, vilka operativsystem du behöver ta emot, hur du planerar att integrera fjärrarbetare, vad dina säkerhetsparametrar kommer att vara, vad du kommer att göra för att säkerställa nära 100% tillgänglighet, hur din organisation planerar att växa och mer.

Initial planering är avgörande för att bygga en organiserad katalog som är väl lämpad för sin miljö och väl positionerad för att tillgodose tillväxt och förändringar. Om du till exempel är en organisation på 10 men vet att du planerar att expandera avsevärt kan det vara vettigt att dela upp dina anställda i avdelningsgrupper från början för att möjliggöra organiserad tillväxt, även om varje avdelning börjar med bara en eller två användare.

planeringssteget är särskilt viktigt för organisationer som bygger sina egna kataloger; men det hjälper också organisationer att förstå vilka LDAP-lösningar som bäst uppfyller deras behov.

när du har planerat din kataloglayout och valt en LDAP-leverantör (eller väljer öppen källkod ldap) måste du konfigurera dina LDAP-servrar.

On-Prem LDAP Setup:

om du är värd för din egen LDAP-instans måste du stå upp för din LDAP-server(er). Stegen för att installera och konfigurera din LDAP-katalog varierar beroende på vilken LDAP-instans du använder. OpenLDAP är kanske den mest populära LDAP-instansen på marknaden, men det finns flera LDAP-servrar att välja mellan. Här är MIT: s steg för att skapa en OpenLDAP-katalog.

Cloud LDAP Setup: som vi nämnde är cloud LDAP-installation och underhåll minimal, vilket är en av anledningarna till att många företag väljer det framför traditionella on-prem-alternativ. Serversteget för cloud LDAP innebär att du prenumererar på en cloud LDAP-server istället för att stå upp den själv. Du vill fortfarande noggrant planera innan du väljer en LDAP-lösning, men de flesta leverantörer erbjuder katalogkonfiguration och hantering via ett användarvänligt GUI som gör ändringar enklare på vägen.

även om det inte finns många gratis LDAP-servrar (inklusive hårdvaran) att välja mellan, finns det flera gratis LDAP-programalternativ tillgängliga. Vi kommer att utforska dem nästa.

LDAP-leverantörer

utan LDAP saknar det vanligtvis synlighet i användarkonton och aktivitet och hanterar resursåtkomst manuellt, vilket skapar en decentraliserad och oorganiserad identitets-och åtkomsthanteringsmodell (IAM) som kan leda till uppsägningar, friktion och säkerhetsrisk. När organisationer inser att kostnaden för att implementera en lösning är mindre än kostnaden för tidskrävande manuell hantering och riskerna med den, börjar de ofta titta på LDAP. Det finns några huvudsakliga LDAP-lösningar som de flesta företag anser:

Active Directory (AD)

AD använder LDAP och Kerberos för att autentisera användare till IT-resurser. Som en Microsoft-produkt passar den bäst för Windows-baserade miljöer. För att kunna använda AD måste IT-administratörer betala för att licensiera Windows Server, vilket inkluderar AD. Detta representerar den traditionella licensmodellen som IT-organisationer känner väl till med Microsoft-produkter. Slutligen kräver AD någon form av fjärråtkomst, som en VPN eller SD-WAN, för att autentisera fjärranvändare till on-prem-resurser. Azure Active Directory har nyligen dykt upp som ett tillägg till AD, men saknar sanna, inbyggda LDAP-funktioner.

OpenLDAP

som tidigare nämnts kostar OpenLDAP ingenting att ladda ner. Betydande kostnader omger dock installationen och den pågående hanteringen av infrastrukturen. På grund av sina rötter med öppen källkod fungerar OpenLDAP bra med Linux-och Unix – baserade operativsystem, så du hittar det i många DevOps-miljöer. Precis som AD behöver du en VPN för att autentisera till on-prem-resurser.

Cloud LDAP

Cloud-based LDAP är leverantörsneutral och arbetar med en mängd olika IT-resurser. Med en molnkatalogplattform finns det inget behov av en VPN (även om de fortfarande stöds); istället etablerar en lätt agent på användarens enhet en säker TLS-anslutning i början av varje session, så att användare säkert kan ansluta till sina LDAP-resurser utan VPN. Cloud LDAP-tjänster innehåller ofta ytterligare protokoll i sitt erbjudande så att ett verktyg kan ge användarna tillgång till praktiskt taget alla sina resurser.

fördelar och nackdelar med LDAP

vilka är fördelarna med LDAP?

• Öppen Källkod: Det kostar inte ofta något att ladda ner och snabbt prova OpenLDAP.
• standardiserad: LDAP ratificerades som en Internet Engineering Task Force (IETF) standard tillbaka 1997 med RFC 2251. Som sådan stöder industrin i stort LDAP och kommer att fortsätta att göra det.
• Flexibel: utvecklare och IT-administratörer använder LDAP-autentisering för många olika användningsfall, inklusive applikations-och fjärrserverautentisering. Och eftersom det har använts på så många olika sätt finns det ett samhälle som omger protokollet som hjälper människor att få ut det mesta av det.
• Device-Agnostic: av naturen är LDAP kompatibel med olika operativsystem och enheter. Olika LDAP-erbjudanden kan dock begränsa denna flexibilitet; AD är till exempel Windows-centrerad och kräver ofta tillägg för att fungera sömlöst med ytterligare operativsystem.
• säker: i sin ursprungliga instans överfördes LDAP över klartext; det finns dock alternativ för att kryptera LDAP-kommunikation, antingen över SSL (LDAPS) eller över TLS (STARTTLS). STARTTLS är det perfekta alternativet och är mycket säkert, med LDAPS som kommer på andra plats — Använd alltid en av de två där det är möjligt (nu, nästan överallt) snarare än att använda klartext. Läs mer om LDAP och LDAPS i vår blogg.

vilka är nackdelarna med LDAP?

• ålder: LDAP är ett äldre protokoll. Nyare autentiseringsprotokoll som SAML är byggda för moderna, moln-framåt IT-miljöer som använder webbapplikationer.
• On-Prem: LDAP är traditionellt inställd på prem med en OpenLDAP-server, och det är inte ett enkelt företag. För organisationer som flyttar till molnet är det mindre än idealiskt att behöva skapa en on-prem-autentiseringsmekanism som överbryggar till moln IT-resurser.
• expertis: LDAP-installation och underhåll kräver i allmänhet en expert. Människor med denna nivå av teknisk kunskap kan vara svåra att hitta och dyra. Detta gäller särskilt för OpenLDAP.
• betydande Ramp-Up: ju större din organisation, desto svårare är det att starta en ny katalog. Eftersom kataloger i huvudsak är en sammanslagning av alla komponenter i din organisation kan det vara utmanande att bygga en ny katalog från grunden eller svänga från en katalog till en annan. Lyckligtvis har vissa molnkatalogplattformar som JumpCloud Installationsvägledning och kan integreras med befintliga kataloger som AD, så stora företag som vill dra nytta av cloud LDAP kan göra det utan att göra ett fullständigt ansikte.

utöka LDAP till en fullständig Molnkatalog

Cloud LDAP använder en molnbaserad server för att ge användarna tillgång till alla sina on-prem-resurser. Cloud directory-plattformar kombinerar nu LDAP med andra protokoll, som SAML, OAuth, RADIUS, SCIM och WebAuthn, som underlättar säker autentisering och auktorisering till webb-och molnbaserade resurser.

vissa LDAP-instanser integreras också med andra protokoll, som RADIUS för att underlätta säker WiFi-och VPN-åtkomst, Samba för säker filbehörighet, SAML, JIT och SCIM för automatiserad webbaserad identitetsförsörjning och mer.

resultatet är en kärnkatalog som hanterar dina användare och ger dem tillgång till alla IT — resurser de behöver-både on-prem och molnbaserad — var de än befinner sig.

Cloud LDAP och därefter med JumpCloud

JumpCloud directory platform var den första omfattande cloud directory-tjänsten som direkt integrerades med LDAP-tjänster och applikationer. Vidare kombinerar JumpCloud LDAP med RADIUS, SAML, Samba, WebAuthn, SCIM och andra protokoll för att ansluta användare till den IT de behöver för att få arbete att hända.

förutom iam och enhetshantering tillämpar JumpCloud en Nolltrustsäkerhetsmetod med verktyg som multi-factor authentication (MFA), underlättar enhetshantering på flera plattformar för att hålla alla enheter säkra och korrekt konfigurerade och erbjuder ett användarvänligt GUI för både administratörer och användare.

Läs mer om Jumpclouds cloud LDAP — erbjudande, eller prova plattformen gratis-det kostar ingenting att lägga till dina första 10-användare och enheter, och plattformen kommer med 10-dagars livechattstöd.