Hi SSSD developers,
I like to submit two patches that both fix compilation issues when using
Heimdal as kerberos provider.
I know the official position regarding Heimdal support. So when the
issues are small, like these two patches, I will try to provide patches
to improve Heimdal support.
The earlier compilation errors that I reported in issue #1385 where
Should I also open issue ticket(s) for these two patches?
ps Please be lenient, since I am neither a C programmer nor a Git user.
As you may have seen on the krb5 mailing list , there was a problem
with my patch  to limit the enctypes requested to those in the keytab.
This patch to krb5 was to help sssd work with keytabs generated by samba
(which has no AES support) when used with AD running on Windows 2008 or
later (which have AES support). We also patched sssd for this problem,
so it can work with versions of krb5 that didn't have the a fore
The problem  was solved  by Greg by getting the
default_tkt_enctypes and sorting the ones in the keytab first.
However it seems that we cannot trivially solve this problem in our sssd
enctypes code in the same way. This is due to the fact that we don't
have access to the default_tkt_enctypes before hand. We have the
1) Rewrite the way we kinit with a keytab. Use krb5_init_creds_init()
+ krb5_init_creds_set_keytab() + krb5_init_creds_get() instead of
2) Revert my patch to sssd, and tell people to upgrade to a recent
krb5 1.11.x. This breaks sssd with samba generated keytabs and
3) Leave my patch in sssd, and tell people not to set
default_tkt_enctypes when using sssd, which would otherwise break
I realize this is a bit confusing, and hope I explained it well enough.
Ping me if something doesn't make sense.
These patches should finish off the AD provider functionality for 1.9.0.
All of these patches depend on those in the thread "Add Active Directory
identity, auth and chpass providers to SSSD"
Patch 0001: Add another option 'ad_keytab' that unifies the krb5_keytab
and ldap_krb5_keytab options.
Patch 0002: Add manpages and SSSDConfig API references for new AD
provider options. This patch depends on "MAN: Unify "SEE ALSO" sections"
Patch 0003: Add a function to the confdb to allow us to write a boolean
value into the configuration database. (Used in patch 0004)
Patch 0004: During initial configuration of the AD provider, force the
option case_sensitive to false, since all AD deployments are
case-insensitive. We do this here (and set it in the confdb) so that the
responders will pick it up. Responders all start after the providers
have registered with the monitor (or if the monitor gives up waiting
after five seconds), so there should be no race here.
Please review promptly. Once these are approved, I will push the
complete set of AD provider patches to the master.
We have not been good about keeping our SEE ALSO sections up to date.
This patch combines all of them into a single includable XML document
and uses it for ALL manpages.
It does mean that we'll end up with the complete list in every manpage,
but I think this is better than having manpages no one knows about.
This patch will be a prerequisite of my AD provider manpages.
I had problems running the python config API test when using a separate
build directory. The reason was that SSSDConfig/__init__.py is only
created in the build directory, but SSSDConfigTest.py was run from the
source directory. So SSSDConfigTest.py searched for SSSDConfig in the
source directory but could not load it, because there was only
__init__.py.in. This patch tries to find out if SSSDConfigTest.py is run
under make be check the srcdir envvar and then sets sys.path
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:
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
>> 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 (every 24 hours)
>> ldap_purge_cache_timeout = 0
>> ldap_enumeration_refresh_timeout = 300
>> What I would like to know, is why long delays occur when doing an "ls -l /home". Is it because it has to write out each entry into the local database?
> How many users are we talking about, and are they all represented in /home?
> The initial enumeration can take up to a few minutes the first time (after that we only update on differences). Once the full enumeration has been completed, it should take about 0.02 seconds per lookup against the local cache. On ordinary lookups, there are no writes going on. Writes to the cache only occur on cache misses.
"ls -l /home" is fast after enumeration. But if I allow the enum cache
to time out, then "ls -l /home" take minutes. We have 430 directories.
I get around this problem, by setting the cache timeout to be very
long. However, it appears that using this configuration, both sssd_nss
and sssd_be are constantly growing in size. I.e., here are the memory
size after about 3 days of use. The resident memory has grown from
about 21m to over 200m. The ldap refresh (every 5 minutes), appears to
be constantly adding to the cache. Or maybe there is a problem with my
configuration that is causing this?
10468 root 20 0 402m 236m 14m S 0.7 1.5 2:50.74
10467 root 20 0 424m 222m 8164 S 0.0 1.4 10:20.20 sssd_be
Thanks. - Mark