[PATCH] Allow more libldap debugging
by Jakub Hrozek
This patch should not be pushed to master, but I would like to get it
reviewed anyway.
It should be used to provide a custom build for users experiencing cases
where ldap_search_ext would block (c.f.
https://bugzilla.redhat.com/show_bug.cgi?id=728343)
For example:
export SSSD_DEBUG_LDAP_SEARCH="0xffff"
would set LDAP_DEBUG_ANY
The attached patch applies cleanly on the RHEL6.1 branch. I also have a
version that applies on master/1.5 if needed.
11 years, 5 months
[PRELIMINARY][PATCHES] Primary server support in SSSD
by Jan Zelený
Hi everybody,
I'm sending some patches which implement the primary server support as I see
it. It it based on comment #6 in the related ticket
https://fedorahosted.org/sssd/ticket/1128
Patch #0001 basically adds the necessary support in failover code
Patches #0002 - #0004 extend this support in each provider
Patch #0005 documents the new concept in failover section in man pages
Patches #0006 - #0008 add new options for each provider which utilize this
concept.
Just briefly about the approach. When adding a new server to the list of
servers related to a service, each server can be marked either as primary or
secondary.
When selecting new server from failover list, the algorithm iterates over the
list twice - first it tries to look for primary server and if none is found, it
tries also secondary server.
If a server is returned from failover, and it is not primary server, a timeout
is set (currently hard-coded for 30 seconds) for primary server lookup. This
timeout is rescheduled until a primary server is found. If a primary server
(either working or neutral) is found after this timeout, status of the backend
is reset, i.e. first all offline and then all online callbacks are called. This
is done to interrupt connection to the secondary server in favor of new
connection to a primary server.
I have just couple concerns about things which I have yet to inspect. First of
all when connection to the old server is interrupted, what if an operation is
currently in progress on this connection? I know ticket #1027 induces similar
scenario. Maybe to kill two birds with one stone I could design an extension
to immediately invoke callbacks of all operations running on existing
connection. What do you think about that?
My second concern is about port status timeout. After some time a port is
marked as neutral if originally marked as not-working. That effectively leads
to second attempt to primary server reconnection being successful even though
the server is still not running. As a result, an unnecessary reconnection to
secondary server is performed once some data are needed from the server.
Thank you very much for your opinions on this
Jan
11 years, 9 months
[PATCH][PRELIMINARY] sudo: send username and uid while requesting default options
by Pavel Březina
https://fedorahosted.org/sssd/ticket/1239
[PATCH 1/2]
Finally removes EOK constant from sudo api header. It is not used in
the SUDO code so it does not require their changes.
[PATCH 2/2]
This does what is requested in the ticket. It seems to be very huge but
in fact it is mainly changing the variable. Basically I tried to get
rid of domain ctx where possible, leave it only in initgroups part and
use command ctx elsewhere.
The in-memory cache is not yet implemented, I want to discuss the
possible ways of doing it.
The basic problem is that we need to get the domain during the request
for default options. How will we do it? I think there are two options:
1. always try to perform the initgroups - find the domain and the check
the in-memory cache (which may be slow if the user is in the last
domain, but that will be probably handled as part of
https://fedorahosted.org/sssd/ticket/1126
2. store uid:username = domain in the in-memory cache (same cache as
results or a new one?)
This patch contains a modified version of sysdb_get_sudo_user_info()
where the uid is not mandatory. I want to replace this function with
sysdb_sudo_get_user_groups() (or make it generic and place it in
sysdb_ops?) because the groupnames are the only thing we don't know.
However this requires a modification of the data provider protocol as
well so I'm keeping it for later.
11 years, 10 months
[PATCH] ding-libs spec file update
by Jan Zelený
Attached patch contains some changes that I'd like to propose. All
modifications are based on spec file for Fedora rawhide.
Thanks
Jan
11 years, 10 months
[PATCHES] Add Active Directory identity, auth and chpass providers to SSSD
by Stephen Gallagher
These patches add a new provider to SSSD: the AD provider. This provider
is designed to simplify communication with Active Directory 2008 R2 and
later. It may work with earlier versions of Active Directory, but we're
not planning to test or support them.
This set of patches adds the identity, auth and chpass providers. I will
be providing an access provider as well, but it's not ready and I wanted
to land these patches sooner rather than later. I also have not added
any manpages or the SSSDConfig API entries for the new options yet.
Those are also still forthcoming.
This provider can be configured for testing as follows:
{{{
[domain/AD.DOMAIN]
id_provider = ad
auth_provider = ad
chpass_provider = ad
ad_server = dc1.example.com, dc2.example.com, _srv_
ad_domain = AD.DOMAIN
case_sensitive = False
}}}
That should be all the configuration needed. The ad_server line can be
ommitted if SRV records for AD domain controllers exist in DNS. I'm
working on a way to eliminate the need for 'case_sensitive = False' as
well, but that's trickier than it sounds because it needs to be set in
the NSS responder, not just the back-end.
Patches 0001-0005 are minor enhancements to utility.
Patch 0001: Some logging enhancements for krb5_child
Patch 0002: KRB5_LOCATOR: Print the filename that couldn't be opened
Patch 0003: Drop memctx parameter of krb5_try_kdcip and fix a small
memory leak in the process.
Patch 0004: Converge the assorted IPA and KRB5 routines for setting up
the online/offline handlers into a common function that can also be
reused for the AD provider.
Patch 0005: Just change the name of the "AD-compatible" schema map for
the pure LDAP provider so it won't conflict with the one I'm adding to
the AD provider.
The following two patches add the "meat" of the new functionality. Sorry
for the size of the patches, but I couldn't find a sensible way to break
them up any further.
Patch 0006: Add AD identity provider
Patch 0007: Add AD auth and chpass providers
11 years, 10 months
Mixing passwd accounts with LDAP groups issue
by Jan Engelhardt
Hi,
I have my user account listed in both /etc/passwd, /etc/shadow and the
LDAP tree. However, only the LDAP tree has the supplementary group list
info.
In sssd-1.8.3 and earlier, issuing `getent passwd jengelh` would return
me all the (primary and) secondary groups I am a mamber of. Something
like
uid=25121(jengelh) gid=100(users)
groups=100(users),399(abuild),56485(friends),
27072(netitwork),31327(rdesktop)
In sssd-1.8.93, this is no longer the case, and instead I get:
uid=25121(jengelh) gid=100(users) groups=100(users),33(video)
`getent group 31327` has to say:
rdesktop:*:31327:fz,mm,mk
`ldapsearch -x cn=rdesktop`:
dn: cn=rdesktop,ou=groups,o=borg
objectClass: posixGroup
objectClass: top
objectClass: groupOfNames
objectClass: sambaGroupMapping
objectClass: zarafa-group
cn: rdesktop
description: Remote Desktop Users
member: uid=jengelh,ou=users,o=company
member: uid=fz,ou=users,o=company
member: uid=mm,ou=users,o=company
member: uid=mk,ou=users,o=company
sambaGroupType: 2
displayName: Remote Desktop
gidNumber: 31327
zarafaHidden: 1
sambaSID: S-1-5-21-2434340325-2384729352-2357823451-12387
If I comment about my entry in /etc/passwd, I do receive the groups from
LDAP again, but naturally I am missing out on the local groups:
uid=25121(jengelh) gid=27072(netitwork)
groups=27072(netitwork),33(video),56485(friends),
31327(rdesktop),399(abuild)
It seems like if the user entry is satisfiable from
/etc/passwd, group lookup is also only limited to passwd. This breaks
with behavior of all previously seen implementations (pam_ldap,..)
which strictly separated user and group lookups like NSS's design set
forth a handful of decades ago.
Side-note supplement:
And then there is the cache coming into play, which provided for a
handful of surprises on its own. Removing the comment hash mark #
from my entry in /etc/passwd again after the previous lookup, I then
get *all* memberships from both local and LDAP:
uid=25121(jengelh) gid=100(users)
groups=100(users),33(video),56485(friends),31327(rdesktop),
27072(netitwork),399(abuild)
so the look-in-passwd-only "misfeature" is not even consistent :)
11 years, 10 months
My solution to keep an update cache of all LDAP entries. Is there a better way?
by Mark London
Here is my solution to have a persistant uptodate local cache of all
ldap entries, so as to avoid very long delays when a user issues a
command that causes a large number of LDAP lookups, i.e. by doing a "ls
-l /home":
enumerate = true
enum_cache_timeout = 86400
ldap_purge_cache_timeout = 0
ldap_enumeration_refresh_timeout = 300
I set the cache timeout to be 24 hours, and do an enumerate every 5 minutes.
What I would like to know, is why such long delays (i.e. minutes) occurs
when doing an "ls -l /home". Is it because it has to write out each
entry into the local database? Just curious. :) Thanks.
Mark London
11 years, 10 months
No negative cache with sssd_nss
by Jan Engelhardt
Hi,
it seems that sssd does not cache negative responses from the shadow/NSS
backend. This is particularly observable when repeatedly querying for
groups that do not exist in /etc/group, but do exist in LDAP. sssd is
configured to search local db, plus another server's LDAP tree.
If the group "clients" is in LDAP, the following testcase below runs in
about ~8.5 sec on the reference machine. However, if I add the "clients"
group to the end of /etc/group, it completes in like 1.3 sec.
When only in LDAP, tcpdump shows no activity on port 389, so at least
the positive caching does work. However, the negative response from NSS
increases the execution time significantly, which leads me to believe
that part is not cached.
---8<---
#include <stdio.h>
#include <stdlib.h>
#include <pwd.h>
#include <grp.h>
int main(void)
{
unsigned int i;
struct group *g;
for (i = 0; i < 50000; ++i) {
g = getgrnam("clients");
}
return EXIT_SUCCESS;
}
11 years, 10 months
