[Freeipa-users] kinit seg-fault for Solaris 9

[Sumit Bose]

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 at 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 <rcritten at redhat.com
> >>> <mailto:rcritten at 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/admin at IDM.LAB.BOS.REDHAT.COM" (which looks strange to
> >> me), while with ipa-getkeytab -P sets the principal in krbExtraData to
> >> "fbar at 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 at REALM user). But we hardcode root/admin at 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 at 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 at REALM.
> >>
> >> Martin
> >>
> >> _______________________________________________
> >> Freeipa-users mailing list
> >> Freeipa-users at redhat.com
> >> https://www.redhat.com/mailman/listinfo/freeipa-users
>