LDAP Search Query liefert Fehlermeldung

[Bubblegum 0]

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.

[Lian 2.425]

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...

[Bubblegum 0]

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

 

[Bubblegum 0]

Am 1.5.2021 um 19:26 schrieb Bubblegum:

Streamline

 

Hat noch jemand eine Idee?

[NilsK 2.939]

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

 

[Bubblegum 0]

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?

[cj_berlin 1.323]

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.

[Bubblegum 0]

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.

[NilsK 2.939]

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

 

[testperson 1.682]

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.)