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
< krbPrincipalKey:: MIIBn...UVrnGY=
> krbPrincipalKey:: MIIBx...xRoWtMY
< krbLastPwdChange: 20130327084336Z
< krbExtraData:: AAI4sVJRcm9vdC9hZG1pbkBJRE0uTEFCLkJPUy5SRURIQVQuQ09NAA==
> krbLastPwdChange: 20130327084406Z

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?

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.


Freeipa-users mailing list

Reply via email to