[Freeipa-users] kinit seg-fault for Solaris 9

[Simo Sorce]

On Wed, 2013-03-27 at 09:56 -0700, David Redmond wrote:
> I've done 1,2,3 many times. 4 always fails.
> 
> I realize you didn't ask for the info about allow_weak_crypto. I
> included it because it seems to me that it's a telling bit of info.

Ok can you run klist -e -kt file.keytab on the keytab you get after you
run ipa-getkeytab ?

What enctypes do you see available ?

I suspect your solaris 9 kinit is choking on a request that do not
include des enctypes somehow ?

Can solaris 9 use any other encryption algorythm than des ?

Simo.

> On Wed, Mar 27, 2013 at 9:50 AM, Simo Sorce <simo at redhat.com> wrote:
>         I didn't ask to run ipa-getkeytab,
>         can you do the following:
>         
>         1. login to a linux client
>         2. change the user password as an admin
>         3. kinit as the user (and perform the password change as it
>         will be
>         requested)
>         4. go to the solaris box and now try the kinit using the new
>         password
>         
>         Does step 4 work if you do 1,2,3 ?
>         Or does it keep segfaulting ?
>         
>         
>         
>         The difference when allow_weak_crypto is false is that des
>         keys are not
>         produced, so an AS REQ reply will return to the client with a
>         list of
>         encryption types that do not include des as a valid algorithm.
>         
>         Maybe your kinit client is choking on that ?
>         
>         You can change the default encryption types used to generate
>         new
>         password, (changing allow_weak_crypto is not sufficient for
>         that) in
>         FreeIPA by adding the desired enctypes in the
>         krbDefaultEncSaltTypes
>         multivalued attribute in entry named:
>         cn=<REALMNAME>,cn=Kerberos,<yoursuffix>
>         
>         The current defaults for new installs do *not* include DES as
>         it is a
>         broken algorithm for security at this point.
>         
>         
>         Simo.
>         
>         On Wed, 2013-03-27 at 09:36 -0700, David Redmond wrote:
>         > I run the ipa-getkeytab command as the user I'm changing the
>         password
>         > for.
>         >
>         > New info: On the server, in my /etc/krb5.conf file I have
>         > "allow_weak_crypto = true". If I remove that from the file,
>         changing
>         > the password via ipa-getkeytab no longer works. The kinit
>         command on
>         > the Solaris client results in a segmentation fault. When I
>         put
>         > "allow_weak_crypto = true" back into the krb5.conf file and
>         change the
>         > password via ipa-getkeytab the kinit command on the Solaris
>         client
>         > works normally.
>         >
>         > The ipa-getkeytab command must somehow be referencing
>         > "allow_weak_crypto" and storing the password differently
>         depending on
>         > it.
>         >
>         > On Wed, Mar 27, 2013 at 5:51 AM, Simo Sorce
>         <simo at redhat.com> wrote:
>         >         On Wed, 2013-03-27 at 12:23 +0100, Sumit Bose wrote:
>         >         > >
>         >         > > I did (as admin at REALM user). But we hardcode
>         >         root/admin at REALM if
>         >         > this is
>         >         > > administrative change:
>         >         > >
>         >         > > ipapwd_chpwop():
>         >         > > ...
>         >         > >     if (pwdata.changetype ==
>         IPA_CHANGETYPE_NORMAL) {
>         >         > >         principal =
>         >         slapi_entry_attr_get_charptr(pwdata.target,
>         >         > >
>         >         > "krbPrincipalName");
>         >         > >     } else {
>         >         > >         principal =
>         slapi_ch_smprintf("root/admin@%s",
>         >         > krbcfg->realm);
>         >         > >     }
>         >         > > ...
>         >         > >
>         >         > > Maybe the root cause of the crash is that we
>         place there a
>         >         principal
>         >         > > (root/admin at REALM) which does not exist. But
>         this is just
>         >         a
>         >         > speculation.
>         >         >
>         >         > ok, the principal is odd, and I guess this should
>         be fixed,
>         >         but maybe
>         >         > Simo knows some more history here. But
>         nevertheless I think
>         >         it is
>         >         > unrelated to the crash, becaus afaik this
>         information is not
>         >         send to
>         >         > the
>         >         > client and only used for book-keeing and auditing
>         on the
>         >         server side.
>         >         >
>         >
>         >         I don't recall the root/admin story, looks odd to
>         me, but
>         >         nothing of
>         >         this matter to a *client* segfaulting.
>         >
>         >         Clients do not get access to this data this is
>         purely internal
>         >         metadata
>         >         used by kadmin and the KDC.
>         >
>         >         What I wonder is if the client is segfaulting when
>         the
>         >         password is
>         >         expired due to a bug in handling the request to
>         immediately
>         >         change the
>         >         password ?
>         >
>         >         David,
>         >         if you kinit on a Linux machine and make sure you
>         properly
>         >         change the
>         >         password of the user (as the user no as an admin),
>         and then
>         >         kinit again
>         >         with the new credentials on Solaris, does it 'solve'
>         your
>         >         segfault
>         >         issue ?
>         >
>         >         In any case a segfault in a client command is
>         something you
>         >         need to
>         >         report to your OS vendor, even if it is indirectly
>         caused by
>         >         the server
>         >         it shows a potential attack vector and it is
>         particularly
>         >         worrying in
>         >         something like kinit that may be run as root on a
>         box.
>         >
>         >         Simo.
>         >
>         >         --
>         >         Simo Sorce * Red Hat, Inc * New York
>         >
>         >
>         
>         
>         --
>         Simo Sorce * Red Hat, Inc * New York
>         
>         
> 


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