Problem mit Mail und Anmeldung

german

#1

Hallo,
ich habe jetzt schon zum 2. Mal das Problem, dass es auf dem UCS (c’t Edition, alle Updates und Fixes) ein Anmeldeproblem gibt. Scheinbar hängt sich die Userverwaltung gleich mit weg, welche Logs relevant sind müsste mir ein Kundiger sagen. Es äussert sich wie folgt:

Outlook (über Zarafa-Client) fordert einen auf, sich anzumelden. User/PW können nicht verifiziert werden, nach mehreren Versuchen gibt OL dann auf. Android und Pushmail gibt auch einen PW-Fehler beim Sync. Die Managementkonsole kann ich aufrufen und mich anmelden, die Web-App habe ich nicht getestet. Ich habe dann die fehlenden letzten 8 Update-Pakete nachinstalliert und den Server neu gestartet. Danach funktionierte auch die Anmeldung etc. wieder. Das alleine ist nur nervig. Richtig schlimm ist, das in der Zeit Mails gebounced werden! Angeblich ist der Empfänger nicht vorhanden und diese Meldung wird auch an die Absender geschickt. Besonders praktisch, wenn Newsletter an die Adresse gehen. (Das steht in .var/log/mail.info) Die Mails werden vom externen Server abgeholt und dann weggeworfen:

May  6 05:22:15 backoffice postfix/smtpd[32026]: A2A084AC310: client=localhost[127.0.0.1]
May  6 05:22:15 backoffice postfix/cleanup[32030]: A2A084AC310: message-id=<E1UZBia-0007MJ-QG.01@web.xxxxx.de>
May  6 05:22:15 backoffice fetchmail[2941]: reading message xxxxxx@xxxxxx.de@customers-slb-6.mx.we.xxxxxx.net:1 of 1 (61267 octets) flushed
May  6 05:22:15 backoffice postfix/qmgr[26128]: A2A084AC310: from=<bounce_ct-magazin_xxxxxxxx=xxxxxx.de_0506@listserv.xxxxx.de>, size=61728, nrcpt=1 (queue active)
May  6 05:22:15 backoffice postfix/smtpd[32026]: disconnect from localhost[127.0.0.1]
May  6 05:22:18 backoffice postfix/smtpd[32037]: connect from localhost[127.0.0.1]
May  6 05:22:18 backoffice postfix/smtpd[32037]: 3FA344AC404: client=localhost[127.0.0.1]
May  6 05:22:18 backoffice postfix/cleanup[32030]: 3FA344AC404: message-id=<E1UZBia-0007MJ-QG.01@web.xxxxxx.de>
May  6 05:22:18 backoffice postfix/smtpd[32037]: disconnect from localhost[127.0.0.1]
May  6 05:22:18 backoffice postfix/qmgr[26128]: 3FA344AC404: from=<bounce_ct-magazin_xxxxxx=xxxxxx.de_0506@listserv.xxxxxx.de>, size=62236, nrcpt=1 (queue active)
May  6 05:22:18 backoffice amavis[27907]: (27907-08) Passed, <bounce_ct-magazin_xxxxxx=xxxxxx.de_0506@listserv.xxxxxx.de> -> <awe@travelbit.de>, quarantine CO23-Wcw9-8J, Message-ID: <E1UZBia-0007MJ-GQ.01@web.xxxxxx.de>, Hits: 0.575
May  6 05:22:18 backoffice postfix/smtp[32031]: A2A084AC310: to=<awe@xxxxxx.de>, relay=127.0.0.1[127.0.0.1]:10024, delay=2.6, delays=0.12/0.03/0.01/2.5, dsn=2.0.0, status=sent (2502.0.0 Ok, id=27907-08, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as 3FA344AC404)
May  6 05:22:18 backoffice postfix/qmgr[26128]: A2A084AC310: removed
May  6 05:22:18 backoffice postfix/lmtp[32038]: 3FA344AC404: to=<awe@xxxxxx.de>, relay=127.0.0.1[127.0.0.1]:2003, delay=0.15, delays=0.02/0.01/0.09/0.03, dsn=5.1.1, status=bounced (host 127.0.0.1[127.0.0.1] said: 503 5.1.1 User does not exist (in reply to RCPT TO command))
May  6 05:22:18 backoffice postfix/cleanup[32030]: 63C744AC411: message-id=<20130506032218.63C744AC411@backoffice.xxxxxx.intranet>
May  6 05:22:18 backoffice postfix/qmgr[26128]: 63C744AC411: from=<>, size=5586, nrcpt=1 (queue active)

Dazu habe ich 2 drängende Fragen:

a) Wie kann ich die Bouncemail verhindern, wenn sich das Ding nochmal weghängt?
b) wo kann ich nachgucken, was sich da aufhängt, damit ich das für die Zukunft verhindern kann.

Ich wollte eigentlich einem Kunden zum Umstieg auf UCS mit Zarafa raten, aber damit warte ich wohl besser noch. Wenn das da passieren würde, der hängt mich an die nächste Strassenlaterne. :wink:

Gruss
Andreas


#2

Hallo,

können Sie bitte nachsehen, ob Sie für das fragliche Datum in /var/log/univention/listener.log und /var/log/zarafa/server.log bzw. den zugehörigen Archiven einen Hinweis finden?

Viele Grüße,
Dirk Ahrnke


#3

Hallo Herr Ahrnke.

Schön dass doch noch wer antwortet. :wink: Ist einfach zu finden, weil heute wieder passiert.

./var/log/univention/listener.log:

27.05.13 01:02:07.793 LISTENER ( WARN ) : received signal 15 27.05.13 01:02:07.793 LISTENER ( PROCESS ) : zarafa: initiating sync User/group synchronization failed, object not found 27.05.13 01:02:13.175 DEBUG_INIT UNIVENTION_DEBUG_BEGIN : uldap.__open host=backoffice.travelbit.intranet port=7389 base=dc=travelbit,dc=intranet UNIVENTION_DEBUG_END : uldap.__open host=backoffice.travelbit.intranet port=7389 base=dc=travelbit,dc=intranet 27.05.13 01:02:44.529 LISTENER ( PROCESS ) : zarafa: initiating sync User/group synchronization failed, object not found 27.05.13 09:22:52.057 LISTENER ( WARN ) : received signal 15 27.05.13 09:23:02.504 DEBUG_INIT UNIVENTION_DEBUG_BEGIN : uldap.__open host=backoffice.travelbit.intranet port=7389 base=dc=travelbit,dc=intranet UNIVENTION_DEBUG_END : uldap.__open host=backoffice.travelbit.intranet port=7389 base=dc=travelbit,dc=intranet 27.05.13 09:23:02.985 LISTENER ( WARN ) : initializing module license_uuid 27.05.13 09:23:07.299 LISTENER ( WARN ) : finished initializing module license_uuid 27.05.13 09:23:10.984 LISTENER ( WARN ) : received signal 15 27.05.13 09:23:16.351 DEBUG_INIT UNIVENTION_DEBUG_BEGIN : uldap.__open host=backoffice.travelbit.intranet port=7389 base=dc=travelbit,dc=intranet UNIVENTION_DEBUG_END : uldap.__open host=backoffice.travelbit.intranet port=7389 base=dc=travelbit,dc=intranet 27.05.13 09:26:56.395 LISTENER ( WARN ) : received signal 15 27.05.13 09:30:35.851 DEBUG_INIT UNIVENTION_DEBUG_BEGIN : uldap.__open host=backoffice.travelbit.intranet port=7389 base=dc=travelbit,dc=intranet UNIVENTION_DEBUG_END : uldap.__open host=backoffice.travelbit.intranet port=7389 base=dc=travelbit,dc=intranet

/var/log/zarafa/server.log:

[code]Mon May 27 01:02:07 2013: Previous message logged 49 times
Mon May 27 01:02:07 2013: Error synchronizing user list: 8000001D
Mon May 27 09:18:32 2013: Received error from ntlm_auth:
GENSEC login failed: NT_STATUS_LOGON_FAILURE

Mon May 27 09:27:10 2013: Previous message logged 8 times
Mon May 27 09:27:10 2013: Shutting down.
Mon May 27 09:27:10 2013: Still waiting for 8 threads to exit
Mon May 27 09:27:12 2013: Server shutdown complete.
Mon May 27 09:30:13 2013: Starting zarafa-server version 7,1,1,37812, pid 2730
Mon May 27 09:30:13 2013: Listening for priority pipe connections on /var/run/zarafa-prio
Mon May 27 09:30:13 2013: Listening for pipe connections on /var/run/zarafa
Mon May 27 09:30:13 2013: Listening for TCP connections on port 236
Mon May 27 09:30:13 2013: Listening for SSL connections on port 237
Mon May 27 09:30:13 2013: Connection to database ‘zarafa’ succeeded
Mon May 27 09:30:13 2013: WARNING: zarafa-licensed not running, commercial features will not be available until it’s started.
Mon May 27 09:30:18 2013: Startup succeeded on pid 2788
Mon May 27 09:30:53 2013: Received error from ntlm_auth:
GENSEC login failed: NT_STATUS_LOGON_FAILURE
[/code]

Und auch heute waren wieder diverse Updates in der Pipe - hatte wohl 2 Wochen nicht auf das Managementinterface geguckt. Gegen halb 10 habe ich die Updates installiert und danach den Server neu gestartet.

Eine Mail ist in der Zeit (nicht) angekommen; ich hab den Absender - einen Vereinskameraden - angemailt, ob er eine Fehlermeldung bekommen hat.

Gestresste Grüsse - I don’t like mondays…

Andreas Weiss


#4

Das sieht nach einem Problem beim Wechsel des Serverkennwortes aus, zu verifizieren in /var/log/univention/server_password_change.log.
Wenn der Passwortwechsel heute morgen war, sollten Sie ihn als vorläufigen Workaround deaktivieren.

ucr set server/password/change='no'

Ich schau mir das demnächst mal in der c’t-Edition an.


#5

Hallo,

das sieht verdächtig aus:

Starting server password change (Mon May 27 01:02:03 CEST 2013) Proceeding with regular server password change scheduled for today run-parts: executing /usr/lib/univention-server/server_password_change.d/50univention-mail-server prechange Create mail/postfix/stoppedbyserverpasswordchange Module: zarafa-cfg Stopping Postfix Mail Transport Agent: postfix. run-parts: executing /usr/lib/univention-server/server_password_change.d/70zarafa prechange run-parts: executing /usr/lib/univention-server/server_password_change.d/univention-bind prechange run-parts: executing /usr/lib/univention-server/server_password_change.d/univention-dhcp prechange run-parts: executing /usr/lib/univention-server/server_password_change.d/univention-libnss-ldap prechange run-parts: executing /usr/lib/univention-server/server_password_change.d/univention-nscd prechange run-parts: executing /usr/lib/univention-server/server_password_change.d/univention-samba4 prechange Object modified: cn=backoffice,cn=dc,cn=computers,dc=travelbit,dc=intranet Restarting univention-directory-listener daemon. ok: run: univention-directory-listener: (pid 13043) 1s, normally down done. run-parts: executing /usr/lib/univention-server/server_password_change.d/50univention-mail-server postchange Multifile: /etc/postfix/ldap.distlist Multifile: /etc/postfix/ldap.groups Multifile: /etc/postfix/ldap.canonicalsender Multifile: /etc/postfix/ldap.sharedfolderlocal Multifile: /etc/postfix/ldap.virtualwithcanonical Multifile: /etc/postfix/ldap.sharedfolderremote Multifile: /etc/postfix/ldap.virtual Multifile: /etc/postfix/ldap.canonicalrecipient Multifile: /etc/postfix/ldap.transport Multifile: /etc/postfix/ldap.virtualdomains Starting Postfix Mail Transport Agent: postfix. Unsetting mail/postfix/stoppedbyserverpasswordchange Module: zarafa-cfg run-parts: executing /usr/lib/univention-server/server_password_change.d/70zarafa postchange Setting zarafa/cfg/ldap/ldap_bind_passwd Module: zarafa-cfg Reloading Zarafa server: zarafa-server. run-parts: executing /usr/lib/univention-server/server_password_change.d/univention-bind postchange run-parts: executing /usr/lib/univention-server/server_password_change.d/univention-dhcp postchange Restarting univention-dhcp daemon. ok: run: univention-dhcp: (pid 13200) 0s, normally down done. run-parts: executing /usr/lib/univention-server/server_password_change.d/univention-libnss-ldap postchange File: /etc/libnss-ldap.conf run-parts: executing /usr/lib/univention-server/server_password_change.d/univention-nscd postchange Restarting NSCD:. run-parts: executing /usr/lib/univention-server/server_password_change.d/univention-samba4 postchange Modified 1 records successfully Changed password OK done (Mon May 27 01:02:25 CEST 2013)

Die Zeiten sind ja relativ eindeutig. Ich hab den pw-change mit dem ucr set-Befehl ausgeschaltet. Wenn ich ausgeschlafen habe, dann gucke ich mal weiter.

tnx und Gruss
Andreas


#6

Mal ein Zwischenstand:
Nach dem Ausschalten hat es bislang keine weiteren Probleme gegeben.
Danke und Gruss
Andreas


#7

Hallo,

die von mir vorgeschlagene vorläufige Workaround muß noch ergänzt werden.

Zunächst einmal sollte man sich das Konzept des Passwortwechsels für Maschinenkonten ansehen. Aktualisierung der Maschinenpasswörter in UCS Domänen.
Bei der Integration von Zarafa in UCS wird das Maschinenkonto für den LDAP-Zugriff benutzt (/etc/zarafa/ldap.cfg).
Wenn das Passwort des Maschinenkontos geändert wird, muss (über /usr/lib/univention-server/server_password_change.d/70zarafa) auch der LDAP-Zugriff geändert werden.
Im Moment erfordert diese Änderung einen Restart von “zarafa-server”. Im Zuge der Lösung von UCS server password change requires a restart of zarafa-server instead of a reload wurde entschieden, auf einen Neustart zu verzichten und statt dessen den Passwortwechsel zu deaktivieren. Für einen dedizierten Zarafa-Server ist das ggf. eine akzeptable Lösung.

Bei der c’t Edition müssen wir aber beachten, dass das Maschinenkonto auch für Samba4 relevant ist (vgl. [bug]24703[/bug]. Wenn wir den Passwortwechsel dauerhaft deaktivieren, könnte es passieren, dass wir damit den Server aus der Sambadomäne aussperren.

Ich habe im Moment 2 Vorschläge zur Lösung. Sie müssten sich bis zum 17.6. für eine entscheiden.

1. Kennwortwechsel der Maschine und Passwortrichtlinie in Samba deaktivieren
In Ergänzung zu meinem vorherigen Vorschlag:

[code]root@ctmaster:~# samba-tool domain passwordsettings show
Password informations for domain ‘DC=mobildemo,DC=it25,DC=de’

Password complexity: on
Store plaintext passwords: off
Password history length: 24
Minimum password length: 7
Minimum password age (days): 1
Maximum password age (days): 42
root@ctmaster:~# udm settings/sambadomain list

DN: sambaDomainName=MOBILDEMO,cn=samba,dc=mobildemo,dc=it25,dc=de
ARG: None
NextUserRid: 1000
passwordHistory: 24
SID: S-1-5-21-715694293-4175324966-4058725619
badLockoutAttempts: None
NextGroupRid: 1000
passwordLength: 7
resetCountMinutes: None
minPasswordAge: 1 days
name: MOBILDEMO
lockoutDuration: 30 minutes
refuseMachinePWChange: None
NextRid: None
disconnectTime: None
maxPasswordAge: 42 days
logonToChangePW: None

root@ctmaster:~# udm settings/sambadomain modify --dn “sambaDomainName=MOBILDEMO,cn=samba,dc=mobildemo,dc=it25,dc=de” --set maxPasswordAge=0
Object modified: sambaDomainName=MOBILDEMO,cn=samba,dc=mobildemo,dc=it25,dc=de
root@ctmaster:~# samba-tool domain passwordsettings show
Password informations for domain ‘DC=mobildemo,DC=it25,DC=de’

Password complexity: on
Store plaintext passwords: off
Password history length: 24
Minimum password length: 7
Minimum password age (days): 1
Maximum password age (days): 0
[/code]

2. zarafa-server beim Wechsel des Maschinenkennwortes neu starten
Nach dem Sie “server/password/change” wieder auf ‘yes’ gesetzt haben, ändern Sie in Zeile 48 in /usr/lib/univention-server/server_password_change.d/70zarafa von “reload” auf “restart”.

Ich selbst sehe in einem Neustart kein Problem. Zum Einen passiert das zu einer Zeit, bei der wenige Clients betroffen sind. Zum Anderen sollten eigentlich mittlerweile alle Clients mit kurzzeitigen Disconnects klarkommen. Wenn man Zarafa mit Pacemaker hochverfügbar macht, wird schließlich bei einem Failover auch alles durchgestartet.
Sie müssen dann allerdings ein Auge darauf haben, was in einer nächsten Version des Paketes zarafa4ucs mit der Änderung passiert. Das dürfte mit Zarafa 7.2 der Fall sein.

Viele Grüße,
Dirk Ahrnke


LDAP search error vs. "503 5.1.1 User does not exist"
#8

Hallo Herr Ahrnke,

vom mir aus (= meinem Sicherheitsbedürfnis) könnte der Passwortwechsel auch dauerhaft ausgeschaltet bleiben. Es wäre nur schlecht, wenn damit die Mailkomponente ausgesperrt bleibt und dann u.U. wieder Mails mit ‘Empfänger unbekannt’ gebounced werden. Von daher werde ich erst den Wechsel und dann den Restart wieder einschalten und das ganze beobachten, wenn eine neue Zarafa-Version eingespielt wird.

Vielen Dank für Ihre kompetente Unterstützung.

Viele Grüsse
Andreas Weiss