Kerberos Digest, Vol 190, Issue 4

[Sanjay Kumar Sahu]

HI All !

We have been using kerberos5/SSO authentication for our application
MediaWiki 1.30.0. running in RHEL7 server with Apache/2.4
Before we are using following encryption method of algorithm in the keytab
so we never had any issue related to kerberos authentication
(des-cbc-crc)
(des-cbc-md5)
(aes256-cts-hmac-sha1-96)
(aes128-cts-hmac-sha1-96)

Now, the DES crypto type is declared weak crypto and not secure so it's
degraded to use by IT dept.
And we required to use the keytab using Advanced Encryption Standard (AES)
Cryptography with either of types (AES128 or AES265) for following cipher
algorithm.
(aes256-cts-hmac-sha1-96)
(aes128-cts-hmac-sha1-96)
But, unfortunately neither of the keytab encrypted with AES Crypto (AES128
or AES265) are working and throws following error in server Error_log.

Please help us providing any solution for this issue would be greatly
appreciated

Error_log
-----------------
gss_accept_sec_context() failed: Unspecified GSS failure. Minor code may
provide more information (, No key table entry found for the SPN)

Thanks,
Sanjay



On Mon, Oct 8, 2018 at 9:31 PM <kerberos-request at mit.edu> wrote:

> Send Kerberos mailing list submissions to
>         kerberos at mit.edu
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://mailman.mit.edu/mailman/listinfo/kerberos
> or, via email, send a message with subject or body 'help' to
>         kerberos-request at mit.edu
>
> You can reach the person managing the list at
>         kerberos-owner at mit.edu
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Kerberos digest..."
>
>
> Today's Topics:
>
>    1. Re: Merge Databases, can't dump -mkey_convert principal
>       (Greg Hudson)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 8 Oct 2018 11:13:47 -0400
> From: Greg Hudson <ghudson at mit.edu>
> Subject: Re: Merge Databases, can't dump -mkey_convert principal
> To: Eric Hattemer <ehatteme at usc.edu>, "kerberos at mit.edu"
>         <kerberos at mit.edu>
> Message-ID: <088a06d0-b6d0-2a90-00c4-2bbbb8235590 at mit.edu>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> (Sorry for the slow response.)
>
> On 10/01/2018 08:54 PM, Eric Hattemer wrote:
> > We have a production Kerberos cluster, and a test cluster.? I'd like to
> > refresh test from production without overwriting those principals that
> > are specific to test.? We also have something wrong with our production
> > master database where it will respond to 'kdb5_util dump -verbose'
> > commands by either hanging or looping.
>
> Release 1.15 added (well, re-added) "kdb5_util dump -recurse" which can
> help with this situation.  The DB2 format contains iteration pointers as
> well as parent-child pointers; if the iteration pointers are corrupt,
> lookups work but iteration does not.  Dumping with the -recurse option
> forces the use of the parent-child pointers for iteration.
>
> > kdb5_util: Decrypt integrity check failed while converting b at REALM to
> > new master key
> > kdb5_util: Decrypt integrity check failed performing Kerberos version 5
> > release 1.11 dump
>
> > That account is involved in some automated testing.? Dumps failed both
> > before and after the account successfully changed its password and
> > logged in.? So the principal works, it just can't be dumped with
> > mkey_convert.? The whole database dumps fine without mkey_convert.? I
> > had two mkeys loaded in the database.? I tried:
> >
> > sudo kdb5_util use_mkey 1
> > sudo kdb5_util update_princ_encryption b at REALM
> >
> > and it converted just fine.
>
> I don't have any good theories here.  krb5_util dump -mkey_convert and
> kdb5_util update_princ_encryption both use similar code paths to decrypt
> the existing key entries
> (src/kadmin/dbutil/dump.c:master_key_convert()), so it's strange that
> one would fail and the other would succeed.  There was a bug related to
> the -keepold flag which we fixed in 1.13:
>
> http://krbdev.mit.edu/rt/Ticket/Display.html?id=7995
>
> but I would expect that problem to apply to update_princ_encryption, and
> you didn't mention using the -keepold flag.
>
>
> ------------------------------
>
> _______________________________________________
> Kerberos mailing list
> Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
>
> End of Kerberos Digest, Vol 190, Issue 4
> ****************************************
>


-- 
*Thanks & Regards,*


*Sanjay Kumar Sahu*