[Samba] sssd getent problem with Samba 4.0

[steve]

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