Re: cyradm cannot connect to cyrus imap server
Dear Cyrus Friends, On Thu, Feb 20, 2014 at 04:12:29PM -0600, Scott Lambert wrote: On Thu, Feb 20, 2014 at 10:35:42AM +0100, Willy Offermans wrote: Dear Cyrus Friends, I need your help to solve the following: I'm setting up cyrus on my new FreeBSD 10.0 server. I have used the following package: cyrus-imapd24-2.4.17_4 If I test my setup with imtest, I get connection to the imap server. MyName@MyComputer:~$ imtest -m login -u username -a username -s localhost It works However, if I try to connect via cyradm, I cannot login. MyName@MyComputer:~$ cyradm --user username localhost Password: verify error:num=19:self signed certificate in certificate chain cyradm: cannot authenticate to server with as username You specified your authentication mechanism to be login with imtest. You did not specify an authentication mechanism with cyradm. Perhaps it would work if you try : cyradm --auth login --user username localhost That is only a guess. -- Scott LambertKC5MLE Unix SysAdmin lamb...@lambertfam.org Indeed, I needed to specify an authentication mechanism and then I could use the command line interface of cyradm: cyradm --user username --auth PLAIN localhost If we are at this point anyway, I was wondering what I need to do to use another authentication mechanism. Is this possible? And what do I need to consider? The IMAP server response with the following authentication mechanism: AUTH=SCRAM-SHA-1 AUTH=DIGEST-MD5 AUTH=CRAM-MD5 AUTH=NTLM AUTH=PLAIN AUTH=LOGIN If I login with SCRAM-SHA-1: MyName@MyComputer:~$ cyradm --user username --auth SCRAM-SHA-1 localhost Password: verify error:num=19:self signed certificate in certificate chain cyradm: cannot authenticate to server with SCRAM-SHA-1 as username In the logs: Feb 21 09:48:36 MyComputer imap[17576]: badlogin: localhost [127.0.0.1] SCRAM-SHA-1 [SASL(-13): user not found: unable to canonify user and get auxprops] I'm pretty sure that the user is registered in the ldap database. -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, De jrus wah, Wiel * W.K. Offermans Home: +31 45 544 49 44 Mobile: +31 681 15 87 68 e-mail: wi...@offermans.rompen.nl Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
replication does not work
Dear cyrus friends, I like to use the replication feature of cyrus. On the backend I changed the cyrus.conf file. I added: syncservercmd=/usr/local/cyrus/bin/sync_server listen=csync to the SERVICES. On the client side I changed the imapd.conf file and cyrus.conf file in the following way. cyrus.conf: I added syncclientcmd=/usr/local/cyrus/bin/sync_client -l -r to the START section. imapd.conf: I added sync_host: MyComputer.example.com sync_authname: username sync_log: 1 sync_password: secret I also did some changes to the services file to add csync and portnumbers. If I run ClientComputer# synctest -u username -a username -t '' -m PLAIN MyComputer.example.com S: * SASL SCRAM-SHA-1 DIGEST-MD5 CRAM-MD5 NTLM S: * STARTTLS S: * COMPRESS DEFLATE S: * OK MyComputer Cyrus sync server v2.4.17 C: STARTTLS S: OK Begin TLS negotiation now verify error:num=19:self signed certificate in certificate chain TLS connection established: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits) S: * SASL SCRAM-SHA-1 DIGEST-MD5 CRAM-MD5 NTLM PLAIN LOGIN S: * OK MyComputer Cyrus sync server v2.4.17 Please enter your password: C: AUTHENTICATE PLAIN sdjaskjfksfhsdfksfdasdkkfjsfdaksjkfjksfjksfjlfjkfjkj S: OK Success (tls protection) Authenticated. Security strength factor: 256 So everything seems to be fine However if I restart imapd on the client, I do not get any synchronization. I found the following message in the logs of the client: Feb 20 16:01:42 ClientComputer sync_client[36229]: couldn't authenticate to backend server: authentication failure I found the following message in the logs of the backend: Feb 20 16:01:39 MyComputer syncserver[15127]: OTP unavailable because can't read/write key database /etc/opiekeys: Permission denied Feb 20 16:01:39 MyComputer syncserver[15127]: badlogin: ClientComputer.example.com [192.168.0.15] SCRAM-SHA-1 [SASL(-13): user not found: unable to canonify user and get auxprops] Feb 20 16:01:57 MyComputer syncserver[15127]: OTP unavailable because can't read/write key database /etc/opiekeys: Permission denied Feb 20 16:01:57 MyComputer syncserver[15127]: badlogin: ClientComputer.example.com [192.168.0.15] SCRAM-SHA-1 [SASL(-13): user not found: unable to canonify user and get auxprops] Feb 20 16:02:30 MyComputer syncserver[15127]: OTP unavailable because can't read/write key database /etc/opiekeys: Permission denied Feb 20 16:02:30 MyComputer syncserver[15127]: badlogin: ClientComputer.example.com [192.168.0.15] SCRAM-SHA-1 [SASL(-13): user not found: unable to canonify user and get auxprops] Feb 20 16:03:33 MyComputer syncserver[15127]: OTP unavailable because can't read/write key database /etc/opiekeys: Permission denied Feb 20 16:03:33 MyComputer syncserver[15127]: badlogin: ClientComputer.example.com [192.168.0.15] SCRAM-SHA-1 [SASL(-13): user not found: unable to canonify user and get auxprops] Feb 20 16:05:36 MyComputer syncserver[15136]: OTP unavailable because can't read/write key database /etc/opiekeys: Permission denied Feb 20 16:05:36 MyComputer syncserver[15136]: badlogin: ClientComputer.example.com [192.168.0.15] SCRAM-SHA-1 [SASL(-13): user not found: unable to canonify user and get auxprops] Or if I directly call for sync_client: MyComputer# /usr/local/cyrus/bin/sync_client -o -l -S 192.168.X.Y -r MyComputer# Can not connect to server '192.168.X.Y' I guess I'm missing the authentication mechanism for the sync_client, but I'm not sure. Can someone help me out? -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, De jrus wah, Wiel * W.K. Offermans Home: +31 45 544 49 44 Mobile: +31 681 15 87 68 e-mail: wi...@offermans.rompen.nl Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: cyradm cannot connect to cyrus imap server
On 02/21/14 10:50 +0100, Willy Offermans wrote: Indeed, I needed to specify an authentication mechanism and then I could use the command line interface of cyradm: cyradm --user username --auth PLAIN localhost If we are at this point anyway, I was wondering what I need to do to use another authentication mechanism. Is this possible? And what do I need to consider? The IMAP server response with the following authentication mechanism: AUTH=SCRAM-SHA-1 AUTH=DIGEST-MD5 AUTH=CRAM-MD5 AUTH=NTLM AUTH=PLAIN AUTH=LOGIN If I login with SCRAM-SHA-1: MyName@MyComputer:~$ cyradm --user username --auth SCRAM-SHA-1 localhost Password: verify error:num=19:self signed certificate in certificate chain cyradm: cannot authenticate to server with SCRAM-SHA-1 as username In the logs: Feb 21 09:48:36 MyComputer imap[17576]: badlogin: localhost [127.0.0.1] SCRAM-SHA-1 [SASL(-13): user not found: unable to canonify user and get auxprops] I'm pretty sure that the user is registered in the ldap database. DIGEST-MD5, CRAM-MD5, and SCRAM-SHA-1 all require cyrus sasl to have access to the shared secret (clear text password) to complete authentication. If you're using LDAP to store your user credentials, you'll need to use the ldapdb auxprop plugin and store users' clear text passwords in userPassword. Presumably you're using 'sasl_pwcheck_method: saslauthd' currently, which is sufficient for PLAIN and LOGIN authentication. If you choose not to go the ldapdb route, I recommend specifying a sasl_mech_list to limit your mechanisms to PLAIN and LOGIN (and EXTERNAL if you intend to do starttls client authentication). If you don't do that, in your current setup, most clients will attempt to first authenticate using a shared secret mechanism (including cyradm in your initial attempt), which will always fail on that attempt. -- Dan White Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: cyradm cannot connect to cyrus imap server
Hallo Dan, On Fri, Feb 21, 2014 at 08:50:41AM -0600, Dan White wrote: On 02/21/14 10:50 +0100, Willy Offermans wrote: Indeed, I needed to specify an authentication mechanism and then I could use the command line interface of cyradm: cyradm --user username --auth PLAIN localhost If we are at this point anyway, I was wondering what I need to do to use another authentication mechanism. Is this possible? And what do I need to consider? The IMAP server response with the following authentication mechanism: AUTH=SCRAM-SHA-1 AUTH=DIGEST-MD5 AUTH=CRAM-MD5 AUTH=NTLM AUTH=PLAIN AUTH=LOGIN If I login with SCRAM-SHA-1: MyName@MyComputer:~$ cyradm --user username --auth SCRAM-SHA-1 localhost Password: verify error:num=19:self signed certificate in certificate chain cyradm: cannot authenticate to server with SCRAM-SHA-1 as username In the logs: Feb 21 09:48:36 MyComputer imap[17576]: badlogin: localhost [127.0.0.1] SCRAM-SHA-1 [SASL(-13): user not found: unable to canonify user and get auxprops] I'm pretty sure that the user is registered in the ldap database. DIGEST-MD5, CRAM-MD5, and SCRAM-SHA-1 all require cyrus sasl to have access to the shared secret (clear text password) to complete authentication. If you're using LDAP to store your user credentials, you'll need to use the ldapdb auxprop plugin and store users' clear text passwords in userPassword. Presumably you're using 'sasl_pwcheck_method: saslauthd' currently, which is sufficient for PLAIN and LOGIN authentication. If you choose not to go the ldapdb route, I recommend specifying a sasl_mech_list to limit your mechanisms to PLAIN and LOGIN (and EXTERNAL if you intend to do starttls client authentication). If you don't do that, in your current setup, most clients will attempt to first authenticate using a shared secret mechanism (including cyradm in your initial attempt), which will always fail on that attempt. -- Dan White Thank you a lot for the clarification. I did some search on the internet myself and I got some increased understanding myself. I changed the imapd.conf on the imap server and added: sasl_mech_list: PLAIN LOGIN to the settings. This solved several issues. So I can already confirm your suggestion for solution. But many thnx anyway. You are pointing to EXTERNAL, next to PLAIN and LOGIN. I do not understand this mechanism yet. At the moment I believe I have PLAIN password wrapped into TLS. So I already do starttls client authentication. What will EXTERNAL do? -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, De jrus wah, Wiel * W.K. Offermans Home: +31 45 544 49 44 Mobile: +31 681 15 87 68 e-mail: wi...@offermans.rompen.nl Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: cyradm cannot connect to cyrus imap server
On 02/21/14 16:11 +0100, Willy Offermans wrote: You are pointing to EXTERNAL, next to PLAIN and LOGIN. I do not understand this mechanism yet. At the moment I believe I have PLAIN password wrapped into TLS. So I already do starttls client authentication. What will EXTERNAL do? TLS client authentication is a scenario where you perform TLS authentication where the client also has a certificate. The server can then use the contents of the client certificate to derive the username (with no password, per se). For example, 'cyradm --tlskey file'. The EXTERNAL mechanism should not be offered unless TLS client authentication was successful during the starttls step. -- Dan White Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: cyradm cannot connect to cyrus imap server
Hello Dan, On Fri, Feb 21, 2014 at 09:22:55AM -0600, Dan White wrote: On 02/21/14 16:11 +0100, Willy Offermans wrote: You are pointing to EXTERNAL, next to PLAIN and LOGIN. I do not understand this mechanism yet. At the moment I believe I have PLAIN password wrapped into TLS. So I already do starttls client authentication. What will EXTERNAL do? TLS client authentication is a scenario where you perform TLS authentication where the client also has a certificate. The server can then use the contents of the client certificate to derive the username (with no password, per se). For example, 'cyradm --tlskey file'. The EXTERNAL mechanism should not be offered unless TLS client authentication was successful during the starttls step. -- Dan White This sounds interesting. I thought that TLSVerifyClient demand in slapd.conf was forcing this behavior. I like to read more about the EXTERNAL mechanism. Do you recommend some reading? At the moment I will stick to PLAIN and play with replication, serving multiple domains etc. -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, De jrus wah, Wiel * W.K. Offermans Home: +31 45 544 49 44 Mobile: +31 681 15 87 68 e-mail: wi...@offermans.rompen.nl Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: cyradm cannot connect to cyrus imap server
On 02/21/14 16:33 +0100, Willy Offermans wrote: This sounds interesting. I thought that TLSVerifyClient demand in slapd.conf was forcing this behavior. I like to read more about the EXTERNAL mechanism. Do you recommend some reading? At the moment I will stick to PLAIN and play with replication, serving multiple domains etc. A TLS primer would be the best place to start. A problem that you may encounter with EXTERNAL over STARTTLS, is that the username mapping process is not standardized, and is left up to the server implementation to perform. Cyrus imapd and slapd may do so in inconsistent ways. -- Dan White Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: replication does not work
Dear cyrus friends, On Fri, Feb 21, 2014 at 03:48:20PM +0100, Willy Offermans wrote: Dear cyrus friends, I like to use the replication feature of cyrus. On the backend I changed the cyrus.conf file. I added: syncservercmd=/usr/local/cyrus/bin/sync_server listen=csync to the SERVICES. On the client side I changed the imapd.conf file and cyrus.conf file in the following way. cyrus.conf: I added syncclientcmd=/usr/local/cyrus/bin/sync_client -l -r to the START section. imapd.conf: I added sync_host: MyComputer.example.com sync_authname: username sync_log: 1 sync_password: secret I also did some changes to the services file to add csync and portnumbers. If I run ClientComputer# synctest -u username -a username -t '' -m PLAIN MyComputer.example.com S: * SASL SCRAM-SHA-1 DIGEST-MD5 CRAM-MD5 NTLM S: * STARTTLS S: * COMPRESS DEFLATE S: * OK MyComputer Cyrus sync server v2.4.17 C: STARTTLS S: OK Begin TLS negotiation now verify error:num=19:self signed certificate in certificate chain TLS connection established: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits) S: * SASL SCRAM-SHA-1 DIGEST-MD5 CRAM-MD5 NTLM PLAIN LOGIN S: * OK MyComputer Cyrus sync server v2.4.17 Please enter your password: C: AUTHENTICATE PLAIN sdjaskjfksfhsdfksfdasdkkfjsfdaksjkfjksfjksfjlfjkfjkj S: OK Success (tls protection) Authenticated. Security strength factor: 256 So everything seems to be fine However if I restart imapd on the client, I do not get any synchronization. I found the following message in the logs of the client: Feb 20 16:01:42 ClientComputer sync_client[36229]: couldn't authenticate to backend server: authentication failure I found the following message in the logs of the backend: Feb 20 16:01:39 MyComputer syncserver[15127]: OTP unavailable because can't read/write key database /etc/opiekeys: Permission denied Feb 20 16:01:39 MyComputer syncserver[15127]: badlogin: ClientComputer.example.com [192.168.0.15] SCRAM-SHA-1 [SASL(-13): user not found: unable to canonify user and get auxprops] Feb 20 16:01:57 MyComputer syncserver[15127]: OTP unavailable because can't read/write key database /etc/opiekeys: Permission denied Feb 20 16:01:57 MyComputer syncserver[15127]: badlogin: ClientComputer.example.com [192.168.0.15] SCRAM-SHA-1 [SASL(-13): user not found: unable to canonify user and get auxprops] Feb 20 16:02:30 MyComputer syncserver[15127]: OTP unavailable because can't read/write key database /etc/opiekeys: Permission denied Feb 20 16:02:30 MyComputer syncserver[15127]: badlogin: ClientComputer.example.com [192.168.0.15] SCRAM-SHA-1 [SASL(-13): user not found: unable to canonify user and get auxprops] Feb 20 16:03:33 MyComputer syncserver[15127]: OTP unavailable because can't read/write key database /etc/opiekeys: Permission denied Feb 20 16:03:33 MyComputer syncserver[15127]: badlogin: ClientComputer.example.com [192.168.0.15] SCRAM-SHA-1 [SASL(-13): user not found: unable to canonify user and get auxprops] Feb 20 16:05:36 MyComputer syncserver[15136]: OTP unavailable because can't read/write key database /etc/opiekeys: Permission denied Feb 20 16:05:36 MyComputer syncserver[15136]: badlogin: ClientComputer.example.com [192.168.0.15] SCRAM-SHA-1 [SASL(-13): user not found: unable to canonify user and get auxprops] Or if I directly call for sync_client: MyComputer# /usr/local/cyrus/bin/sync_client -o -l -S 192.168.X.Y -r MyComputer# Can not connect to server '192.168.X.Y' I guess I'm missing the authentication mechanism for the sync_client, but I'm not sure. Can someone help me out? I can answer my own question. I was indeed missing the authentication mechanism. I added sasl_mech_list: PLAIN LOGIN to imapd.conf on the back-end server and the replication worked. So I wonder how I can tell sync_client which authentication mechanism to use? It seems like a feature request to me? or a hidden option to the sync_client executable. I'm playing with replication now and testing what happens if one deletes e-mails on the back-end server and not on the client. Will these mails be restored on the back-end by replication and when? -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, De jrus wah, Wiel * W.K. Offermans Home: +31 45 544 49 44 Mobile: +31 681 15 87 68 e-mail: wi...@offermans.rompen.nl Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: replication does not work
Hi, Am Freitag, den 21.02.2014, 17:23 +0100 schrieb Willy Offermans: [...] I can answer my own question. I was indeed missing the authentication mechanism. I added sasl_mech_list: PLAIN LOGIN to imapd.conf on the back-end server and the replication worked. So I wonder how I can tell sync_client which authentication mechanism to use? It seems like a feature request to me? or a hidden option to the sync_client executable. That's an interesting question. I had a similar problem this week to force master and slave to sync via TLS. As long as the banner on slave side offered DIGEST-MD5 CRAM-MD5 NTLM LOGIN PLAIN to connection plain. I set allowplaintext: no and sasl_mech_list: PLAIN on slave and now both are talking PLAIN via TLS. So if there is an option on master side to force to login using eg. CRAM-MD5 then there might be an option too to force TLS. I'm playing with replication now and testing what happens if one deletes e-mails on the back-end server and not on the client. Will these mails be restored on the back-end by replication and when? Don't understand, what is the client, the replica server? Ciao! Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: replication does not work
On Fri, 21 Feb 2014, Marcus Schopen wrote: Hi, Am Freitag, den 21.02.2014, 17:23 +0100 schrieb Willy Offermans: [...] I can answer my own question. I was indeed missing the authentication mechanism. I added sasl_mech_list: PLAIN LOGIN to imapd.conf on the back-end server and the replication worked. So I wonder how I can tell sync_client which authentication mechanism to use? It seems like a feature request to me? or a hidden option to the sync_client executable. That's an interesting question. I had a similar problem this week to force master and slave to sync via TLS. As long as the banner on slave side offered DIGEST-MD5 CRAM-MD5 NTLM LOGIN PLAIN to connection plain. I set allowplaintext: no and sasl_mech_list: PLAIN on slave and now both are talking PLAIN via TLS. So if there is an option on master side to force to login using eg. CRAM-MD5 then there might be an option too to force TLS. I'm playing with replication now and testing what happens if one deletes e-mails on the back-end server and not on the client. Will these mails be restored on the back-end by replication and when? Don't understand, what is the client, the replica server? Have you looked at the sasl_minimum_layer option? sasl_minimum_layer: 0 The minimum SSF that the server will allow a client to negotiate. A value of 1 requires integrity protection; any higher value requires some amount of encryption. Andy Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: replication does not work
Hi Andrew, Am Freitag, den 21.02.2014, 11:21 -0800 schrieb Andrew Morgan: On Fri, 21 Feb 2014, Marcus Schopen wrote: Hi, Am Freitag, den 21.02.2014, 17:23 +0100 schrieb Willy Offermans: [...] I can answer my own question. I was indeed missing the authentication mechanism. I added sasl_mech_list: PLAIN LOGIN to imapd.conf on the back-end server and the replication worked. So I wonder how I can tell sync_client which authentication mechanism to use? It seems like a feature request to me? or a hidden option to the sync_client executable. That's an interesting question. I had a similar problem this week to force master and slave to sync via TLS. As long as the banner on slave side offered DIGEST-MD5 CRAM-MD5 NTLM LOGIN PLAIN to connection plain. I set allowplaintext: no and sasl_mech_list: PLAIN on slave and now both are talking PLAIN via TLS. So if there is an option on master side to force to login using eg. CRAM-MD5 then there might be an option too to force TLS. I'm playing with replication now and testing what happens if one deletes e-mails on the back-end server and not on the client. Will these mails be restored on the back-end by replication and when? Don't understand, what is the client, the replica server? Have you looked at the sasl_minimum_layer option? sasl_minimum_layer: 0 The minimum SSF that the server will allow a client to negotiate. A value of 1 requires integrity protection; any higher value requires some amount of encryption. Andy Many thanks for your response. Yes, I've tried sasl_minimum_layer with values from 1 up to 100. But even then the master doesn't start a TLS connection to the replica. Hmm Cheers from Germany Marcus Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
