[Samba] sssd getent problem with Samba 4.0

[Rowland Penny]

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



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.