Jump to content

LDAP Search Query liefert Fehlermeldung


Recommended Posts

vor 7 Stunden schrieb Lian:

 

Damit das Raten nicht zur Dauerschleife gerät: Um welche Anwendung handelt es sich?

Magst Du uns den Namen verraten?
Ist es Kaufsoftware, Open Source, was ist Sinn und Zweck der Applikation?

Es ist eine Follow Me Printing Applikation, womit du dich mit deinen AD Credentials anmelden tust.

 

Im Standard konnte man sich mit dem SAMAccountname anmelden und das hat auch funktioniert.

Nun möchte ich es so anpassen, dass man den SAMAccountname oder den UPN zur Anmeldung nutzt.

 

Deshalb muss ich hierfür den Suchstring anpassen.

Link to post
vor 51 Minuten schrieb Bubblegum:

Es ist eine Follow Me Printing Applikation, womit du dich mit deinen AD Credentials anmelden tust.

Welcher Hersteller?

 

Vielleicht kennen das unsere Mitglieder oder es gibt eine Doku online...

Link to post
vor 2 Stunden schrieb Lian:

Welcher Hersteller?

 

Vielleicht kennen das unsere Mitglieder oder es gibt eine Doku online...

Streamline

vor 34 Minuten schrieb Bubblegum:

RICOH Streamline

 

Link to post

Moin,

 

wenn du deinerseits ab jetzt mitmachst ...

 

Also: ^ ist in LDAP nicht als Platzhalter definiert. Es ist denkbar, dass deine Applikation dies als Platzhalter verwendet für den User, der die Suche ausführt. Wäre sehr exotisch, aber Programmierer haben ja schon mal seltsame Ideen.

 

Da sowohl sAMAccountName als auch userPrincipalName im AD eindeutig sind, brauchst du bei deinen Filterstrings keine weiteren Attribute anzugeben. Das macht das Troubleshooting (und die Syntax) einfacher. Und ab hier könnte man jetzt systematisch vorgehen:

  • (sAMAccountName=^) 
    was kommt zurück?
  • (userPrincipalName=^)
    was kommt zurück?

Diese Versuche sind natürlich nur sinnvoll, wenn bei dem User, der gesucht wird, diese Felder auch gesetzt sind. Und: Nur dies ist der Suchstring, nichts weiter davor oder dahinter. Auf Basis der Ergebnisse können wir dann weitersehen.

 

Gruß, Nils

 

  • Like 2
Link to post
vor 2 Stunden schrieb NilsK:

Moin,

 

wenn du deinerseits ab jetzt mitmachst ...

 

Also: ^ ist in LDAP nicht als Platzhalter definiert. Es ist denkbar, dass deine Applikation dies als Platzhalter verwendet für den User, der die Suche ausführt. Wäre sehr exotisch, aber Programmierer haben ja schon mal seltsame Ideen.

 

Da sowohl sAMAccountName als auch userPrincipalName im AD eindeutig sind, brauchst du bei deinen Filterstrings keine weiteren Attribute anzugeben. Das macht das Troubleshooting (und die Syntax) einfacher. Und ab hier könnte man jetzt systematisch vorgehen:

  • (sAMAccountName=^) 
    was kommt zurück?
  • (userPrincipalName=^)
    was kommt zurück?

Diese Versuche sind natürlich nur sinnvoll, wenn bei dem User, der gesucht wird, diese Felder auch gesetzt sind. Und: Nur dies ist der Suchstring, nichts weiter davor oder dahinter. Auf Basis der Ergebnisse können wir dann weitersehen.

 

Gruß, Nils

 

  • (sAMAccountName=^) 
    Der User wurde ausgegeben
  • (userPrincipalName=^)
    The user was not found in the LDAP directory

 

Mir ist gerade nochwas aufgefallen. Versuchsweise habe ich (mail=^) als Suchstring eingeben und damit kam es zurück. Der userPrincipalName war als Anwenderattribut nicht definiert, sondern das Attribut mail.

 

Wie wäre nun der Suchstring einzugeben, damit SAMAccountName sowie userPrincipalName funktionieren?

Link to post

Moin,

 

sorry, falls es oben schon erwähnt wurde: Hat der User, den Du suchst, das UPN-Attribut tatsächlich belegt? Man kann nämlich durchaus User ohne UPN erzeugen. Für Kerberos wird dann zwar der implizite UPN (sAMAccountName@Default.Suffix.Der.Doma.In) verwendet, beim Suchen wird der User aber nicht gefunden.

Link to post
vor 29 Minuten schrieb cj_berlin:

Moin,

 

sorry, falls es oben schon erwähnt wurde: Hat der User, den Du suchst, das UPN-Attribut tatsächlich belegt? Man kann nämlich durchaus User ohne UPN erzeugen. Für Kerberos wird dann zwar der implizite UPN (sAMAccountName@Default.Suffix.Der.Doma.In) verwendet, beim Suchen wird der User aber nicht gefunden.

Im AD ist das UPN Attribut hinterlegt.

Link to post

Moin,

 

dann haben wir mehrere Möglichkeiten:

  1. bei dem betreffenden User ist der UPN doch nicht belegt
  2. die Applikation ersetzt den Akzent ^ nur bei bestimmten Feldern/Abfragen
  3. noch was anderes

Für 1. wäre jetzt eine Überprüfung sinnvoll, 2. könnte wohl nur der Hersteller beantworten. Für 3. spricht der Rest der Angaben: Wenn ^ von der Anwendung ersetzt wird - durch welchen Wert? Einen, der im sAMAccountName erkannt wird, eine gültige Mailadresse darstellt, aber im UPN nicht erkannt wird? Klingt sehr seltsam - und wirft uns wahrscheinlich auf 2. zurück, also den Herstellersupport.

 

Man könnte jetzt noch versuchen, per Wireshark oder so aufzuzeichnen, was denn die Applikation da für eine Anfrage ans AD schickt. Das kann aber in großen Aufwand ausarten.

 

Gruß, Nils

 

  • Like 1
Link to post
vor 1 Stunde schrieb NilsK:

Das kann aber in großen Aufwand ausarten.

Ich ergänze (nochmal) um: ... oder den Hersteller Support bemühen ...  (Wobei das halt auch in "Aufwand" ausarten kann.) ;-)

Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...