Attached patch adresses issue https://fedorahosted.org/sssd/ticket/1816
I thought about ignoring these right after fetching from ldap, but the
solution to just ignore the range while updating sysdb seems more
appropriate, than going through whole range list.
Associate Software Engineer
Identity Management - SSSD
Red Hat Czech
the attached patches implement lookups in Global Catalog and AD
subdomains. Unfortunately they turned out to be quite complex and I'd like
to make them shorter and remove some of the complexity during the review
The patches implement identity lookups, authentication. There will be
additional patch that implements SRV discovery, but I wanted to get
the patches reviewed so that I don't waste time if the approach was not
correct. Authentication currently requires the subdomain to be present in
krb5.conf otherwise the Kerberos libraries would search for _kerberos-master,
not _kerberos and fail. Sumit, who kindly helped me debug this problem
might already have a MIT bug handy.
There is couple of LDAP provider patches that instead of using a single
connection towards LDAP allows for a linked list in the sdap_id_ctx.
Then the caller of the LDAP ID function can choose himself what
connection he would like to use for the particular lookup. For instance,
for trusted AD users, GC lookups are always used, but for native AD
users, LDAP can be used (and is actually preferred).
One part of the complexity comes from the fact that initially I wanted
the ID code to be flexible and allow "failover" between the connection.
In other words, the ID code could try GC lookup first and optionally
fail over to LDAP lookup using the same context if the entry was not
found using the first connection.
But after testing the identities I'm not sure if that is actually needed. The
trusted users and groups have to be looked up from GC anyway and the local
users and groups would be available in LDAP. Maybe we could conserve
some resources by attempting to look up local users from GC and only
keep one connection open when possible, but I'm not quite sure it is
worth it. Removing the connection failover would get rid of having to
report the LDAP return code to AD identity functions and maybe we could
even tie the connection with sdap_domain, too.
So can anyone think of a lookup where we would like to try one
connection and then the other? Maybe groups that contain members from
both primary and trusted domains might be such a case, but there we
could handle the failover in the group request.
[PATCH 01/15] Do not obfuscate calls with booleans
This is purely a personal preference, but I found it hard to follow what
the various booleans meant when reading function calls. Maybe macros
would make the code more readable, but I'm OK with not applying this
patch if others disagree.
[PATCH 02/15] LDAP: sdap_id_ctx might contain several connections
With some LDAP server implementations, one server might provide different
"views" of the identites on different ports. One example is the Active
Directory Global catalog. The provider would contact different view
depending on which operation it is performing and against which SSSD domain.
At the same time, these views run on the same server, which means the same
server options, enumeration, cleanup or Kerberos service should be used.
So instead of using several different failover ports or several instances
of sdap_id_ctx, this patch introduces a new "struct sdap_id_conn_ctx" that
contains the connection cache to the particular view and an instance of
"struct sdap_options" that contains the URI.
No functional changes are present in this patch, currently all providers
use a single connection. Multiple connections will be used later in the
[PATCH 03/15] LDAP: Refactor account info handler into a tevent request
The sdap account handler was a function with its own private callback
that directly called the back end handlers. This patch refactors the
handler into a new tevent request that the current sdap handler calls.
This refactoring would allow the caller to specify a custom sdap
connection for use by the handler and optionally retry the same request
with another connection inside a single per-provider handler.
No functional changes are present in this patch.
[PATCH 04/15] LDAP: Pass in a connection to ID functions
Instead of using the default connection from the sdap_id_ctx, allow the
caller to specify which connection shall be used for this particular
request. Again, no functional change is present in this patch, just
another parameter is added.
[PATCH 05/15] LDAP: new SDAP domain structure
Previously an sdap_id_ctx was always tied to one domain with a single
set of search bases. But with the introduction of Global Catalog
lookups, primary domain and subdomains might have different search
This patch introduces a new structure sdap_domain that contains an sssd
domain or subdomain and a set of search bases. With this patch, there is
only one sdap_domain that describes the primary domain.
[PATCH 06/15] LDAP: return sdap search return code to ID
By default, the LDAP searches delete the entry from cache if it wasn't
found during a search. But if a search wants to try both Global Catalog
and LDAP, for example, it might be beneficial to have an option to only
delete the entry from cache after the last operation fails to prevent
unnecessary memberof operations for example.
[PATCH 07/15] Move domain_to_basedn outside IPA subtree
The utility function will be reused to guess search base from the base
DN of AD trusted domains.
[PATCH 08/15] LDAP: split a function to create search bases
This function will be used later to fill the sdap_domain structures with
[PATCH 09/15] LDAP: store FQDNs for trusted users and groups
Because the NSS responder expects the name attribute to contain FQDN,
we must save the name as FQDN in the LDAP provider if the domain we save
to is a subdomain.
[PATCH 10/15] Split generating primary GID for ID mapped users into a
Move the part of sdap_save_user into a separate function so that it can
be special cased an only called for users in primary domains, not
[PATCH 11/15] LDAP: Do not store separate GID for subdomain users
As the subdomains are MPG domains, we don't want to store a separate GID
for the subdomain users, but rather just create a UPG.
[PATCH 12/15] New utility function sss_get_domain_name
Instead of copying a block of code that checks whether domain is a subdomain
and uses only name of FQDN as appropriate, wrap the logic into a function.
This patch might need rebase on top of the flat name patches on the
[PATCH 13/15] AD: Add additional service to support Global Catalog lookups
When fixed host names of AD servers are configured in the config file,
we can't know (unlike when service discovery is at play) if the servers
are Global Catalogs or not. This patch adds a private data to servers
read from the config file that denote whether the server can be tried for
contacting the Global Catalog port or just LDAP. The GC or LDAP URIs are
generated based on contents of this private data structure.
Because SSSD sticks to a working server, we don't have to disable or
remove the faulty GC servers from the list. Service lookups will be
supported in additional patch.
[PATCH 14/15] AD ID lookups - choose GC or LDAP as appropriate
Some lookups should be performed from GC only -- for example trusted
users are only present in the Global Catalog, while some lookups should be
performed from LDAP only as not all objects or attributes are replicated
to Global Catalog.
This patch adds a generic failover mechanism for identity lookups in the
AD provider that allows to choose the appropriate source and even fail
over to the other source if available.
[PATCH 15/15] AD: Store trusted AD domains as subdomains
Looks up trusted domain objects in the LDAP and stores them as AD subdomains.
Currently only trusted domains that run NT5 or newe from the same forest
are looked up and stored.
this patch makes sure that the PAC responder can be used with the AD
provider as well and so should fix
https://fedorahosted.org/sssd/ticket/1558. It depends on the SID mapping
It turned out that major parts of the PAC responder had to removed or
changed. E.g. all functions which were tested by the PAC responder unit
test got removed and hence the unit test is removes as well.
If tested the patch with IPA and AD provider. But since I certainly did
not cover all the corner cases (and maybe even missed some common
cases :-) I didn't enable the PAC responder for the AD provider by
default. But this can be done easily with an additional patch later.
I'm wondering whether we should be indexing the ghost users attribute.
Currently we are not.
In general, the ghost attribute is quite similar to the memberuid
attribute and I'm trying to see if the balance between the speed
benefits of having the attribute indexes vs the cost of indexing are
The ghost attribute is used on a couple of places. Most prominent are:
* nss responder - when the responder is gathering the list of users
who are members of a group, the members are the combined values of
memberUID and ghost attributes. Here we just check an element of
the group object, no search that includes the "ghost" attribute is
* LDAP provider - whenever a user is saved or deleted, the sysdb
is searched for any "ghost" entries with value equal to user's name
Which means saving or deleting a user triggers a search that
includes the ghost attribute.
* LDAP provider - when a group is saved and its members are not
resolved yet, a ghost entry is saved instead. I don't see us
searching using the ghost attribute there.
I suspect that indexing would only speed up the situation where we refer
to the ghost attribute in a search filter, right?
Then I suspect we wouldn't gain much by indexing the attribute, but I
wanted to check with the list anyway.
recently the patch "Allow flat name in the FQname format" was commit to
master. The flat domain name is determined at runtime but currently only when
the responders receive a request with an unknown domain name.
If now the flat domain name is used in the FQname and the nss responder
receives e.g. a 'getent passwd DOM\username' request with the flat
domain name after startup everything is fine. Because after startup the
domain part of the given fully qualified user name is not know and a
request will be send to the backends to look it up. If the request is
done the flat domain name is know and can be used in the returned
if on the other hand the nss responder receives a 'getent passwd
username(a)domain.name' with the domain name from sssd.conf the domain
part of the user name is known and there is no reason to send a
get_domains request to the backend. Hence the flat domain name is not
known when the FQname for the response is constructed and will be
replaced by the full name.
To avoid this the following patch will always run a get_domains request
at startup to get the needed domain data.
srv_data->dns_domain and srv_data->discovery_domain pointed to the same memory.
srv_data->dns_domain was freed in function resolve_srv_done()
but srv_data->discovery_domain was used on another place.
If there is a reason, that dns_domain and discovery_domain should be the same,
then It is possible to unite them to one "domain" member
Patch is attached