[SSSD] Configuring SSSD

Stephen Gallagher sgallagh at redhat.com
Wed May 12 12:39:14 UTC 2010


On 05/12/2010 08:35 AM, Stjepan Gros wrote:
> On Wed, 2010-05-12 at 07:06 -0400, Stephen Gallagher wrote:
>> On 05/12/2010 02:01 AM, Stjepan Gros wrote:
>>> 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-Administration_Guide-Configuring_Authentication-Managing_Service_Principals.html
>>>>
>>>>        kinit admin at FREEIPA.LOCAL
>>>>        ipa-addservice host/fedora.freeipa.local at FREEIPA.LOCAL
>>>>        ipa-getkeytab -s 10.0.9.200 \
>>>>             -p host/fedora.freeipa.local at 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
>>>>
>>>>
>>>>
>>>
>>> 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
>>>
>>
>> This maps to option 1) I described earlier.
>
> Now, that's interesting. I had to notice that it's more like option 1
> than 2 (obviously!), but the point is that I selected FreeIPA in
> authconfig and authconfig generated that file so I somehow implicitly
> concluded it's option 2. Why it didn't generate configuration file like
> option 2?
>

I forget if we made this choice consciously, but I think the plan was 
for us to support FreeIPA v1 in the simplest way right now (which would 
be to set it up the way that ipa-client-install in v1 would work).

Once FreeIPAv2 is available, we'll handle this a little differently.

> Also, if FreeIPA is selected as authentication server, then no ldap and
> kerberos data should be asked for?
>

Yeah, that's something we're planning in the future.

>>> 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?
>>>
>>
>> Please file a bug report against authconfig. I will work with the
>> maintainer to support this.
>>
>>> 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.
>>>
>>
>> This should also be filed against authconfig.
>>
>>> 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.
>>>
>>
>> Yes, this should probably be sent to the syslog. Please open a bug
>> against SSSD.
>
> I'll fill bug and enhancement reports later this day.
>

Thank you very much.

-- 
Stephen Gallagher
RHCE 804006346421761

Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/



More information about the sssd-devel mailing list