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?):
[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).
The following ldap searches work (the search filter is lifted literally from sssd_SAMBA.log):
# Without host uri specification (will default to 127.0.0.1): ldapsearch -x -ZZ -L -D ldap-elohim@raaftech.nl -W -b "dc=raaftech,dc=nl" '(&(objectclass=person)(msSFU30Name=*)(uidNumber=*)(gidNumber=*))'
# With short hostname: ldapsearch -x -ZZ -L -H ldap://elohim -D ldap-elohim@raaftech.nl -W -b "dc=raaftech,dc=nl" '(&(objectclass=person)(msSFU30Name=*)(uidNumber=*)(gidNumber=*))'
# With domainname: ldapsearch -x -ZZ -L -H ldap://raaftech.nl -D ldap-elohim@raaftech.nl -W -b "dc=raaftech,dc=nl" '(&(objectclass=person)(msSFU30Name=*)(uidNumber=*)(gidNumber=*))'
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!!
Kind regards,
Rubin Simons, RAAF Technology
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).
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@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
sssd-devel@lists.fedorahosted.org
-
Rubin -
Stephen Gallagher