Jump to content

LDAP Search Query liefert Fehlermeldung


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

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 zu diesem Kommentar

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

 

Link zu diesem Kommentar
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 zu diesem Kommentar
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 zu diesem Kommentar

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

 

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...