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

[David Redmond]

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.

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20130327/4201db01/attachment.htm>