On 06/19/2012 07:12 PM, Stephen Ingram wrote:
On Tue, Jun 19, 2012 at 9:55 AM, Simo Sorce <s...@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 <d...@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



_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to