On 05/06/2010 05:29 AM, Stjepan Gros wrote:
Hi!
I didn't found mailing list on which I could discuss user
(configuration) issues, so I'm sending the comments/questions here.
Yeah, we don't yet have a separate user mailing list. We should probably
create one once Fedora 13 ships, since it will be seeing more use.
For the past two or so weeks I tried to configure SSSD on F-12 and
RHEL6
beta (and also on Ubuntu 9.10) using authconfig and editing
configuration files without any success and it drives me crazy!
For best results on Fedora 12, you should install sssd 1.1.1-3.fc12 from
the updates repo, and authconfig 6.1.4-1.fc13 from here:
http://koji.fedoraproject.org/koji/buildinfo?buildID=165917
As Tomas mentioned, we're not bringing that version of authconfig back
into Fedora 12 so that we don't impose SSSD on Fedora 12 users.
Moreover, the information on the Internet is very scarce, and debug
options are quite limited (at least as far as I know). I'm using FreeIPA
server on another Fedora which, I believe, works, because, configuring
individually LDAP, Kerberos and nss/pam everyting is fine. But, using
SSSD, it doesn't work.
As a side note, when I configured SSSD using authconfig I had to
manually configure /etc/krb5.conf in order to be able to use kinit. I
don't know if it is intentional or not, but if I configure kerberos
parameters in SSSD section of authconfig, wouldn't it be reasonable that
all the related configuration files are also updated?
This is fixed with the 6.1.3 versions of authconfig and later.
Next, trying to obtain list of users from the server by issuing the
following command:
getent -s sss group
I get nothing. Looking into debug log of sssd, I found the following
lines which could be related:
<snip>
Which, I assume, indicate that everything is OK?
No, what it's telling you is that it was unable to connect to the remote
server, so it was attempting to return the results from the cache (if
they were there, which in this case they are not)
I used tcpdump to see if anything accesses the LDAP port on IPA
server
and there is no single try to access LDAP!
The reason it's not accessing LDAP is that when using the IPA backend,
it's first trying to kinit as host/fedora.freeipa.local and failing
(because the keytab does not exist)
What confuses me is the question how to debug local issues.
Obviously
it's a local problem, but what are my options in debugging those?
The configuration file (/etc/sssd/sssd.conf) is at the end of this mail.
Stjepan Gros
Configuration file (very slightly edited to remove sensitive
information):
[sssd]
config_file_version = 2
reconnection_retries = 3
sbus_timeout = 30
services = nss, pam
domains = ASBIPA
[nss]
filter_groups = root
filter_users = root
reconnection_retries = 3
[pam]
offline_credentials_expiration = 2
reconnection_retries = 3
[domain/ASBIPA]
use_fully_qualified_names = False
cache_credentials = True
auth_provider = ipa
access_provider = ipa
debug_level = 0
store_legacy_passwords = False
enumerate = True
ldap_user_search_base = dc=freeipa,dc=local
krb5_realm = FREEIPA.LOCAL
chpass_provider = ipa
id_provider = ipa
ipa_hostname = fedora.freeipa.local
min_id = 1000
ipa_server = 10.0.9.200
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
--
Stephen Gallagher
RHCE 804006346421761
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/