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 <s...@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 > <s...@redhat.com> 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 > > > -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users