[PATCH 1/2] SYSDB: Use the add_string convenience functions for managing
ghost user attribute
Using the convenience function instead of low-level ldb calls makes the
code more compact and more readable.
[PATCH 2/2] LDAP: Only convert direct parents' ghost attribute to member
I'm not too happy with the originalDN attribute exposed in the
sysdb_add_user/store_user functions but it seemed like a better way
than grabbing the attribute from the extended attributes in the "attrs"
array. At the same time, we need to adjust the attributes during all user
adds, not just during sdap_store_user from the LDAP provider. Ideas on
how to make the process cleaner are welcome.
This patch changes the handling of ghost attributes when saving the
actual user entry. Instead of always linking all groups that contained
the ghost attribute with the new user entry, the original member
attributes are now saved in the group object and the user entry is only
linked with its direct parents.
As the member attribute is compared against the originalDN of the user,
if either the originalDN or the originalMember attributes are missing,
the user object is linked with all the groups as a fallback.
The original member attributes are only saved if the LDAP schema
The behaviour of ldap_sasl_authid was changed in
e81a816cddab4a62f263d1a0274d5d3f101e8e0f so that it no longer accepted full
principal, but only hostname. The realm was read from the (undocumented)
Moreover the "hostname" had to be specified in exactly the format that would
match the keytab later, ie if the first match was host/hostname, the option
would have to be specified as host/hostname, otherwise the user got an error.
I also found out that the principal selection is only used in IPA and AD
providers, but I'll file a separate ticket to track that. Right now, I'm
mostly interested in fixing the regression.
The attached patched modify that behaviour:
[PATCH 1/3] MAN: document the ldap_sasl_realm option
The option was completely undocumented.
[PATCH 2/3] LDAP: Provide a common sdap_set_sasl_options init function
The AD and IPA initialization functions shared the same code. This patch
moves the code into a common initialization function.
[PATCH 3/3] LDAP: Make it possible to use full principal in ldap_sasl_authid again
When the guessing of principals was introduced, we changed the existing
behaviour and instead of allowing both host/hostname@REALM and
host/hostname, only the latter worked and the realm was always appended
from the (then undocumented) ldap_sasl_realm option.
This patch changes the behaviour to be more backwards-compatible -- if
the ldap_sasl_authid contains the @-sign, then the ldap_sasl_realm is
not always appended.
The strict requirement of checking the requested authid/realm against
the one found in keytab was also kind of relaxed because it didn't
really work. For example when hostname was requested and the keytab
matched host/hostname first, the code blew up.
the following three patches make password changes for trusted AD users
work and fix https://fedorahosted.org/sssd/ticket/1615 . The most
important fix, disabling canonicalization for the AS-REQ for the change
password ticket, is in the third patch. The other two fixes issues I
came across which might block password changes under specific
In case a service is restarted while the DP is not ready yet, it gets
restarted again immediatelly, which means the DP might still not be
ready. The allowed number of restarts is then depleted quickly.
This patch changes the restart mechanism such that the first restart
happens immediatelly, the second is scheduled after 2 second, then 4
In our current RHEL5 deployment, we use pam_listfile to control access
to our servers. While I was putting together our sss config for RHEL6, I
initially thought I could use the simple access provider to replace it.
However, we have both central accounts as well as local service accounts
on some servers. While we try to avoid scenarios where a local service
account needs to log in directly, in some cases it is unavoidable and as
such some of them exist in our pam_listfile configuration.
The sss pam provider always returns user unknown for these local users
in the account module, never getting to the access control. I would
consider it useful for the simple access provider to be able to control
access based on the allow/deny lists for users that aren't part of any
sss domain, without that capability it cannot replace pam_listfile. I
took a look, and unfortunately making such a change seems far from
What are thoughts on such functionality? From a design perspective, do
you prefer that this access control mechanism only function with sss
domain users? From an abstract perspective, it could easily process
allow/deny for users that it doesn't know about. Groups, OTOH, would be
more problematic. I think all of our current pam_listfile configuration
for local accounts is based on users though.
The other option I considered was adding a second sss domain that
proxied nss_files such that sss was aware of local users. This seemed a
bit kludgy, more so than just continuing to use pam_listfile, which is
what we ended up doing.
This patch changes the way subdomain users are stored in the database.
The reason for changing the way we do it is that the sysdb code, before the
subdomain patches were added assumed a single domain per cache file. This
assumption beled in many other interfaces including the way users are read and
returned in the nss responder, as well as potentially how hbac and sudo handle
rules for checking if users are part of a rule.
In order to make sure subdomain users are univocally recognized as such the
safest way is to change how users are saved and always save subdomain users
with sully qualified names.
With this change we solve one of the most eveident issues we currently have
where subdomain users are not listed fully wualified in group membership when
The side effect of this change is that cache files need to be removed if the
admin decides to change the formatting string for representing fully qualified
users. An action like this has many other important consequences on the system
so I think this limitation is perfectly reasonable.
This patch is in RFC status because I haven't dealt with database migrations
to fix existing subdomain users. Would it be acceptable to simply remove
all subdomain user entries on upgrade ?
Also in order to fix this important issue for 1.9 I have refrained from
significantly changing sysdb interfaces or other code around domain
manipulation. I think such changes are necessary in future. The consequence
of not changing sysdb interfaces is that knowledge of the fact the subdonains
users need to be fully qualified bleeds in various other callers. I hope I
caught all the callers that need to know about this difference but I haven't
yet checked sudo related code for example.
The patch is so far fully tested and allows password based logins with full
HABC checking. getent passwd/group commands also return the extected outputs.
Please review carefully.
Simo Sorce (1):
Refactor the way subdomain accounts are saved
src/db/sysdb_search.c | 17 +++++++++++-
src/providers/data_provider_be.c | 11 +++++++
src/providers/ipa/ipa_s2n_exop.c | 54 +++++++++++++++++++++++++++++++++++---
src/responder/nss/nsssrv_cmd.c | 36 +++++++++++++++++++++++--
src/responder/pac/pacsrv_cmd.c | 15 +++++++++-
src/responder/pac/pacsrv_utils.c | 52 ++++++++++++++++++++----------------
src/responder/pam/pamsrv_cmd.c | 18 ++++++++++++-
src/util/domain_info_utils.c | 2 +-
8 files changed, 170 insertions(+), 35 deletions(-)