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

[Sigbjorn Lie]

Hi,

Do you have the Solaris Encryption Kit installed? I believe you need this to gain any more
encryption than DES on pre-Solaris 10. Even the early Solaris 10 releases were delivered without
proper crypto by default.

We have a few Solaris 8 hosts where I had to limit the number of enctypes in the hosts keytab
before it would work.



Regards,
Siggi




On Wed, March 27, 2013 17:56, 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.
>
> 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
>>
>>
>>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users