Direktoriju pakalpojums ar LDAP [4]: ​​OpenLDAP (I)

Sveiki draugi!. Sāksim ķerties pie lietas, un, kā mēs vienmēr iesakām, izlasiet trīs iepriekšējos sērijas rakstus:

DNS, DHCP un NTP ir obligāti nepieciešamie pakalpojumi mūsu vienkāršajā direktorijā, kuras pamatā ir OpenLDAP dzimtā, pareizi darbojas Debian 6.0 "saspiest", vai arī Ubuntu 12.04 LTS "Precise Pangolin".

Tīkla piemērs:

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

Pirmajā daļā mēs redzēsim:

  • OpenLDAP instalēšana (slapd 2.4.23-7.3)
  • Pārbaudes pēc uzstādīšanas
  • Indeksi, kas jāņem vērā
  • Datu piekļuves kontroles noteikumi
  • TLS sertifikātu ģenerēšana Squeeze

savukārt otrajā daļā mēs turpināsim ar:

  • Vietējā lietotāja autentifikācija
  • Aizpildiet datu bāzi
  • Pārvaldiet datu bāzi, izmantojot konsoles utilītprogrammas
  • Līdzšinējais kopsavilkums ...

OpenLDAP instalēšana (slapd 2.4.23-7.3)

OpenLDAP serveris tiek instalēts, izmantojot pakotni iepļaukāt. Mums arī jāinstalē pakotne ldap-utils, kas mums nodrošina dažus klienta puses rīkus, kā arī OpenLDAP pašu utilītus.

: ~ # aptitude instalēt slapd ldap-utils

Instalēšanas procesa laikā debconf Tas mums prasīs administratora vai lietotāja paroli «admin«. Ir uzstādītas arī vairākas atkarības; lietotājs ir izveidots openldap; tiek izveidota sākotnējā servera konfigurācija, kā arī LDAP direktorijs.

Iepriekšējās OpenLDAP versijās dēmona konfigurācija iepļaukāt tika pilnībā veikts, izmantojot failu /etc/ldap/slapd.conf. Versijā, kuru mēs izmantojam, un vēlāk konfigurācija tiek veikta tāpat iepļaukāt, un šim nolūkam a DIT «Kataloga informācijas koksVai arī direktoriju informācijas koks, atsevišķi.

Konfigurācijas metode, kas pazīstama kā RTC «Reālā laika konfigurācija»Reālā laika konfigurācija vai kā metode cn = konfigurācija, ļauj mums dinamiski konfigurēt iepļaukāt neprasot pakalpojuma restartēšanu.

Konfigurācijas datu bāze sastāv no teksta failu kolekcijas formātā LDIF «LDAP datu apmaiņas formāts»LDAP formāts datu apmaiņai, kas atrodas mapē /etc/ldap/slapd.d.

Lai iegūtu priekšstatu par mapju organizāciju slapd.d, skrienam:

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

Ja mazliet paskatāmies uz iepriekšējo iznākumu, redzam, ka aizmugure Squeeze izmantotais ir datu bāzes tips hdb, kas ir bdb "Berkeley Database" un ka tā ir pilnībā hierarhiska un atbalsta apakškoku pārdēvēšanu. Lai uzzinātu vairāk par iespējamo Aizmugures sistēmas kas atbalsta OpenLDAP, apmeklējiet vietni http://es.wikipedia.org/wiki/OpenLDAP.

Mēs arī redzam, ka tiek izmantotas trīs atsevišķas datubāzes, tas ir, viena ir veltīta konfigurācijai, otra - frontend, un pēdējā ir datubāze hdb per se.

Turklāt, iepļaukāt pēc noklusējuma ir instalēta ar shēmām Kodols, Kosinē, Nis e Inetorgpersona.

Pārbaudes pēc uzstādīšanas

Terminālā mēs mierīgi izpildām un lasām izejas. Mēs pārbaudīsim, it īpaši ar otro komandu, konfigurāciju, kas secināta no mapes saraksta slapd.d.

: ~ # ldapsearch -Q -LLL -Y ĀRĒJĀ -H ldapi: /// -b cn = config | vairāk: ~ # ldapsearch -Q -LLL -Y ĀRĒJĀ -H ldapi: /// -b cn = config dn
dn: cn = config dn: cn = modulis {0}, cn = config dn: cn = shēma, cn = config dn: cn = {0} kodols, cn = shēma, cn = config dn: cn = {1} kosinuss , 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} priekšējā daļa, cn = config dn: olcDatabase = {0} config, cn = config dn: olcDatabase = {1} hdb, cn = config

Katras izejas skaidrojums:

  • cn = konfigurācija: Globālie parametri.
  • cn = modulis {0}, cn = konfigur: Dinamiski ielādēts modulis.
  • cn = shēma, cn = config: Satur grūti kodēts sistēmas shēmu līmenī.
  • cn = {0} kodols, cn = shēma, cn = config: The grūti kodēts kodola shematisks.
  • cn = {1} kosinuss, cn = shēma, cn = config: Shēma Kosinuss.
  • cn = {2} nis, cn = shēma, cn = config: Shēma Nis.
  • cn = {3} inetorgperson, cn = shēma, cn = config: Shēma Inetorgpersona.
  • olcBackend = {0} hdb, cn = konfigurācija: aizmugure datu glabāšanas veids hdb.
  • olcDatabase = {- 1} frontend, cn = config: frontend datu bāzes un noklusējuma parametri citām datubāzēm.
  • olcDatabase = {0} config, cn = config: konfigurācijas datu bāze iepļaukāt (cn = konfigurācija).
  • olcDatabase = {1} hdb, cn = config: Mūsu datu bāzes gadījums (dc = draugi, dc = cu)
: ~ # ldapsearch -x -LLL -H ldap: /// -b dc = piemērs, dc = com dn
dn: dc = draugi, dc = cu dn: cn = administrators, dc = draugi, dc = cu
  • dc = draugi, dc = cu: DIT bāzes direktorija informācijas koks
  • cn = administrators, dc = draugi, dc = cu: Instalēšanas laikā deklarētā DIT administrators (rootDN).

Atzīmēt: Bāzes piedēklis dc = draugi, dc = cu, paņēma to debconf instalēšanas laikā no FQDN serveris mildap.amigos.cu.

Indeksi, kas jāņem vērā

Ierakstu indeksēšana tiek veikta, lai uzlabotu meklēšanu vietnē DIT, ar filtru kritērijiem. Indeksi, kurus mēs uzskatīsim, ir minimāli ieteicamie pēc noklusējuma shēmās deklarētajiem atribūtiem.

Lai dinamiski modificētu indeksus datu bāzē, mēs izveidojam teksta failu formātā LDIF, un vēlāk mēs to pievienojam datu bāzei. Mēs izveidojam failu olcDbIndex.ldif un mēs to atstājam ar šādu saturu:

: ~ # nano olcDbIndex.ldif
dn: olcDatabase = {1} hdb, cn = config changetype: modify add: olcDbIndex olcDbIndex: uidNumber eq - pievienot: olcDbIndex olcDbIndex: gidNumber eq - pievienot: olcDbIndex olcDbIndex, login: loginUid eq, login: loginUid eq : loginShell eq, olcDbIndex: login - pievienot: olcDbIndex olcDbIndex: uid pres, sub, eq - pievienot: olcDbIndex olcDbIndex: cn pres, sub, eq - pievienot: olcDbIndex olcDbIndex: sn pres, sub, eq - addInxx: , ou pres, eq, sub - pievienot: olcDbIndex olcDbIndex: displayName pres, sub, eq - pievienot: olcDbIndex olcDbIndex: noklusējuma sub - pievienot: olcDbIndex olcDbIndex: pasta eq, subinitial - pievienot: olcDbIndex olcDbIn

Mēs pievienojam indeksus datu bāzei un pārbaudām modifikāciju:

: ~ # ldapmodify -Y ĀRĒJĀ -H ldapi: /// -f ./olcDbIndex.ldif

: ~ # ldapsearch -Q -LLL -Y ĀRĒJS -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, sub pres, uid presc, uid pres, olcDbIndex: sn pres, sub, eq olcDbIndex: givenName, ou pres, eq, sub olcDbIndex: displayName pres, sub, eq olcDbIndex: noklusējuma sub olcDbIndex: pasta eq, subinitial olcDbIndex: dc eq

Datu piekļuves kontroles noteikumi

Noteikumi, kas izveidoti, lai lietotāji varētu lasīt, modificēt, pievienot un dzēst datus direktoriju datu bāzē, tiek saukti par piekļuves kontroli, savukārt mēs izsauksim piekļuves kontroles sarakstus vai «ACL piekļuves kontroles saraksts»Uz politikām, kas konfigurē kārtulas.

Lai zinātu, kuru ACL tika noklusēti deklarēti iepļaukāt, mēs izpildām:

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

: ~ # ldapsearch -Q -LLL -Y ĀRĒJĀ -H ldapi: /// -b \
cn = config '(olcDatabase = {- 1} priekšējā daļa)' olcAccess

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

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

Katra no iepriekš minētajām komandām parādīs mums ACL ka līdz šim mēs esam paziņojuši savā direktorijā. Konkrēti, pēdējā komanda parāda tos visus, bet pirmie trīs dod mums piekļuves kontroles noteikumus visiem trim. DIT iesaistīts mūsu iepļaukāt.

Par tēmu ACL un, lai neradītu daudz garāku rakstu, iesakām izlasīt rokasgrāmatas lapas cilvēks slapd.piekļūt.

Lai garantētu lietotāju un administratoru piekļuvi, lai atjauninātu viņu pieteikšanāsShell y Gekoss, mēs pievienosim šādu ACL:

## Mēs izveidojam olcAccess.ldif failu un atstājam to ar šādu saturu: ~ # 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" raksta pats * lasīt

## Pievienojam ACL
: ~ # ldapmodify -Y ĀRĒJĀ -H ldapi: /// -f ./olcAccess.ldif

# Mēs pārbaudām izmaiņas
ldapsearch -Q -LLL -Y ĀRĒJĀ -H ldapi: /// -b \
cn = config '(olcAccess = *)' olcAccess olcSuffix

Sertifikātu ģenerēšana TLS saspiest

Lai nodrošinātu drošu autentifikāciju ar OpenLDAP serveri, mums tas jādara, izmantojot šifrētu sesiju, kuru mēs varam sasniegt, izmantojot TLS «Transporta slāņa drošība» o Drošs transporta slānis.

OpenLDAP serveris un tā klienti var izmantot ietvars TLS, lai nodrošinātu aizsardzību attiecībā uz integritāti un konfidencialitāti, kā arī atbalstu drošai LDAP autentifikācijai, izmantojot mehānismu SASL «Vienkāršs autentifikācijas un drošības slānis« Ārējais.

Mūsdienu OpenLDAP serveri atbalsta * izmantošanu/ StartTLS /* o Sāciet drošu transporta slāni uz /LDAPS: ///, kas ir novecojis. Ja rodas kādi jautājumi, apmeklējiet vietni * Start TLS v. ldaps: // * en http://www.openldap.org/faq/data/cache/605.html

Vienkārši atstājiet failu kā instalētu pēc noklusējuma / etc / default / slapd ar paziņojumu SLAPD_SERVICES = »ldap: /// ldapi: ///», ar mērķi izmantot šifrētu kanālu starp klientu un serveri un pašām palīgprogrammām, lai administrētu lokāli instalēto OpenLDAP.

Šeit aprakstītā metode, kuras pamatā ir paketes gnutls-bin y ssl-sert tas ir derīgs Debian 6 "Squeeze" un arī Ubuntu Server 12.04. Debian 7 "Wheezy" vēl viena metode, kuras pamatā ir OpenSSL.

Sertifikātu ģenerēšana Squeeze notiek šādi:

1.- Mēs instalējam nepieciešamās paketes
: ~ # aptitude instalējiet gnutls-bin ssl-cert

2.- Mēs izveidojam primāro atslēgu sertificēšanas iestādei
: ~ # sh -c "certtool --generate-privkey> /etc/ssl/private/cakey.pem"

3.- Mēs izveidojam veidni, lai definētu CA (sertifikāta iestādi)
: ~ # nano /etc/ssl/ca.info cn = Kubas draugi ca cert_signing_key

4.- Mēs klientiem izveidojam CA pašparakstītu vai pašparakstītu sertifikātu
: ~ # certtool --generate-self-parakstīts \ --load-privkey /etc/ssl/private/cakey.pem \ --template /etc/ssl/ca.info \ --outfile / etc / ssl / certs / cacert.pem

5.- Mēs ģenerējam privātu atslēgu serverim
: ~ # certtool --generate-privkey \ --bits 1024 \ --outfile /etc/ssl/private/mildap-key.pem

Atzīmēt: Aizvietot "mildap"faila nosaukumā iepriekš jūsu serverim. Sertifikāta un atslēgas nosaukšana gan serverim, gan pakalpojumam, kas to izmanto, palīdz mums saglabāt lietas skaidrības.

6.- Mēs izveidojam failu /etc/ssl/mildap.info ar šādu saturu:
: ~ # nano /etc/ssl/mildap.info organization = Kubas draugi cn = mildap.amigos.cu tls_www_server encryption_key signing_key expiration_days = 3650

Atzīmēt: Iepriekšējā saturā mēs paziņojam, ka sertifikāts ir derīgs 10 gadus. Parametrs jāpielāgo mūsu ērtībām.

7.- Mēs izveidojam servera sertifikātu
: ~ # 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

Līdz šim mēs esam izveidojuši nepieciešamos failus, mums direktorijā jāpievieno tikai pašparakstītā sertifikāta atrašanās vieta cacert.pem; servera sertifikāta mildap-cert.pem; un servera privāto atslēgu mildap-key.pem. Mums ir jāpielāgo arī ģenerēto failu atļaujas un īpašnieks.

: ~ # nano /etc/ssl/certinfo.ldif
dn: cn = config add: olcTLSCACertificateFile olcTLSCACertificateFile: /etc/ssl/certs/cacert.pem - pievienot: olcTLSCertificateFile olcTLSCertificateFile: /etc/ssl/certs/mildap-cert.pem / pievienot / privateKc /mildap-key.pem

8.- Pievienot: ~ # ldapmodify -Y ĀRĒJS -H ldapi: /// -f /etc/ssl/certinfo.ldif

9.- Mēs pielāgojam īpašnieku un atļaujas
: ~ # adduser openldap ssl-cert: ~ # chgrp ssl-cert /etc/ssl/private/mildap-key.pem: ~ # chmod g + r /etc/ssl/private/mildap-key.pem: ~ # chmod vai /etc/ssl/private/mildap-key.pem

Sertifikāts cacert.pem Tas ir tas, kas mums jākopē katrā klientā. Lai šo sertifikātu varētu izmantot pašā serverī, mums tas jādeklarē failā /etc/ldap/ldap.conf. Lai to izdarītu, mēs modificējam failu un atstājam to ar šādu saturu:

: ~ # nano /etc/ldap/ldap.conf
PAMATOT dc = draugi, dc = cu URI ldap: //mildap.amigos.cu TLS_CACERT /etc/ssl/certs/cacert.pem

Visbeidzot un arī kā pārbaudi mēs restartējam pakalpojumu iepļaukāt un mēs pārbaudām syslog no servera, lai uzzinātu, vai pakalpojums tika restartēts pareizi, izmantojot nesen deklarēto sertifikātu.

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

Ja pakalpojums netiek restartēts pareizi vai novērojam nopietnu kļūdu syslog, neuzdrošināsimies. Mēs varam mēģināt novērst bojājumus vai sākt no jauna. Ja mēs nolemjam sākt no jauna, instalējiet iepļaukāt, nav nepieciešams formatēt mūsu serveri.

Lai izdzēstu visu, ko līdz šim esam izdarījuši viena vai otra iemesla dēļ, mums jāinstalē pakotne iepļaukātun pēc tam izdzēsiet mapi / var / lib / ldap. Mums arī jāatstāj fails tā sākotnējā versijā /etc/ldap/ldap.conf.

Reti kas ar pirmo mēģinājumu darbojas pareizi. 🙂

Atcerieties, ka nākamajā maksājumā mēs redzēsim:

  • Vietējā lietotāja autentifikācija
  • Aizpildiet datu bāzi
  • Pārvaldiet datu bāzi, izmantojot konsoles utilītprogrammas
  • Līdzšinējais kopsavilkums ...

Uz drīzu tikšanos, draugi !.


Raksta saturs atbilst mūsu principiem redakcijas ētika. Lai ziņotu par kļūdu, noklikšķiniet uz šeit.

19 komentāri, atstājiet savus

Atstājiet savu komentāru

Jūsu e-pasta adrese netiks publicēta. Obligātie lauki ir atzīmēti ar *

*

*

  1. Atbildīgais par datiem: Migels Ángels Gatóns
  2. Datu mērķis: SPAM kontrole, komentāru pārvaldība.
  3. Legitimācija: jūsu piekrišana
  4. Datu paziņošana: Dati netiks paziņoti trešām personām, izņemot juridiskus pienākumus.
  5. Datu glabāšana: datu bāze, ko mitina Occentus Networks (ES)
  6. Tiesības: jebkurā laikā varat ierobežot, atjaunot un dzēst savu informāciju.

  1.   Hugo teica

    Skolotājs !!!
    TAS NOTIKA AR TUTO!
    ir izcils
    visi jums patīk PASAULES.
    ????

    1.    Federico teica

      Liels paldies, Hugo !!! Gaidiet nākamos rakstus par šo tēmu.

  2.   šis vārds ir nepareizs teica

    Sveiki

    interesanta jūsu rakstu sērija.

    Es biju pārsteigts, lasot šo paziņojumu: "Mūsdienu OpenLDAP serveri dod priekšroku StartTLS vai Start a Secure Transport Layer lietošanai, nevis vecajam TLS / SSL protokolam, kas ir novecojis."

    Vai jūs apgalvojat, ka visos gadījumos, pat ārpus LDAP darbības jomas, STARTTLS ir aizsardzības mehānisms, kas ir pārāks par TSL / SSL?

    1.    Federico teica

      Paldies par komentāru. Ņemiet vērā, ka es domāju OpenLDAP. Es nepārsniedzu. In http://www.openldap.org/faq/data/cache/185.html, varat izlasīt sekojošo:

      Transporta slāņa drošība (TLS) ir drošā ligzdas slāņa (SSL) standarta nosaukums. Termini (ja vien tie nav kvalificēti ar konkrētiem versiju numuriem) parasti ir savstarpēji aizstājami.

      StartTLS ir standarta LDAP operācijas nosaukums TLS / SSL iniciēšanai. TLS / SSL tiek uzsākts, veiksmīgi pabeidzot šo LDAP darbību. Alternatīva osta nav nepieciešama. Dažreiz to dēvē par TLS jaunināšanas darbību, jo tā jaunina parasto LDAP savienojumu ar tādu, kuru aizsargā TLS / SSL.

      ldaps: // un LDAPS attiecas uz “LDAP over TLS / SSL” vai “LDAP Secured”. TLS / SSL tiek aktivizēts, izveidojot savienojumu ar alternatīvu portu (parasti 636). Lai arī LDAPS ports (636) ir reģistrēts šai lietošanai, informācija par TLS / SSL iniciēšanas mehānismu nav standartizēta.

      Pēc uzsākšanas nav atšķirības starp ldaps: // un StartTLS. Viņiem ir vienādas konfigurācijas opcijas (izņemot ldaps: // nepieciešama atsevišķa klausītāja konfigurēšana, skatiet slapd (8) s -h opciju), kā rezultātā tiek izveidoti līdzīgi drošības pakalpojumi.
      Piezīme:
      1) ldap: // + StartTLS jāvirza uz parasto LDAP portu (parasti 389), nevis uz ldaps: // portu.
      2) ldaps: // jānovirza uz LDAPS portu (parasti 636), nevis uz LDAP portu.

      1.    šis vārds ir nepareizs teica

        Atvainojiet, bet man joprojām nav skaidrs, kāpēc jūs apgalvojat, ka: 1) mūsdienu serveri dod priekšroku STARTTLS, nevis SSL / TLS; 2) ka STARTTLS ir mūsdienīgs, salīdzinājumā ar SSL / TLS, kas ir novecojis.

        Es pusmēnesi cīnījos ar dažādu pasta klientu konfigurāciju, kuri piekļūst serverim, izmantojot SSL (izmantojot openssl bibliotēkas, kā to dara lielākā daļa bezmaksas programmatūras), ar CA sertifikātiem mapē / etc / ssl / certs / un citiem piederumiem. Un to, ko esmu iemācījies, ir: 1) STARTTLS šifrē tikai sesijas autentifikāciju, un viss pārējais tiek sūtīts nešifrēts; 2) SSL šifrē pilnīgi visu sesijas saturu. Tāpēc nekādā gadījumā STARTTLS nav tehniski pārāks par SSL; Es labāk gribētu domāt pretēji, jo jūsu sesijas saturs tīklā pārvietojas nešifrēts.

        Vēl viena atšķirīga lieta ir tā, ka STARTTLS ir ieteicams citu iemeslu dēļ, kurus es nezinu: lai nodrošinātu saderību ar MSWindows, jo ieviešana ir stabilāka vai labāk pārbaudīta ... Es nezinu. Tāpēc es jums jautāju.

        No rokasgrāmatas citāta, kuru esat man pievienojis atbildē, es redzu, ka atšķirība starp ldap: // un ldaps: // ir līdzvērtīga atšķirībai starp imap: // un imaps: // vai starp smtp: // smtps: //: tiek izmantots cits ports, konfigurācijas failā tiek pievienots papildu ieraksts, bet pārējie parametri tiek saglabāti. Bet tas neko neliecina par priekšroku STARTTLS vai nē.

        Sveiciens, un atvainojos par atbildi. Es tikai cenšos uzzināt nedaudz vairāk.

        1.    Federico teica

          Paskaties, tas ir ļoti reti, ka savos rakstos es apgalvoju šāda kalibra prasības, ja mani neatbalsta kāda nopietna publikācija. Sērijas beigās es iekļaušu visas saites uz dokumentāciju, kuru es uzskatu par nopietnu un kuru esmu konsultējies, lai rakstītu ziņu. Es jums virzu šādas saites:

          https://wiki.debian.org/LDAP/OpenLDAPSetup
          Ubuntu servera rokasgrāmata https://code.launchpad.net/serverguide
          OpenLDAP-Oficiālais http://www.openldap.org/doc/admin24/index.html
          LDAP, izmantojot SSL / TLS un StartTLS http://tt4cs.wordpress.com/2014/01/18/ldap-over-ssltls-and-starttls/

          Turklāt es iepazinos ar pievienoto dokumentāciju, kas ir uzstādīta katrā paketē.

          Drošības jautājums kopumā un atšķirības starp StartTLS un TLS / SSL ir ļoti tehniskas un tik dziļas, ka neuzskatu, ka man būtu nepieciešamās zināšanas šādu paskaidrojumu sniegšanai. Es domāju, ka mēs varam turpināt sarunu pa e-pastu.

          Turklāt nekur es nenorādu, ka LDAPS: // nevar izmantot. Ja jūs to uzskatāt par drošāku, tad uz priekšu !!!

          Es vairs nevaru jums palīdzēt, un es ļoti novērtēju jūsu komentārus.

        2.    Federico teica

          Nedaudz vairāk skaidrības, ko vienmēr varat iegūt par OpenLDAP:
          http://www.openldap.org/faq/data/cache/605.html

          StartTLS paplašinātā darbība [RFC 2830] ir LDAPv3 standarta mehānisms, lai iespējotu TLS (SSL) datu konfidencialitātes aizsardzību. Mehānisms izmanto paplašinātu LDAPv3 darbību, lai izveidotu šifrētu SSL / TLS savienojumu jau izveidotā LDAP savienojumā. Kaut arī mehānisms ir paredzēts lietošanai kopā ar TLSv1, nepieciešamības gadījumā lielākā daļa ieviešanu tiks pakļauti SSLv3 (un SSLv2).

          ldaps: // ir mehānisms šifrēta SSL / TLS savienojuma izveidošanai LDAP. Tam ir nepieciešams izmantot atsevišķu portu, parasti 636. Lai gan sākotnēji tas bija paredzēts lietošanai kopā ar LDAPv2 un SSLv2, daudzas ieviešanas atbalsta tā izmantošanu ar LDAPv3 un TLSv1. Lai gan ldaps: // nav tehniskās specifikācijas: // tā tiek plaši izmantota.

          ldaps: // ir novecojis par labu Start TLS [RFC2830]. OpenLDAP 2.0 atbalsta abus.
          Drošības apsvērumu dēļ serveris ir jākonfigurē tā, lai tas nepieņemtu SSLv2.

  3.   freebsddick teica

    Šis būs viens no rakstiem, kurā lietotāji nekomentēs, jo, tā kā viņi pornogrāfiju skatās tikai savās Linux stacijās, viņus vienkārši neinteresē.Par ldap man ir vairāki saistīti pakalpojumi neviendabīgā tīkla ietvaros uzņēmumam, kurā strādāju. Labs raksts !!

    1.    Federico teica

      Paldies par komentāru !!!. Un jūsu apgalvojums ir ļoti patiess attiecībā uz dažiem komentāriem daudzos manos rakstos. Tomēr es saņemu korespondenci no ieinteresētiem lasītājiem vai citiem, kas lejupielādē rakstu vēlākai lasīšanai un lietošanai.

      Vienmēr ir ļoti noderīgi saņemt atsauksmes, izmantojot komentārus, pat ja tie ir: es to saglabāju vēlākai lasīšanai, interesantam vai citam viedoklim.

      Sveicieni

  4.   Federico teica

    The Freeke !!! Paldies par komentāru. Es saņēmu jūsu komentāru pa pastu, bet es to neredzu, lai gan es atsvaidzinu lapu vairākas reizes. Draugs, jūs varat pārbaudīt šo un iepriekšējos rakstus bez problēmām vietnē Squeeze vai Ubuntu Server 12.04. Wheezy sertifikāti tiek ģenerēti atšķirīgi, izmantojot OpenSSL. Bet neko. Ar cieņu, brāli !!!.

  5.   Federico teica

    @thisnameisfalse: Labākais ierēdnis ir izplūdis. Pateicoties jūsu komentāriem, es domāju, ka attiecīgajai rindkopai jābūt šādai:

    Mūsdienu OpenLDAP serveri dod priekšroku StartTLS vai Start a Secure Transport Layer lietošanai, nevis LDAPS: // protokolam, kas ir novecojis. Ja jums ir kādi jautājumi, apmeklējiet vietni Start TLS v. ldaps: // lv http://www.openldap.org/faq/data/cache/605.html

    Sveicieni

  6.   Hosē Monge teica

    Ideāli, šobrīd man ir mājas darbi uz ldap

  7.   Walter teica

    Jūs nevarat visu ievietot vienā failā, lai jūs varētu lejupielādēt pilnu apmācību

  8.   EVER teica

    Es esmu datortehniķis ar lielu pieredzi Linux, un man joprojām pietrūka raksta vidusdaļas. Tad es to rūpīgāk pārlasīšu. Liels paldies par apmācību.
    Lai gan ir taisnība, ka tas ļauj mums daudz vairāk saprast, kāpēc šīm lietām parasti tiek izvēlēts ActiveDirectory. Konfigurācijas un ieviešanas vienkāršības ziņā pastāv atšķirības.
    Sveicieni

  9.   Federico teica

    Paldies visiem par komentāriem !!!
    @ jose monge, es ceru, ka tas tev palīdzēs
    @walter visu ierakstu beigās redzēšu, vai varu sastādīt apkopojumu html vai pdf formātā
    @eVeR otrādi, OpenLDAP ir vienkāršāks - pat ja tas nešķiet kā Active Directory. pagaidi nākamos rakstus un redzēsi.

  10.   Marcelo teica

    Vaicājums: Es veicu instalēšanu soli pa solim, bet, restartējot slapd pakalpojumu, tas man rada šādu kļūdu>

    30. jūlijs 15:27:37 xxxx slapd [1219]: @ (#) $ OpenLDAP: slapd (Ubuntu) (17. gada 2014. marts 21:20:08) $ # 012 # 011buildd @ aatxe: /build/buildd/openldap-2.4.31 .XNUMX / debian / build / serveriem / slapd
    30. jūlijs 15:27:37 xxxxx slapd [1219]: Ievietots nezināms atribūts Apraksts "CHANGETYPE".
    30. jūlijs 15:27:37 xxxxx slapd [1219]: Nezināms atribūts Apraksts "ADD" ir ievietots.
    30. jūlijs 15:27:37 xxxxx [1219]: <= str2entry: slap_str2undef_ad (-): tukšs AttributeDescription
    30. jūlijs 15:27:37 xxxxx slapd [1219]: slapd apstājās.
    30. jūlijs 15:27:37 xxxxx [1219]: savienojumi_iznīcināt: nav ko iznīcināt.

    1.    x11tete11x teica

      varat pajautāt forumā 😀 http://foro.desdelinux.net/

  11.   pedrops teica

    Visiem, kas redz šo lielisko un labi izskaidroto ziņu, un šī problēma rodas, veidojot ACL:
    ldapmodify: nederīgs formāts (5. rinda) ieraksts: "olcDatabase = {1} hdb, dc = config"

    Pēc tam, kad esmu meklējis galvu, meklējot internetu, izrādās, ka ldapmodify ir visprecīzākais veids, kas atrodas tīmeklī. Tas ir histēriski ar nepareizām rakstzīmēm, kā arī ar atstarpēm. Bez papildu domām ieteicams rakstīt blakus nosacījumu pēc nosacījuma vai X rakstīt pats, rakstot * lasīt. Ja tas joprojām nedarbojas, instalējiet Notepad ++> Skats> Rādīt simbolu un visbeidzot nāvi neredzamām rakstzīmēm. Es ceru, ka kāds palīdzēs.

  12.   pedrops teica

    Ģenerējiet Debian Wheezy sertifikātus, pamatojoties uz OpenSSL, ko tas var izmantot:
    http://blog.phenobarbital.info/2014/10/openldap-tlsssl-configuracion-basica-y-aseguramiento/