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 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 <>. 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 Browser button.

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 credentials"

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 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 see that'.

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

Reply via email to