Anmeldung schlägt fehl nach Update des Sametimeservers auf Version 11

[Ottmar]

Hallo liebes Forum

wir haben ein Notes 9 (als Registrierungsserver) im Einsatz. Dazu gibt es einen Sametimeserver (ganz früher mal Sametime 7, nach diversen Updates dann mal Sametime 10)
Bislang hat immer alles funktioniert. Kürzlich wurde der Sametimeserver auf Release 11 umgestellt. Da hat immer noch alles funktioniert. Jetzt stellen wir aber fest, dass alle neuen Anwender, die nach diesem Update registriert werden, sich nicht am Sametime anmelden können. (Benutzername oder Kennwort falsch)
Das Dominoverzeichnis wird aber korrekt repliziert.
An den Notes-Clients liegt es auch nicht (Es sind 10-er und 11-er Clients im Einsatz, die Anmeldung an Sametime funktioniert an jedem Client immer genau dann, wenn man sich mit den Daten eines Anwenders anmeldet, der vor dem Sametime-Serverupdate registriert wurde.

Hat jemand eine Idee?

[Patrick Schneider]

Hallo Ottmar,

wenn ihr Domino SSO für die Anmeldung verwendet, fehlt wahrscheinlich das Feld "HTTPPassword" im Personendokument von neu registrierten Usern.
Siehe https://support.hcltechsw.com/community?id=community_question&sys_id=6cf883b3db1d181055f38d6d13961970&anchor=answer_77e16d321baad098086dcbfc0a4bcb66

Workarounds um das Problem:
* Per Agent manuell oder periodisch das Feld einfügen, falls es nicht vorhanden ist
* Ein leeres Notes Internetpassword für die User eintragen
* Das HTTPPassword Feld aus einer 9er pubnames.ntf Schablone (Teilmaske $PersoninheritableSchema) in die gleiche Teilmaske in das v10/v11 Adressbuch kopieren, dann funktioniert es bei Usern, die nach der Änderung registriert werden.
* Auf den Fix warten:
https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0081483

Viele Grüße,
Patrick

[Ottmar]

Das Feld HTTPPasswort ist allerdings auf beiden Servern vorhanden.

Ich habe die Idee aber mal aufgegriffen und zwei Dokumente (ein neues, ein altes) mal feldweise miteinander verglichen. Mir ist aufgefallen, dass bei den neu registrierten Benutzern ein Feld "$SecurePassword" im Personendokument vorhanden ist, in den älteren aber nicht.

Ich werde hier noch ein paar Versuche durchführen und dann mal berichten

[CarstenH]

Das Feld $SecurePassword (mit dem Wert "1") zeigt lediglich an, dass das Kennwort im Feld HTTPPassword im sogenannten sicheren Format vorliegt. Das sieht dann in etwa so aus
"(SebBI00U7WXamvbsg9Np)".

Das ältere, weniger sichere Format, erzeugte bei gleichem Passwort auch immer gleiche Schlüssel, z.B. so etwas "(ABA3376BAFEDBB296AD4)" wodurch Brute-Force-Attacken offline mit einer simplen Adressbuchkopie und dem Aufruf von @Password() möglich waren.

Das Wissen hilft dir jetzt aber nichts bzw. ändert nichts an deinem Problem Ist denn das Feld HTTPPasswort bei den betreffenden Nutzern denn vorhanden und auch gefüllt? Bringt der Workaround "PW Reset" wie im HCL Support Dokument vorgeschlagen etwas?

HTH
Carsten

[Ottmar]

Zunächst erst einmal Danke an CarstenH für den Hinweis zur Bedeutung des Feldes $SecurePassword, wieder was gelernt. Darüber hinaus haben Tests auch gezeigt, dass das Feld $SecurePassword als Übeltäter auch ausgeschlossen werden kann.

Der Vorgang als solches ist leider noch ungelöst. An dem Feld HTTPPassword kann es nicht liegen, der Registrierungsserver ist noch vom Release 9 und auch das Dominoverzeichnis des Sametime-Servers basiert noch auf der 9-er-Schablone, im übrigen sind alle Felder da.

Ich denke auch nicht, dass es daran liegt, dass der Sametime-Server (Release 11) noch ein Release 9 Adressbuch hat, denn dann dürfte die Anmeldung ja bei niemanden funktionieren.

Ich habe heute mal weiter experimentiert, ein funktionierendes Personendokument genommen, kopiert, umbenannt in "Test User" und repliziert. Ergebnis:
Als Test User über das Web mit dem Internetkennwort anmelden (auf dem Registierungsserver) -> läuft.
Als Test User am Sametime-Server anmelden -> läuft nicht.

Insofern können Fehler im Personendokument meiner Meinung nach ausgeschlossen werden, aber gegenwärtig habe ich keine Idee, woran es sonst liegen könnte.

[Tode]

Gerade kam das FP2 für Sametime 11, das Probleme mit Sonderzeichen im Passwort behebt... vielleicht ist es ja das Passwort was dem Sametime nicht schmeckt.

[Ottmar]

Das Passwort ist ein einfaches Passwort ohne Sonderzeichen, daran kann es nicht liegen.
Zumal für den Testuser das selbe Passwort gilt, wie für dien ursprünglichen User, beim Kopieren des Personendokumentes wurden in der Dokumentenkopie außer der Name keine Daten geändert.

Unabhängig davon ist das Aufspielen eines Featurepacks immer eine gute Idee. Allerdings finde ich das Featurepack auf den HCL-Downloadseiten bis heute noch nicht. Hat da jemand einen Hinweis?

[Ottmar]

Nachtrag:

Die Installation des FP2 führte leider nicht zum Erfolg.
Vermutlich werde ich damit leben müssen, dass Registrierungsserver R9 und Sametimeserver R11 nicht kompatibel miteinander sind.

Oder gibt es irgend jemanden, der diese Kombination erfolgreich einsetzt?

[Ottmar]

Neuer Stand:

Ich habe irgendwo den Hinweis gefunden, dass für die Sametimeanmeldung auf dem Sametimeserver als Voraussetzung das Dominoverzeichnis in ODS-Version 53 vorliegen muss. Das war im vorliegenden Fall natürlich nicht so, das Dominoverzeichnis hatte noch die betagte ODS 43-er Einstellung.

So habe ich mir dann erklärt, dass das Update des Registrierungsservers auf Release 11, dass der Kunde vorgenommen hat, auch nichts geholfen hat.

Nun ergab sich allerdings ein ganz anderes Problem: Beide Release 11 Server lassen sich nicht davon überzeugen, Datenbanken in ODS53 anzulegen. Ein Eintrag "Create_R10_Databases=1" in den Server-notes.ini's ist vorhanden. Trotzdem legen beide Server neue DB's in ODS52 an. Frage: legt ein Release 11 Server neue Datenbanken "naturgemäß" (ohne Konfiguration) in ODS 43 oder ODS 52 an? Da habe ich jetzt auf die Schnelle keinen Hinweis zu gefunden. Wenn es - wie ich vermute - ODS 43 wäre, muss es irgendwo in den Innereien der Server-names noch einen "Create_R9_Databases" geben, der die Server-notes.ini aussticht.

Ich habe keine weiteren Notes.ini-Einträge in den Server-notes.ini's gefunden, die  was mit ODS Version zu tiun haben könnten. Auch im Serverkonfigurationsdokument ist diesbezüglich nichts konfiguriert und Richtliniendokumente hierzu gibt es auch nicht. Ist alles sehr merkwürdig.

Ich habe eine lokale Replik des Dominoverzeichnisses erstellt (ODS 53) und diese dann per Betriebssystemkopie auf dem Server übertragen. Jetzt ist das Dominoverzeichnis auf dem Sametimeserver zwar in ODS 53, die Aktion brachte aber leider keinen Erfolg. Anmeldung scheitert nach wie vor.

Trotzdem vermute ich, dass das Sametime-Anmeldeproblem mit dem ODS-Problem irgendwie zusammenhängt. Durch zahlreiche Versuche bin ich auch davon überzeugt, dass das Problem irgendwo an der oder in der Server-names.nsf zu suchen ist.

Ich habe noch ein paar Ideen und werde die Server-names.nsf demnächst mal weiter abklopfen. Wenn jemand konkrete Tipps hat, die nehme ich gerne.

[stoeps]

Also laut Doku https://help.hcltechsw.com/domino/10.0.1/wn_ods52_is_default.html ist ODS 52 der Default in Domino 10.

Eine Idee dazu: notes.ini über config-Doc oder direkt editiert? Leerzeile am Ende? Neugestartet?

Verstehe ich das richtig? Sametime mit Domino (nicht LDAP) Authentifizierung?

[kuabuab]

@Ottmar

Was verwendest du als Sametime Client?
Plugin im Notes, V11?
Fullclient, oder gar den Sametime Proxy mit der Weboberfläche?

Grundsätzlich, tue doch mal am Sametime Community Server das logging einschalten und dann die Logs nach Fehler durchforsten: https://help.hcltechsw.com/sametime/11.0.0/admin/enabling_logging_and_tracing_sametime_clients.html


- Daniel

[Tode]

Was sollte die ODS mit der Anmeldung zu tu haben? Das ist, als ob Du sagst: die Reifen sind schuld, dass Dein Schlüssel das Auto nicht starten kann.... „irgendwo im Netz den Hinweis“... bitte die Stelle hier posten.

Hier hilft nur: Logging hochdrehen und systematisch testen...

- geht anmeldne mit Internetkennwort allgemein
- geht es in der names.nsf auf dem Sametime Server
- geht es mit einem anderen User
- geht es mit einem anderen Passwort
- was sagt das Sametime Log wenn es nicht geht (Client und Server, wenn Du nicht den Browser verwendest, dann Server + Proxy)

U.s.w
U.s.w

[oliK]

Hier noch ein Tipp: in der Datenbank vpuserinfo.nsf gibt es eine Ansicht "users by name" oder so ähnlich.
Diese wird intern von Sametime genutzt, um Benutzerprofilinformationen abzurufen.
Hier musste ich nach einem Serverupdate tatsächlich mal per Notes-Client einsteigen und den Ansichtsindex über Refresh-Funktionen aktualisieren, da dieser neue Dokumente/Profile nicht automatisch angezeigt hat. Seitdem konnte er wieder automatisch den Index aktualisieren.

[MaVo]

Wie Tode es beschreibt ist es die richtige Vorgehensweise.

Ich würde an dem betroffenen Client mit einem Benutzer, der sich an ST anmelden kann, prüfen ob die Anmeldung funktioniert, um Probleme am Client auszuschließen.
Das Internetpasswort der betroffenen Benutzers nochmals im Personendokument setzen, um sicher zugehen, dass das PW korrekt abgespeichert ist.
Mit beiden Anmeldevarianten Mein Name/MeineFirma oder E-Mailadresse die Anmeldung durchführen.

Wenn das nicht hilft, dann helfen nur die Debugparameter an Client und Server.


Die vpuserinfo beinhaltet die Kontaktlisten der Benutzer und ist m.M. nicht für die Anmeldung zuständig.

[Ottmar]

Nachtrag zum Abschluss dieser Anfrage:

Es wurde ein Call bei HCL aufgemacht. Die konnten das Problem zunächst auch nicht lösen.
Mit Release 11.5 ist das aber gefixt.