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 > > 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
