Posts Tagged: ‘LDAP’

BES 10.2 verfügbar

3. Dezember 2013 Posted by Oliver Regelmann

Blackberry hat heute die neue Version 10.2 des Blackberry Enterprise Service veröffentlicht. Neben erweiterten MDM-Funktionen gibt es für Traveler-Umgebungen auch Neues:

“Integrate an LDAP company directory: Organizations that do not use Microsoft Active Directory can connect to LDAP company directories such as IBM Domino Directory and Novell eDirectory”

Man muss Blackberry-Benutzer also nicht mehr unbedingt im AD haben. Und:

Improved support for IBM Notes Traveler: You can now enable synchronization of IBM Notes Traveler To Do lists in BlackBerry Enterprise Service 10. This feature is supported on devices with BlackBerry 10 OS version 10.2.1 and later

Vermisst wird weiterhin die Synchronisation des Notizbuchs und die Integration mehrerer Adressbücher.

Release Notes als PDF
Meldung bei Heise

Domino LDAP Suche mit speziellen Attributen ist manchmal fehlerhaft

8. September 2012 Posted by Manfred Meise

Man kann Benutzer in Domino Directories mittels LDAP finden.
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 ""
Image:Domino LDAP Suche mit speziellen Attributen ist manchmal fehlerhaft

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!

Domino LDAP Suche mit speziellen Attributen ist manchmal fehlerhaft

8. September 2012 Posted by Manfred Meise

Man kann Benutzer in Domino Directories mittels LDAP finden. 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 ""
Image:Domino LDAP Suche mit speziellen Attributen ist manchmal fehlerhaft

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!

Domino LDAP Suche mit speziellen Attributen ist manchmal fehlerhaft

8. September 2012 Posted by Manfred Meise

Man kann Benutzer in Domino Directories mittels LDAP finden.
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 ""
Image:Domino LDAP Suche mit speziellen Attributen ist manchmal fehlerhaft

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!

Domino LDAP Suche mit speziellen Attributen ist manchmal fehlerhaft

8. September 2012 Posted by Manfred Meise

Man kann Benutzer in Domino Directories mittels LDAP finden.
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 ""
Image:Domino LDAP Suche mit speziellen Attributen ist manchmal fehlerhaft

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!