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 <[email protected]> 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 <[email protected]> wrote: >>> On Wed, 2013-03-27 at 12:23 +0100, Sumit Bose wrote: >>> >>>>> >>>>> I did (as admin@REALM user). But we hardcode >>>>> >>> root/admin@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@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 > [email protected] > https://www.redhat.com/mailman/listinfo/freeipa-users _______________________________________________ Freeipa-users mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-users
