On Tue, 2012-05-08 at 12:43 +0200, Rubin wrote:
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?):
Typical, yes. Useful: rarely. The short version is this: Active
Directory does a lot of completely unnecessary internal LDAP referrals.
Unless you're using partial replication (e.g. satellite offices only
contain a subset of the total AD data), they're a waste of time and
cause all sorts of problems.
Specifically, we cannot always successfully follow the referral if the
referred server requires different credentials or negotiation. In the
case of AD, chances are that the server you're trying to rebind to will
only accept SASL/GSSAPI authentication with a host principal, and is
The easy answer here (as long as you're not using partial replication)
is to set 'ldap_referrals = False' in sssd.conf. I strongly suspect that
everything will just start working.
If you're using partial replication, you probably need to enroll the
host and get a host keytab to use, and you can follow the directions at
to accomplish this.
We're working in SSSD 1.9.0 to improve our interactions with AD. It's
one of our primary goals for that release.
[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).