[Freeipa-users] ipa-getkeytab and mandatory password change

[Darran Lofthouse]

On 06/19/2012 07:12 PM, Stephen Ingram wrote:
> On Tue, Jun 19, 2012 at 9:55 AM, Simo Sorce <simo at redhat.com> wrote:
>> On Tue, 2012-06-19 at 09:15 -0700, Stephen Ingram wrote:
>>> On Tue, Jun 19, 2012 at 2:54 AM, Dmitri Pal <dpal at redhat.com> wrote:
>>>> On 06/18/2012 11:58 AM, Darran Lofthouse wrote:
>>>>> Just experienced some weird behaviour on my Fedora 17 installation,
>>>>> just wanted to check if this was expected.
>>>>>
>>>>> I have the default config that requires a user to change their
>>>>> password the first time they run kinit.
>>>>>
>>>>> However I created a user and immediately used ipa-getkeytab as this
>>>>> user will be a non-interactive process, despite the ipa-getkeytab
>>>>> resetting the secret for the user the first attempt at authentication
>>>>> failed as the user was still told to change their password.
>>>>>
>>>>
>>>>
>>>> I do not think we have anticipated this use. The ipa-getkeytab is
>>>> designed for the host and services keytabs not for users. I suggest that
>>>> use a service principal rather than a user principal to run those jobs.
>>>> You can also file an RFE to allow keytabs for users if you think that
>>>> services would not work for you.
>>>>
>>>>> My expectation would have been that any update to the secret should
>>>>> meet the requirement for the user to change their password.
>>>
>>> Darren-
>>>
>>> I'm not sure if you went further with this, but if you do change the
>>> password through other means, you then will be able to get a copy of
>>> the keytab for the user with ipa-getkeytab. I tried it out because the
>>> thought of not being able to get a keytab for a user was concerning. I
>>> agree that the service keytabs make more sense for these instances (I
>>> was also told this by Simo in another thread), but I keep being told
>>> by the application people that I need to use a user principal, which,
>>> thankfully works.
>>
>> Ask them why, I am curious about the requirement.

What I was trying to achieve was a single Java process obtaining it's 
own ticket before it connected to a service that was identified by a 
service principal mapping.

In this scenario the client process is just as non-interactive as the 
server process so both sides were being configured with a keytab.

Obtaining the keytab works fine and the client can use it - the only 
part that was a surprise was that the requirement for the client to 
change their password remained even though it was now redundant as a 
keytab had been generated.

> I'm still waiting for responses. The only thing I've been told thus
> far is that since there are multiple processes authenticating to their
> respective servers, it might be difficult to direct each to the proper
> credential cache. If you use one user to auth to each server process
> then there is only one credential cache.
>
> Steve
>