On Wed, Mar 27, 2013 at 11:44:06AM +0100, Martin Kosek wrote: > On 03/27/2013 11:36 AM, Sumit Bose wrote: > > On Wed, Mar 27, 2013 at 10:44:53AM +0100, Martin Kosek wrote: > >> On 03/27/2013 02:11 AM, David Redmond wrote: > >>> Hi again, > >>> > >>> I've got a bit more information. I've found that I can successfully kinit > >>> on > >>> the Solaris 9 clients if, on the server, I change the user's password by: > >>> > >>> ipa-getkeytab -s SERVER -p USER@REALM -k krb5.keytab -P > >>> > >>> This works even if I delete the resulting keytab file. However, kinit on > >>> the > >>> Solaris 9 client seg-faults if I set the user's password using the web > >>> gui, the > >>> 'passwd' or 'kpasswd' commands, or even the `ipa user-mod --password` > >>> command. > >>> > >>> There must be something different about how the ipa-getkeytab command > >>> stores > >>> the password. Any help would be greatly appreciated. > >>> > >>> Thanks, > >>> Dave > >>> ~""~ > >>> > >>> On Tue, Mar 26, 2013 at 4:05 PM, Rob Crittenden <[email protected] > >>> <mailto:[email protected]>> wrote: > >>> > >>> David Redmond wrote: > >>> > >>> Hi, > >>> > >>> I've setup FreeIPA for the first time and am using it > >>> successfully with > >>> Linux and Solaris 10 clients. On 8 separate Solaris 9 clients I'm > >>> running into an issue where 'kinit USER', for any user, fails > >>> with a > >>> segmentation fault after prompting for a password. On the client > >>> side > >>> there are no log entries. On the server side the "Additional > >>> pre-authentication required" entry is written to the log. When I > >>> execute > >>> 'kinit -k' everything works normally. I've verified that the > >>> keytabs for > >>> the Solaris 9 clients use only des-cbc-crc encryption and that > >>> allow_weak_crypto = true is set on the server side. Running > >>> 'truss kinit > >>> USER' on the Solaris 9 clients end with: > >>> Incurred fault #6, FLTBOUNDS %pc = 0xFF3582E4 > >>> siginfo: SIGSEGV SEGV_MAPERR addr=0x00000004 > >>> Received signal #11, SIGSEGV (default) > >>> siginfo: SIGSEGV SEGV_MAPERR addr=0x00000004 > >>> > >>> I've been fighting this for a while and have ensured that my > >>> Solaris 9 > >>> boxes are running the latest patches. Kerberos on the clients is > >>> the > >>> standard one that comes with Solaris. I've installed no additional > >>> kerberos components or packages. > >>> > >>> I'm hoping someone has seen this before or can point me in a new > >>> direction. At this point I've pretty much reached the end of my > >>> rope and > >>> am looking at using local passwords (blech!) on my Solaris 9 > >>> clients. > >>> > >>> > >>> I don't have a very helpful answer, but if memory serves my Sparc 9 > >>> install > >>> exhibits the same behavior. I don't have access to the latest updates > >>> though so I assumed it was related to that. > >>> > >>> rob > >>> > >> > >> Hello David, > >> > >> Interesting... I checked the difference in the user account when I change > >> the > >> password with "ipa-getkeytab ... -P" and "ipa passwd" and I see that only > >> krbPrincipalKey, krbLastPwdChange and krbExtraData changed: > >> > >> # diff /tmp/1 /tmp/2 > >> 41,48c41,49 > >> < krbPrincipalKey:: MIIBn...UVrnGY= > >> --- > >>> krbPrincipalKey:: MIIBx...xRoWtMY > >> 50,51c51,52 > >> < krbLastPwdChange: 20130327084336Z > >> < krbExtraData:: AAI4sVJRcm9vdC9hZG1pbkBJRE0uTEFCLkJPUy5SRURIQVQuQ09NAA== > >> --- > >>> krbLastPwdChange: 20130327084406Z > >>> krbExtraData:: AAJWsVJRZmJhckBJRE0uTEFCLkJPUy5SRURIQVQuQ09NAA== > >> > >> I focused on krbExtraData and looked for differences, with "ipa passwd > >> $USER", > >> we set principal "root/[email protected]" (which looks strange > >> to > >> me), while with ipa-getkeytab -P sets the principal in krbExtraData to > >> "[email protected]". Simo, is this intended? > > > > iirc this is the principal which changed the password the last time. Did > > you run 'ipa passwd' and ipa-getkeytab with the same credentials? > > > > bye, > > Sumit > > 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. bye, Sumit > > Martin > > > > >> > >> If no and David is willing to test it, I can prepare a scratch build of > >> FreeIPA > >> which would set user's principal to krbExtraData instead of > >> root/admin@REALM. > >> > >> Martin > >> > >> _______________________________________________ > >> 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
