On Thu, 2010-05-06 at 08:11 -0400, Stephen Gallagher wrote:
On 05/06/2010 05:29 AM, Stjepan Gros wrote:
Ok, we really need to document how to set up an IPA client better.
The
IPA backend was really designed to be used when talking to FreeIPA v2.
It makes certain assumptions that are available but not default in
FreeIPA v1.
The first of these is that when selecting id_provider = ipa, it implies
that you have an available host keytab that will be used for
communicating with the ipa server. If not separately specified in the
krb5_keytab option, it expects there to be an entry in /etc/krb5.keytab
for host/<ipa_hostname>@<ipa_realm>.
The idea behind the host keytab is to provide IPA with assurance that
the client connecting is a known host.
So there are two ways to set up FreeIPA v1. You can set it up as a
traditional LDAP+Kerberos configuration, or you can generate a host
keytab and connect with the IPA backend.
Option 1 - LDAP+KRB5)
Use this configuration:
[domain/ASBIPA]
min_id = 1000
id_provider = ldap
ldap_server = ldap://10.0.9.200
ldap_search_base = dc=freeipa,dc=local
auth_provider = krb5
enumerate = true #If you have a large deployment, this can be a bad idea
auth_provider = krb5
cache_credentials = true
krb5_realm = FREEIPA.LOCAL
access_provider = permit # or simple
chpass_provider = krb5
krb5_kpasswd = 10.0.9.200 #Optional if they're the same server
Option 2 - IPA)
First, generate a host keytab for this machine.
For more detail, see
http://freeipa.org/docs/1.2/Administration_Guide/en-US/html/sect-Administ...
kinit admin(a)FREEIPA.LOCAL
ipa-addservice host/fedora.freeipa.local(a)FREEIPA.LOCAL
ipa-getkeytab -s 10.0.9.200 \
-p host/fedora.freeipa.local(a)FREEIPA.LOCAL \
-k /tmp/fedora.freeipa.local.keytab
Now copy that file (e.g. scp) to fedora.freeipa.local and put it in
place as /etc/krb5.keytab.
Now you can use this configuration:
[domain/ASBIPA]
min_id = 1000
ipa_domain = FREEIPA.LOCAL
ipa_server = 10.0.9.200
ipa_hostname = fedora.freeipa.loca
id_provider = ipa
auth_provider = ipa
access_provider = permit # or simple
chpass_provider = ipa
Please note that you should NOT use 'access_provider = ipa' with FreeIPA
v1. This is a v2-only feature, and on FreeIPA v1 will simply result in
disallowing all users access.
For the record, the ipa-client-install script has been rewritten for
FreeIPA v2 and will automatically set up all the correct SSSD options
when it is run, but that obviously doesn't help you in your current
deployment.
I hope this information helps you get up and running. If you have other
problems, don't hesitate to ask here on the list, or you can talk to us
directly in the #freeipa channel on
irc.freenode.net
Ok, I managed to get option 2 to work on Fedora 12 using authconfig from
Fedora 13, but I have to do some additional tests. It also appears that
it works on Ubuntu 10.10 (sssd 1.0.5) though the process is much more
involved as there is no authconfig equivalent. My configuration file in
the end looks like this:
[sssd]
services = nss, pam
config_file_version = 2
domains = default
[nss]
[pam]
[domain/default]
ldap_id_use_start_tls = False
cache_credentials = True
auth_provider = krb5
debug_level = 0
enumerate = True
krb5_kpasswd = 10.0.9.200
ldap_schema = rfc2307bis
krb5_realm = FREEIPA.LOCAL
ldap_search_base = dc=freeipa,dc=local
chpass_provider = krb5
id_provider = ldap
min_id = 1000
ldap_uri = ldap://10.0.9.200/
krb5_kdcip = 10.0.9.200
ldap_tls_cacertdir = /etc/openldap/cacerts
And also, krb5.conf is appropriately modified, keytab is in place and
host principal is in the kerberos database.
And I have three remarks on the whole process (maybe I should fill bug
reports?):
1. When I select FreeIPA in authconfig and then mark checkbox 'Use DNS
to locate KDC for realms' wouldn't it be good that the fields KDCs and
'Admin servers' are grayed out? As I understand in that case those are
found via DNS? And also, this info (both option to use DNS and specific
KDC entry) is filled into krb5.conf while it seems to me it is
redundand?
2. When selecting Local authentication after FreeIPA, and then Apply,
error is reported on the console because authconfig tries to start sssd
which doesn't have configuration file any more. Also, sssd should be
disabled during boot process in that case, or any case where it is not
used.
3. I think that when sssd searches for krb5.keytab, and doesn't find it,
for whatever reason can not read it, or can not find appropriate data
(exact host principal) it should at least emit some warning.
SG