-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 07/30/2013 07:58 PM, Chris Hayes wrote:
Hi everyone,
My aim is to have consistent Active Directory Users/Groups to Unix
UID/GID designations across several Linux machines joined to that
domain. Ideally without explicitly setting these in the directory.
After failing to get Winbind with a RID backend to work as desired,
a Samba user suggested that I try using SSSD instead.
For the last few hours I've been trying to get this to work; but
without much luck.
Right now I'm hitting a problem whereby SSSD's unable to find
valid users because none of my directory users have the attribute
"dataExpireTimestamp" and this is part of the search filter.
(Wed Jul 31 00:21:58 2013) [sssd[be[DEVDOM]]] [sysdb_search_users]
(0x0400): Search users with filter:
(&(objectclass=user)(&(!(dataExpireTimestamp=0))(dataE
xpireTimestamp<=1375226518)(!(lastLogin=*))))
That's not an LDAP search (though it uses the same syntax). That's an
internal search of our cache, which uses an LDAP-like database. The
dataExpireTimestamp is an internal attribute we use to identify when a
cached entry is expired and needs to be refreshed.
(Wed Jul 31 00:21:58 2013) [sssd[be[DEVDOM]]] [ldb] (0x4000):
tevent: Added timed event "ltdb_callback": 0x186bbc0 (Wed Jul 31
00:21:58 2013) [sssd[be[DEVDOM]]] [ldb] (0x4000): tevent: Added
timed event "ltdb_timeout": 0x186bce0 (Wed Jul 31 00:21:58 2013)
[sssd[be[DEVDOM]]] [ldb] (0x4000): tevent: Destroying timer event
0x186bce0 "ltdb_timeout" (Wed Jul 31 00:21:58 2013)
[sssd[be[DEVDOM]]] [ldb] (0x4000): tevent: Ending timer event
0x186bbc0 "ltdb_callback" (Wed Jul 31 00:21:58 2013)
[sssd[be[DEVDOM]]] [sysdb_search_users] (0x0400): No such entry
What this is telling you is that the entry wasn't found in the cache.
The next steps in the log *should* show it attempting to ask the LDAP
server to refresh the cache. We need to see more to help debug the
situation. If it's not going to LDAP here, it probably means that some
earlier attempt to talk to LDAP put the SSSD into 'offline' mode. This
may have been due to a misconfiguration, such as the server not
allowing the bind user access.
I've tried explicitly setting this without any luck. IT seems to
be ignoring the following line.
ldap_user_search_base =
CN=Users,DC=devdom,DC=orange,DC=local?subtree?(objectCategory=User)
And here's what I mean about that attribute affecting the search.
First using the filter that SSSD is using, second time using one
that doesn't reference the "dataExpireTimestamp" attribute.
/usr/local/samba/bin/ldbsearch -H ldaps://192.168.1.33
'(&(objectclass=user)(&(!(dataExpireTimestamp=0))(dataExpireTimestamp<=1375224572))))'
- -UAdministrator%XXX -b CN=Users,DC=devdom,DC=orange,DC=local
# returned 0 records # 0 entries # 0 referrals
/usr/local/samba/bin/ldbsearch -s sub -H ldaps://192.168.1.33
'(&(objectclass=user)(!(lastLogin=*)))' -UAdministrator%XXX -b
CN=Users,DC=devdom,DC=orange,DC=local [...] # returned 5 records #
5 entries # 0 referrals
As I said above, you're confusing an internal cache lookup against our
LDB database with an LDAP search.
I'm running SSSD version 1.8.4, and Samba4 version 4.0.6 as my
Domain Controller.
I *strongly* encourage you to try SSSD 1.9.x (available in Fedora,
RHEL 6.4+ and many other distributions; you didn't say which OS you
were running). Among other things, it's *much* easier to configure for
AD (especially if you use realmd or adcli to set up the keytab)
This is my current SSSD configuration (/etc/sssd/sssd.conf):
[sssd] domains = DEVDOM services = nss, pam config_file_version =
2 reconnection_retries = 3 sbus_timeout = 30
[nss] filter_groups = root filter_users = root reconnection_retries
= 3
[pam] offline_credentials_expiration = 0 reconnection_retries = 3
[domain/DEVDOM] debug_level = 9
description = LDAP domain with AD server id_provider = ldap
auth_provider = krb5 ;auth_provider = ldap ldap_default_bind_dn =
cn=Administrator,cn=Users,DC=devdom,DC=orange,DC=local
ldap_default_authtok_type = password ldap_default_authtok = XXX
Not related, but you almost certainly don't want to be using
password-auth for the bind DN if you're not encrypting the
communication channel with LDAPS, LDAP+TLS or LDAP+SASL. The LDAP
protocol puts the password on the wire in plaintext for all to intercept.
The best solution would be to set SSSD (1.9.x+) up with adcli to join
the realm and create a keytab that you could use for SSSD's
authentication to the server.
;ldap_user_object_class = person ;ldap_user_name = msSFU30Name
;ldap_user_uid_number = msSFU30UidNumber ;ldap_user_gid_number =
msSFU30GidNumber ;ldap_user_home_directory = msSFU30HomeDirectory
;ldap_user_shell = msSFU30LoginShell ;ldap_user_principal =
userPrincipalName ;ldap_group_object_class = group ;ldap_group_name
= msSFU30Name ;ldap_group_gid_number = msSFU30GidNumber
enumerate = TRUE ;cache_credentials = TRUE
chpass_provider = krb5
;tls_reqcert = demand ;ldap_tls_cacert =
/etc/pki/tls/certs/ca-bundle.crt
ldap_id_mapping = True ldap_idmap_default_domain_sid =
S-1-5-21-2003857637-2616505931-2053645484 ldap_idmap_range_min =
70000 ldap_idmap_range_max = 7000000 ldap_schema = ad
;; kerberos config ;; auth_provider = krb5 krb5_server =
hirst.devdom.orange.local krb5_realm = DEVDOM.ORANGE.LOCAL
krb5_changepw_principle = kadmin/changepw krb5_ccachedir = /tmp
krb5_ccname_template = FILE:%d/krb5cc_%U_XXXXXX krb5_auth_timeout =
15 ;cache_credentials = True
> ;;
https://lists.fedorahosted.org/pipermail/sssd-devel/2012-May/009677.html
;;
ldap_referrals = False ;ldap_search_base =
CN=users,DC=devdom,DC=orange,DC=local ldap_user_search_base =
CN=Users,DC=devdom,DC=orange,DC=local?subtree?(objectCategory=User)
;ldap_group_search_base =
CN=Users,DC=devdom,DC=orange,DC=local??(objectCategory=User)
Any ideas as to what could help would be really appreciated.
Thanks for your time,
As I said above, we really need more logs (at level 6 or above) to
help you figure out where things went wrong. I notice that you're
using 'enumerate = True', so there's a very real possibility that the
initial enumeration run that occurs when you start SSSD is detecting
an error and marking the SSSD offline. While you're testing right now,
I'd recommend setting that to False and using 'getent passwd
<username>' to test whether IDs are coming back. If that works, but it
doesn't when you turn enumerate back on, it probably means that one or
more of the entries in LDAP is invalid or contradictory, and you'll
need to check the enumerate logs for the reason.
Good enough to start with? You may also want to review
https://fedorahosted.org/sssd/wiki/FAQ#Troubleshooting for some more
tricks (though some are outdated; we support the 'ad' ldap_schema now
as well. I'll fix later; right now the Fedora Infrastructure is having
a planned patch outage)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -
http://www.enigmail.net/
iEYEARECAAYFAlH4XW8ACgkQeiVVYja6o6Nq2ACgkblr9HdHTIqgIHY20xLraIDh
A2YAnjXgG63oJdhLgtOjF2vh8sdlzYab
=d8yz
-----END PGP SIGNATURE-----