On 14/04/13 13:50, Rowland Penny wrote:
On 14/04/13 11:58, steve wrote:
On 14/04/13 10:59, Rowland Penny wrote:
On 14/04/13 09:29, steve wrote:
Version 4.0.6-GIT-4bebda4
Hi
I have sssd up and running. It works fine except that getent only
returns domain users if I specify the object e.g.
getent passwd
and
getent group
return only local users
but
getent passwd steve2
steve2:*:3000034:20513:steve2:/home/users/steve2:/bin/bash
and
getent group Domain\ Users
Domain Users:*:20513:
work fine.
This doesn't seem to be a problem.
/etc/nsswitch.conf
passwd: compat sss
group: compat sss
/etc/sssd/sssd.conf
[sssd]
services = nss, pam
config_file_version = 2
domains = default
[nss]
[pam]
[domain/default]
access_provider = simple
#simple_allow_users = myuser
enumerate = false
cache_credentials = True
id_provider = ldap
auth_provider = krb5
chpass_provider = krb5
krb5_realm = HH3.SITE
krb5_server = hh16.hh3.site
krb5_kpasswd = hh16.hh3.site
ldap_uri = ldap://hh16.hh3.site/
ldap_search_base = dc=hh3,dc=site
ldap_tls_cacertdir = /usr/local/samba/private/tls
ldap_id_use_start_tls = False
ldap_default_bind_dn = cn=lynn2,cn=Users,dc=hh3,dc=site
ldap_default_authtok = xx
ldap_default_authtok_type = password
ldap_user_object_class = person
ldap_user_name = samAccountName
ldap_user_uid_number = uidNumber
ldap_user_gid_number = gidNumber
ldap_user_home_directory = unixHomeDirectory
ldap_user_shell = loginShell
ldap_group_object_class = group
#ldap_user_search_filter =(&(objectCategory=User)(uidNumber=*))
I've tried
enumerate = true
and it works as expected but strangely, only for the first time
after sssd is started. it then returns only local users.
I have never tried it myself, the sssd wiki recommends not setting
'enumerate = true' until everything else is working and then not on
a large domain.
Any ideas?
Cheers,
Steve
Here is my sssd.conf
[sssd]
debug_level = 0x0270
config_file_version = 2
sbus_timeout = 30
domains = domain.tld
services = nss, pam
[nss]
debug_level = 0x0270
[pam]
debug_level = 0x0270
[domain/domain.tld]
debug_level = 0x0270
description = AD domain with Samba 4 server
cache_credentials = true
id_provider = ldap
auth_provider = krb5
chpass_provider = krb5
access_provider = ldap
# Uncomment if dns discovery of your AD servers isn't working.
krb5_server = server.domain.tld
krb5_kpasswd = server.domain.tld
krb5_realm = DOMAIN.TLD
ldap_referrals = false
# Comment out if not using SASL/GSSAPI to bind
ldap_sasl_mech = GSSAPI
ldap_schema = rfc2307bis
ldap_access_order = expire
ldap_account_expire_policy = ad
ldap_force_upper_case_realm = true
ldap_user_search_base = dc=domain,dc=tld
ldap_user_object_class = user
ldap_user_name = sAMAccountName
ldap_user_uid_number = uidNumber
ldap_user_gid_number = gidNumber
ldap_user_home_directory = unixHomeDirectory
ldap_user_shell = loginShell
ldap_user_principal = userPrincipalName
ldap_group_search_base = dc=domain,dc=tld
ldap_group_object_class = group
ldap_group_name = sAMAccountName
ldap_group_gid_number = gidNumber
Rowland
Hi Rowland
Thanks. I can live with the getent thing. The other worry I have is
that it seems to work without any sort of authentication. If I
comment out all this lot:
#ldap_tls_cacertdir = /usr/local/samba/private/tls
#ldap_id_use_start_tls = true
#ldap_default_bind_dn = cn=steve2,cn=Users,dc=hh3,dc=site
#ldap_default_authtok = s2
#ldap_default_authtok_type = password
#ldap_sasl_mech = GSSAPI
It still works. Users can still log in and getent passwd <user> works
too! There seems to be no security check made. Is there a cache I
need to clear? nscd is not running.
I've tried starting and stopping everything and even rebooted but
still is works without any authentication.
Worrying. . .
Cheers,
Steve
Hi Steve, I seem to remember reading on the sssd mailing list that
sssd uses a kerberos cache but the cache is stored in memory. When a
user logs in they get their own cache in /tmp with the format
'krb5_uidNumber_XXXXXX'
There is another cache in /var/lib/sss/db/
When they get the ad backend to work, you will find that the sssd conf
gets to be even smaller, you do not need any of the ldap lines.
Rowland
Hi Rowland
Thanks. I deleted user cache's under /tmp which had been created during
me messing around, whereupon no one could get anywhere near it. I then
configured gssapi/sasl, and now it's bulletproof without any passwords
flying around.
I got confused by your sssd.conf file. It has:
ldap_sasl_mech = GSSAPI
but nothing configured.
I used the machine key of the client for the auth_id which is already in
the default keytab when you join the domain.
I must say that I'm impressed by the simplicity of sssd. Just one slower
bit I've found is that using gssapi under nss-ldapd, the key is cached
under /tmp. With sssd, it seems to query for the (in my case) machine
key for every action it makes. Otherwise, fresh air.
Cheers,
Steve
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
