Univention Bugzilla – Bug 12907
[Cyrus] Anmeldung mit UID
Last modified: 2013-11-19 13:34:21 CET
Müsste man sich mit cyradm nicht auch mit der UID anmelden können, da ja pam_univentionmailcyrus.so nicht zwangsläufig die Mail-Adresse in die UID umwandelt? sschwardt@slugis:~$ cyradm --authz=sschwardt --user=sschwardt localhost IMAP Password: Login failed: authentication failure at /usr/lib/perl5/Cyrus/IMAP/Admin.pm line 119 cyradm: cannot authenticate to server as sschwardt sschwardt@slugis:~$
Dachte ich bis eben auch.. aber in /etc/pam.d/imap steht: auth requisite pam_univentionmailcyrus.so ldap_host=qamaster.univention.de ldap_base=dc=univention,dc=qa from_attr=mailPrimaryAddress to_attr=uid Wenn man aus requisite optional macht, geht es.
Ticket#: 2010033010000651 Das wird öfter angefragt...
Die Einschätzungen oben beziehen sich auf den Fall wo die UID mit dem lokalen Teil der Mailadresse, und damit im Wesentlichen mit dem Mailboxnamen übereinstimmt. Wenn das nicht der Fall ist, ist die Sache komplizierter. Mail-Clients wie Horde können in diesem Fall natürlich vor dem Login ein Mapping von der UID auf den Mailboxnamen vornehmen, aber wenn man das serverseitig lösen will, geht das zur Zeit wohl nicht ohne Anpassung des IMAP-Servers: Ich denke, dass cyrus generell über den username (authz) den Namen der Mailbox zuordnet. Wenn das so ist, dann müsste da wohl ein Patch wie der KOLAB_cyrus-imapd-2.3.16_UID.patch aus http://www.kolab.org/pipermail/kolab-commits/2009q4/011053.html in cyrus2.2 eingebaut werden. Eine SASL-Authentifizierung mit authn != authz funktioniert wohl nur für Benutzer, die in imapd.conf als "admin" eingetragen sind: root@qamaster:~# imtest -s -a cyrus -u bob@univention.qa \ -w $(cat /etc/cyrus.secret) localhost verify error:num=20:unable to get local issuer certificate verify error:num=27:certificate not trusted verify error:num=21:unable to verify the first certificate TLS connection established: TLSv1 with cipher AES256-SHA (256/256 bits) S: * OK qamaster Cyrus IMAP4 v2.2.13-Debian-2.2.13-14.53.201001081230 server ready C: C01 CAPABILITY S: * CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ NAMESPACE UIDPLUS ID NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE IDLE AUTH=PLAIN SASL-IR S: C01 OK Completed C: A01 AUTHENTICATE PLAIN Ym9iQHVuaXZlbnRpb24ucWEAY3lydXMAQ3pzaTVK S: A01 OK Success (tls protection) Authenticated. Security strength factor: 256 . list "" * * LIST (\HasChildren) "/" "INBOX" * LIST (\HasNoChildren) "/" "INBOX/Ham" * LIST (\HasNoChildren) "/" "INBOX/Spam" . OK Completed (0.000 secs 4 calls) . select inbox * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) * OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen \*)] * 1 EXISTS * 0 RECENT * OK [UNSEEN 1] * OK [UIDVALIDITY 1267017974] * OK [UIDNEXT 2] . OK [READ-WRITE] Completed . logout * BYE LOGOUT received . OK Completed Connection closed Note: cyradm geht so auch nicht ohne weiteres, da man eine SSL-Verbindung für PLAIN login benötigt: shell# stunnel -c -d 8143 -r localhost:993 shell# cyradm -p 8143 -u cyrus --authz bob@univention.qa \ -w $(cat /etc/cyrus.secret) localhost # funktioniert jedes 2. Mal..
Es gibt noch eine weitere Alternative: an kann wohl das authz-Mapping über SASL erledigen zu lassen, aber ich weiss nicht, ob das schon durch eine aktuelle libsasl in cyrus2.2 verfügbar ist, oder erst ab cyrus-2.3: http://lists.andrew.cmu.edu/pipermail/info-cyrus/2009-January/030410.html Im Kern würde das in imapd.conf durch folgende Zeilen aktiviert: sasl_canon_user_plugin: ldapdb sasl_ldapdb_canon_attr: mail # to mail allerdings muss dafür dann auch das ldapdb ausprop-Plugin konfiguriert werden, was wahrscheinlich etwas komplexer ist: 1. Im UCS-Verzeichnisdienst ein administratives proxy-user Authentisierungs-Objekt für ldapdb anlegen. 2. In imapd.conf über sasl_ldapdb_uri sasl_ldapdb_id etc. die Daten für ein LDAP-Bind der ldpadb_id hinterlegen (SASL-Mech PLAIN (über ldapi oder TLS) oder GSSAPI) 3. In slapd.conf über ein authz-regexp den SASL-DN der ldapdb_id auf die DN des administrativen proxy-user Authentisierungs-Objekts mappen 4. In slapd.conf z.B. über ein authzTo-Attribut an dem administrativen proxy-user Authentisierungs-Objekt den ldpadb_id-Proxy-User dazu berechtigen, die Rolle bestimmter Benutzer zu übernehmen. Ob der letzte Schritt tatsächlich für das canon_user_plugin notwendig ist, müsste man dann mal testen. Eigentlich braucht man das nur, wenn auxprop als sasl_pwcheck_method und ldapdb als sasl_auxprop_plugin zur Benutzer-Authentifikation verwendet wird. Ggf. sind in der Diskussion zwischen dem Entwickler und Howard Chu (Autor des ldapdb Plugins) weitere Hinweise zu finden: http://cyrusimap.web.cmu.edu/archive/message.php?mailbox=archive.cyrus-sasl&msg=8395 Man sollte dabei dann allerdings bedenken, dass man login per Mail-Adresse trotzdem weiter ermöglichen will.
I asked the support if this is still relevant, but no such request in the past two years. Horde/zarafa/ox login with the uid is possible (mapping is done in the application itself). I think we don't need this.