[Freeipa-users] Kerberos error: PREAUTH_FAILED: KRB5KRB_AP_ERR_BAD_INTEGRITY

Wed Nov 26 17:45:14 UTC 2014

On Wed, Nov 26, 2014 at 06:04:21PM +0100, Petr Spacek wrote:
> Hello,
> 
> Simo, do you have an idea what may be causing the problem?

Maybe there is a version mismatch between the keys on the server and on
the client?

On the IPA server you can check with

#kadmin.local
> getprinc imap/zimbrafreeipa.example.com at FI.example.com

on the IMAP server

klist -k -t <path to keytab used by Zimbra server>

the KVNO should be the same, if not you can generate a fresh keytab with
ipa-getkeytab.

hth

bye,
Sumit

> 
> Maria, generally, you can try to do two things on Zimbra server:
> $ kinit -kt <path to keytab used by Zimbra server>
> "imap/zimbrafreeipa.example.com at 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-request at redhat.com>:
> > 
> >> Send Freeipa-users mailing list submissions to
> >>         freeipa-users at 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-request at redhat.com
> >>
> >> You can reach the person managing the list at
> >>         freeipa-users-owner at 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 <lslebodn at redhat.com>
> >> To: William Muriithi <william.muriithi at gmail.com>
> >> Cc: freeipa-users at redhat.com
> >> Subject: Re: [Freeipa-users] Is it possible to set up SUDO with
> >>         redudancy?
> >> Message-ID: <20141125080259.GB2590 at mail.corp.redhat.com>
> >> Content-Type: text/plain; charset=utf-8
> >>
> >> On Mon, Nov 24, 2014 at 8:38 PM, William Muriithi <
> >> william.muriithi at 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 <pspacek at redhat.com>
> >> To: freeipa-users at redhat.com
> >> Subject: Re: [Freeipa-users] Setting up a Kerberized IMAP Server.
> >> Message-ID: <547447CE.8090400 at 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.com at 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.COM at FI.EXAMPLE.COM
> >>> 11/24/14 14:05:52  11/25/14 14:04:50  imap/
> >>> zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM
> >>>
> >>> Then run
> >>> KRB5_TRACE=/dev/stdout kvno imap/
> >> zimbrafreeipa.example.com at FI.EXAMPLE.COM
> >>> and got this:
> >>> ---------------------------------------     OUTPUT
> >>> ---------------------------------------------------------------
> >>> [20649] 1416845334.9690: Getting credentials usuipa at FI.EXAMPLE.COM ->
> >> imap/
> >>> zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM using ccache
> >> FILE:/tmp/krb5cc_0
> >>> [20649] 1416845334.27562: Retrieving usuipa at FI.EXAMPLE.COM -> imap/
> >>> zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM from FILE:/tmp/krb5cc_0 with
> >>> result: 0/Conseguido
> >>> imap/zimbrafreeipa.fi.example.com at 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 usuipa at FI.EXAMPLE.COM for
> >> server
> >>> principal imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM
> >>> [20906] 1416845377.323834: Retrieving usuipa at FI.EXAMPLE.COM ->
> >>> krb5_ccache_conf_data/proxy_impersonator at X-CACHECONF: from
> >>> FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found
> >>> [20906] 1416845377.323939: Getting credentials usuipa at FI.EXAMPLE.COM ->
> >>> imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM using ccache
> >>> FILE:/tmp/krb5cc_0
> >>> [20906] 1416845377.324677: Retrieving usuipa at FI.EXAMPLE.COM -> imap/
> >>> zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM from FILE:/tmp/krb5cc_0 with
> >>> result: 0/Conseguido
> >>> [20906] 1416845377.325617: Creating authenticator for
> >> usuipa at FI.EXAMPLE.COM
> >>> -> imap/zimbrafreeipa.fi.example.com at 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 usuipa at FI.EXAMPLE.COM for
> >> server
> >>> principal imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM
> >>> [20906] 1416845377.353971: Retrieving usuipa at FI.EXAMPLE.COM ->
> >>> krb5_ccache_conf_data/proxy_impersonator at 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 usuipa at FI.EXAMPLE.COM for
> >> server
> >>> principal imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM
> >>> [20906] 1416845396.10290: Retrieving usuipa at FI.EXAMPLE.COM ->
> >>> krb5_ccache_conf_data/proxy_impersonator at X-CACHECONF: from
> >>> FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found
> >>> [20906] 1416845396.10316: Getting credentials usuipa at FI.EXAMPLE.COM ->
> >> imap/
> >>> zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM using ccache
> >> FILE:/tmp/krb5cc_0
> >>> [20906] 1416845396.10391: Retrieving usuipa at FI.EXAMPLE.COM -> imap/
> >>> zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM from FILE:/tmp/krb5cc_0 with
> >>> result: 0/Conseguido
> >>> [20906] 1416845396.10469: Creating authenticator for
> >> usuipa at FI.EXAMPLE.COM
> >>> -> imap/zimbrafreeipa.fi.example.com at 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 usuipa at FI.EXAMPLE.COM for
> >> server
> >>> principal imap/zimbrafreeipa.fi.example.com at FI.EXAMPLE.COM
> >>> [20906] 1416845396.35196: Retrieving usuipa at FI.EXAMPLE.COM ->
> >>> krb5_ccache_conf_data/proxy_impersonator at 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