Steven Jones wrote:
I tried https://localhost:443
and I get a "Kerberos Authentication failed".....there is no workable
documentation / indication on how to fix this....
In short, you need to configure your browser to do kerberos
authentication, trust the IPA root CA and you need a kerberos ticket in
order to connect.
I did this however it keeps coming up with the same msg.
Also there is no instruction to tell me how to get the kerberos ticket
I'm not sure what you mean recognized. The basic idea is this:
1. Do a kinit admin. You now have a ticket.
2. Fire up Firefox and configure it per the documentation. What this
tells firefox is which what domains it will do kerberos negotiation with
so single sign-on will work.
3. You need to trust the CA that issued the SSL certificate that IPA
uses in the browser. This generally requires a restart.
After that it should just work. If not then you should check out section
3.3.1 in the Installation & Deployment guide. The problem can be any
number of things including DNS problems.
Kerberos and SSL are super picky that the remote server you are talking
to has the exact same name that you are requesting. So thinks like short
names don't work so hot (foo.example.com != foo in other words). We do
what we can to force things to work the right way but sometimes one has
to delve into the logs to figure out why something isn't working.
"Kerberos Authentication Failed
Unable to verify your Kerberos credentials. Please make sure that you
have valid Kerberos tickets (obtainable via kinit), and that you have
configured your browser correctly
<https://vuwunicofedipa1.vuw.ac.nz/ipa/errors/ssbrowser.html>. If you
are still unable to access the IPA Web interface, please contact the
helpdesk on for additional assistance.
Import the IPA Certificate Authority
You can automatically configure your browser to work with Kerberos by
importing the Certificate Authority above and clicking on the Configure
You *must* reload this page after importing the Certificate Authority
for the automatic settings to work
So I run kinit as a local user and get told....
"kinit: Client not found in Kerberos database while getting initial
Did you add your user as a user in IPA? You can always try getting a
ticket as the admin user for testing (kinit admin).
No, the documentation didnt tell me to, or how....so this part of the "testing"
needs to include suitable cli commands / instructions to allow a proper test. This should
be a sequence all in order of all the steps needed and not dig your way through a 500
page manual and guess...
The Installation and Deployment guide does exactly this. Perhaps it
needs more steps but it goes to the level of 'type this and you should
When you run just 'kinit' then it assumes you want to use the principal
of the current uid. So in my case my login name is rcritten. If I do
'kinit' it is the same thing as 'kinit rcritten'. If you haven't added
an IPA user 'rcritten' then you'll see this error message.
Really I guess someone wants to write a quick start or evaluation guide. Its
interesting when you watch the youtube on freeipa and they talk about not
having to be an expert in every single aspect, yet that's exactly what we end
up with here, again.
I'm sorry you're having problems. If you've ever tried to set up a KDC
by hand you'd know better what they mean. We try to hide a lot of the
complexity and lousy error messages of kerberos but we can only do so much.
Some basic understanding of kerberos (principals, tickets, keytabs, etc)
is necessary to fully take advantage of IPA.
I have run kinit as admin and that seems fine, however the I have not been able
to figure out how to use the admin's kerberos ticket I assume its /tmp/krb5cc_0
(which is owned by root) in a user's webrowser...Fedora 12 prevents root
logging in under a gui which is silly...and I have not been able to find how to
allow that yet.
In kerberos the user you're logged in as doesn't have to match the
kerberos principal you use, hence being able to 'kinit admin' while
logged in as root.
Kerberos credentials are cached by default as /tmp/krb5cc_<uid>. So
/tmp/krb5cc_0 is root's kerberos credentials cache. If you did 'kinit
admin' as root then yes, this is the cache being used.
Once you have successfully done a kinit there isn't anything you need to
"do" to use it in most cases. kerberized applications will use the cache
automatically. There are some applications, such as the browser, that
you need to provide additional configuration data to.
Each user will have their own credentials cache. You don't do a single
kinit and everyone just works.
Also I cant login as the admin user as I got told that the admin account already exists
when I try a "adduser admin"....yet does not exist in /etc/passwd, group or
Right, the admin user is stored in the IPA database. The whole idea of
IPA is for distributed identity management. You create users in IPA,
configure your clients properly and the same user credentials can be
used anywhere within your deployment. No more rsyncing /etc/passwd,
/etc/shadow and /etc/group to keep users, groups and passwords synchronized.
So once you get things going you can use standard nss commands to view
your users and groups as well, things like:
# getent passwd admin
# getent group ipausers
# id admin
I'm not sure why the admin user can't log in, how were you trying to log
in? ssh, X, telnet...?
So what do I do with this ticket? simply change its permissions to that of the
local user? hack a file somewhere to point to it?
No, kinit to admin as a local user. If you want to see if things are
working at a very basic level do:
$ kinit admin
$ ipa-finduser admin
If that works (e.g. you get some output about the admin user) then your
IPA installation is more or less functioning. At this point you can
start adding users to IPA (ipa-adduser). Then you can run
ipa-client-install on your other machines to configure them to
authenticate against your IPA server. Once that's done you should be
able to log into those client machines using your IPA credentials.
Note that when you set a user password as an administrator the user will
need to reset that password the first time they use it (so that only the
end-user has the password). If you have problems logging in via ssh you
need to set ChallengeResponseAuthentication to yes in /etc/ssh/sshd_config
I'd recommend reading the Client Installation guide before trying to
install additional client machines.
Freeipa-users mailing list