Hello, Simo, do you have an idea what may be causing the problem?
Maria, generally, you can try to do two things on Zimbra server: $ kinit -kt <path to keytab used by Zimbra server> "imap/zimbrafreeipa.example....@fi.example.com" It should succeed. This will very that content of the keytab is okay. Regarding KRB5_TRACE trick: You have to find init script or systemd unit file which is used to start Zimbra server process. Edit that script and add KRB5_TRACE to it before the actual server start. Let us know your findings :-) Petr^2 Spacek On 25.11.2014 19:02, Maria Jose Yañez Dacosta wrote: > Sorry for delay in answering, I've been testing a few things before going > back to ask. > > Thanks for the advice, I'll be careful with security :). > > I also tried as is explained in the url you shared with me and as you > suspected that isn't the problem either. > > I installed Wireshark, packet capture shows me these errors: > > error_code: KRB5KRB_AP_ERR_BAD_INTEGRITY (31) > e-text: PREAUTH_FAILED > > Where the origin of these packages is the FreeIPA server and the > destination is the Zimbra server. > > I think this may be causing problems. > > I'm ashamed to say this, but haven't known as I have to do to debug Imap > process on the server using KRB5_TRACE. > > Thanks so much for all your help and if you have more suggestions, it would > be appreciated. > > Have a good day. > > > > > 2014-11-25 15:00 GMT-02:00 <freeipa-users-requ...@redhat.com>: > >> Send Freeipa-users mailing list submissions to >> freeipa-users@redhat.com >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://www.redhat.com/mailman/listinfo/freeipa-users >> or, via email, send a message with subject or body 'help' to >> freeipa-users-requ...@redhat.com >> >> You can reach the person managing the list at >> freeipa-users-ow...@redhat.com >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of Freeipa-users digest..." >> >> >> Today's Topics: >> >> 1. Re: Is it possible to set up SUDO with redudancy? >> (Lukas Slebodnik) >> 2. Re: Setting up a Kerberized IMAP Server. (Petr Spacek) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Tue, 25 Nov 2014 09:02:59 +0100 >> From: Lukas Slebodnik <lsleb...@redhat.com> >> To: William Muriithi <william.murii...@gmail.com> >> Cc: freeipa-users@redhat.com >> Subject: Re: [Freeipa-users] Is it possible to set up SUDO with >> redudancy? >> Message-ID: <20141125080259.gb2...@mail.corp.redhat.com> >> Content-Type: text/plain; charset=utf-8 >> >> On Mon, Nov 24, 2014 at 8:38 PM, William Muriithi < >> william.murii...@gmail.com> wrote: >> >>> Evening, >>> >>> After looking at almost all the SUDO documentation I could find, it looks >>> one has to hardcode FreeIPA hostname on sssd.conf file. Below is what red >>> hat advice to add in sssd config file. >>> >>> services = nss, pam, ssh, pac, sudo [domain/idm.coe.muc.redhat.com] >>> sudo_provider = ldap ldap_uri = ldap://grobi.idm.coe.muc.redhat.com >>> ldap_sudo_search_base = ou=sudoers,dc=idm,dc=coe,dc=muc,dc=redhat,dc=com >>> ldap_sasl_mech = GSSAPI ldap_sasl_authid = host/ >>> tiffy.idm.coe.muc.redhat.com ldap_sasl_realm = IDM.COE.MUC.REDHAT.COM >>> krb5_server = grobi.idm.coe.muc.redhat.com >>> >>> The implications of adding above is that SUDO would break if the >>> hardcoded ipa is not available even if there is another replica somewhere >>> in the network. Is that correct assumption? >>> >>> Is there a better way of doing it that I have missed? >>> >> >> Which version of sssd do you have? >> sssd >= 1.10 has native ipa suod providers and you don't need to use >> "sudo_provider = ldap". >> >> LS >> >> >> >> ------------------------------ >> >> Message: 2 >> Date: Tue, 25 Nov 2014 10:11:42 +0100 >> From: Petr Spacek <pspa...@redhat.com> >> To: freeipa-users@redhat.com >> Subject: Re: [Freeipa-users] Setting up a Kerberized IMAP Server. >> Message-ID: <547447ce.8090...@redhat.com> >> Content-Type: text/plain; charset=windows-1252 >> >> On 24.11.2014 17:45, Maria Jose Ya?ez Dacosta wrote: >>> Thank you for your prompt reply :). >>> >>> I still don't discover what caused the problem, but now I could get more >>> information about the problem. >>> >>> I run the command that you commented me, I did as follows: >>> >>> - kinit usuipa >>> - kvno imap/zimbrafreeipa.example....@fi.example.com >>> >>> (I said in my previous mail fi.example.com but should have said >>> zimbrafreeipa.example.com. >>> Forgiveness!!). >>> >>> Then run klist and got this: >>> >>> 11/24/14 14:04:53 11/25/14 14:04:50 krbtgt/ >> fi.example....@fi.example.com >>> 11/24/14 14:05:52 11/25/14 14:04:50 imap/ >>> zimbrafreeipa.fi.example....@fi.example.com >>> >>> Then run >>> KRB5_TRACE=/dev/stdout kvno imap/ >> zimbrafreeipa.example....@fi.example.com >>> and got this: >>> --------------------------------------- OUTPUT >>> --------------------------------------------------------------- >>> [20649] 1416845334.9690: Getting credentials usu...@fi.example.com -> >> imap/ >>> zimbrafreeipa.fi.example....@fi.example.com using ccache >> FILE:/tmp/krb5cc_0 >>> [20649] 1416845334.27562: Retrieving usu...@fi.example.com -> imap/ >>> zimbrafreeipa.fi.example....@fi.example.com from FILE:/tmp/krb5cc_0 with >>> result: 0/Conseguido >>> imap/zimbrafreeipa.fi.example....@fi.example.com: kvno = 2 >>> --------------------------------------- END OF OUTPUT >>> --------------------------------------------------- >>> >>> When I rum >>> KRB5_TRACE=/dev/stdout thunderbird >>> this show: >>> >>> --------------------------------------- OUTPUT >>> --------------------------------------------------------------- >>> Gtk-Message: Failed to load module "canberra-gtk-module": >>> libcanberra-gtk-module.so: no se puede abrir el fichero del objeto >>> compartido: No existe el fichero o el directorio >>> [20906] 1416845377.323420: ccselect module realm chose cache >>> FILE:/tmp/krb5cc_0 with client principal usu...@fi.example.com for >> server >>> principal imap/zimbrafreeipa.fi.example....@fi.example.com >>> [20906] 1416845377.323834: Retrieving usu...@fi.example.com -> >>> krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: from >>> FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found >>> [20906] 1416845377.323939: Getting credentials usu...@fi.example.com -> >>> imap/zimbrafreeipa.fi.example....@fi.example.com using ccache >>> FILE:/tmp/krb5cc_0 >>> [20906] 1416845377.324677: Retrieving usu...@fi.example.com -> imap/ >>> zimbrafreeipa.fi.example....@fi.example.com from FILE:/tmp/krb5cc_0 with >>> result: 0/Conseguido >>> [20906] 1416845377.325617: Creating authenticator for >> usu...@fi.example.com >>> -> imap/zimbrafreeipa.fi.example....@fi.example.com, seqnum 138355536, >>> subkey aes256-cts/3BB4, session key aes256-cts/A007 >>> [20906] 1416845377.353847: ccselect module realm chose cache >>> FILE:/tmp/krb5cc_0 with client principal usu...@fi.example.com for >> server >>> principal imap/zimbrafreeipa.fi.example....@fi.example.com >>> [20906] 1416845377.353971: Retrieving usu...@fi.example.com -> >>> krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: from >>> FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found >>> [20906] 1416845377.354331: Read AP-REP, time 1416845380.325675, subkey >>> (null), seqnum 1067232298 >>> [20906] 1416845396.10173: ccselect module realm chose cache >>> FILE:/tmp/krb5cc_0 with client principal usu...@fi.example.com for >> server >>> principal imap/zimbrafreeipa.fi.example....@fi.example.com >>> [20906] 1416845396.10290: Retrieving usu...@fi.example.com -> >>> krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: from >>> FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found >>> [20906] 1416845396.10316: Getting credentials usu...@fi.example.com -> >> imap/ >>> zimbrafreeipa.fi.example....@fi.example.com using ccache >> FILE:/tmp/krb5cc_0 >>> [20906] 1416845396.10391: Retrieving usu...@fi.example.com -> imap/ >>> zimbrafreeipa.fi.example....@fi.example.com from FILE:/tmp/krb5cc_0 with >>> result: 0/Conseguido >>> [20906] 1416845396.10469: Creating authenticator for >> usu...@fi.example.com >>> -> imap/zimbrafreeipa.fi.example....@fi.example.com, seqnum 592157704, >>> subkey aes256-cts/5F4D, session key aes256-cts/A007 >>> [20906] 1416845396.35033: ccselect module realm chose cache >>> FILE:/tmp/krb5cc_0 with client principal usu...@fi.example.com for >> server >>> principal imap/zimbrafreeipa.fi.example....@fi.example.com >>> [20906] 1416845396.35196: Retrieving usu...@fi.example.com -> >>> krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: from >>> FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found >>> [20906] 1416845396.35293: Read AP-REP, time 1416845399.10477, subkey >>> (null), seqnum 911725412 >>> >>> --------------------------------------- END OF OUTPUT >>> --------------------------------------------------- >> >> This seems okay, Thunderbird got necessary ticket so the problem could be >> on >> server side. (Just to be 100% sure: Did you configure >> network.negotiate-auth >> option in Thunderbird according to >> https://jpolok.web.cern.ch/jpolok/kerberos-macosx.html ?) >> >>> About permissions on keytab file, I have as following: >>> >>> ls -l /opt/zimbra/conf/krb5.keytab >>> -rwxrwxrwx 1 zimbra zimbra 366 nov 20 14:45 /opt/zimbra/conf/krb5.keytab >>> >>> Selinux (/etc/selinux/config) >>> SELINUX=disabled >>> >>> What do you think about this?, >> >> That it is completely insecure :-) Seriously, keytab contains symmetric >> cryptographic keys so it should be protected as much as feasible. >> >> It is fine for testing purposes (assuming that you do not forget to secure >> file permissions and generate new keytab before moving it to production). >> >> As a next step please raise debug levels on the server and possibly use >> KRB5_TRACE=/dev/stdout trick for IMAP server process. >> >> -- >> Petr^2 Spacek -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project