[PATCH] Adding script to create a SRPM
by Lukas Slebodnik
ehlo,
Recommended way to create SRPM is to run make (prerelease-)srpm.
But in previous case make file have to be generated, therefore
configure script should not fail. (all sssd required dependencies have to be
installed)
Script make_srpm.sh can be runned without running configure, script can be
runned only from git repository.
https://fedorahosted.org/sssd/ticket/1927
Patch is attached.
LS
10 years, 10 months
[PATCH] Global Catalog lookups and Active Directory trusted domains
by Jakub Hrozek
Hi,
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
if possible.
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
upcoming patches.
[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
bases.
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
search bases.
[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
separate function
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
subdomain users.
[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
list.
[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
https://fedorahosted.org/sssd/ticket/1557
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
https://fedorahosted.org/sssd/ticket/364
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.
10 years, 10 months
[PATCH] Enhance PAC responder for AD users
by Sumit Bose
Hi,
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
patches.
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.
bye,
Sumit
10 years, 10 months
[PATCH] Lookup domains at startup
by Sumit Bose
Hi,
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
FQname.
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.
Fixes https://fedorahosted.org/sssd/ticket/1951.
bye,
Sumit
10 years, 10 months
Ticket #1376 -- Add support for suppressing group members
by Paul B. Henson
I'm attaching an initial draft of the implementation of
ignore_group_members per ticket #1376. I still need to update the
documentation (and some python code in SSSDConfig it looks like), but
functionality wise this prevents ldap from requesting the member
attribute and sssd from returning any cached members that might be left
in the local db. As this is my first attempt at working with sssd, I
wanted to get early feedback in case I'm doing something silly ;).
Also, regarding the comment on the ticket:
"The trickiest piece of this functionality would be ensuring that we
don't delete existing member/memberOf linkages from the cache during
group lookups that were put there by previous initgroups() requests.
Thus, when this option is in play, member/memberOf should only be
managed by initgroups() calls."
My understanding of this is that an initgroups call will set up some
state in the cache regarding members of groups, and a getgrnam or
getgrgid call that skips retrieving the member attribute will wipe these
out of the cache. However, it's also my understanding that *every*
initgroups call hits ldap directly to make sure stale data isn't used
for authorization purposes. If so, why do we care that the data in the
cache, which isn't going to be used, gets wiped out? When
ignore_group_members is enabled, the only thing that cares about group
members is initgroups, correct?
Thanks...
10 years, 11 months
[PATCH] Set canonicalize flag if enterprise principals are used
by Sumit Bose
Hi,
after some discussion with Greg Hudson I realized that AD does not
canonicalize enterprise principals by default, as a MIT KDC does, but
explicitly needs the canonicalize flag to be set. With this fix the ugly
user\@SOME.REALM(a)OTHER.REALM principals in the credential cache should
go away.
bye,
Sumit
10 years, 11 months
