On 03-02-17 10:17, Jakub Hrozek wrote:
> On Fri, Feb 03, 2017 at 09:45:34AM +0100, Kees Bakker wrote:
>> On 02-02-17 17:32, Jakub Hrozek wrote:
>>> On Thu, Feb 02, 2017 at 05:19:07PM +0100, Kees Bakker wrote:
>>>> Sorry, I did search wherever I could but I couldn't find it.
>>>> How do I enable krb5_child debug log? I'm on an Ubuntu
>>>> system which by default writes an empty /var/log/krb5_child.log
>>>> Is it a section in /etc/sssd/sssd.conf? Is it in /etc/krb5.conf? What
>>>> do I have to add where to get logging in krb5_child.log?
>>> add debug_level= to the [domain] section.
>> OK. I've done that before with 0x3ff0 , but this time I used level 6
>> (which I read somewhere as being the old method). And now I see
>> output in krb5_child.log
>> What's weird though. On another system I'm doing the exactly same.
>> Nothing is logged in krb5_child.log.
>>>> BTW. I'm trying to debug a problem that results in
>>>> "Invalid UID in persistent keyring"
>>>> The weird thing is, if I become root (via another ssh login) and
>>>> then do a "su - user" (the same user with the error), the problem
>>>> does not show up. Meanwhile that user keeps getting the above
>>>> error (for klist kdestroy, klist).
>>> su as root gets automatically authenticated by the pam_rootok.so
>> I'm not sure if you understood what I was doing:
>> The "root" way
>> $ ssh r...@xyz.example.com
>> # su - someuser
> As you can see you were not prompted for a password. This is the
> pam_rootok.so module in action that just flipped the current user to
>> $ klist someuser
>> klist: Credentials cache keyring 'persistent:1013:1013' not found
> This is expected, since pam_sss.so wasn't invoked because the PAM
> conversation finished after pam_rootok.so was called.
Ah, OK. Thanks for clarifying.
Learn something new everyday :-)
>> $ kinit someuser
>> Password for someu...@example.com:
>> The latter seems to be working (I can't finish because I don't have that
> Then you won't be able to kinit as the user because you need either to
> know the password or have the keytab to decrypt the KDC response with.
Yes, I did expect that.
>> Then, at the very same time user "someuser", on his own login, gets this:
>> $ klist
>> klist: Invalid UID in persistent keyring name while getting default ccache
>> One more thing I should mention. It may be of influence. The "someuser"
>> is a local user in /etc/passwd, _and_ it is a user in IPA, with different
>> Could that trigger the error?
> Yes, if the UID of the local user and the IPA user differ.
> If you need to use the user from passwd and authenticate the user with
> his IPA credentials, then you can't use id_provider=ipa in sssd.conf,
> but id_provider=proxy and auth_provider=krb5.
Thanks, Jakub. I really appreciate your feedback.
I'll test what you suggested.
Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project