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

[Simo Sorce]

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