[gelöst] LDAP Replication funktioniert nach LDAPS nicht mehr

[joe2017]

Weiß jemand wie die Replication zwischen zwei LDAP Servern abgefragt bzw neu angestoßen werden kann?

Anbei meine Vorgehensweise:
LDAP1
sudo nano /tmp/provider_sync.ldif

Code: Alles auswählen

# Add indexes to the frontend db.
dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcDbIndex
olcDbIndex: entryCSN eq
-
add: olcDbIndex
olcDbIndex: entryUUID eq

#Load the syncprov and accesslog modules.
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: syncprov
-
add: olcModuleLoad
olcModuleLoad: accesslog

# Accesslog database definitions
dn: olcDatabase={2}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {2}mdb
olcDbDirectory: /var/lib/ldap/accesslog
olcSuffix: cn=accesslog
olcRootDN: cn=admin,dc=local,dc=net
olcDbIndex: default eq
olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart

# Accesslog db syncprov.
dn: olcOverlay=syncprov,olcDatabase={2}mdb,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
olcSpNoPresent: TRUE
olcSpReloadHint: TRUE

# syncrepl Provider for primary db
dn: olcOverlay=syncprov,olcDatabase={1}mdb,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
olcSpNoPresent: TRUE

# accesslog overlay definitions for primary db
dn: olcOverlay=accesslog,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcAccessLogConfig
olcOverlay: accesslog
olcAccessLogDB: cn=accesslog
olcAccessLogOps: writes
olcAccessLogSuccess: TRUE
# scan the accesslog DB every day, and purge entries older than 7 days
olcAccessLogPurge: 07+00:00 01+00:00

sudo ldapadd -Q -Y EXTERNAL -H ldapi:/// -f /tmp/provider_sync.ldif

LDAP2
sudo nano /tmp/consumer_sync.ldif

Code: Alles auswählen

dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: syncprov

dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcDbIndex
olcDbIndex: entryUUID eq
-
add: olcSyncRepl
olcSyncRepl: rid=0 provider=ldap://LDAP1.local.net bindmethod=simple binddn="cn=admin,dc=local,dc=net"
  credentials=secretpassword searchbase="dc=local,dc=net" logbase="cn=accesslog"
  logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on
  type=refreshAndPersist retry="60 +" syncdata=accesslog
-
add: olcUpdateRef
olcUpdateRef: ldap://LDAP1.local.net

Meine Replication zwischen meinen beiden LDAP Servern hatte eigentlich funktioniert. Wenn ich den Status der beiden LDAP Server abfrage erhalte ich jetzt unterschiedliche Werte.

Code: Alles auswählen

ldapsearch -z1 -LLLQY EXTERNAL -H ldapi:/// -s base -b dc=local,dc=net contextCSN

LDAP1
dn: dc=local,dc=net
contextCSN: 20180702122323.909412Z#000000#000#000000

LDAP2
dn: dc=local,dc=net
contextCSN: 20180615100130.647912Z#000000#000#000000

Ich hab anschließend lediglich die Verschlüsselung (SSL) aktiviert. Hier hab ich selbstverständlich auch die Einträge in dem LDAP2 bearbeitet.
sudo nano /tmp/consumer_sync.ldif

Code: Alles auswählen

dn: olcDatabase={1}mdb,cn=config
replace: olcSyncRepl
olcSyncRepl: rid=0 provider=ldaps://LDAP1.local.net bindmethod=simple binddn="cn=admin,dc=local,dc=net" credentials=secretpassword searchbase="dc=local,dc=net" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on type=refreshAndPersist retry="60 +" syncdata=accesslog starttls=critical tls_reqcert=demand
-
replace: olcUpdateRef
olcUpdateRef: ldaps://LDAP1.local.net

sudo ldapadd -Q -Y EXTERNAL -H ldapi:/// -f /tmp/consumer_sync.ldif

Ich komm nicht ganz dahinter, weshalb die Replication nicht mehr funktioniert? Der folgende Befehl zeigt mir auch, dass diverse Inhalte fehlen.
sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b dc=local,dc=net dn

Gibt es einen Befehl um die Replication direkt noch einmal zu starten?

Was mich auch wunder... Folgender Befehl liefert mir eine Fehlermeldung. Funktioniert das mit ldaps:/// nicht?
ldapsearch -z1 -LLLQY EXTERNAL -H ldaps:/// -s base -b dc=local,dc=net contextCSN

Code: Alles auswählen

ldap_sasl_interactive_bind_s: Unknown authentication method (-6)
        additional info: SASL(-4): no mechanism available:

[joe2017]

Ich habe am LDAP2 wieder auf ldap:// gestellt und schon funktioniert es wieder?

sudo nano /tmp/consumer_sync_tls.ldif

Code: Alles auswählen

dn: olcDatabase={1}mdb,cn=config
replace: olcSyncRepl
olcSyncRepl: rid=0 provider=ldap://LDAP1.local.net bindmethod=simple binddn="cn=admin,dc=local,dc=net" credentials=secretpassword searchbase="dc=local,dc=net" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on type=refreshAndPersist retry="60 +" syncdata=accesslog starttls=critical tls_reqcert=demand
-
replace: olcUpdateRef
olcUpdateRef: ldap://LDAP1.local.net

Code: Alles auswählen

sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f /tmp/consumer_sync_tls.ldif
sudo systemctl restart slapd.service

Im Log stand folgendes:
cat /var/log/debug

Code: Alles auswählen

slap_client_connect: URI=ldaps://LDAP1.local.net Error, ldap_start_tls failed (1)

[habakug]

Hallo,

möglicherweise ist keine passende TLSCipherSuite vorhanden. Du brauchst dann etwa sowas:

Code: Alles auswählen

dn: cn=config
changetype: modify
replace: olcTLSCipherSuite
olcTLSCipherSuite: SECURE256:SECURE128:-VERS-SSL3.0:-VERS-TLS-ALL:+VERS-TLS1.2:+VERS-TLS1.1

Gruss, habakug

https://www.openldap.org/doc/admin24/tls.html

[joe2017]

Ich denke nicht, dass es daran liegt.

Mit meinem Client kann ich mich erfolgreich mit ldaps anmelden. Lediglich die Replication funtioniert mit ldaps nicht?

[joe2017]

Wenn ich folgendes eingebe erhalte ich ebenfalls eine Fehlermeldung.
ldapsearch -x -z 1 -ZZ -H ldaps://IP.local.net contextCSN -LLL

Code: Alles auswählen

ldap_start_tls: Can't contact LDAP server (-1)

Die Meldung errhalte ich auf beiden Servern. Das ist auch die Fehlermeldung aus dem Logfile /var/log/debug

[joe2017]

möglicherweise ist keine passende TLSCipherSuite vorhanden. Du brauchst dann etwa sowas:

Ich glaube du könntest evtl. doch recht damit haben. Meine Clients können sich zwar anmelden, jedoch hab ich auf dem LDAP auch den Kerberos Server installiert. Evtl. melden sich meine Clients gar nicht am LDAP Server sondern am Kerberos Server an. Wie kann ich die Verbindung von meinem Client prüfen?
Wobei wenn ich an meinem Cliente getent passwd eingebe, bekomme ich alle LDAP User gelistet. Somit steht die Verbindung eigentlich.

Und wie bringe ich die richtige TLSCipher in mein LDAP?
Ich habe folgende Zertifikate: ECDSA 384

[habakug]

Hallo,

Schau welche Ciphers vorliegen:

Code: Alles auswählen

$ openssl ciphers -v ALL | grep -i ecdsa
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
ECDHE-ECDSA-AES256-CCM8 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESCCM8(256) Mac=AEAD
ECDHE-ECDSA-AES256-CCM  TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESCCM(256) Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(128) Mac=AEAD
ECDHE-ECDSA-AES128-CCM8 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESCCM8(128) Mac=AEAD
ECDHE-ECDSA-AES128-CCM  TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESCCM(128) Mac=AEAD
ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA384
ECDHE-ECDSA-CAMELLIA256-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=Camellia(256) Mac=SHA384
ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(128)  Mac=SHA256
ECDHE-ECDSA-CAMELLIA128-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=Camellia(128) Mac=SHA256
ECDHE-ECDSA-AES256-SHA  TLSv1 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA1
ECDHE-ECDSA-AES128-SHA  TLSv1 Kx=ECDH     Au=ECDSA Enc=AES(128)  Mac=SHA1

Ändere den obigen Code :

Code: Alles auswählen

dn: cn=config
changetype: modify
replace: olcTLSCipherSuite
olcTLSCipherSuite: ECDHE-ECDSA-CAMELLIA256-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:!RC4:HIGH:!MD5:!EDH:!EXP:!SSLV2:!eNULL

Gruss, habakug

https://access.redhat.com/articles/1482663
https://access.redhat.com/articles/1474813

[joe2017]

Also ich hab schon mal den richtigen Cipher herausgefunden:

Code: Alles auswählen

ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(256) Mac=AEAD

Jedoch sieht dein Beispiel String etwas anders aus:

Code: Alles auswählen

ECDHE-ECDSA-CAMELLIA256-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:!RC4:HIGH:!MD5:!EDH:!EXP:!SSLV2:!eNULL

Bin mir jetzt nicht ganz sicher wie ich meinen Cipher eintragen soll?

Kann man sich die derzeit eingetragene olcTLSCipherSuite anzeigen lassen?

[joe2017]

Also ich hab jetzt folgendes herausgefunden. Wenn ich auf meinen beiden Servern nach einem User suche, bekomme ich diesen auch angezeigt.

Code: Alles auswählen

ldapsearch -x uid=user -H ldaps://LDAP1
ldapsearch -x uid=user -H ldaps://LDAP2

Das funktioniert beides auf beiden Servern.
Aber die Replication funktioniert noch immer nicht. Ich erhalte folgende Fehlermeldung im Log.

Code: Alles auswählen

slap_client_connect: URI=ldaps://LDAP1.local.net:636 Error, ldap_start_tls failed (1)

[joe2017]

Hat hier vielleicht noch jemand eine Idee? Keine Ahnung an was das liegt?

LDAP"S" funktioniert ja eigentlich. Meine Clients melden sich auch so an. Lediglich die Replication geht nicht?

[eggy]

Vielleicht ne Firewall irgendwo zwischen/auf den beiden Kisten, die nur den normalen ldap-Port und nicht den ldaps durchlässt?

[joe2017]

Das ganze ist aktuell nur in einem Testnetz aufgebaut. Hier existiert keine Hardware Firewall. Die interne Debian Firewall habe ich derzeit auch noch nicht aktiv.
Ist schon alles sehr seltsam. Warum kann ein Client sich mit LDAPS anmelden, und bei der REPL bekomme ich ein SSL Fehler?

[joe2017]

Also ich habe das ganze jetzt noch einmal neu aufgesetzt.

Auch hier funktioniert die Replication nicht mit LDAP'S'
Anbei meine Config:

Code: Alles auswählen

dn: olcDatabase={1}mdb,cn=config
replace: olcSyncRepl
olcSyncRepl: rid=0 provider=ldaps://LDAPServer.domain.net bindmethod=simple binddn="cn=admin,dc=domain,dc=net" credentials=***** searchbase="dc=domain,dc=net" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on type=refreshAndPersist retry="60 +" syncdata=accesslog starttls=critical tls_reqcert=demand
-
replace: olcUpdateRef
olcUpdateRef: ldaps://LDAPServer.domain.net

ändere ich das ldaps in ldap funktioniert die Replication.

Code: Alles auswählen

dn: olcDatabase={1}mdb,cn=config
replace: olcSyncRepl
olcSyncRepl: rid=0 provider=ldap://LDAPServer.domain.net bindmethod=simple binddn="cn=admin,dc=domain,dc=net" credentials=***** searchbase="dc=domain,dc=net" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on type=refreshAndPersist retry="60 +" syncdata=accesslog starttls=critical tls_reqcert=demand
-
replace: olcUpdateRef
olcUpdateRef: ldap://LDAPServer.domain.net

die Fehlermeldung im Log ist folgende:

Code: Alles auswählen

slap_client_connect: URI=ldaps://LDAPServer.domain.net Error, ldap_start_tls failed (1)

Aber die Zertifikate sind korrekt, denn meine Clients können sich ja mit ldaps:// anmelden.
Was könnte hier der Fehler sein?

Meine Zertifikate sind ausschließlich SERVER Zertifikate. Benötige ich hierfür ein zusätzliches CLIENT Zertifikat?

[joe2017]

Ich habe in einem anderen Post gelesen, dass es mit dem Zertifikat ein Problem geben könnte, wenn es ein reines Server Zertifikat ist.
Ich habe jetzt sogar ein Zertifikat erstellt, welches Server und Client Zertifikat Informationen enthält. Jedoch habe ich immer noch die selbe Fehlermeldung.

openssl x509 -noout -text -in Zertifikat.crt.pem

Code: Alles auswählen

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 4108 (0x100c)
    Signature Algorithm: ecdsa-with-SHA384
        Issuer: *****************************
        Validity
            Not Before: Aug 22 14:46:40 2018 GMT
            Not After : Aug 21 14:46:40 2023 GMT
        Subject: *****************************
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (384 bit)
                pub:
                    *****************************
                ASN1 OID: secp384r1
                NIST CURVE: P-384
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            Netscape Cert Type:
                SSL Client, SSL Server
            Netscape Comment:
                OpenSSL Generated Server Cert
            X509v3 Subject Key Identifier:
                *****************************
            X509v3 Authority Key Identifier:
                keyid:*****************************
                DirName:*****************************
                serial:10:01

            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 CRL Distribution Points:

                Full Name:
                  URI:*****************************

            Authority Information Access:
                CA Issuers - URI:*****************************
                OCSP - URI:*****************************

    Signature Algorithm: ecdsa-with-SHA384
         *****************************

Unter Ubuntu lief die Replication mit einem reinen Server Zertifikat. Wo könnte ich noch suchen? Hat noch jemand eine Idee?

[joe2017]

Ich hab meinen Fehler gefunden. Ich hatte anscheinend ausversehen Zeilenumbrüche gelöscht und alles in eine Zeile geschrieben.

Hier das FALSCHE Config File

Code: Alles auswählen

dn: olcDatabase={1}mdb,cn=config
replace: olcSyncRepl
olcSyncRepl: rid=0 provider=ldaps://LDAP1.local.net bindmethod=simple binddn="cn=admin,dc=local,dc=net" credentials=secretpassword searchbase="dc=local,dc=net" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on type=refreshAndPersist retry="60 +" syncdata=accesslog starttls=critical tls_reqcert=demand
-
replace: olcUpdateRef
olcUpdateRef: ldaps://LDAP1.local.net

Hier das RICHTIGE Config File

Code: Alles auswählen

dn: olcDatabase={1}mdb,cn=config
replace: olcSyncRepl
olcSyncRepl: rid=0 provider=ldaps://LDAP1.local.net bindmethod=simple binddn="cn=admin,dc=local,dc=net"
  credentials=secretpassword searchbase="dc=local,dc=net" logbase="cn=accesslog"
  logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on
  type=refreshAndPersist retry="60 +" syncdata=accesslog
-
replace: olcUpdateRef
olcUpdateRef: ldaps://LDAP1.local.net

[hec_tech]

Soviel ich sehe hast du aber auch 2 Optionen entfernt:

starttls=critical tls_reqcert=demand

Die Frage ist was dadurch mit TLS passiert.

[joe2017]

Ohhh!!

Vielen Dank für den Tipp. Da hab ich wohl noch ein Fehler drin. Nach hinzufügen der Fehlenden Optionen funktioniert die Replikation wieder nicht.

Code: Alles auswählen

slap_client_connect: URI=ldaps://LDAP1.local.net Error, ldap_start_tls failed (1)

Ich muss hier noch mal alles checken. Ich geb auf jeden Fall noch mal eine Rückmeldung wenn ich den Fehler gefunden habe!

[joe2017]

Ich habe meine beiden LDAP Server noch einmal sauber aufgesetzt um evtl. Fehler zu vermeiden.
Ich habe von meinem SECONDARY LDAP immer noch die Fehlermeldung im LOG
/var/log/syslog

Code: Alles auswählen

slap_client_connect: URI=ldaps://LDAP1.local.net Error, ldap_start_tls failed (1)

Wenn ich jedoch folgendes abfrage, bekomme ich eine erfolgreiche Rückmeldung.

Code: Alles auswählen

ldapsearch -x -LLL -H ldaps:/// -b dc=local,dc=net dn | grep USER
ldapsearch -x -LLL -H ldaps://LDAP1.local.net contextCSN | grep USER

Das macht doch eigentlich keinen Sinn oder?

[joe2017]

Also irgendwie komme ich hier nicht so ganz weiter.
Ich habe von meinem Client (mit JXplorer) eine SSL (Port 636) Verbindung zu meinen beiden OpenLDAP Servern herstellen können.
Somit sind doch die Zertifikate auf meinen Servern kein Problem? Auch die LDAPS Verbindung sollte nicht das Problem sein.

In welchem Log bekomme ich noch genauere Informationen zu dem Fehler:

Code: Alles auswählen

slap_client_connect: URI=ldaps://LDAP1.local.net Error, ldap_start_tls failed (1)

[format_c]

Schon mal das Debug-Level des slapd erhöht das die Verbindung aufbauen möchte und fehlschlägt?

[joe2017]

Ich habe das Log Level jetzt mal auf "any" gesetzt um hier mehr zu erfahren. Ich erhalte jetzt zwar sehr viele Infos, jedoch am Ende wo die Verbindung aufgebaut wird, steht nicht viel.

Code: Alles auswählen

daemon: epoll: listen=8 active_threads=0 tvp=zero
daemon: epoll: listen=9 active_threads=0 tvp=zero
daemon: epoll: listen=10 active_threads=0 tvp=zero
daemon: epoll: listen=11 active_threads=0 tvp=zero
daemon: epoll: listen=12 active_threads=0 tvp=zero
=>do_syncrepl rid=000
slap_client_connect: URI=ldaps://LDAP1.local.net Error, ldap_start_tls failed (1)
daemon: activity on 1 descriptor
daemon: activity on:
Oct 25 09:26:53 LDAP2 slapd[487]:
daemon: epoll: listen=8 active_threads=0 tvp=zero
daemon: epoll: listen=9 active_threads=0 tvp=zero
daemon: epoll: listen=10 active_threads=0 tvp=zero
daemon: epoll: listen=11 active_threads=0 tvp=zero
daemon: epoll: listen=12 active_threads=0 tvp=zero
do_syncrepl: rid=000 rc 1 retrying

Zumindest nichts mit dem ich etwas anfangen könnte.

Nur mal so als Frage. Ich habe für beide LDAP Server ein Server Zertifikat was ich für die Replication verwende. Wird hier irgendwo noch ein Client Zertifikat benötigt?
Hier die Optionen von meinen Server Zertifikaten:

Code: Alles auswählen

basicConstraints = CA:FALSE
nsCertType = server
nsComment = "OpenSSL Generated Server Cert"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth

Ich habe mein CA Cert jetzt auch schon ausgetauscht. Am Anfang hatte ich hier das reine Intermediate Cert. Jetzt habe ich ein CHAIN Cert im Einsatz (Root CA & Intermediate CA). Ich dachte das an der Zertifikat Kette vielleicht etwas nicht gefunden wird.

Was mich auch etwas wundert. Auf folgender Webseite wird die gesamte Installation beschrieben. https://help.ubuntu.com/lts/serverguide ... erver.html
Unter dem Abschnitt "Replication and TLS" wird seltsamerweise in der "consumer_sync_tls.ldif" in der Option "provider" folgendes eingetragen: "ldap://ldap01.example.com"
Hier müsste doch eigentlich ldaps:// verwendet werden. Wenn ich anschließend in der Config "/etc/default/slapd" nur noch "SLAPD_SERVICES="ldaps:///"" erlaube, würde das nicht mehr funktionieren.

[format_c]

Hab nochmal ein bisschen geforscht.
Also LDAP ist dem SMTP Protokoll in Sachen TLS ziemlich ähnlich.
Es gibt 2 Arten eine TLS Verbindung aufzubauen:
Explizit an einen anderen Port (meist 636/tcp) verbinden und nach dem die TCP Sitzung aufgebaut ist, direkt mit dem TLS Handshake beginnen. Wenn der komplett ist, kann LDAP "gesprochen" werden, z.B. das binding was u.a. als Authentisieren dient.
Eine andere Vorgehensweise ist, dass der LDAP Client auf Port 389/tcp eine Verbindung aufbaut und mittels STARTTLS Kommando nun diese Klartext Verbindung auf eine verschlüsselte Verbindung "upgraded".

Die Frage die sich nun stellt: Was erwartet der Server? Was versucht der Client? Vielleicht passt das eine ja nicht auf das andere.
Ich würde mal

Code: Alles auswählen

netstat -tlnp

auf dem Server machen und mal ein Packet Capture anfertigen was zwischen den beiden Hosts passiert während es zu dem Fehler kommt.

P.S.
die Funktion ldap_start_tls(1) deutet darauf hin, dass der Client die STARTTLS Methode versucht. Der Return Code 1 entspricht LDAP_OPERATIONS_ERROR.

[joe2017]

Wenn ich in meiner Consumer Config wieder beides von ldaps:// auf ldap:// umstelle, wie kann ich dann prüfen ob eine TLS Verbindung aufgebaut wird? Gibt es hier vielleicht eine Möglichkeit? Vielleicht würde das ja auch passen. Dann würde die Beschreibung der Installation auch korrekt sein.

Code: Alles auswählen

dn: olcDatabase={1}mdb,cn=config
replace: olcSyncRepl
olcSyncRepl: rid=0 provider=ldap://LDAP1.local.net bindmethod=simple binddn="cn=admin,dc=local,dc=net"
  credentials=secret searchbase="dc=local,dc=net" logbase="cn=accesslog"
  logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on
  type=refreshAndPersist retry="60 +" syncdata=accesslog
  starttls=critical tls_reqcert=demand
-
replace: olcUpdateRef
olcUpdateRef: ldap://LDAP1.local.net

[format_c]

was wenn du die URI auf ldaps:// änderst und das starttls=critical weg lässt?

[joe2017]

Schönen guten Morgen und vielen Dank für den Tipp!

Ich hab jetzt alles wie folgt eingestellt und die Replication funktioniert einwandfrei.

Code: Alles auswählen

dn: olcDatabase={1}mdb,cn=config
replace: olcSyncRepl
olcSyncRepl: rid=0 provider=ldaps://LDAP1.local.net bindmethod=simple binddn="cn=admin,dc=local,dc=net"
  credentials=secret searchbase="dc=local,dc=net" logbase="cn=accesslog"
  logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on
  type=refreshAndPersist retry="60 +" syncdata=accesslog
  tls_reqcert=demand
-
replace: olcUpdateRef
olcUpdateRef: ldaps://LDAP1.local.net

sudo nano /etc/default/slapd

Code: Alles auswählen

SLAPD_SERVICES="ldaps:///"