AtNotes Übersicht Willkommen Gast. Bitte einloggen oder registrieren.
17.10.21 - 09:26:57
Übersicht Hilfe Regeln Glossar Suche Einloggen Registrieren
News:
Schnellsuche:
+  Das Notes Forum
|-+  Domino 9 und frühere Versionen
| |-+  ND9: Administration & Userprobleme (Moderatoren: Axel, Thomas Schulte, koehlerbv)
| | |-+  Directory Assistance mit AD und SSL: Verify klappt, aber sonst nix
« vorheriges nächstes »
Seiten: [1] Nach unten Drucken
Autor Thema: Directory Assistance mit AD und SSL: Verify klappt, aber sonst nix  (Gelesen 2807 mal)
Tode
Moderatoren
Gold Platin u.s.w. member:)
*****
Offline Offline

Geschlecht: Männlich
Beiträge: 6632


Geht nicht, gibt's (fast) nicht... *g*


WWW
« am: 11.12.19 - 14:44:17 »

Wir versuchen hier gerade einen Domino an einen Domain Controller 2019 mit aktiviertem SSL anzubinden:

Wir haben folgendes gemacht:

- keyring auf dem Domino eingerichtet
- Root und Intermediate der internen CA, die das AD- Server- Zertifikat ausgestellt hat in cacert und Adressbuch als "Vertrauenswürdig" importiert
- Directory Assictance mit Authentication eingerichtet.
- aktivierte Cipher zwischen AD und Domino abgeglichen, zusätzliche Cipher auf Domino aktiviert.

Ein Klick auf "Verify" in der DA startet ja einen Server- Agenten, der die Verbindung prüft und liefert "OK" zurück.
Sobald ich die Konfig aber abspeichere, taucht der Eintrag nicht in der DA auf. Auf dem Domain Controller sind meine erfolgreichen Tests mit "Verify" im log sichtbar, die Versuche der DA selbst aber nicht.

Wie kann ich das Debuggen?

Domino ist 9.0.1FP10 HF265
Gespeichert

Gruss
Torsten (Tode)

P.S.: Da mein Nickname immer mal wieder für Verwirrung sorgt: Tode hat NICHTS mit Tod zu tun. So klingt es einfach, wenn ein 2- Jähriger versucht "Torsten" zu sagen...

Mit jedem Tag meines Lebens erhöht sich zwangsweise die Zahl derer...
... denen ich am AdminCamp ein Bier schulde... Wenn ich hier jemanden angehe: Das ist nie persönlich, sondern immer gegen die "Sparwut" der Firmen gedacht, die ungeschultes Personal in die Administration unternehmenskritischer Systeme werfen... Sprecht mich einfach am AdminCamp an, ich zahle gerne zur "Wiedergutmachung" das ein oder andere Bierchen an der Bar
Pfefferminz-T
Gold Platin u.s.w. member:)
*****
Offline Offline

Beiträge: 1174


« Antworten #1 am: 12.12.19 - 08:40:33 »

Wie meinst Du "taucht der Eintrag nicht in der DA auf"? In der da selbst oder bei show xdir? Was sagt show xdir debug?
Gespeichert

Grüsse,
Thorsten
Tode
Moderatoren
Gold Platin u.s.w. member:)
*****
Offline Offline

Geschlecht: Männlich
Beiträge: 6632


Geht nicht, gibt's (fast) nicht... *g*


WWW
« Antworten #2 am: 12.12.19 - 10:35:18 »

show xdir und show xdir reload bringen nichts, sh xdir debug kannte ich tatsächlich noch nicht. Es taucht in der Konsole sporadisch die Meldung auf, dass er den Server ad.domain.de:443 nicht kontaktieren könnte und keine Alternative vorhanden wäre.

Nun... werde ich dem Admin mal sh xdir debug übermitteln... und der soll mir den Output sagen... ansonsten muss das bis zum nächsten Vor- Ort- Termin wartten: mit dem "alten" Domain- Controller ohne SSL geht es ja noch, und der wird erst im Februar abgeschaltet (sobald MS LDAP ohne SSL wie angekündigt abschaltet)
Gespeichert

Gruss
Torsten (Tode)

P.S.: Da mein Nickname immer mal wieder für Verwirrung sorgt: Tode hat NICHTS mit Tod zu tun. So klingt es einfach, wenn ein 2- Jähriger versucht "Torsten" zu sagen...

Mit jedem Tag meines Lebens erhöht sich zwangsweise die Zahl derer...
... denen ich am AdminCamp ein Bier schulde... Wenn ich hier jemanden angehe: Das ist nie persönlich, sondern immer gegen die "Sparwut" der Firmen gedacht, die ungeschultes Personal in die Administration unternehmenskritischer Systeme werfen... Sprecht mich einfach am AdminCamp an, ich zahle gerne zur "Wiedergutmachung" das ein oder andere Bierchen an der Bar
THX
Frischling
*
Offline Offline

Beiträge: 1


« Antworten #3 am: 03.02.20 - 11:16:15 »

Hallo zusammen und in die Runde  Wink


Ich stehe auch gerade vor diesem Problem und habe auch die gleichen Schritte, wie Torsten (Tode) unternommen.
Verify im DA Dokument (GUI) ergibt ein "Success" aber wenn ich das DA Dokument aktiviere erscheint der Eintrag nicht bei der Anzeige mit sh xdir. Wenn ich das DA Dokument umstelle auf Port 389 (ohne SSL) geht, LDAP Daten werden übertragen und es wird auch bei sh xdir angezeigt.

Ich habe mir den SSL Verbindungsversuch per WireShark angeschaut und es kommt auch eine Verbindung per Port 636 mit dem AD Server zustande aber es werden irgendwie dann keine LDAP Daten übertragen.

Mit erhöhtem Loglevel ist dann noch Das in der Console zu sehen (Ende SSL Handshake):
...
...
03.02.2020 11:01:09,01 SSL_Handshake> TLS/SSL Handshake completed successfully
03.02.2020 11:01:09,01 int_MapSSLError> Mapping SSL error 0 to 0 [SSLNoErr]

...und wiederholt sich dann ständig

sh xdir debug habe ich auch probiert, hat aber leider keine wirklichen verwertbaren Ergebnisse geliefert.

In der Console/Log wird folgendes, oft nur nach Neustart des Servers, angezeigt: Error attempting to access the Directory *ad.domain.tld:636 (no available alternatives),  error is LDAP Server is NOT available.

Ach ja bei mir ist es allerdings ein IBM/HCL Domino 10.0.1FP2. Da ich das aber auch noch für andere Server mit 9.0.1FP10 benötige ist die Basis im Prinzip auch gleich.

Evtl. habt ihr ja noch Hinweise, wo ich noch suchen oder was ich noch ausprobieren kann.
Gespeichert

Grüße

Torsten
Günther Rupitz
Senior Mitglied
****
Offline Offline

Geschlecht: Männlich
Beiträge: 359



« Antworten #4 am: 16.04.20 - 18:53:22 »

Grüße Euch

Ich habe vielleicht ein ähnliches Problem.

Ich hatte unter Domino 9.0.1 schon DA mit LDAP nach ActiveDirectory mit SSL im Einsatz, durch SAML wurde es aber obsolet.
Nun wollen wir es unter Domino 10.0.1 FP4 aber wieder einsetzen.

Wenn ich im entsprechenden DA-Dokument nicht über SSL gehe funktioniert alles so wie es soll, wenn ich jedoch SSL aktiviere schlägt die Verifikation jedoch fehl (alle 3 Buttons).
Wenn ich mit Debug_Directory_Assistance=1 das logging aufdrehe bekomme ich aber auch keine Fehlermeldung.

sh xdir zeigt das das Verzeichnis korrekt an.

Als erstes habe ich natürlich das AD-Rootzertifikat ins Domino kyr File importiert, damit erhalte ich auf der Konsole keine SSL Zertifikatsfehler mehr, hier ein Auszug:

[207C:0008-05FC] 16.04.2020 18:23:42,76 SSL_Handshake> Protocol Version = TLS1.2 (0x303)
[207C:0008-05FC] 16.04.2020 18:23:42,76 SSL_Handshake> Cipher = ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xC028)
[207C:0008-05FC] 16.04.2020 18:23:42,76 SSL_Handshake> KeySize = 256 bits
[207C:0008-05FC] 16.04.2020 18:23:42,76 SSL_Handshake> Ephemeral Elliptic Curve = NIST P-256 (23)
[207C:0008-05FC] 16.04.2020 18:23:42,76 SSL_Handshake> Using Extended Master Secret from RFC 7627
[207C:0008-05FC] 16.04.2020 18:23:42,76 SSL_Handshake> TLS/SSL Handshake completed successfully

Kann es sein, dass hier der Verifikationsprozess ein Problem hat?
Wie kann ich noch testen ob die LDAP Abfrage tatsächlich funktioniert?

Danke.
Günther
Gespeichert
Deragon
Frischling
*
Offline Offline

Geschlecht: Männlich
Beiträge: 15



WWW
« Antworten #5 am: 13.08.20 - 09:41:16 »

Dumme Frage: Hatte jemand von euch zwischenzeitlich Erfolg? Hier (bei einem Kunden) das gleiche Problem - zumindest ungefähr.  ;-)

Wir haben einen OpenLDAP-Server als LDAP-Proxy dazwischen geschaltet. Domino wird über ein LDAP-Dokument in der DA angetragen, Verbindung mit dem OpenLDAP-Server aufzunehmen (läuft lokal auf der gleichen VM, Kontakt über 127.0.0.1), dieser macht dann TLS-geschützt die Anfrage an das AD.
Testanfragen mit Softerra LDAP Browser und ldapsearch (cygwin, nicht Domino) gegen den OpenLDAP-Proxy funktionieren.
Alle Verify-Buttons im LDAP-Dokument der DA auch.
Auf einem Test-Server und einem produktiven Domino-Server läuft es wie geschmiert.
Aber auf einem, auch wichtigen anderen Domino-Server erscheint das LDAP-Verzeichnis beim show xdir (reload) nicht in der Tabelle.
Das LDAP-Verzeichnis hat den ersten Platz in der Suchreihenfolge.
Dementsprechend wird das OpenLDAP auch gar nicht erst gefragt.
Domino 9.0.1FP10 mit HF. Alle Domino-Server sind gleichartig installiert.

Die "Ich kann keinen Kontakt aufnehmen zu LDAP-Server XYZ"-Meldung bekomme ich auch, z. B. wenn ich mich versuche, mit Windows-Benutzer-Credentials anzumelden:
12.08.2020 12:39:05   nHTTP: BenutzerName [xx.xx.xx.xx] authentication failure using internet password
...
12.08.2020 12:39:20   Error attempting to access the Directory *[127.0.0.1]:9389 (no available alternatives),  error is LDAP Server is NOT available
« Letzte Änderung: 13.08.20 - 09:48:13 von Deragon » Gespeichert
Günther Rupitz
Senior Mitglied
****
Offline Offline

Geschlecht: Männlich
Beiträge: 359



« Antworten #6 am: 17.08.20 - 13:24:04 »

Hallo

Bei unserem Problem ging es ausschliesslich um LDAPS Verbindungen.
Hier konnte HCL mittlerweile bestätigen, dass es sich um einen Bug im Template handelt (Buttons).

Es funktioniert nämlich, obwohl der Button einen Fehler meldet.

Günther
Gespeichert
Deragon
Frischling
*
Offline Offline

Geschlecht: Männlich
Beiträge: 15



WWW
« Antworten #7 am: 17.08.20 - 13:55:51 »

Update zu "meinem" Problem:
Domino-Server sagt, er könne den LDAP-Server unter 127.0.0.1 Port 9389 nicht erreichen.
LDAP-Server läuft und beantwortet Anfragen unter eben dieser IP-Adresse und Port, z. B. mit Softerra LDAP Browser oder ldapsearch (Cygwin, nicht Domino).
Im auf Maximum aufgedrehten Log des OpenLDAP-Servers erscheint KEIN Verbindungsversuch des Domino-Servers.
Gespeichert
renote
Frischling
*
Offline Offline

Geschlecht: Männlich
Beiträge: 2



« Antworten #8 am: 22.06.21 - 13:25:43 »

Hier hatte ich auch ein dickes Problem mit LDAPS (636) über ADS und Directory Assistance. Sechs Server konnte ich erfolgreich umstellen, nur einer wollte absolut nicht. Nun habe ich entdeckt, weshalb: Es ist ein Bug in der Serversoftware Domino. Werde einen entspr. BugReport an HCL senden... Verwendete Version: 9.0.1FP10, wird vermutlich aber auch in neueren Versionen noch vorhanden sein:

An dem Server, wo die LDAPS-Abfrage nicht funktionierte, war die Besonderheit, dass ich dort ein Web-Internetsite-Dokument habe (Form=WebSite). Demzufolge wird die Schlüsseldatei auch dort hinterlegt (Feld "SSLKeyFile"="keyfile_34_20.kyr"). HTTPS bei Aufruf der Seiten klappt natürlich, aber über DA eine LDAP-Abfrage über Port 636 nicht. Im Serverlog (console log) stand immer nur "LDAP Server is NOT responding".
Dann fiel mir auf, dass im Serverdokument dieses Servers (Form=Server), in dem Feld "HTTP_SSLKeyFile" der Eintrag "keyfile.kyr", also der default Eintrag vorhanden war. Weil für diesen Server eine Web-Internetsite existiert, ist dieser Eintrag im Serverdokument nicht mehr zu erreichen, man muss in dem Web-Internetsitedokument unter dem Tab Sicherheit - SSL-Optionen die Schlüsseldatei pflegen.

Daraufhin habe ich im Serverdokument das Feld "HTTP_SSLKeyFile" mit einem Agenten auf "keyfile_34_20.kyr" geändert, damit es mit der aktuellen Bezeichnung übereinstimmt. Was soll ich sagen? Die Verbindung hat funktioniert, alles gut.

Der Dominoserver unterscheidet also nicht, schaut bei Verwendung der Directory-Assistance nur im Serverdokument nach der zu verwendenden Schlüsseldatei.

Ich hoffe, dass ich mit dieser Info dem einen oder anderen einen wertvollen Hinweis geben konnte...

Die besten Grüße aus der Aachener Region, Ralf

Edith hat einen Schreibfehler behoben...
« Letzte Änderung: 22.06.21 - 13:57:45 von renote » Gespeichert

Gruesse Ralf - CLP 4...8 System Administration
DomAdm
Senior Mitglied
****
Offline Offline

Geschlecht: Männlich
Beiträge: 327

Ich liebe dieses Forum!


« Antworten #9 am: 22.06.21 - 13:56:08 »

Ich denke mal das ist hier beschrieben:
How to allow Directory Assistance to communicate with an external LDAP server using SSL encryption
https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0024955
Gespeichert

Jacob
renote
Frischling
*
Offline Offline

Geschlecht: Männlich
Beiträge: 2



« Antworten #10 am: 22.06.21 - 14:08:16 »

Ich denke mal das ist hier beschrieben:
How to allow Directory Assistance to communicate with an external LDAP server using SSL encryption
https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0024955

Ja, stimmt... allerdings scheint mit das doch ein Bug zu sein, denn das sollte automatisch synchronisiert werden, wenn man die Datei im Web-Sitedokument einträgt oder besser man muss den Dateinamen nur an einer Stelle pflegen, egal wie man Domino konfiguriert...
« Letzte Änderung: 22.06.21 - 14:14:33 von renote » Gespeichert

Gruesse Ralf - CLP 4...8 System Administration
Seiten: [1] Nach oben Drucken 
« vorheriges nächstes »
Gehe zu:  


Einloggen mit Benutzername, Passwort und Sitzungslänge

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2006, Simple Machines Prüfe XHTML 1.0 Prüfe CSS
Impressum Atnotes.de - Powered by Syslords Solutions - Datenschutz | Partner: