Hallo und schön, dass dieses Forum existiert! Danke @MLangguth!

Dank einiger Hinweise hier aus dem Forum habe ich heute ein Simpel-Setup mit o.g. KIM-Client initial zum Laufen gebracht (Senden und Empfangen), aber LDAP tut nicht. Jeder Versuch, auf das Adressbuch zuzugreifen, wird mit einem Fehler:

'Fehler $Id: Mit dem LDAP-Server "$s" kann keine Verbindung hergestellt werden...'

geahndet. Ja, die Variablen werden nicht ausgefüllt. MS halt...

Der Client Installer hat eine clientmodule.xml generiert, die bezüglich Ldap folgende Eigenschaften aufweist:

<Ldap>
                <AllowAnonymous>true</AllowAnonymous>
                <User/>
                <Password/>
                <!-- Ldap search by email base and scope -->
                <!-- Ldap search base dn, default is empty -->
                <BaseDn>dc=data,dc=vzd</BaseDn>
                <!-- Ldap search scope options are base, one, sub, default ist one -->
                <Scope>one</Scope>
                <Connection>
                    <Host>konnektor</Host>
                    <Port>636</Port>
                    <!-- Proxy Settings -->
                    <Proxy password="" user=""/>
                    <!-- Connect Timeout: default is 10 secs -->
                    <ConnectTimeout unit="sec">10</ConnectTimeout>
                    <!-- Read Timeout: default is 30 secs -->
                    <ReadTimeout unit="sec">30</ReadTimeout>
                    <!-- Currently Selected Authentication Mode. One of NONE, SRV -->
                    <AuthMode>SRV</AuthMode>
                    <SSLEnabledProtocols>TLSv1.2</SSLEnabledProtocols>
                    <!-- supported cipher suites -->
                    <CipherSuites>TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384</CipherSuites>
                    <!-- Client Key Store configuration with with Private key and password -->
                    <Keystore type="PKCS12"/>
                    <KeystorePassword/>
                    <KeyAlias>valid</KeyAlias>
                    <KeyPassword/>
                    <!-- verify truststore -->
                    <Truststore type="PKCS12">connector.p12</Truststore>
                    <TruststorePassword>ENC(Ützgül...=)</TruststorePassword>
                </Connection>
            </Ldap>
 
 

Ein paar Merkwürdigkeiten:

• Dies baut die Verbindung zum Konnektor auf, aber welche Authentifikation kommt hier zum Einsatz?
• Bedeutet das, der KIM Client ist neben POP3 und SMTP auch ein LDAP Proxy?
• Wenn ja, dann sollte das LDAP Adressbuch in Outlook doch auch auf localhost verwenden
• Wenn nein, warum wird dies hier aufgeführt, und was muß ich im Outlook Adressbuch verwenden?

<<Nutzer hat Beitrag gelöscht>>

Ich hänge mich mal an diesen Thread, denn neuerdings zeigt bei mir das KIM-Adressbuch nichts mehr an. Es ist wie o.g. konfiguriert (allerdings in Thunderbird), wenn man im Suchfeld etwas eingibt, erscheint.... nichts! LDAP_Admin als Test gibt die Meldung heraus: Server heruntergefahren.

<<Nutzer hat Beitrag gelöscht>>

Danke, das habe ich natürlich schon genau so probiert, aber ohne Erfolg.

Auch wenn hier der secunet-Konnektor im Einsatz ist, war ich zwischenzeitlich so verzweifelt, auch mal ins KoCoBox Manual reinzuschauen, und siehe da, da gibt es einen Hinweis, dass der LDAP Zugriff nur zertifikatbasiert funktioniert.

Also werde ich alles noch mal umbauen, und schauen...

<<Nutzer hat Beitrag gelöscht>>

Interessant, aber dann darf man bei secunet gar keine Kommunikationsverschlüsselung im internen Netz verwenden (und bekommt nette Hinweise auf das selbst zu tragende Risiko...).

<<Nutzer hat Beitrag gelöscht>>

Inzwischen kann ich wieder Adressen finden, es lag an der Thunderbird Version 91.xx. Man muss das Adressbuch unter Thunderbirds 78.xx anlegen und danach ein Update auf Thunderbirds 98.xx machen, dann geht es. So sagte und machte es der nette "DVO" von Visionmaxx.

Ich schliesse mich hier mal an. Auch ich habe das Problem, dass, wenn der Konnektor TLS-verschlüsselt ist, LDAP nicht mehr funktioniert.

Ich verwende die IP des Konnektors, Port ist 636 (Für LDAPS).

Benutzername ist der Name des Clients welchen ich beim Erstellen des Zertifikats durch den Konnektor ausgewählt habe. Das Passwort ist jenes, welches ich beim Herunterladen des Zertifikats in der KocoBox-Servicemanagementschnittstelle erhalten habe.

SSL ist angekreuzt, Suchbasis = "dc=data,dc=vzd".

Ich habe ein ähnliches Problem mit der Anbindung mit TLS, in meinem Fall mit Thunderbird (Bin inzwischen auch ohne Erfolg runter auf Version 78.10).

Interessanterweise funktioniert das Ganze, mit dem Softerra LDAP Browser, wie hier beschrieben "/t54f22-KIM-VDZ-LDAP-konfigurieren-und-suchen-fuer-Thunderbird-Claws-Mail.html#msg159", ohne Probleme. Mit TLS und ohne Authentifizierung.

Auf den ersten Blick sieht das für mich danach aus, als hätte Thunderbird ein Problem mit dem Konnektorzertifikat. Die Verbindung scheint nach der Aushandlung immer mit "Bad Certificate" abzubrechen. Das Konnektorzertifikat habe ich in Thunderbird aber eigentlich für den Port 636 als vertrauenswürdig eingestellt.

Es sieht so aus, dass die Fehlerbehebung vorgezogen wurde auf die Version 91.5.1.
Der Bug-Tracker wurde angepasst:
Bug Tracker Thunderbird zum LDAP-Problem

Da der Release-Pfad aktuell auf die 91.5.0 lautet, sind meine Hoffnungen groß, dass das Problem bald behoben ist.

Zitat von robertbeerwerth im Beitrag #12

---

...
Interessanterweise funktioniert das Ganze, mit dem Softerra LDAP Browser, wie hier beschrieben "/t54f22-KIM-VDZ-LDAP-konfigurieren-und-suchen-fuer-Thunderbird-Claws-Mail.html#msg159", ohne Probleme. Mit TLS und ohne Authentifizierung.

Auf den ersten Blick sieht das für mich danach aus, als hätte Thunderbird ein Problem mit dem Konnektorzertifikat. Die Verbindung scheint nach der Aushandlung immer mit "Bad Certificate" abzubrechen. Das Konnektorzertifikat habe ich in Thunderbird aber eigentlich für den Port 636 als vertrauenswürdig eingestellt.

---