Re: [SSSD] Thoughts...
by Stephen Gallagher
CCing sssd-devel
On Tue, 2011-10-04 at 22:41 +0000, JR Aquino wrote:
> So I have been looking through the results of ldbsearch and have been
> wondering...
>
> Why is it that I see cached entries for objects (hbac/ hosts/ etc) that
> have no correlation to the host itself?
>
> Might it be more optimized to search / cache only the data relevant to
> the client system in question?
>
> Surely that would cut down on the exponential costs against an ldap
> database with grown hosts/users/hbacrules/sudorules ?
Well, the issue is this: rules can specify hostgroups as well as hosts.
So in order to decide which rules to download, we need to know which
hostgroups the current machine is a member of. This results in a minimum
of two ldap searches (one for the hosts, and then one for the
hostgroups) to get the machine-specific information. We then need to
perform a rule search for just the rules that apply to that machine.
After we have the rule, we'll need to perform an iterative series of
lookups for every host and hostgroup that the rules we just acquired
list as a source host. Now, suppose that one or more of the hostgroups
specified in source host contains thousands of host entries?
So in other words, doing it this way will result in a net increase in
the number of back-and-forth LDAP exchanges. In theory this is much
slower than just grabbing everything in two lookups up front (getting
all hosts and hostgroups) and doing the processing locally.
In practice, we're hitting a performance issue because of the way we're
updating the data. So it's better all-around to resolve the issue here,
rather than deferring the problem by changing the lookup order around
and potentially increasing the LDAP lookups. And since we still might
end up with rules that have to handle a lot of hosts, we'll still have
the same update issue.
The problem in the source is this: I tried to simplify the update
process by simply wiping out the hosts and hostgroups subtrees in the
cache and then writing the new values in. The problem with this is that
deleting entries with memberOf attributes is an expensive operation,
which I did not take into account.
There are two approaches to resolving this that I'm taking into
consideration.
1) Instead of doing a full purge followed by a full write, make only
changes. This will be a somewhat more complex logic to follow, but if
little or nothing has changed on the server, then it will save us a LOT
of memberOf operations.
2) Add a new feature to the memberOf plugin to allow us to defer
processing memberOf until all entries have first been written (keeping
an index of the attributes that will need processing). This is *very*
complicated and potentially dangerous (though also has the potential for
the highest performance gain), so I'd prefer to try option 1 first.
12 years, 6 months
[PATCH] The new memberof plugin
by Jan Zelený
Attached patch rewrites almost entire memberof plugin. It heavily utilizes
hash tables instead of lists and arrays and it introduces concept of reference
counting which should heavily optimize all operations when no loops are
present in the user/group tree.
I tested the patch by running sysdb test suite, all tests passed. I also
attach a document where basic concepts of the plugin are explained.
Please note that the patch is functional, although I don't consider it ready.
I just want to get pre-ACK or some comments about the patch design. I have yet
to implement the recompute task, I will work on that later.
Jan
12 years, 6 months
SSSD on RHEL6 problems
by Andy Kannberg
Hi all,
I'm running into problems on a RHEL6 machine with configuring sssd.
I keep getting errors like this:
Sep 30 14:11:26 tst0030 sshd[7512]: pam_unix(sshd:auth): authentication
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=somehost.domain.com user=XXX
Sep 30 14:11:27 tst0030 sshd[7512]: Failed password for XXX21358 from
12.34.56.78 port 32950 ssh2
Sep 30 14:11:33 tst0030 sshd[7512]: Failed password for XXX21358
from 12.34.56.78 port 32950 ssh2
However, I can perform a ldapsearch succesfully. So LDAP is available.
I've copied the configuration from a working RHEL5 machine(which runs just
fine, I can login with the same credentials I try on the RHEL6 box), but it
appears to be a no-go for now. sssd.conf looks like this:
[sssd]
config_file_version = 2
# Number of times services should attempt to reconnect in the
# event of a crash or restart before they give up
reconnection_retries = 3
# If a back end is particularly slow you can raise this timeout here
sbus_timeout = 30
services = nss, pam
# SSSD will not start if you do not configure any domains.
# Add new domain configurations as [domain/<NAME>] sections, and
# then add the list of domains (in the order you want them to be
# queried) to the "domains" attribute below and uncomment it.
domains = default
[nss]
# The following prevents SSSD from searching for the root user/group in
# all domains (you can add here a comma-separated list of system accounts
that
# are always going to be /etc/passwd users, or that you want to filter out).
filter_groups = root
filter_users = root
reconnection_retries = 3
# The entry_cache_timeout indicates the number of seconds to retain an
# entry in cache before it is considered stale and must block to refresh.
# The entry_cache_nowait_timeout indicates the number of seconds to
# wait before updating the cache out-of-band. (NSS requests will still
# be returned from cache until the full entry_cache_timeout). Setting this
# value to 0 turns this feature off (default).
; entry_cache_timeout = 600
; entry_cache_nowait_timeout = 300
[pam]
reconnection_retries = 3
#offline_credentials_expiration = 0
#offline_failed_login_attempts = 5
#offline_failed_login_delays = 15
[domain/default]
ldap_id_use_start_tls = False
cache_credentials = True
ldap_search_base = ou=TST_EMEA_NL-TST01,ou=Locations,ou=NXDI,o=NXP
ldap_user_search_base = ou=People,ou=NXDI,o=NXP
ldap_user_object_class = NxpUserAuxClass
ldap_user_principal = krbForeignPrincipalName
ldap_force_upper_case_realm = True
ldap_user_fullname = fullName
ldap_user_member_of = groupMembership
ldap_group_search_base = ou=Group,ou=NXDI,o=NXP
ldap_group_object_class = NxpGroupAuxClass
ldap_group_gid_number = gidNumber
ldap_schema = rfc2307bis
enumerate = True
krb5_realm = WBI.NXP.COM
chpass_provider = krb5
krb5_kdcserver = wbi.nxp.com
id_provider = ldap
auth_provider = krb5
debug_level = 0
ldap_uri = ldap://dtc0001.dtq.nl-htc01.nxp.com,ldap://
dtc0002.dtq.nl-htc01.nxp.com
krb5_kpasswd = wbi.nxp.com
ldap_tls_cacertdir = /etc/openldap/cacerts
I've modified nsswitch.conf to use sss, and also the system-auth to use the
sssd-pam library. These look like:
auth required pam_env.so
auth sufficient pam_unix.so likeauth nullok
auth requisite pam_succeed_if.so uid >= 500 quiet
auth sufficient pam_sss.so use_first_pass
auth required pam_deny.so
account required pam_unix.so broken_shadow
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 500 quiet
account [default=bad success=ok user_unknown=ignore] pam_sss.so
account required pam_permit.so
#account required pam_access.so
accessfile=/etc/security/access.netgroup.conf
password requisite pam_cracklib.so try_first_pass retry=3
password sufficient pam_unix.so nullok use_authtok md5 shadow
password sufficient pam_sss.so use_authtok
password required pam_deny.so
#session required pam_limits.so
session required pam_unix.so
session required pam_keyinit.so revoke
session optional pam_sss.so
Anyone who can help me out with this ? I'm kinda stuck. Google didn't show
up any useful results.
cheers,
Andy
12 years, 6 months
[PATCHES][PRELIMINARY] Support for multiple LDAP search bases
by Stephen Gallagher
These patches add support for multiple search bases for users and groups
in non-enumeration mode. I want to get these out for review before I
start working on the enumeration support, so if there are major issues
they will be found before I put in a lot more work.
Some notes: There is no patch adding multiple search base support for
group lookups in RFC2307bis because it's meaningless right now. Since
the group memberships are direct DNs, we do all of our searches as base
searches, ignoring group_search_base. There is a separate ticket,
https://fedorahosted.org/sssd/ticket/960 that will need to address this,
taking advantage of the multiple search base features.
Also, while working through this, I opened
https://fedorahosted.org/sssd/ticket/1006 as I noticed that we are using
far too many separate transactions while processing RFC2307bis (which is
likely the cause of the extreme slowdown that some of our users were
reporting with AD).
Thank you, and please review promptly.
Patch 0001: Remove some unused options in a struct
Patch 0002: Fix size return for split_on_separator()
It was returning the size of the array, rather than the number of
elements. (The array was NULL-terminated). This argument was only
used in one place that was actually working around this odd return
value.
Patch 0003: Make sdap_get_id_specific_filter() more strict
Just makes it take const char * instead of char *.
Patch 0004: Add parser for multiple search bases
As discussed on the list, this will the ldap_*_search_base options in
the form of:
search_base[?scope?[filter][?search_base?scope?[filter]]*]
This is backwards-compatible (just use a search base)
Patch 0005: Add support for multiple search bases for users
Patch 0006: Add support for multiple search bases for netgroups
Patch 0007: Add support for multiple search bases for RFC2307 groups
Patch 0008: Add support for multiple search bases for initgroups (user
portion)
Patch 0009: Add support for multiple search bases for initgroups
(RFC2307 group portion)
Patch 0010: Add support for multiple search bases for initgroups
(RFC2307 group portion)
This patch I'm not 100% sure of. It may need more processing. With
RFC2307, it was safe to have duplicate groups in the list, because only
the group name is important (and we guarantee that the name list has
only unique values before saving it). With RFC2307bis, I'm not sure if
it's safe to add two groups that may have the same name. Comments
welcome.
Patch 0011: Temporary patch that just disallows the use of multiple
search bases when enumeration mode is turned on. We can drop this patch
when the enumeration support is available.
12 years, 6 months
[PATCH] Use explicit base 10 for converting strings to integers
by Jakub Hrozek
https://fedorahosted.org/sssd/ticket/1013
I'll provide a 1.6/1.5 back port when this patch is acked.
I've tested with a user that looks like this:
---------------
dn: cn=octaluid,$DC
objectClass: posixAccount
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: top
uid: octaluid
uidNumber: 1000
gidNumber: 1000
homeDirectory: /home/octaluid
gecos: 01000
loginShell: /bin/bash
sn: octaluid
givenName: octaluid
cn: octaluid
---------------
Then remapped the uidNumber attribute in /etc/sssd/sssd.conf:
ldap_user_uid_number = gecos
Without the patch, getent passwd octaluid reported uid 512, with the
patch, it reports 1000. Saving users with UIDs of bases that cannot
be converted with base-10 fails now (I tested hexadecimal 0x1000).
12 years, 6 months