Passwort-Reset wird für SMTP nicht erkannt

Apps & App Center
, , ,
#1

Hallo zusammen,

wir sind aktuell dabei den Kennwortwechsel über den Self-Service im Zusammenspiel mit Kopano zu integrieren. Soweit klappt alles auch recht gut, bis auf SMTP. Sobald wir das Kennwort für einen User wechseln, funktioniert der Zugriff dort nicht mehr. Wir haben einen DC (ucs01) und einen Memberserver (ucs02) mit Kopano + Postfix.

Ich habe mir hierzu auch diesen Thread angesehen, in dem empfohlen wird /etc/pam.d/smtp anzupassen. Der Wert ist im aktuellen Konfigurationsfile aber scheinbar schon per Default richtig.

Was mich dort nur stutzig macht ist, dass auf dem Kopano-Server (ucs02) in /etc/pam.d/smtp als ldap_host nicht der DC angegeben ist.

auth    sufficient    pam_unix.so
auth optional pam_univentionmailcyrus.so ldap_host=ucs02.do.main.de ldap_base=dc=do,dc=main,dc=de from_attr=mailPrimaryAddress to_attr=uid binddn=cn=ucs01,cn=dc,cn=computers,dc=do,dc=main,dc=de  pwfile=/etc/machine.secret ldap_port=7389

auth    sufficient    pam_ldap.so use_first_pass
auth    required      pam_krb5.so use_first_pass

account  sufficient   pam_unix.so
account  required     pam_ldap.so

Ist das so richtig?

Hier noch die entsprechenden mail.log-Einträge auf dem Kopano-Server:

Dec  2 15:29:00 ucs02 postfix/smtpd[26265]: warning: SASL authentication failure: cannot connect to saslauthd server: Connection refused
Dec  2 15:29:00 ucs02 postfix/smtpd[26265]: warning: SASL authentication failure: Password verification failed
Dec  2 15:29:00 ucs02 postfix/smtpd[26265]: warning: XXX.dip0.t-ipconnect.de[X.X.X.X]: SASL PLAIN authentication failed: generic failure
#2

Nach einigem Testen stellt sich die Situation nach einem Kennwortwechsel über den Self-Service jetzt wie folgt dar:

  • SMTP-Authentifizierung mit Alias bzw. Domain-User z.B. h.mueller funktioniert nicht
  • SMTP-Authentifizierung mit voller Email-Adresse h.mueller@domain.de funktioniert mit dem neuen Kennwort

Das sind mir dann doch nach einem Problem mit der Konfiguration von sasl aus. Gibt es hierzu noch Infos wie das einzurichten ist? Ich denke das Problem dürfte ja nicht selten auftreten, wenn Mail und der Self-Service genutzt werden.

#3

Hallo,
im log steht/stand

cannot connect to saslauthd server: Connection refused

Dazu steht evtl. in SASL authentication failure: cannot connect to saslauthd server: Connection refused etwas (mit Workaround)

1 Like
#4

Vielen Dank für den Hinweis! Der saslauthd hat sich tatsächlich das ein oder andere Mal ohne Logmeldung aufgehängt. Das letzte was zu sehen war, waren fehlerhafte Anmeldungen.

Ich habe den Workaround mit sudo ucr set mail/saslauthd/threads=‘0’ eingerichtet und bisher ist es ruhig. Ein aktueller Versuch über den Self-Service das Kennwort zu wechseln hat für SMTP nach ein paar Minuten Wartezeit nun auch funktioniert.

#5

Als Abschlussmeldung zu diesem Thema: Das Wechseln des Kennworts über den Self-Service klappt mit einer Wartezeit von ca. 5 Minuten jetzt stabil. Nur der saslauthd ist auch mit dem Workaround nicht zu beruhigen. Hierzu mache ich nochmal einen Thread auf, weil das hier nicht so gut aufgehoben ist.

#6

Wir hatten auch Probleme damit. (SASLAUTH) Aber das zu Grunde liegende Problem war ein Kommunikationsproblem in der AD zwischen Master und Slave … das hat der Support für uns repariert und ich habe es nicht verstanden, was genau da falsch war.

Mastodon