Hi Stephen,
Thanks for the quick reply. I was suspecting that this referal stuff was
breaking things so I tried setting:
ldap_user_search_base = ou=organization,dc=raaftech,dc=nl
ldap_group_search_base = cn=users,dc=raaftech,dc=nl
And sure enough, the nss part was now working; I suppose that is because
I'm not running into referal records in these specific search-bases! Now
I still got into trouble with the pam part though and kept getting
"System Error 4" messages. Setting:
ldap_referrals = False
Fixed this! I can now login to my Linux systems using Samba 4 and SSSD,
Thanks for the tip + prompt response!
I've attached a working sssd.conf file for other people who might run
into these issues when making SSSD talk to Samba 4. I've also attached
the neccessary MSFU30 ldif files that I created and used to make Samba 4
a real "Server for NIS" Domain so you can use the regular ADUC client
tool to administer "UNIX Attributes". If other readers want to use these
files, make sure you replace elohim, raaftech, raaftech.nl and
dc=raaftech,dc=nl strings with ones that make sense for you. You can
import these ldif files with a client like "Apache Directory Studio".
Kind regards + thanks for the great work + support,
Rubin Simons,
RAAF Technology
On 5/8/2012 1:34 PM, Stephen Gallagher wrote:
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).
_______________________________________________
sssd-devel mailing list
sssd-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel