[Freeipa-users] User keytab file

Daniel Scott djscott at mit.edu
Tue Jun 23 15:49:24 UTC 2009


2009/5/27 Daniel Scott <djscott at mit.edu>

> Hi,
>
> 2009/5/13 Simo Sorce <ssorce at redhat.com>:
> >> I have a FreeIPA server configured and working. I'm now trying to
> >> automate a few processes and have a question regarding user keytabs.
> >> I'm looking to enable passwordless authentication/login for a
> >> particular user.
> >>
> >> I have followed the instructions found here:
> >> http://kb.iu.edu/data/aumh.html
> >>
> >> >From the above page, it appears that I can do this using a user
> >> keytab. I have created a user named 'backup' and given it a good,
> >> long
> >> password. I then created a user keytab file using the following
> >> command:
> >>
> >> # ktutil
> >> ktutil: addent -password -p backup -k 1 -e des-cbc-crc
> >> ktutil: addent -password -p backup -k 2 -e des3-cbc-sha1
> >> ktutil: wkt /etc/backup.keytab
> >>
> >> I can display the contents of this keytab and it appears to have been
> >> created successfully. Then, I should be able to authenticate using
> >> the
> >> following command, correct?
> >>
> >> # kinit backup -k -t /etc/backup.keytab
> >> kinit(v5): Key table entry not found while getting initial
> >> credentials
> >>
> >> The server logs show the following:
> >>
> >> May 12 11:54:34 example.com krb5kdc[12175](info): AS_REQ (7 etypes
> >> {18
> >> 17 16 23 1 3 2}) 192.168.1.50: NEEDED_PREAUTH: backup at EXAMPLE.COM for
> >> krbtgt/EXAMPLE.COM at EXAMPLE.COM, Additional pre-authentication
> >> required
> >
> > This is fine, I need the next line in the log to see what's the problem.
> > If you don't have a next line, then something is definitely "Wrong"
> >
> >> I have tried numerous combinations of the username in the kinit
> >> command, but I cannot obtain a ticket. Does anyone have any
> >> suggestions? Am I approaching this in the wrong way? Am I using the
> >> wrong hashing algorithm?
> >>
> >> A little more background information:
> >> 1. The backup.keytab has permissions 600 and is owned by backup.
> >> 2. I have also tried this as root.
> >
> > I don't have enough information to be sure (logs) but one of your
> problems
> > maybe that you came up with arbitrary (as in made up) kvno numbers.
> > (the -k option to addent in ktutil).
>
> Does anyone have any more suggestions for this? I've tried explicitly
> stating the kvno, but no luck. It just seems like the keytab file is
> not being recognised correctly. I still get the log message above, but
> the error message on the command line looks like the kinit command
> isn't even hitting the server - the error seems to be with the keytab
> file.
>
> Am I even approaching this in the correct way? All my searching on the
> web seems to find information related to service principals rather
> than user principals. There are another couple of sites which mention
> principals such as username/admin at EXAMPLE.COM which I'm unsure about.
>
> It's very strange that I can extract the keytab entry for a principal,
> but then am told that the entry does not exist. Has anyone seen this
> before?


Hi,

This problem still occurs. I've worked around it by using the standard
fedora user authorization/authentication, but it's not really the best way
to go about it. I'm still not sure if I'm even going about this the right
way. Is there actually such a thing as a 'user principal'. There must be a
way for an automated process to obtain a kerberos ticket. Maybe I'm going
about this the wrong way?

Any suggestions would be greatly appreciated. Does anyone have this or
something similar working?

Thanks,

Dan

-------------------------------
http://danieljamesscott.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20090623/5c4a2ce1/attachment.htm>


More information about the Freeipa-users mailing list