[SSSD] Using SSSD with Samba 4 (ldap_result error: [Can't contact LDAP server])

Stephen Gallagher sgallagh at redhat.com
Tue May 8 11:34:51 UTC 2012


On Tue, 2012-05-08 at 12:43 +0200, Rubin wrote:
> Hi All,
> 
> 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
> sssd_SAMBA.log file.
> 
> Essentially, I can see that results are returned from the ldap server:
> 
> 	[sdap_parse_entry] (0x4000): OriginalDN: [CN=Rubin \
> 	Simons,OU=Organization,DC=raaftech,DC=nl].
> 
> 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
therefore failing.

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
http://goo.gl/Be7sJ 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 \
> 	[ldap://raaftech.nl/CN=Configuration,DC=raaftech,DC=nl].
> 
> 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).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20120508/945588df/attachment.sig>


More information about the sssd-devel mailing list