[PATCH] Don't report a fatal error for an HBAC denial
by Stephen Gallagher
I noticed a minor bug while working on the ldap_access_filter patch.
Currently, if the HBAC access provider returns ANYTHING but PAM_SUCCESS,
it reports it as a fatal error in the backend.
However, we should also be handling PAM_PERM_DENIED as a successful
return. So this patch corrects that.
Should apply cleanly to both master and sssd-1-2.
--
Stephen Gallagher
RHCE 804006346421761
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
13 years, 11 months
[PATCH] IPA password migration (master only)
by Sumit Bose
Hi,
these are the two patches for the IPA password migration for master.
Because master already contains the sync sysdb patches it is not easy to
rebase the first patch from the sssd-1-2 branch to master so I rewrote
it. The second patch is mainly the same with a substitution of an async
sysdb call with his sync version.
bye,
Sumit
13 years, 11 months
How to handle ldap_access_filter when offline
by Stephen Gallagher
I'm working on ticket https://fedorahosted.org/sssd/ticket/457
The idea is that there will be a new access_provider=ldap that will
accept an option "ldap_access_filter". For example "ldap_access_filter =
host=client.example.com"
This would then translate into an LDAP request to see if an ldapsearch
on the search base with the filter
"&(uid=userloggingin)(host=client.example.com)"
returned a valid entry. If it did not, the user would be denied access.
The question is: how do we cache this for offline access. The filter is
an arbitrary LDAP query, so we can't just have the ID provider look up
an attribute when looking up the user and then check that it matches.
My thought is that the simplest approach would be to store in the LDB a
list of users that have successfully passed this access check before. If
and only if we're offline, it should ask this cache.
When we perform an access check while online, if it passes, we should
add the user to this cache. If it fails, we should ensure that the user
is not in the cache.
--
Stephen Gallagher
RHCE 804006346421761
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
13 years, 11 months
Configuring SSSD
by Stjepan Gros
Hi!
I didn't found mailing list on which I could discuss user
(configuration) issues, so I'm sending the comments/questions here.
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!
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?
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:
(Thu May 6 11:21:09 2010) [sssd[nss]] [nss_cmd_setgrent_ext] (4):
Requesting info for all groups
(Thu May 6 11:21:09 2010) [sssd[nss]] [sss_dp_send_acct_req_create]
(4): Sending request for [ASBIPA][4098][1][name=*]
(Thu May 6 11:21:09 2010) [sssd[nss]] [sss_dp_get_reply] (4): Got reply
(1, 11, Fast reply - offline) from Data Provider
(Thu May 6 11:21:09 2010) [sssd[nss]] [nss_cmd_setgr_dp_callback] (2):
Unable to get information from Data Provider
Error: 1, 11, Fast reply - offline
Will try to return what we have in cache
(Thu May 6 11:21:09 2010) [sssd[nss]] [nss_cmd_getgrent] (4):
Requesting info for all groups
(Thu May 6 11:21:09 2010) [sssd[nss]] [nss_cmd_endgrent] (4):
Terminating request info for all groups
(Thu May 6 11:21:09 2010) [sssd[nss]] [client_recv] (5): Client
disconnected!
(Thu May 6 11:21:11 2010) [sssd] [monitor_quit] (0): Interrupt: killing
children
Note that the log is full of the following lines:
(Thu May 6 11:20:27 2010) [sssd] [service_check_alive] (4): Checking
service ASBIPA(11208) is still alive
(Thu May 6 11:20:27 2010) [sssd] [service_send_ping] (4): Pinging
ASBIPA
(Thu May 6 11:20:27 2010) [sssd] [service_check_alive] (4): Checking
service nss(11209) is still alive
(Thu May 6 11:20:27 2010) [sssd] [service_send_ping] (4): Pinging nss
(Thu May 6 11:20:27 2010) [sssd] [service_check_alive] (4): Checking
service pam(11210) is still alive
(Thu May 6 11:20:27 2010) [sssd] [service_send_ping] (4): Pinging pam
(Thu May 6 11:20:27 2010) [sssd] [ping_check] (4): Service ASBIPA
replied to ping
(Thu May 6 11:20:27 2010) [sssd] [ping_check] (4): Service nss replied
to ping
(Thu May 6 11:20:27 2010) [sssd] [ping_check] (4): Service pam replied
to ping
Which, I assume, indicate that everything is OK?
I used tcpdump to see if anything accesses the LDAP port on IPA server
and there is no single try to access LDAP!
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
13 years, 11 months
How to handle kdcinfo when offline
by Stephen Gallagher
Simo and I had a long discussion on IRC today regarding how to handle
the kdcinfo and kpasswdinfo files for the Kerberos locator plugin.
The basic problem is this: our recent changes made it so that when we
shut down the SSSD, we remove the kdcinfo files. When we start back up,
we write a new kdcinfo file with a correct IP address if available, or
with a fake one if we're offline.
This is causing problems with non-SSSD kerberized services. Prior to
these changes, we always left the kdcinfo file around, so when we went
online (such as connecting to a VPN), the locator plugin would already
have the old IP saved, so we would be able to hand it off and continue
to work.
Now, we continue to return "Can't contact KDC" until the SSSD performs
an online kinit. This may not happen immediately (or for a very long
time). And until that happens, kerberized servers and applications won't
work.
After much discussion, Simo and I have come up with the following
approach: When the SSSD is offline (mark_offline() is called) we should
remove the kdcinfo and kpasswdinfo files. In the locator plugin, if
those files are not present, we should return the appropriate error code
to pass the handling on to the krb5.conf.
We will then allow the configuration in krb5.conf to handle requests
until we go online, at which time we will write out the kdcinfo files
and handle it ourselves.
This will probably require the following changes:
1) Enable providers to register a callback for "mark_offline()"
2) Create a callback for the kerberos provider to remove kdcinfo and
kpasswdinfo files upon going offline (and also when shutting down)
3) Modify the locator plugin to return "not handled" if the kdcinfo file
is missing.
--
Stephen Gallagher
RHCE 804006346421761
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
13 years, 11 months
What is "a configuration error"?
by David O'Brien
From the sssd-simple man page:
"Please note that it is an configuration error if both,
simple_allow_users and simple_deny_users, are defined."
Does this mean it (and what is "it", exactly?) will throw an error of
some sort, and what error? Or, is it just bad practice and will cost you
brownie points?
I'll do a copy-edit on the man page as soon as I get time.
thanks
--
David O'Brien
Red Hat Asia Pacific Pty Ltd
He who asks is a fool for five minutes, but he who does not ask remains
a fool forever."
~ Chinese proverb
13 years, 11 months