[postfix-users] keine Mailzustellung an deaktiviert LDAP-Benutzer
Hi, ich habe folgende Abfrage in meiner ldap.cf
query_filter = (&(loginDisabled=TRUE)(uid=%u)) result_attribute = uid
welche einstellung muss jetzt noch in der main.cf gesetzt werden damit die deaktivierten Benutzer keine Mails empfangen??
folgende settings scheinen nicht zu gehen:
smtpd_recipient_restrictions = reject_unauth_destination, reject_unlisted_recipient, check_recipient_access ldap:/etc/postfix/ldap.cf, reject_unverified_recipient, permit_auth_destination, reject smtpd_reject_unlisted_recipient = yes
vielen dank schon mal für eure hilfe!
* Johannes Grimm postfix-users@de.postfix.org:
Hi, ich habe folgende Abfrage in meiner ldap.cf
query_filter = (&(loginDisabled=TRUE)(uid=%u)) result_attribute = uid
welche einstellung muss jetzt noch in der main.cf gesetzt werden damit die deaktivierten Benutzer keine Mails empfangen??
In der main.cf musst (und kannst) Du nicht dafür nichts setzen.
Die Logik steckt ja in Deiner Abfrage. Ich würde sie aber andes aufbauen.
Liste alle, deren loginDisabled FALSE ist.
Die, deren loginDisabled TRUE ist, sind ja diejenigen für die Du den Login abschalten willst.
p@rick
stimmt!
query_filter = (&(loginDisabled=FALSE)(uid=%u)) result_attribute = uid, loginDisabled
einfach ein zweites result_attribute dazu packen und schon gehts!
vielen dank
Patrick Ben Koetter schrieb:
- Johannes Grimm postfix-users@de.postfix.org:
Hi, ich habe folgende Abfrage in meiner ldap.cf
query_filter = (&(loginDisabled=TRUE)(uid=%u)) result_attribute = uid
welche einstellung muss jetzt noch in der main.cf gesetzt werden damit die deaktivierten Benutzer keine Mails empfangen??
In der main.cf musst (und kannst) Du nicht dafür nichts setzen.
Die Logik steckt ja in Deiner Abfrage. Ich würde sie aber andes aufbauen.
Liste alle, deren loginDisabled FALSE ist.
Die, deren loginDisabled TRUE ist, sind ja diejenigen für die Du den Login abschalten willst.
p@rick
Johannes Grimm schrieb:
stimmt!
query_filter = (&(loginDisabled=FALSE)(uid=%u)) result_attribute = uid, loginDisabled
einfach ein zweites result_attribute dazu packen und schon gehts!
Wozu soll das gut sein? Jetzt bekommst du neben uid - z.B. mmeier - auch noch "false" zurückgeliefert. Ich kann mich ja täuschen, aber versucht dann Postfix nicht auch an "false" zuzustellen?
Marc
On Behalf Of Marc Patermann
Johannes Grimm schrieb:
stimmt!
query_filter = (&(loginDisabled=FALSE)(uid=%u)) result_attribute = uid, loginDisabled
einfach ein zweites result_attribute dazu packen und schon gehts!
Wozu soll das gut sein? Jetzt bekommst du neben uid - z.B. mmeier - auch noch "false" zurückgeliefert. Ich kann mich ja täuschen, aber versucht dann Postfix nicht auch an "false" zuzustellen?
Nö, Postfix lässt den zugang nur zu wenn eben genau dieser Datensatz ein OK zurückgibt
Der select schaut nach ob es den Usernamen mit diesem passwort und ein Feld mit dem Wert false in einem Datensatz gibt und gibt ein OK bzw. row 1 zurück.
Select user, pw, loginDisable from Mialkonten where User = "müller" and pw = "MaIer" and loginDisable = "false";
Ergibt bei Datensatz bestehend aus
User: müller PW: MaIer loginDisable: false
ok (denn das war die Suche)
User: müller PW: MaIer loginDisable: true
keinen wert denn danach wurde nicht gesucht.
Mit freundlichen Grüßen
Drießen
* Marc Patermann postfix-users@de.postfix.org:
Johannes Grimm schrieb:
stimmt!
query_filter = (&(loginDisabled=FALSE)(uid=%u)) result_attribute = uid, loginDisabled
einfach ein zweites result_attribute dazu packen und schon gehts!
Wozu soll das gut sein? Jetzt bekommst du neben uid - z.B. mmeier - auch noch "false" zurückgeliefert. Ich kann mich ja täuschen, aber versucht dann Postfix nicht auch an "false" zuzustellen?
Nein. Der Postfix smtpd wertet die Map als Liste aus. Die Tatsache, dass jemand auf der Liste "steht" dient als Beweis - es handelt sich um einen "valid recipient".
Insofern ist es also egal, was (Wert, Anzahl von Werten) zurückgeliefert wird, solange überhaupt was als Antwort geliefert wird.
Das Routing, also wohin die Nachricht soll, wird u.a. vom queue manager bestimmt. In dem Zusammenhang wird sie dann als Map ("Das hier, wohin?") ausgewertet.
p@rick
Patrick Ben Koetter schrieb:
- Marc Patermann postfix-users@de.postfix.org:
Johannes Grimm schrieb:
stimmt!
query_filter = (&(loginDisabled=FALSE)(uid=%u)) result_attribute = uid, loginDisabled
einfach ein zweites result_attribute dazu packen und schon gehts!
Wozu soll das gut sein? Jetzt bekommst du neben uid - z.B. mmeier - auch noch "false" zurückgeliefert. Ich kann mich ja täuschen, aber versucht dann Postfix nicht auch an "false" zuzustellen?
Nein. Der Postfix smtpd wertet die Map als Liste aus. Die Tatsache, dass jemand auf der Liste "steht" dient als Beweis - es handelt sich um einen "valid recipient".
Ja, ok, in dem Fall ist dann das Ergebnis egal. Trotzdem sollte es doch aber zwei Ergebnisse / Rückgabewerte geben, wovon eines immer "false" ist. (Jetzt nur auf die zwei Zeilen bezogen. Die Abfrage könnte ja auch in einer Virtual-Map o.ä stehen.)
result_attribute (default: maildrop) The attribute(s) Postfix will read from any direc- tory entries returned by the lookup, to be resolved to an email address.
result_attribute = mailbox, maildrop
Insofern ist es also egal, was (Wert, Anzahl von Werten) zurückgeliefert wird, solange überhaupt was als Antwort geliefert wird.
Trotzdem ist ein zweiter Wert hier IMHO überflüssig, denn bedingt durch die Abfrage erhalte ich für loginDisabled immer nur "false" zurück. Ist loginDisabled für den Account "true" gibt die Abfrage ja kein Ergebnis zurück.
Marc
* Marc Patermann postfix-users@de.postfix.org:
Patrick Ben Koetter schrieb:
- Marc Patermann postfix-users@de.postfix.org:
Johannes Grimm schrieb:
stimmt!
query_filter = (&(loginDisabled=FALSE)(uid=%u)) result_attribute = uid, loginDisabled
einfach ein zweites result_attribute dazu packen und schon gehts!
Wozu soll das gut sein? Jetzt bekommst du neben uid - z.B. mmeier - auch noch "false" zurückgeliefert. Ich kann mich ja täuschen, aber versucht dann Postfix nicht auch an "false" zuzustellen?
Nein. Der Postfix smtpd wertet die Map als Liste aus. Die Tatsache, dass jemand auf der Liste "steht" dient als Beweis - es handelt sich um einen "valid recipient".
Ja, ok, in dem Fall ist dann das Ergebnis egal. Trotzdem sollte es doch aber zwei Ergebnisse / Rückgabewerte geben, wovon eines immer "false" ist. (Jetzt nur auf die zwei Zeilen bezogen. Die Abfrage könnte ja auch in einer Virtual-Map o.ä stehen.)
Ja, stimmt.
result_attribute (default: maildrop) The attribute(s) Postfix will read from any direc- tory entries returned by the lookup, to be resolved to an email address.
result_attribute = mailbox, maildropInsofern ist es also egal, was (Wert, Anzahl von Werten) zurückgeliefert wird, solange überhaupt was als Antwort geliefert wird.
Trotzdem ist ein zweiter Wert hier IMHO überflüssig, denn bedingt durch
Ja, das ist er. Der Fehler war anfänglich IMO in der fehlerhaft gesetzen Bedingung: loginDisabled=TRUE
Ich setze bei sowas immer loginEnabled und das ggf. auf FALSE. Mein Kopf tut sich damit leichter ... ;)
die Abfrage erhalte ich für loginDisabled immer nur "false" zurück. Ist loginDisabled für den Account "true" gibt die Abfrage ja kein Ergebnis zurück.
Genau.
p@rick
Patrick Ben Koetter schrieb:
- Marc Patermann postfix-users@de.postfix.org:
Patrick Ben Koetter schrieb:
- Marc Patermann postfix-users@de.postfix.org:
Johannes Grimm schrieb:
stimmt!
query_filter = (&(loginDisabled=FALSE)(uid=%u)) result_attribute = uid, loginDisabled
einfach ein zweites result_attribute dazu packen und schon gehts!
Wozu soll das gut sein? Jetzt bekommst du neben uid - z.B. mmeier - auch noch "false" zurückgeliefert. Ich kann mich ja täuschen, aber versucht dann Postfix nicht auch an "false" zuzustellen?
Nein. Der Postfix smtpd wertet die Map als Liste aus. Die Tatsache, dass jemand auf der Liste "steht" dient als Beweis - es handelt sich um einen "valid recipient".
Ja, ok, in dem Fall ist dann das Ergebnis egal. Trotzdem sollte es doch aber zwei Ergebnisse / Rückgabewerte geben, wovon eines immer "false" ist. (Jetzt nur auf die zwei Zeilen bezogen. Die Abfrage könnte ja auch in einer Virtual-Map o.ä stehen.)
Ja, stimmt.
result_attribute (default: maildrop) The attribute(s) Postfix will read from any direc- tory entries returned by the lookup, to be resolved to an email address.
result_attribute = mailbox, maildrop
Bei allen Test kam nun auch immer ein "false" als /mailadresse /zurück
_*ldap:*_ filter: "(&(loginDisabled=FALSE)(uid=bak14512))" attribute: "uid" attribute: "loginDisabled" (xxx.xxx.xxx.xxx:41940)(0x0002:0x63) Sending operation result 0:"":"" to connection 0x984ac620
_*postfix*_ sles postfix/local[9165]: CB1C82DC8E: to=FALSE@testdomain.priv, orig_to=BaK14512@testdomain.priv, relay=local, delay=0.14, delays=0.07/0.01/0/0.06, dsn=5.1.1, status=bounced (unknown user: "false")
Mir scheint als würde der Postfix* keine boolean Abfrage machen bzw. keinen boolean wert empfangen (können)* Stattdessen wird der zurückgeliefert wert "false" vor das @ gesetzt, aber nicht ausgewertet.
auch wenn man als result_attribute das *loginDisabled entfernt*, wird es mit einem "false" aufgefüllt.
query_filter = (&(loginDisabled=FALSE)(uid=%u)) result_attribute = uid, loginDisabled
Korrekterweise sollte bei einer negative abfrage ja auch nur die uid geliefert werden. und bei einem "true" sollte ein "user not found" das ergebnis sein.
kann postfix boolean werte auswerten???
Insofern ist es also egal, was (Wert, Anzahl von Werten) zurückgeliefert wird, solange überhaupt was als Antwort geliefert wird.
Trotzdem ist ein zweiter Wert hier IMHO überflüssig, denn bedingt durch
Ja, das ist er. Der Fehler war anfänglich IMO in der fehlerhaft gesetzen Bedingung: loginDisabled=TRUE
Ich setze bei sowas immer loginEnabled und das ggf. auf FALSE. Mein Kopf tut sich damit leichter ... ;)
die Abfrage erhalte ich für loginDisabled immer nur "false" zurück. Ist loginDisabled für den Account "true" gibt die Abfrage ja kein Ergebnis zurück.
Genau.
p@rick
* Johannes Grimm postfix-users@de.postfix.org:
Patrick Ben Koetter schrieb:
- Marc Patermann postfix-users@de.postfix.org:
Patrick Ben Koetter schrieb:
- Marc Patermann postfix-users@de.postfix.org:
Johannes Grimm schrieb:
stimmt!
query_filter = (&(loginDisabled=FALSE)(uid=%u)) result_attribute = uid, loginDisabled
einfach ein zweites result_attribute dazu packen und schon gehts!
Wozu soll das gut sein? Jetzt bekommst du neben uid - z.B. mmeier - auch noch "false" zurückgeliefert. Ich kann mich ja täuschen, aber versucht dann Postfix nicht auch an "false" zuzustellen?
Nein. Der Postfix smtpd wertet die Map als Liste aus. Die Tatsache, dass jemand auf der Liste "steht" dient als Beweis - es handelt sich um einen "valid recipient".
Ja, ok, in dem Fall ist dann das Ergebnis egal. Trotzdem sollte es doch aber zwei Ergebnisse / Rückgabewerte geben, wovon eines immer "false" ist. (Jetzt nur auf die zwei Zeilen bezogen. Die Abfrage könnte ja auch in einer Virtual-Map o.ä stehen.)
Ja, stimmt.
result_attribute (default: maildrop) The attribute(s) Postfix will read from any direc- tory entries returned by the lookup, to be resolved to an email address.
result_attribute = mailbox, maildropBei allen Test kam nun auch immer ein "false" als /mailadresse /zurück
_*ldap:*_ filter: "(&(loginDisabled=FALSE)(uid=bak14512))" attribute: "uid" attribute: "loginDisabled" (xxx.xxx.xxx.xxx:41940)(0x0002:0x63) Sending operation result 0:"":"" to connection 0x984ac620
_*postfix*_ sles postfix/local[9165]: CB1C82DC8E: to=FALSE@testdomain.priv, orig_to=BaK14512@testdomain.priv, relay=local, delay=0.14, delays=0.07/0.01/0/0.06, dsn=5.1.1, status=bounced (unknown user: "false")
Mir scheint als würde der Postfix* keine boolean Abfrage machen bzw. keinen boolean wert empfangen (können)* Stattdessen wird der zurückgeliefert wert "false" vor das @ gesetzt, aber nicht ausgewertet.
auch wenn man als result_attribute das *loginDisabled entfernt*, wird es mit einem "false" aufgefüllt.
query_filter = (&(loginDisabled=FALSE)(uid=%u)) result_attribute = uid, loginDisabled
Korrekterweise sollte bei einer negative abfrage ja auch nur die uid geliefert werden. und bei einem "true" sollte ein "user not found" das ergebnis sein.
kann postfix boolean werte auswerten???
Nein. Hast Du den thread mitverfolgt? Postfix erwartet das ein (lies: irgendein) Ergebnis zurück kommt. Es ist keine Skripting-Engine oder so.
In welchem Zusammenhang wertest Du die Abfrage denn aus?
Für die Frage, ob der Empfänger existiert ist das Ergebnis egal. Hauptsache, es kommt ein Ergebnis.
Für das nachfolgende Routing ist es nicht egal. Bei einer alias-Map willst Du den wahren recipient als Empfänger nennen. Für einen Empfänger die Mailbox. etc.
p@rick
Insofern ist es also egal, was (Wert, Anzahl von Werten) zurückgeliefert wird, solange überhaupt was als Antwort geliefert wird.
Trotzdem ist ein zweiter Wert hier IMHO überflüssig, denn bedingt durch
Ja, das ist er. Der Fehler war anfänglich IMO in der fehlerhaft gesetzen Bedingung: loginDisabled=TRUE
Ich setze bei sowas immer loginEnabled und das ggf. auf FALSE. Mein Kopf tut sich damit leichter ... ;)
die Abfrage erhalte ich für loginDisabled immer nur "false" zurück. Ist loginDisabled für den Account "true" gibt die Abfrage ja kein Ergebnis zurück.
Genau.
p@rick
--
==============================================================
Hochschule für angewandte Wissenschaften - Fachhochschule Rosenheim
University of Applied Sciences
Rechenzentrum / Raum Sb 1.28
Johannes Grimm
Hochschulstr.1
D-83024 Rosenheim
Tel: +49-8031/805-229
Fax: +49-8031/805-223
johannes.grimm@fh-rosenheim.de
==============================================================
postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
Johannes Grimm schrieb:
Bei allen Test kam nun auch immer ein "false" als /mailadresse /zurück
quod erat demonstrandum ;)
Mir scheint als würde der Postfix* keine boolean Abfrage machen bzw. keinen boolean wert empfangen (können)* Stattdessen wird der zurückgeliefert wert "false" vor das @ gesetzt, aber nicht ausgewertet.
Die Logik steckt in der Abfrage. Wähle die LDAP-Abfrage so, dass sie nur dann ein Ergebnis hat, wenn die Bedingung erfüllt. Mailadresse im Verzeichnis? query_filter = (mail=%s) result_attribute = mail
Mailadresse vorhanden und Mail erlaubt? query_filter = (&(loginDisabled=FALSE)(mail=%s)) result_attribute = mail
Da der LDAP-Suchfilter eine AND-Verknüpfung "&" enthält, hast du deine Boolean-Abfrage dort untergebraucht
Korrekterweise sollte bei einer negative abfrage ja auch nur die uid geliefert werden. und bei einem "true" sollte ein "user not found" das ergebnis sein.
kann postfix boolean werte auswerten???
Ich glaube, du hast da noch ein Verständnisproblem was die LDAP-Abfragen angeht.
Angenommen es ist so: Zustellung an Attribut "uid" Mailen bei loginDisabled "false" erlaubt, bei "true" verboten. Dann müsste query_filter = (&(loginDisabled=FALSE)(uid=%u)) result_attribute = uid trotzdem richtig sein, weil beide Werte durch "&" verknüpft sind und daher nur dann wenn es ein uid-Attribut gibt und loginDisabled=FALSE ist, ein Ergebnis zurück kommt und Postfix dies dann als positives Signal wertet (je nach Kontext dann an den Wert von uid versucht zuzustellen).
Marc
Marc Patermann schrieb:
Johannes Grimm schrieb:
Bei allen Test kam nun auch immer ein "false" als /mailadresse /zurück
quod erat demonstrandum ;)
Mir scheint als würde der Postfix* keine boolean Abfrage machen bzw. keinen boolean wert empfangen (können)* Stattdessen wird der zurückgeliefert wert "false" vor das @ gesetzt, aber nicht ausgewertet.
Die Logik steckt in der Abfrage. Wähle die LDAP-Abfrage so, dass sie nur dann ein Ergebnis hat, wenn die Bedingung erfüllt. Mailadresse im Verzeichnis? query_filter = (mail=%s) result_attribute = mail
Mailadresse vorhanden und Mail erlaubt? query_filter = (&(loginDisabled=FALSE)(mail=%s)) result_attribute = mail
Da der LDAP-Suchfilter eine AND-Verknüpfung "&" enthält, hast du deine Boolean-Abfrage dort untergebraucht
Korrekterweise sollte bei einer negative abfrage ja auch nur die uid geliefert werden. und bei einem "true" sollte ein "user not found" das ergebnis sein.
kann postfix boolean werte auswerten???
Ich glaube, du hast da noch ein Verständnisproblem was die LDAP-Abfragen angeht.
Angenommen es ist so: Zustellung an Attribut "uid" Mailen bei loginDisabled "false" erlaubt, bei "true" verboten. Dann müsste query_filter = (&(loginDisabled=FALSE)(uid=%u)) result_attribute = uid trotzdem richtig sein, weil beide Werte durch "&" verknüpft sind und daher nur dann wenn es ein uid-Attribut gibt und loginDisabled=FALSE ist, ein Ergebnis zurück kommt und Postfix dies dann als positives Signal wertet (je nach Kontext dann an den Wert von uid versucht zuzustellen).
Soweit so gut ;) Postfix bekommt aber trotzdem einen Wert zurück bei dieser abfrage:
filter: "(&(loginDisabled=FALSE)(uid=bak14512))" attribute: "uid" (0x0002:0x63) Sending operation result 0:"":"" to connection 0x984ac620
der theorie nach sollte nun keine zustellung erfolgen, dummerweise passiert diese aber trotzdem, und zwar an die uid. und shcon bekomme ich wieder die "too many hops" fehlermeldung ich weiss nicht weiter.... ein user-not-found ndr oder dergleichen wäre optimal....
Marc
postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
Johannes Grimm schrieb:
filter: "(&(loginDisabled=FALSE)(uid=bak14512))" attribute: "uid" (0x0002:0x63) Sending operation result 0:"":"" to connection 0x984ac620
Was ist denn das Ergebnis, wenn man die gleiche Abfrage mit ldapsearch macht? (ggf. mit den erforderlichen und in Postfix verwendeten Anmeldedaten) # ldapsearch -x -h hostname "(&(loginDisabled=FALSE)(uid=bak14512))" uid
Marc
mit LoginDisabled:
filter: "(&(loginDisabled=FALSE)(uid=BaK14512))" attribute: "uid" (:60522)(0x0002:0x63) Sending operation result 0:"":"" to connection 0x8e47ae00
ohne loginDisabled:
filter: "(&(loginDisabled=FALSE)(uid=BaK14512))" attribute: "uid" (:60523)(0x0002:0x63) Sending search result entry "cn=BaK14512,ou=Sz-1,o=xxx,c=DE" to connection 0x8e0f2620
gibt es noch irgend eine andere lösung als die ldap-abfrage in dieser form? ich denke an eine extra abfrage nur für dieses attribute loginDisabled und bei positivem treffer --> reject
Marc Patermann schrieb:
Johannes Grimm schrieb:
filter: "(&(loginDisabled=FALSE)(uid=bak14512))" attribute: "uid" (0x0002:0x63) Sending operation result 0:"":"" to connection 0x984ac620
Was ist denn das Ergebnis, wenn man die gleiche Abfrage mit ldapsearch macht? (ggf. mit den erforderlichen und in Postfix verwendeten Anmeldedaten) # ldapsearch -x -h hostname "(&(loginDisabled=FALSE)(uid=bak14512))" uid
Marc _______________________________________________ postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
Johannes Grimm schrieb:
mit LoginDisabled:
filter: "(&(loginDisabled=FALSE)(uid=BaK14512))" attribute: "uid" (:60522)(0x0002:0x63) Sending operation result 0:"":"" to connection 0x8e47ae00
ohne loginDisabled:
filter: "(&(loginDisabled=FALSE)(uid=BaK14512))" attribute: "uid" (:60523)(0x0002:0x63) Sending search result entry "cn=BaK14512,ou=Sz-1,o=xxx,c=DE" to connection 0x8e0f2620
Ich verstehe dich nicht. Die Filter, die du hier schreibst, sind ja immer gleich. Änderst du den Eintrag?
I.Ü. sieht ein Standardoutput von ldapsearch bei mir so aus:
# ldapsearch -x "(&(mail=*@ofd-sth*)(cn=marc*))" mail # extended LDIF # # LDAPv3 # base <> with scope subtree # filter: (&(mail=*@ofd-sth*)(cn=marc*)) # requesting: mail #
# 22144, humans, foo dn: employeeNumber=22144,ou=humans,ou=foo mail: marcxxxxxxxxxxxxx
# 21727, humans, steuer, foo dn: employeeNumber=21727,ou=humans,ou=foo mail: marcusxxxxxxxxxxx
# search result search: 2 result: 0 Success
# numResponses: 3 # numEntries: 2
bzw:
# ldapsearch -x "(&(mail=*@ofd-stx*)(cn=marc*))" mail # extended LDIF # # LDAPv3 # base <> with scope subtree # filter: (&(mail=*@ofd-stx*)(cn=marc*)) # requesting: mail #
# search result search: 2 result: 0 Success
# numResponses: 1
Marc
sorry, ja klar ich hab hier eine nds und dort wird das häckchen für den user gesetzt ob aktiv bzw. inaktiv. das ist dann so im log natürlich nicht erkennbar....
Marc Patermann schrieb:
Johannes Grimm schrieb:
mit LoginDisabled:
filter: "(&(loginDisabled=FALSE)(uid=BaK14512))" attribute: "uid" (:60522)(0x0002:0x63) Sending operation result 0:"":"" to connection 0x8e47ae00
ohne loginDisabled:
filter: "(&(loginDisabled=FALSE)(uid=BaK14512))" attribute: "uid" (:60523)(0x0002:0x63) Sending search result entry "cn=BaK14512,ou=Sz-1,o=xxx,c=DE" to connection 0x8e0f2620
Ich verstehe dich nicht. Die Filter, die du hier schreibst, sind ja immer gleich. Änderst du den Eintrag?
I.Ü. sieht ein Standardoutput von ldapsearch bei mir so aus:
# ldapsearch -x "(&(mail=*@ofd-sth*)(cn=marc*))" mail # extended LDIF # # LDAPv3 # base <> with scope subtree # filter: (&(mail=*@ofd-sth*)(cn=marc*)) # requesting: mail #
# 22144, humans, foo dn: employeeNumber=22144,ou=humans,ou=foo mail: marcxxxxxxxxxxxxx
# 21727, humans, steuer, foo dn: employeeNumber=21727,ou=humans,ou=foo mail: marcusxxxxxxxxxxx
# search result search: 2 result: 0 Success
# numResponses: 3 # numEntries: 2
bzw:
# ldapsearch -x "(&(mail=*@ofd-stx*)(cn=marc*))" mail # extended LDIF # # LDAPv3 # base <> with scope subtree # filter: (&(mail=*@ofd-stx*)(cn=marc*)) # requesting: mail #
# search result search: 2 result: 0 Success
# numResponses: 1
Marc _______________________________________________ postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
Johannes Grimm schrieb:
sorry, ja klar ich hab hier eine nds und dort wird das häckchen für den user gesetzt ob aktiv bzw. inaktiv. das ist dann so im log natürlich nicht erkennbar....
Sorry, ich versteh dich nicht. So kann ich dir nicht helfen. "nds" = Novell Directory Service?
Mach doch einfach mal ein ldapsearch und poste den Output ...
Marc
das ist die abfrage mit wert TRUE für loginDisabled (wie gesagt in der nds gesetzt, siehe screenshot unten) sles:~/aliases # ldapsearch -x -h 141.60.50.25 "(&(loginDisabled=FALSE)(uid=BaK14512))" uid # extended LDIF # # LDAPv3 # base <> with scope subtree # filter: (&(loginDisabled=FALSE)(uid=BaK14512)) # requesting: uid #
# search result search: 2 result: 0 Success
hier ist der output für loginDisabled false # numResponses: 1 sles:~/aliases # ldapsearch -x -h 141.60.50.25 "(&(loginDisabled=FALSE)(uid=BaK14512))" uid # extended LDIF # # LDAPv3 # base <> with scope subtree # filter: (&(loginDisabled=FALSE)(uid=BaK14512)) # requesting: uid #
# BaK14512, Sz-1, Student, FH-Rosenheim, DE dn: cn=BaK14512,ou=Sz-1,ou=Student,o=xxx,c=DE uid: BaK14512
# search result search: 2 result: 0 Success
hier ist der auszug aus dem softerra ldap-admin
und hier aus der console1 (nds)
vielen dank auch mal für eure bemühungen!!
Marc Patermann schrieb:
Johannes Grimm schrieb:
sorry, ja klar ich hab hier eine nds und dort wird das häckchen für den user gesetzt ob aktiv bzw. inaktiv. das ist dann so im log natürlich nicht erkennbar....
Sorry, ich versteh dich nicht. So kann ich dir nicht helfen. "nds" = Novell Directory Service?
Mach doch einfach mal ein ldapsearch und poste den Output ...
Marc _______________________________________________ postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
Johannes Grimm schrieb:
das ist die abfrage mit wert TRUE für loginDisabled (wie gesagt in der nds gesetzt, siehe screenshot unten) sles:~/aliases # ldapsearch -x -h 141.60.50.25 "(&(loginDisabled=FALSE)(uid=BaK14512))" uid # extended LDIF # # LDAPv3 # base <> with scope subtree # filter: (&(loginDisabled=FALSE)(uid=BaK14512)) # requesting: uid #
# search result search: 2 result: 0 Success
OK, du fragst nach "false", das Attribut ist aber "true", also gibt es kein Ergebnis.
hier ist der output für loginDisabled false # numResponses: 1 sles:~/aliases # ldapsearch -x -h 141.60.50.25 "(&(loginDisabled=FALSE)(uid=BaK14512))" uid # extended LDIF # # LDAPv3 # base <> with scope subtree # filter: (&(loginDisabled=FALSE)(uid=BaK14512)) # requesting: uid #
# BaK14512, Sz-1, Student, FH-Rosenheim, DE dn: cn=BaK14512,ou=Sz-1,ou=Student,o=xxx,c=DE uid: BaK14512
# search result search: 2 result: 0 Success
OK, du fragst nach "false", das Attribut ist auch "false", also gibt es ein Ergebnis. Und es wird nur uid zurück geliefert.
Soweit alles gut.
query_filter = (&(loginDisabled=FALSE)(uid=%u)) result_attribute = uid
Sollte also richtig sein. Vielleicht kannst du in den LDAP-Server Logs sehen, welche Suche Postfix tatsächlich startet.
Marc
Hi, ich habe das Problem jetzt mit einer zweiten Abfrage gelöst.
relevante Einstellungen: *main.cf * alias_maps = hash:/etc/aliases, ldap:/etc/postfix/ldap/ldap.cf alias_database = hash:/etc/aliases, ldap:/etc/postfix/ldap/ldap.cf smtpd_recipient_restrictions = reject_unauth_destination, *check_recipient_access* ldap:/etc/postfix/ldap/checkldap.cf
*checkldap.cf * query_filter = (&(loginDisabled=TRUE)(mail=%s)) result_attribute = uid
danch wird die /eigentliche/ uid Abfrage gestartet wenn die check_recipient_access abfrage negativ ist: ** *ldap.cf* query_filter = (uid=%u) result_attribute = uid
postconf reload reinfeuern und spass haben ;)
trotzdem danke an alle!
Marc Patermann schrieb:
Johannes Grimm schrieb:
das ist die abfrage mit wert TRUE für loginDisabled (wie gesagt in der nds gesetzt, siehe screenshot unten) sles:~/aliases # ldapsearch -x -h 141.60.50.25 "(&(loginDisabled=FALSE)(uid=BaK14512))" uid # extended LDIF # # LDAPv3 # base <> with scope subtree # filter: (&(loginDisabled=FALSE)(uid=BaK14512)) # requesting: uid #
# search result search: 2 result: 0 Success
OK, du fragst nach "false", das Attribut ist aber "true", also gibt es kein Ergebnis.
hier ist der output für loginDisabled false # numResponses: 1 sles:~/aliases # ldapsearch -x -h 141.60.50.25 "(&(loginDisabled=FALSE)(uid=BaK14512))" uid # extended LDIF # # LDAPv3 # base <> with scope subtree # filter: (&(loginDisabled=FALSE)(uid=BaK14512)) # requesting: uid #
# BaK14512, Sz-1, Student, FH-Rosenheim, DE dn: cn=BaK14512,ou=Sz-1,ou=Student,o=xxx,c=DE uid: BaK14512
# search result search: 2 result: 0 Success
OK, du fragst nach "false", das Attribut ist auch "false", also gibt es ein Ergebnis. Und es wird nur uid zurück geliefert.
Soweit alles gut.
query_filter = (&(loginDisabled=FALSE)(uid=%u)) result_attribute = uid
Sollte also richtig sein. Vielleicht kannst du in den LDAP-Server Logs sehen, welche Suche Postfix tatsächlich startet.
Marc _______________________________________________ postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
Johannes Grimm schrieb:
postconf reload reinfeuern und spass haben ;)
korrekterweise muss es natürlich /postfix reload /heißen ;)
participants (4)
-
Johannes Grimm -
Marc Patermann -
Patrick Ben Koetter -
Uwe Driessen