This option is similar to override_homedir, except that it will
take effect only for users that do not have an explicit home
directory specified in LDAP.
It also fixes a minor bug in confdb_get_domain_internal() where we were
not testing the return value of talloc_strdup() for override_homedir
This option will allow administrators to set a default shell to be
used if a user does not have one set in the identity provider.
This patch was built atop "[PATCH] NSS: Add fallback_homedir option". It
may not apply cleanly without that patch.
When the ldap child process is killed after a timeout, try the next KDC.
When none of the ldap child processes succeed, just abort the connection
because we wouldn't be able to authenticate to the LDAP server anyway.
I scanned the SSSD source code with the clang static analyzer and found
a number of issues. Patches are attached -- I think that most of them
are OK to just include in master. Patches #1, #13 and #16 may be
something that we want to include sooner.
Because the clang analyzer is freely available in Fedora, I think it would
make sense to run a scan at least before a release.
Developers can also run the clang tool themselves - I'll add info how
into our Developers page.
I'm trying to get sssd to work with samba 4 and am having a rather
difficult time to get things to work.
I can see that sssd can actually talk to the samba 4 ldap service, and I
have verified that all attributes as specified in my sssd.conf exist. I
have verified that I can do ldapsearch queries identical to those done
by ldap_search_ext. The attached sssd.conf is known_working with a
"real" Active Directory 2003 R2.
I have set TLS_REQCERT = never and TLS_CACERT in /etc/ldap/ldap.conf
because I know that one of the error messages (see subject) might be
related to that. In sssd.conf I've set ldap_tls_reqcert=never and
temporarily set ldap_auth_disable_tls_never_use_in_production to True.
This has not made any difference.
I'm using Ubuntu LTS 12.04, on x86_64 with sssd 1.8.2-0ubuntu1.
I've attached my sssd.conf and a selection of relevant lines from the
Essentially, I can see that results are returned from the ldap server:
[sdap_parse_entry] (0x4000): OriginalDN: [CN=Rubin \
But then I see it reconnecting to the base domain name (probably typical
for Active Directory?):
[sdap_rebind_proc] (0x1000): Successfully bind to \
Which seems to fail later on (10 lines later):
[sdap_process_result] (0x0040): ldap_result error: \
[Can't contact LDAP server]
Since raaftech.nl is not in my ca.crt certificate I was suspecting an
typical tls hostname mismatch to be the cause, but since I've set
ldap_tls_reqcert=never and ldap_auth_disable_tls_never_use_in_production
I would not expect this error to occur (I know the error is very generic
but it is often related to tls).
The following ldap searches work (the search filter is lifted literally
# Without host uri specification (will default to 127.0.0.1):
ldapsearch -x -ZZ -L -D ldap-elohim(a)raaftech.nl -W -b
# With short hostname:
ldapsearch -x -ZZ -L -H ldap://elohim -D ldap-elohim(a)raaftech.nl -W -b
# With domainname:
ldapsearch -x -ZZ -L -H ldap://raaftech.nl -D ldap-elohim(a)raaftech.nl -W
In short, I think I tried everything and am suspecting an issue inside
sssd. As an aside, I don't understand fully why the reconnect occurs to
ldap://raaftech.nl/CN=Configuration,DC=raaftech,DC=nl .. I suspect this
has to do with why I'm having a problem.
Any pointers would be GREATLY appreciated!!
A Gentoo user reported configuration and build issues when building the
SSSD with Heimdal. He confirmed that the attached patch (which is a
modified version of his original patch) fixes the problem for him.