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 <rcrit...@redhat.com >>> <mailto:rcrit...@redhat.com>> 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/ad...@idm.lab.bos.redhat.com" (which looks strange to >> me), while with ipa-getkeytab -P sets the principal in krbExtraData to >> "f...@idm.lab.bos.redhat.com". 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. 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 >> Freeipa-users@redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users _______________________________________________ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users