[Freeipa-users] Fedora 12 install documentation 2.0.0 & admin documentation 2.0.0 and problems.

Rob Crittenden rcritten at redhat.com
Wed Jul 7 21:45:11 UTC 2010


Steven Jones wrote:
> 8><----
> 
>> I tried https://localhost:443
>>
>> and I get a "Kerberos Authentication failed".....there is no workable 
>> documentation / indication on how to fix this....
> 
> http://freeipa.org/docs/1.2/Installation_Deployment_Guide/en-US/html/sect-Installation_and_Deployment_Guide-Setting_up_the_IPA_Server-Configuring_Your_Browser.html
> 
> 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.
> 
> 8><------
> 
> 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 recognised.....

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 
>> <https://vuwunicofedipa1.vuw.ac.nz/ipa/errors/ca.crt>.
>>
>> 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 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 
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 shadow....

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.

rob




More information about the Freeipa-users mailing list