Bug 37814 - mailPrimaryAddress vs. uid as username
mailPrimaryAddress vs. uid as username
Product: UCS
Classification: Unclassified
Component: Mail
UCS 4.1
Other Linux
: P5 normal (vote)
: ---
Assigned To: Mail maintainers
: 40109 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2015-02-16 16:22 CET by Janis Meybohm
Modified: 2019-01-03 07:23 CET (History)
8 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 2: Improvement: Would be a product improvement
Who will be affected by this bug?: 2: Will only affect a few installed domains
How will those affected feel about the bug?: 2: A Pain – users won’t like this once they notice it
User Pain: 0.046
Enterprise Customer affected?: Yes
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number: 2015021621000113 2015112621000131
Bug group (optional): External feedback, Usability
Max CVSS v3 score:


Note You need to log in before you can comment on or make changes to this bug.
Description Janis Meybohm univentionstaff 2015-02-16 16:22:14 CET

Login to mail services (SMTP/IMAP/POP3) require mailPrimaryAddress:Password for authentication but in most cases Username:Password is accepted too.

If users clients are configured with Username:Password and they change their password (in S4 environments), userPassword is set to {KINIT} and authentication against the mail services fail:
(pam_unix fails and pam_univentionmailcyrus can't map the "useranme" so the PAM stack exits with "PAM auth error")

Feb 16 12:13:42 master saslauthd[4051]: pam_unix(smtp:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=  user=tim
Feb 16 12:13:42 master PAM-univentionmailcyrus[4051]: No or ambigous result, found 0 entries.
Feb 16 12:13:42 master PAM-univentionmailcyrus[4051]: failed to map username

This happens "silently" as neither the admin nor the user "hash changed anything".

This only appears strange primarily but gets worse for example when Zarafa is used as the users need to use/configure different authentication information for the "same" service. An example:

* Zarafa Webapp (LDAP-Bind): Username and Password
* Thunderbird SMTP (pam_univentionmailcyrus): mailPrimaryAddress and Password
* Thunderbird IMAP/POP (LDAP-Bind via Zarafa): Username and Password

I don't know a good solution to this problem. Maybe we should ensure that Username:Password works (which is difficult for multi server/multi domain setups) or we should ensure that Username:Password never works as this won't lead to misconfigured clients in first place.
Comment 1 Sönke Schwardt-Krummrich univentionstaff 2015-11-26 12:54:45 CET
*** Bug 40109 has been marked as a duplicate of this bug. ***
Comment 2 Daniel Tröder univentionstaff 2015-11-26 13:23:14 CET
I also think, that for all cases Auth should be configured for web, imap and smtp to be the same, but there there could be different cases. Apps could change the way authentication is done in a consistent way:

* Zarafa Web : username, Zarafa-IMAP: username, UCS-Postfix: email
* OX Web : username, UCS-Dovecot: email OR UCS-Cyrus: username, UCS-Postfix: email
* UCS mailserver IMAP-Cyrus: username OR IMAP-Dovecot: email, UCS-Postfix: email
* Horde Web: ? IMAP: ?, SMTP: ?
* Egroupware Web: ? IMAP: ?, SMTP: ?

A UCRV could configure the allowed LDAP attributes for the same auth for web+imap+smtp.
Comment 3 Jens Thorp-Hansen univentionstaff 2015-12-07 12:21:46 CET
Has also been reported at Ticket#2015112621000131.
Comment 4 Dirk Ahrnke 2016-12-20 17:38:59 CET

For Zarafa+UCS it is a challenge to configure a very basic integration which tries to fetch messages from Zarafa using POP3/IMAP and send messages through SMTP if there is just one user:password pair to configure.
Comment 5 Ralf Becker 2017-02-02 15:56:22 CET
EGroupware App currently used mailPrimaryAddress for IMAP, SMTP and Sieve, but can be configured to use uid.
Comment 6 Daniel Tröder univentionstaff 2017-11-10 12:43:53 CET
To allow the uid as a login for dovecot, remove line
"print auth" from univention-mail-dovecot/conffiles/etc/pam.d/dovecot.
Comment 7 Stefan Gohmann univentionstaff 2019-01-03 07:23:51 CET
This issue has been filled against UCS 4.1. The maintenance with bug and security fixes for UCS 4.1 has ended on 5st of April 2018.

Customers still on UCS 4.1 are encouraged to update to UCS 4.3. Please contact
your partner or Univention for any questions.

If this issue still occurs in newer UCS versions, please use "Clone this bug" or simply reopen the issue. In this case please provide detailed information on how this issue is affecting you.