[Freeipa-users] Kerberos error: PREAUTH_FAILED: KRB5KRB_AP_ERR_BAD_INTEGRITY

Petr Spacek pspacek at redhat.com
Wed Nov 26 17:04:21 UTC 2014


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.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




More information about the Freeipa-users mailing list