Katalogtjänst med LDAP [4]: ​​OpenLDAP (I)

Hej kompisar!. Låt oss börja, och som vi alltid rekommenderar, läs de tidigare tre artiklarna i serien:

DNS, DHCP och NTP är de minsta viktiga tjänsterna för vår enkla katalog baserad på OpenLDAP infödd, fungerar ordentligt på Debian 6.0 "Pressa", eller i Ubuntu 12.04 LTS "Precise Pangolin".

Exempel på nätverk:

Lan: 10.10.10.0/24
Dominio: amigos.cu
Servidor: mildap.amigos.cu
Sistema Operativo Servidor: Debian 6 "Squeeze
Dirección IP del servidor: 10.10.10.15
Cliente 1: debian7.amigos.cu
Cliente 2: raring.amigos.cu
Cliente 3: suse13.amigos.cu
Cliente 4: seven.amigos.cu

I första delen kommer vi att se:

  • OpenLDAP-installation (slapd 2.4.23-7.3)
  • Kontroll efter installation
  • Index att ta hänsyn till
  • Regler för datatillgångskontroll
  • Generering av TLS-certifikat i Squeeze

medan vi i andra delen fortsätter med:

  • Lokal användarautentisering
  • Befolka databasen
  • Hantera databasen med hjälp av konsolverktyg
  • Sammanfattning hittills ...

OpenLDAP-installation (slapd 2.4.23-7.3)

OpenLDAP-servern installeras med hjälp av paketet slag. Vi måste också installera paketet ldap-verktyg, vilket ger oss några verktyg på klientsidan samt OpenLDAP: s egna verktyg.

: ~ # aptitude installera slapd ldap-utils

Under installationen debconf Det kommer att be oss om lösenordet för administratören eller användaren «administration«. Ett antal beroenden är också installerade; användaren skapas openldap; den ursprungliga serverkonfigurationen skapas liksom LDAP-katalogen.

I tidigare versioner av OpenLDAP, daemon-konfigurationen slag gjordes helt genom filen /etc/ldap/slapd.conf. I den version vi använder och senare görs konfigurationen på samma sätt slag, och för detta ändamål a DIT «Kataloginformationsträd»Eller kataloginformationsträd, separat.

Konfigurationsmetoden känd som RTC «Konfiguration i realtid»Konfiguration i realtid eller som metoden cn = config, låter oss dynamiskt konfigurera slag utan att tjänsten måste startas om.

Konfigurationsdatabasen består av en samling textfiler i formatet LDIF «LDAP-datautbytesformat»LDAP-format för datautbyte, finns i mappen /etc/ldap/slapd.d.

För att få en uppfattning om mapporganisationen slapd.d, låt oss springa:

: ~ # ls -lR /etc/ldap/slapd.d/
/etc/ldap/slapd.d/: totalt 8 drwxr-x --- 3 openldap openldap 4096 16 feb 11:08 cn = config -rw ------- 1 openldap openldap 407 feb 16 11:08 cn = config.ldif /etc/ldap/slapd.d/cn=config: totalt 28 -rw ------- 1 openldap openldap 383 feb 16 11:08 cn = modul {0} .ldif drwxr-x --- 2 openldap openldap 4096 16 feb 11:08 cn = schema -rw ------- 1 openldap openldap 325 16 feb 11:08 cn = schema.ldif -rw ------- 1 openldap openldap 343 feb 16 11:08 olcBackend = {0} hdb.ldif -rw ------- 1 openldap openldap 472 16 februari 11:08 olcDatabase = {0} config.ldif -rw ------- 1 openldap openldap 586 16 feb 11:08 olcDatabase = {- 1} frontend.ldif -rw ------- 1 openldap openldap 1012 16 feb 11:08 olcDatabase = {1} hdb.ldif /etc/ldap/slapd.d/cn = config / cn = schema: totalt 40 -rw ------- 1 openldap openldap 15474 16 februari 11:08 cn = {0} core.ldif -rw ------- 1 openldap openldap 11308 16 feb 11:08 cn = {1} cosine.ldif -rw ------- 1 openldap openldap 6438 16 feb 11:08 cn = {2} nis.ldif -rw ------- 1 openldap openldap 2802 16 feb 11:08 cn = {3} inetorgperson.ldif

Om vi ​​tittar lite på den föregående produktionen ser vi att backend används i Squeeze är databastypen hdb, som är en variant av bdb "Berkeley Database", och att den är helt hierarkisk och stöder döpa om underträd. För att lära dig mer om det möjliga backends som stöder OpenLDAP, besök http://es.wikipedia.org/wiki/OpenLDAP.

Vi ser också att tre separata databaser används, det vill säga en dedikerad till konfiguration, en annan till Frontendoch den sista som är databasen hdb i sig.

Dessutom, slag installeras som standard med schemat Kärna, cosinus, nis e internet person.

Kontroll efter installation

I en terminal kör vi lugnt och läser utgångarna. Vi kommer att kontrollera, särskilt med det andra kommandot, konfigurationen härledd från listning av mappen slapd.d.

: ~ # ldapsearch -Q -LLL -Y EXTERNAL -H ldapi: /// -b cn = config | mer: ~ # ldapsearch -Q -LLL -Y EXTERNAL -H ldapi: /// -b cn = config dn
dn: cn = config dn: cn = modul {0}, cn = config dn: cn = schema, cn = config dn: cn = {0} kärna, cn = schema, cn = config dn: cn = {1} cosinus , cn = schema, cn = config dn: cn = {2} nis, cn = schema, cn = config dn: cn = {3} inetorgperson, cn = schema, cn = config dn: olcBackend = {0} hdb, cn = config dn: olcDatabase = {- 1} frontend, cn = config dn: olcDatabase = {0} config, cn = config dn: olcDatabase = {1} hdb, cn = config

Förklaring av varje utgång:

  • cn = config: Globala parametrar.
  • cn = modul {0}, cn = konfiguration: Dynamiskt laddad modul.
  • cn = schema, cn = config: Innehåller hårdkodad på nivån för systemschemat.
  • cn = {0} kärna, cn = schema, cn = konfiguration: Den hårdkodad av kärnschemat.
  • cn = {1} cosinus, cn = schema, cn = config: Schemat Cosinus.
  • cn = {2} nis, cn = schema, cn = config: Schemat Nej.
  • cn = {3} inetorgperson, cn = schema, cn = config: Schemat internet person.
  • olcBackend = {0} hdb, cn = config: backend datalagringstyp hdb.
  • olcDatabase = {- 1} frontend, cn = config: Frontend av databasen och standardparametrar för de andra databaserna.
  • olcDatabase = {0} config, cn = config: Konfigurationsdatabas för slag (cn = config).
  • olcDatabase = {1} hdb, cn = config: Vår databasinstans (dc = vänner, dc = cu)
: ~ # ldapsearch -x -LLL -H ldap: /// -b dc = exempel, dc = com dn
dn: dc = vänner, dc = cu dn: cn = admin, dc = vänner, dc = cu
  • dc = vänner, dc = cu: DIT Base Directory Information Tree
  • cn = admin, dc = vänner, dc = cu: Administratör (rootDN) för DIT som deklareras under installationen.

anteckning: Bas-suffixet dc = vänner, dc = cu, tog den debconf under installationen från FQDN för servern mildap.amigos.cu.

Index att ta hänsyn till

Indexeringen av posterna utförs för att förbättra sökningens resultat DIT, med filterkriterier. De index som vi kommer att överväga är det lägsta som rekommenderas enligt de attribut som deklarerats i standardscheman.

För att dynamiskt ändra indexen i databasen skapar vi en textfil i formatet LDIF, och senare lägger vi till den i databasen. Vi skapar filen olcDbIndex.ldif och vi lämnar det med följande innehåll:

: ~ # nano olcDbIndex.ldif
dn: olcDatabase = {1} hdb, cn = config changetype: modify add: olcDbIndex olcDbIndex: uidNumber eq - add: olcDbIndex olcDbIndex: gidNumber eq - lägg till: olcDbIndex olcDbIndex: loginUdx : loginShell eq, olcDbIndex: login - lägg till: olcDbIndex olcDbIndex: uid pres, sub, eq - lägg till: olcDbIndex olcDbIndex: cn pres, sub, eq - lägg till: olcDbIndex olcDbIndex: sn pres, sub, eqb - add: olcd: ol , ou pres, eq, sub - add: olcDbIndex olcDbIndex: displayName pres, sub, eq - add: olcDbIndex olcDbIndex: default sub - add: olcDbIndex olcDbIndex: mail eq, subinitial - add: olcDbIndex olcDbIndex:

Vi lägger till index i databasen och kontrollerar modifieringen:

: ~ # ldapmodify -Y EXTERNAL -H ldapi: /// -f ./olcDbIndex.ldif

: ~ # ldapsearch -Q -LLL -Y EXTERNAL -H ldapi: /// -b \ cn = config '(olcDatabase = {1} hdb)' olcDbIndex

dn: olcDatabase = {1} hdb, cn = config olcDbIndex: objectClass eq olcDbIndex: uidNumber, gidNumber eq olcDbIndex: memberUid eq, pres, sub olcDbIndex: loginShell eq olcDbIndex: uid presq, subq, olcDbIndex: sn pres, sub, eq olcDbIndex: givenName, ou pres, eq, sub olcDbIndex: displayName pres, sub, eq olcDbIndex: default sub olcDbIndex: mail eq, subinitial olcDbIndex: dc eq

Regler för datatillgångskontroll

De regler som fastställs så att användare kan läsa, ändra, lägga till och ta bort data i katalogdatabasen kallas Access Control, medan vi kommer att ringa Access Control Lists eller «ACL-åtkomstkontrollista»Till de policyer som konfigurerar reglerna.

Att veta vilken ACL förklarades som standard under installationen av slag, vi utför:

: ~ # ldapsearch -Q -LLL -Y EXTERNAL -H ldapi: /// -b \
cn = config '(olcDatabase = {1} hdb)' olcAccess

: ~ # ldapsearch -Q -LLL -Y EXTERNAL -H ldapi: /// -b \
cn = config '(olcDatabase = {- 1} frontend)' olcAccess

: ~ # ldapsearch -Q -LLL -Y EXTERNAL -H ldapi: /// -b \
cn = config '(olcDatabase = {0} config)' olcAccess

: ~ # ldapsearch -Q -LLL -Y EXTERNAL -H ldapi: /// -b \
cn = config '(olcAccess = *)' olcAccess olcSuffix

Var och en av ovanstående kommandon visar oss ACL som vi hittills har förklarat i vår katalog. Specifikt visar det sista kommandot dem alla, medan de första tre ger oss åtkomstkontrollreglerna för alla tre. DIT inblandade i vår slag.

På ämnet av ACL och för att inte göra en mycket längre artikel rekommenderar vi att du läser manualsidorna man slapd.access.

För att garantera åtkomst för användare och administratörer att uppdatera sina poster av loginShell y Geckos, vi lägger till följande ACL:

## Vi skapar olcAccess.ldif-filen och lämnar den med följande innehåll: ~ # nano olcAccess.ldif
dn: olcDatabase = {1} hdb, cn = config changetype: modify add: olcAccess olcAccess: {1} to attrs = loginShell, gecos by dn = "cn = admin, dc = friends, dc = cu" skriv själv skriva av * läs

## Vi lägger till ACL
: ~ # ldapmodify -Y EXTERNAL -H ldapi: /// -f ./olcAccess.ldif

# Vi kontrollerar ändringarna
ldapsearch -Q -LLL -Y EXTERNAL -H ldapi: /// -b \
cn = config '(olcAccess = *)' olcAccess olcSuffix

Generering av certifikat TLS i Squeeze

För att ha en säker autentisering med OpenLDAP-servern måste vi göra det genom en krypterad session som vi kan uppnå med hjälp av TLS "Transport Layer Security" o Säkra transportlager.

OpenLDAP-servern och dess klienter kan använda ramverk TLS för att ge skydd avseende integritet och konfidentialitet, samt för att stödja en säker LDAP-autentisering genom mekanismen SASL «Enkel autentisering och säkerhetslager« Extern.

Moderna OpenLDAP-servrar gynnar användningen av */ StartTLS /* o Starta ett säkert transportskikt till / protokolletLDAPS: ///, vilket är föråldrat. Några frågor, besök * Start TLS v. ldaps: // * en http://www.openldap.org/faq/data/cache/605.html

Lämna bara filen som installerad som standard / etc / default / slapd med uttalandet SLAPD_SERVICES = »ldap: /// ldapi: ///», i syfte att använda en krypterad kanal mellan klienten och servern, och själva hjälpapplikationerna för att administrera OpenLDAP som installeras lokalt.

Metoden som beskrivs här, baserat på paketen gnutls-bin y ssl-cert det är giltigt för Debian 6 "Squeeze" och även för Ubuntu Server 12.04. För Debian 7 "Wheezy" en annan metod baserad på OpenSSL.

Genereringen av certifikaten i Squeeze utförs enligt följande:

1.- Vi installerar nödvändiga paket
: ~ # aptitude installera gnutls-bin ssl-cert

2.- Vi skapar den primära nyckeln för certifikatutfärdaren
: ~ # sh -c "certtool --generate-privkey> /etc/ssl/private/cakey.pem"

3.- Vi skapar en mall för att definiera CA (Certificate Authority)
: ~ # nano /etc/ssl/ca.info cn = Kubanska vänner ca cert_signing_key

4.- Vi skapar CA-själv- eller självsignerat certifikat för kunder
: ~ # certtool --generate-self-signed \ --load-privkey /etc/ssl/private/cakey.pem \ --template /etc/ssl/ca.info \ --outfile / etc / ssl / certs / cacert.pem

5.- Vi genererar en privat nyckel för servern
: ~ # certtool --generate-privkey \ --bits 1024 \ --outfile /etc/ssl/private/mildap-key.pem

anteckning: Byta ut "mildap"i namnet på filen ovan av din egen server. Att namnge certifikatet och nyckeln, både för servern och för den tjänst som använder den, hjälper oss att hålla saker klart.

6.- Vi skapar filen /etc/ssl/mildap.info med följande innehåll:
: ~ # nano /etc/ssl/mildap.info organisation = Kubanska vänner cn = mildap.amigos.cu tls_www_server kryptering_nyckelsignering_key expiration_days = 3650

anteckning: I innehållet ovan förklarar vi att intyget är giltigt i en period av tio år. Parametern måste anpassas efter vår bekvämlighet.

7.- Vi skapar servercertifikatet
: ~ # certtool --generate-certificate \ --load-privkey /etc/ssl/private/mildap-key.pem \ --load-ca-certificate /etc/ssl/certs/cacert.pem \ --load- ca-privkey /etc/ssl/private/cakey.pem \ --template /etc/ssl/mildap.info \ --outfile /etc/ssl/certs/mildap-cert.pem

Hittills har vi genererat nödvändiga filer, vi behöver bara lägga till platsen för det självsignerade certifikatet i katalogen cacert.pem; servercertifikatet mildap-cert.pem; och serverns privata nyckel mildap-key.pem. Vi måste också justera behörigheterna och ägaren till de genererade filerna.

: ~ # nano /etc/ssl/certinfo.ldif
dn: cn = config add: olcTLSCACertificateFil olcTLSCACertificateFile: /etc/ssl/certs/cacert.pem - lägg till: olcTLSCertificateFile olcTLSCertificateFile: /etc/ssl/certs/mildap-cert.cem.scem.cert.pem - -key.pem

8.- Lägg till: ~ # ldapmodify -Y EXTERNAL -H ldapi: /// -f /etc/ssl/certinfo.ldif

9.- Vi justerar ägare och behörigheter
: ~ # adduser openldap ssl-cert: ~ # chgrp ssl-cert /etc/ssl/private/mildap-key.pem: ~ # chmod g + r /etc/ssl/private/mildap-key.pem: ~ # chmod eller /etc/ssl/private/mildap-key.pem

Certifikatet cacert.pem Det är den som vi måste kopiera till varje klient. För att detta certifikat ska kunna användas på själva servern måste vi deklarera det i filen /etc/ldap/ldap.conf. För att göra detta ändrar vi filen och lämnar den med följande innehåll:

: ~ # nano /etc/ldap/ldap.conf
BASE dc = vänner, dc = cu URI ldap: //mildap.amigos.cu TLS_CACERT /etc/ssl/certs/cacert.pem

Slutligen och även som en kontroll startar vi om tjänsten slag och vi kontrollerar produktionen av syslog från servern för att ta reda på om tjänsten startades om ordentligt med det nyligen deklarerade certifikatet.

: ~ # service slapd restart
: ~ # svans / var / log / syslog

Om tjänsten inte startar om korrekt eller om vi ser ett allvarligt fel i syslog, låt oss inte bli avskräckta. Vi kan försöka reparera skadan eller börja om. Om vi ​​bestämmer oss för att börja om från början installerar vi slag, är det inte nödvändigt att formatera vår server.

För att radera allt som vi hittills har gjort av en eller annan anledning måste vi avinstallera paketet slagoch radera sedan mappen / var / lib / ldap. Vi måste också lämna filen i sin ursprungliga version /etc/ldap/ldap.conf.

Det är sällsynt att allt fungerar korrekt vid första försöket. 🙂

Kom ihåg att i nästa del ser vi:

  • Lokal användarautentisering
  • Befolka databasen
  • Hantera databasen med hjälp av konsolverktyg
  • Sammanfattning hittills ...

Vi ses snart vänner !.


Innehållet i artikeln följer våra principer om redaktionell etik. Klicka på för att rapportera ett fel här.

19 kommentarer, lämna din

Lämna din kommentar

Din e-postadress kommer inte att publiceras.

*

*

  1. Ansvarig för uppgifterna: Miguel Ángel Gatón
  2. Syftet med uppgifterna: Kontrollera skräppost, kommentarhantering.
  3. Legitimering: Ditt samtycke
  4. Kommunikation av uppgifterna: Uppgifterna kommer inte att kommuniceras till tredje part förutom enligt laglig skyldighet.
  5. Datalagring: databas värd för Occentus Networks (EU)
  6. Rättigheter: När som helst kan du begränsa, återställa och radera din information.

  1.   Hugo sade

    Lärare!!!
    DET HÄNDADE MED TUTOEN!
    är utmärkt
    alla världens likheter för dig.
    ????

    1.    federico sade

      Tack så mycket, Hugo !!! Vänta på nästa artiklar om ämnet.

  2.   detta namn är falskt sade

    Hej:

    intressant din serie artiklar.

    Jag blev förvånad över att läsa detta uttalande: "Moderna OpenLDAP-servrar föredrar användningen av StartTLS eller Start a Secure Transport Layer framför det gamla TLS / SSL-protokollet, vilket är föråldrat."

    Påstår du att STARTTLS, i alla fall även utanför LDAP-räckvidden, är en skyddsmekanism som är överlägsen TSL / SSL?

    1.    federico sade

      Tack för kommentaren. Observera att jag menar OpenLDAP. Jag översträcker inte. I http://www.openldap.org/faq/data/cache/185.htmlkan du läsa följande:

      Transport Layer Security (TLS) är standardnamnet för Secure Socket Layer (SSL). Villkoren (om inte kvalificerade med specifika versionsnummer) är i allmänhet utbytbara.

      StartTLS är namnet på standard LDAP-operationen för att initiera TLS / SSL. TLS / SSL initieras efter att denna LDAP-operation har slutförts. Ingen alternativ port är nödvändig. Det kallas ibland TLS-uppgraderingen, eftersom den uppgraderar en normal LDAP-anslutning till en skyddad av TLS / SSL.

      ldaps: // och LDAPS hänvisar till "LDAP över TLS / SSL" eller "LDAP Secured". TLS / SSL initieras vid anslutning till en alternativ port (normalt 636). Även om LDAPS-porten (636) är registrerad för denna användning är uppgifterna om TLS / SSL-initieringsmekanismen inte standardiserade.

      När det väl har initierats är det ingen skillnad mellan ldaps: // och StartTLS. De delar samma konfigurationsalternativ (förutom att ldaps: // kräver konfiguration av en separat lyssnare, se slapd (8) s -h-alternativ) och resulterar i att liknande säkerhetstjänster upprättas.
      Notera:
      1) ldap: // + StartTLS ska riktas till en normal LDAP-port (normalt 389), inte ldaps: // -porten.
      2) ldaps: // ska riktas till en LDAPS-port (normalt 636), inte LDAP-porten.

      1.    detta namn är falskt sade

        Tyvärr, men jag är fortfarande inte säker på varför du hävdar att: 1) moderna servrar föredrar STARTTLS framför SSL / TLS; 2) STARTTLS är modern, mot SSL / TLS som är föråldrad.

        Jag har kämpat i en halv månad med konfigurationen av olika e-postklienter som får åtkomst till servern med SSL (med hjälp av openssl-bibliotek, som de flesta gratisprogram gör), med CA-certifikat i / etc / ssl / certs / och andra tillbehör. Och vad jag har lärt mig är att: 1) STARTTLS krypterar endast sessionsautentisering, och allt annat skickas okrypterat; 2) SSL krypterar absolut allt innehåll i sessionen. Därför är STARTTLS i inget fall tekniskt överlägset SSL; Jag skulle hellre vara benägen att tänka tvärtom, eftersom innehållet i din session reser okrypterat över nätverket.

        En annan annorlunda sak är att STARTTLS rekommenderas av andra skäl som jag inte vet: för kompatibilitet med MSWindows, eftersom implementeringen är mer stabil eller är bättre testad ... Jag vet inte. Det är därför jag frågar dig.

        Från citatet från handboken som du har bifogat mig i ditt svar ser jag att skillnaden mellan ldap: // och ldaps: // motsvarar skillnaden mellan imap: // och imaps: // eller mellan smtp : // och smtps: //: en annan port används, någon ytterligare post läggs till i konfigurationsfilen, men resten av parametrarna behålls. Men det indikerar ingenting om att föredra STARTTLS eller inte.

        Hälsningar och ledsen för svaret. Jag försöker bara lära mig lite mer.

        1.    federico sade

          Se, det är mycket sällsynt att jag i mina artiklar gör anspråk på den kalibern utan att stödjas av någon seriös publikation. I slutet av serien kommer jag att inkludera alla länkar till dokumentation som jag anser vara allvarliga och som jag har rådfrågat för att skriva inlägget. Jag flyttar fram följande länkar:

          https://wiki.debian.org/LDAP/OpenLDAPSetup
          Ubuntu Serverguide https://code.launchpad.net/serverguide
          OpenLDAP-tjänsteman http://www.openldap.org/doc/admin24/index.html
          LDAP över SSL / TLS och StartTLS http://tt4cs.wordpress.com/2014/01/18/ldap-over-ssltls-and-starttls/

          Och dessutom konsulterade jag medföljande dokumentation som installeras med varje paket.

          Frågan om säkerhet i allmänhet och skillnaderna mellan StartTLS och TLS / SSL är mycket tekniska och så djupa att jag inte anser mig ha den kunskap som krävs för att ge sådana förklaringar. Jag tror att vi kan fortsätta prata via e-post.

          Dessutom anger jag ingenstans att LDAPS: // inte kan användas. Om du anser att det är säkrare, fortsätt sedan !!!

          Jag kan inte hjälpa dig längre och jag uppskattar verkligen dina kommentarer.

        2.    federico sade

          Lite mer tydlighet kan du få - alltid om OpenLDAP- i:
          http://www.openldap.org/faq/data/cache/605.html

          StartTLS utökade operation [RFC 2830] är LDAPv3s standardmekanism för att möjliggöra TLS (SSL) datakonfidentialitetsskydd. Mekanismen använder en utökad LDAPv3-operation för att upprätta en krypterad SSL / TLS-anslutning inom en redan etablerad LDAP-anslutning. Medan mekanismen är utformad för användning med TLSv1 kommer de flesta implementeringar att falla tillbaka till SSLv3 (och SSLv2) om det behövs.

          ldaps: // är en mekanism för att upprätta en krypterad SSL / TLS-anslutning för LDAP. Det kräver användning av separat port, vanligtvis 636. Även om den ursprungligen utformades för användning med LDAPv2 och SSLv2, stöder många implementeringar dess användning med LDAPv3 och TLSv1. Även om det inte finns någon teknisk specifikation för ldaps: // används den ofta.

          ldaps: // förfaller till förmån för Start TLS [RFC2830]. OpenLDAP 2.0 stöder båda.
          Av säkerhetsskäl bör servern konfigureras för att inte acceptera SSLv2.

  3.   freebsddick sade

    Detta kommer att vara en av de artiklar där användarna inte kommer att kommentera eftersom de bara tittar på porr på sina Linux-stationer, de är helt enkelt inte intresserade. Om ldap Jag har flera relaterade tjänster inom det heterogena nätverket för företaget jag arbetar för. Bra artikel !!

    1.    federico sade

      Tack för kommentaren !!!. Och ditt uttalande om de få kommentarerna i många av mina artiklar är mycket sant. Men jag får korrespondens från intresserade läsare eller från andra som laddar ner artikeln för senare läsning och tillämpning.

      Det är alltid bra att ha feedback genom kommentarer, även om de är: Jag sparade den för senare läsning, intressant eller annan åsikt.

      hälsningar

  4.   federico sade

    Freeke !!! Tack för kommentaren. Jag fick din kommentar i posten men jag ser den inte trots att jag uppdaterar sidan flera gånger. Vän, du kan testa detta och tidigare artiklar utan problem på Squeeze eller Ubuntu Server 12.04. I Wheezy genereras certifikat på ett annat sätt med OpenSSL. Men inget. Mina hälsningar, bror !!!.

  5.   federico sade

    @thisnameisfalse: Den bästa kontoristen har en oskärpa. Tack vare dina kommentarer tycker jag att stycket i fråga bör vara som följer:

    Moderna OpenLDAP-servrar föredrar användningen av StartTLS, eller Start a Secure Transport Layer, framför LDAPS: // -protokollet, vilket är föråldrat. Eventuella frågor, besök Start TLS v. ldaps: // sv http://www.openldap.org/faq/data/cache/605.html

    hälsningar

  6.   Jose Monge sade

    Perfekt, just nu har jag läxor på ldap

  7.   Walter sade

    Du kan inte lägga allt i en enda fil så att du kan ladda ner hela handledningen

  8.   någonsin sade

    Jag är en datortekniker med lång erfarenhet av Linux, men jag har ändå gått vilse mitt i artikeln. Sedan ska jag läsa igenom det noggrant. Tack så mycket för handledningen.
    Även om det är sant att det låter oss förstå mycket mer varför ActiveDirectory vanligtvis väljs för dessa saker. Det finns ett universum av skillnad när det gäller enkel konfiguration och implementering.
    hälsningar

  9.   federico sade

    Tack alla för att ni kommenterade !!!
    @jose monge, jag hoppas att det hjälper dig
    @walter i slutet av alla inlägg ser jag om jag kan skapa ett kompendium i html- eller pdf-format
    @eVeR i omvänd ordning, en OpenLDAP är enklare - även om det inte verkar som en Active Directory. vänta på nästa artiklar så får du se.

  10.   Marcelo sade

    En fråga, jag gör installationen steg för steg men när jag startar om slapd-tjänsten, ger det mig följande fel>

    30 jul 15:27:37 xxxx slapd [1219]: @ (#) $ OpenLDAP: slapd (Ubuntu) (17 mars 2014 21:20:08) $ # 012 # 011buildd @ aatxe: /build/buildd/openldap-2.4.31 .XNUMX / debian / build / servers / slapd
    30 jul 15:27:37 xxxxx slapd [1219]: Okänt attribut Beskrivning "CHANGETYPE" infogad.
    30 jul 15:27:37 xxxxx slapd [1219]: Okänt attribut Beskrivning "ADD" infogad.
    30 jul 15:27:37 xxxxx [1219]: <= str2entry: slap_str2undef_ad (-): tom AttributBeskrivning
    30 jul 15:27:37 xxxxx slapd [1219]: slapd stoppade.
    30 jul 15:27:37 xxxxx [1219]: anslutningar_förstör: inget att förstöra.

    1.    x11tete11x sade

      kan du fråga i forumet 😀 http://foro.desdelinux.net/

  11.   pedrop sade

    För alla som ser det här utmärkta och välförklarade inlägget och problemet uppstår när ACL skapas:
    ldapmodify: ogiltigt format (rad 5) post: "olcDatabase = {1} hdb, dc = config"

    Efter att ha tagit huvudet på internet, visar det sig att ldapmodify är den mest exakta typen där ute på nätet. Det är hysteriskt med felplacerade karaktärer och efterföljande mellanslag. Utan vidare ado är rådet att skriva by-tillståndet bredvid varandra eller genom X skriva själv skriva genom * läsa. Om det fortfarande inte fungerar installerar du Notepad ++> Visa> Visa symbol och slutligen död till osynliga tecken. Jag hoppas att någon hjälper.

  12.   pedrop sade

    Skapa certifikat för Debian Wheezy baserat på OpenSSL som kan tjäna:
    http://blog.phenobarbital.info/2014/10/openldap-tlsssl-configuracion-basica-y-aseguramiento/