G
On 14/04/13 16:09, Rowland Penny wrote:
On 14/04/13 14:28, steve wrote:
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


Hi Steve, just a quick question, what OS are your clients running, if its Ubuntu, there is a ppa with the latest version available.

Anyway have a look here: https://fedorahosted.org/sssd/wiki/Configuring%20sssd%20to%20authenticate%20with%20a%20Windows%202008%20Domain%20Server

Rowland



Hi
Have openSUSE test client at the moment. Thanks for the link. Everything is working with the GSSAPI authentication, we've even got getent group to list not only the gidNumber, but group members too:) I'll test an Ubuntu client tomorrow, but it's looking good. Maybe I'll put some doco together.
Steve

--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba

Reply via email to