[Freeipa-users] Kerberos error: PREAUTH_FAILED: KRB5KRB_AP_ERR_BAD_INTEGRITY

Simo Sorce simo at redhat.com
Wed Nov 26 20:28:47 UTC 2014


On Wed, 26 Nov 2014 18:04:21 +0100
Petr Spacek <pspacek at redhat.com> wrote:

> Hello,
> 
> Simo, do you have an idea what may be causing the problem?

The most probable explanation is that the Zimbra server has the wrong
key. Unfortuinately there isn't enough data in the email to guess
further.

Simo.

> 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



-- 
Simo Sorce * Red Hat, Inc * New York




More information about the Freeipa-users mailing list