Sametime 8.5 Community LDAP Anbindung

[DigitDani]

Das hier http://www-10.lotus.com/ldd/stforum.nsf/55c38d716d632d9b8525689b005ba1c0/4116b7cdee5bfaf28525758c004ba0aa?OpenDocument könnte auch noch hilfreich sein

Klasse, danke. Kannte ich auch noch nicht.

Das hier zu aktivieren "Use Cananoical name for instant messaging status lookup", hatte ich allerdings bereits versucht. Das brachte nicht die Lösung. Werde das aber noch mal ausführlich prüfen. Der Server defensive Fix von IBM passt zumindest weder zur Client noch zur Sametime Server Version.

[eknori]

Nach dem Hinzufügen von "displayname" zu den Authentifizierungsattributen kann ich mich jetzt sowohl mit First Last als auch mt First Last/Org anmelden.

[DigitDani]

Super, danke für die Info!

[eknori]

Auch die Suche über den Nachnamen funktioniert mit der Erweiterung des Suchstrings über die System Console

[hallo.dirk]

Hui hier gehts aber ab
Nun nochmal zusammenfassend für Anfänger (also für mich):

Genauso wie Daniel, hab ist das alles in der stconfig getestet. Zumal auch IBM der Meinung ist, dass hier die Quelle meine Probleme ist.....

Also so wie ich es verstanden hab, trage ich alles in in die WAS Console ein, richtig?

Was steht nun bei Euch in der Sametime Console genau drin?
Und wie sieht es in der stconfig.nsf aus?

Danke.

[DigitDani]

Hi Dirk,

im Prinzip ist es egal aber über die ST System Console ist es auf jeden Fall der saubere Weg. Bei mir siehts jetzt so aus wie auf dem Bild.
Am ST Console Server anmelden --> Sametime System Console --> Voraussetzungen für Sametime --> Verbindung zu LDAP-Server herstellen --> vorhandene Verbindung bearbeiten --> durcklicken bis zu Personeneinstellungen erfassen.

Die Authentifizierungsattribute sind bei mir jetzt:
mail;cn;uid;displayName

Die Suchattribute sind bei mir jetzt:
mail;cn;uid;sn;displayName

Den displayName bei der Suche will ich wegen dem Awarenessproblem in der MailDB testen. Ein Ergebnis habe ich noch nicht.

[eknori]

Sieht bei mir auch so aus, wie bei Daniel

im Prinzip ist es egal aber über die ST System Console ist es auf jeden Fall der saubere Weg.

Richtig, weil der String in der stconfig über diesen Weg aktualisiert wird. Umgekehrt siehst du in der Console die Änderungen nicht, die du in der stconfig gemacht hast. Dadurch ergeben sich Inkonsistenzen bei der Konfiguration ( oder zumindest bei der Dokumentation der Installation ).

Wichtig ist auch, dass mail immer zuerst aufgeführt ist, weil es sonst Probleme mit dem Meeting Server gibt.

[DigitDani]

Ich habe bei dem Kunden jetzt auch alles so wie hier besprochen implementiert. Außerdem habe ich das Awareness Thema nochmal genauer betrachtet. Schlau geworden bin ich nicht daraus aber kann folgendes mal festhalten.

Die Awareness für Personen die auch wirklich online sind, funktioniert auf dem Client des Admins (Notes Standard 8.5.1FP2, Sametime 8.5 embedded, Mailtemplate 8.5.1) auf dem ich dort arbeite so:

- Manche Personen die online sind, werden in der Inbox und in diversen Ansichten auch online angezeigt
- Die meisten Personen die online sind, werden aber offline angezeigt
- Angenommen es gibt 10 Mails vom Absender X in der Inbox, dann kann es sein, dass in einer davon der Absender X als online angezeigt wird.

Bei letzterem Punkt bin ich stutzig geworden und hab mir die Mails genauer angeschaut. Zumindest hier ist ganz klar eine Regelmäßigkeit zu erkennen. Kommt die Mail des Absenders X von dessen SMTP-Mailadresse (Vorname.Nachname@domain.de) funktioniert die Awarenessanzeige. Kommt sie von seiner internen Adresse (Vorname Nachname/OU/O) funktioniert sie nicht.

Der Clou ist: Es gibt Personen, für die ist es genau umgekehrt. Da funktioniert die Awarenessanzeige wenn die Mail im From-Feld die interne Adresse stehen hat, aber nicht wenn es die SMTP-Adresse ist. Das Verhalten ist also pro Person unterschiedlich.

Ein ldapsearch auf diese Personen, um evtl. Unterschiede festzustellen, brachte mir keine Erkenntnisse. Ich kann keine Unterschiede sehen.
In den Sametime Community Vorgaben am Notes Client die Option "Use Cananoical name for instant messaging status lookup" zu aktivieren oder deaktivieren ändert gar nichts.
Das Attribut "displayName" bei den Suchattributen mit aufzunehmen brachte auch nichts.

Da ich leider nicht permanent Zugriff auf die Kundenumgebung habe, komme ich im Moment nicht weiter. Falls hier jemand dieses Verhalten irgendwie nachstellen oder bestätigen kann, wäre ich sehr dankbar.

Danke für die tolle Zusammenarbeit hier!

[hallo.dirk]

Wenn ich displayName nun hinzufügen bekomme ich diese Meldung wenn ich "weiter" betätige...?

Im Domino Konfigurationsdokument habe ich displayName aufgenommen.

Egal ersteinmal Pfingsten.....

[eknori]

Das N wird klein geschrieben in displayname. Ldap task neu gestartet?

[hallo.dirk]

bin sicher, beides Probiert zu haben...
Werde es nochmal testen...

[eknori]

Mit der Schreibweise hat es wohl nichts zu tun. Allerdings erhalte ich die Fehlermeldung für den Fall, dass ich ein Attribut angeben, das nicht vom LDAP angeboten wird.

Spricht also dafür, dass displayname nicht verfügbar war, als du die Konfiguration gespeichert hast. Du sagst, da hast es im KonfigDoc neu hinzugefügt. Dann sollte ein Neustart des LDAP task am Domino das Problem beheben.

[hallo.dirk]

Also nach einer Woche Testen klappt das mit dem Displaname immer noch nicht

Auch wenn ich mit einem LDAP Tool auf den Server zugreife liefert mir die Suche nach dem Feld (Displayname=*) nichts zurück.
(Server neu gestartet, Ansichten aktualisiert, tests mit neuem LDAP Server..)


Nun habe ich aber gesehen, dass es ja noch das Feld Fullname gibt, den kann ich zumindest in der WAS Console eintragen.

Nun muss ich nur noch den ST Server neu starten....

[eknori]

Gehst du mit anonymer Bindung auf den LDAP los? Dann kontrolliere doch mal, ob das Attribut überhaupt in der Liste für den anonymen Zugriff enthalten ist.
Wenn du schreibst, dass du das Attribut nicht einmal im LDAP Browser siehst, muss es in diese Richtung gehen.

[DigitDani]

Hi Dirk,

mach mal ne ldapsearch -h server.domain.de cn="Vorname Nachname" und schau Dir die ganzen Attribute an, die zurückgegeben werden. Wenn da displayName nicht dabei ist, ist dieses Attribut wahrscheinlich nicht im Konfigdokument des Servers auf dem LDAP Tab konfiguriert. Schau Dir einfach die Attributliste dort an und wenn es fehlt, füge es hinzu.

[hallo.dirk]

Danke Daniel, aber ob nun ldapsearch oder ein LDAP Browser liefen nicht den Wert und im konfig Dokument steht es definitiv drinnen.

Aber:
Eure LDAP Server sind doch alle 8er, oder?

Mein LDAP Server stammt noch aus Quickplace Zeiten und ist immer noch Version 7. Ich habe so das Gefühl, dass hier die Ursache zu suchen ist......

Auf einem 8.5er Testsystem bekomme ich nun endlich den DisplayName angezeigt. Ein in der gleichen Domain befindlicher 7.03er Server gibt mir diesen Wert nicht zurück.
Edit: Ah nun klappt es auch unter 7, wenn ich das DD mit in der Directory Assistance aufnehme Habe ich da etwas verpasst??


Nun habe ich die LDAP Task auf unserem Admin Server (8.5.1.FP2) gestartet aber der gibt mir den DisplayName auch nicht zurück Oh manno  

[eknori]

Ist da an der schema.ntf irgendwie geschraubt worden ?

[hallo.dirk]

nein s.o.

Einen kleinen Teilerfolg habe ich schon zumindest im Testsystem, nun muss ich das alles noch im Live einstellen....

[hallo.dirk]

Es ist der LDAP Server selber, bzw das Domino Relesase, welches den Wert nicht liefert.
Ich muss den LDAP Server mindestens auf 7.0.3 bringen, dann bekomme ich endlich meinen displayname....

Hätte ich mal gleich einen 8er Server genommen.

[hallo.dirk]

So Fall erledigt

Danke an alle Beteiligten für diese Erkenntnisse.....


@Daniel
Bisher konnte ich die Online Stati in den Ansichten mit  IM_USE_CANONICAL_NAME=1 (bzw click auf diese Option in der Community) wieder sichtbar machen.

Allerdings habe ich letzte Woche FP3 installiert und nun ist wieder alles weg .
Ich muss aber erst noch einen 2. Client ausfetzen, um das zu verifizieren.


@all
Hat schon einer mit den Richtlinien in der WAS Console experimentiert? Nun kann hier keine Domino Gruppen auflösen...argh....
Fehlen hier auch noch Attribute?

P.S.: Im Sametime Client werden die Gruppen aber richtig aufgelöst

P.P.S.: Oder hat das etwas mit der SearchBase von O=Cert zu tun?? Gruppen haben keine O=Cert