Domino LDAP Suche mit speziellen Attributen ist manchmal fehlerhaft
Manfred Meise 8 September 2012 16:39:36
Testweise kann man hierfür LDAPSearch (z.B. direkt auf dem Domino Server) einsetzen.
So liefert z.B. folgende LDAP Abfrage :
ldapsearch -h localhost "(uid=D*Notes)" cn
dieses Ergebnis:
08.09.2012 16:57:53,24 [069C:0004-02F4] LDAP> Type of search: View Search
08.09.2012 16:57:53,24 [069C:0004-02F4] LDAP> ... Searching view $Users for partial match on uid = D
08.09.2012 16:57:53,24 [069C:0004-02F4] LDAP> NIFFindByKey(d) candidate matches: 18, error: 0
08.09.2012 16:57:53,24 [069C:0004-02F4] LDAP> Found matching entry, Note ID: 5406
CN=Doctor Notes,O=WWCorp
cn=Doctor Notes
cn=WWCORP\Doctor.Notes
Für die Suche wird hierbei die Ansicht "$Users" verwendet. Das Ergebnis ist richtig und vollständig.
Hinweis: Die erweiterten Ergebnisdarstellungen erhält man durch setzen der Notes.ini Variablen "LDAPDebug=1"
Variiert man die Abfrage nur ein wenig:
ldapsearch -h localhost "(uid=*Notes)" cn
so erhält man mit dieses Ergebnis:
08.09.2012 16:58:22,63 [0B68:0004-0A40] LDAP> Type of search: FT Search
08.09.2012 16:58:22,63 [0B68:0004-0A40] LDAP> ... No FT index was found
08.09.2012 16:58:22,63 [0B68:0004-0A40] LDAP> ... Fallback to All Search
08.09.2012 16:58:22 LDAP Server: You should full text index Domino directory names.nsf on to improve search performance for filters like '(uid=*x)'
08.09.2012 16:58:22,63 [0B68:0004-0A40] LDAP> ... Getting entries in ($LDAPRDNHier)
08.09.2012 16:58:22,66 [0B68:0004-0A40] LDAP> Found matching entry CN=Doctor Notes/O=WWCorp (NoteID: 5406)
CN=Doctor Notes,O=WWCorp
cn=Doctor Notes
cn=WWCORP\Doctor.Notes
Für die Suche wird hierbei NICHT die Ansicht "$Users" verwendet, sondern eine Volltext-Abfrage. Nun gut: Das Ergebnis ist richtig und vollständig. Allerdings stört der Hinweis auf den fehlenden Volltextindex und klingt logisch: Viele solcher Abfragen auf ein großes Directory sind ineffiziert.
Als vorausschauender Administrator legt man somit (wie in der Administrationshilfe beschrieben) einen Volltext-Index für das Domino Directory an und konfiguriert im Konfigurationsdokument für den LDAP Service ""
Somit erhält man auf die vorherige Abfrage:
ldapsearch -h localhost "(uid=*Notes)" cn
... das Suchergebnis:
08.09.2012 17:18:22,78 [0B74:0004-0DA4] LDAP> Type of search: FT Search
08.09.2012 17:18:22,78 [0B74:0004-0DA4] LDAP> ... FT Query: ([ShortName] Contains (*"Notes"))
08.09.2012 17:18:22,78 [0B74:0004-0DA4] LDAP> FTSearch candidate matches: 1
08.09.2012 17:18:22,78 [0B74:0004-0DA4] LDAP> Type of search: Modified Since FT Search (08.09.2012 17:17:34 - 08.09.2012 17:18:22)
08.09.2012 17:18:22,78 [0B74:0004-0DA4] LDAP> Found matching entry, Note ID: 5406
CN=Doctor Notes,O=WWCorp
cn=Doctor Notes
cn=WWCORP\Doctor.Notes
Hurra!?? Sollte doch auch mit anderen LDAP Attributen gehen, oder?
ldapsearch -h localhost "(displayname=*/WWCorp)" cn
..doch weit gefehlt! Hier ergibt sich ein anderes Bild:
08.09.2012 17:24:51,95 [0EB0:0004-0EF4] LDAP> Type of search: FT Search
08.09.2012 17:24:51,95 [0EB0:0004-0EF4] LDAP> ... FT Query: ([displayname] Contains (*"/WWCorp"))
08.09.2012 17:24:51,95 [0EB0:0004-0EF4] LDAP> FTSearch candidate matches: 103557980
08.09.2012 17:24:51,95 [0EB0:0004-0EF4] LDAP> Type of search: Modified Since FT Search (08.09.2012 17:24:25 - 08.09.2012 17:24:51)
...und KEIN Ergebnis. Hmmm könnte daran liegen, dass im angefragten Zeitraum keine Dokumente modifiziert wurden? Die Bearbeitung eines Personendokumentes bestätigt den Verdacht und liefert genau den zuvor geänderten Eintrag. Leider ist somit das Ergebnis bei Abfragen z.B. auf das "displayName" Attribut bei Verwendung des Wildcard-Zeichens an erster Stelle ein falsches Ergebnis. Verwirrend genug: Verwendet man das Wildcard-Zeichen mitten in einem Suchstring stimmt das Suchergebnis. Ich halte dieses nicht für eine sinnvolles Produktverhalten, sondern für einen Fehler !!!
(Umgehungs-)Lösung: Keinen Volltext-Index auf das Domino Directory einsetzen! Und schon erhält (vielleicht nicht das schnellste, aber) stets das richtige Suchergebnis!
Zielgruppe: Administrator Kategorien: LDAP Diskussion: Kommentare [0]