[Samba] Using SSSD + AD with Samba seems to require Winbind be running

[Robert Marcano]

On 8/12/20 9:11 AM, L.P.H. van Belle via samba wrote:
> What i dont get/understand ..
> 
> Why ? Why such setup.
> Can TP explain this?
> 
> Just trying to understand you idea why setup like this..
> There must be a reason?
> 

SSSD provides features that Samba probably will not, like GPO login 
enforcement, and some it doesn't do yet like automatically define 
private groups (groups with the same name of the user, I filled a bug 
for this one)

There are meny others but my intention is not to advertice SSSD but help 
people that need to use it by company policy or by needed features.

> 
> Greetz,
> 
> Louis
> 
> 
>   
> 
>> -----Oorspronkelijk bericht-----
>> Van: samba [mailto:samba-bounces at lists.samba.org] Namens
>> Rowland penny via samba
>> Verzonden: woensdag 12 augustus 2020 14:41
>> Aan: samba at lists.samba.org
>> Onderwerp: Re: [Samba] Using SSSD + AD with Samba seems to
>> require Winbind be running
>>
>> On 12/08/2020 13:24, Robert Marcano via samba wrote:
>>> If you are runnning a Samba server as a member of a domain,
>> you need
>>> to start winbind. The following is a not a Samba issue
>> since Samba and
>>> SSSD interactions are not part of Samba.
>>>
>>> You can still run SSSD/realmd/adcli as your domain
>> membership toolkit,
>>> but you need to start winbind if a Samba server is started
>> on the same
>>> machine. Running winbind doesn't means you have to use winbind
>>> nsswitch module, you can still use SSSD module there and let it
>>> provide the list of users and groups to the system. In
>> order to make
>>> SSSD and winbind users match accordingly, you have to use
>> something like:
>>>
>>> idmap config MYDOMAIN : range = 278000000-278999999
>>> idmap config MYDOMAIN : backend = rid
>> There is no reason to match the sssd ID's on a Samba domain
>> member, also
>> you shouldn't have sssd and winbind installed on the same
>> machine, they
>> both use different version of the winbind libs.
>>>
>>> Use realmd to join the server and everything should work,
>> Just use 'net ads join', no need for realmd.
>>> Be careful that SSSD properly updates the machine account password,
>>> and Samba could be doing that too, but it doesn't with some
>>> combinations of the setting "kerberos method". I use
>>>
>>>    kerberos method = secrets and keytab
>> The kerberos method has nothing to do with updating the machine
>> passwords, it just tells Samba how to verify tickets, using
>> secrets.tdb
>> and the system keytab (the one in memory) in this case.
>>>
>>> Whe that setting is set, Samba doesn't try the machine password
>>> periodically. but as SSSD will try to do it, the Samba
>> server stores
>>> password and the SSSD one are different and your Samba
>> server start to
>>> have authentication problems.
>> If that is the case, one of them is broken and it isn't Samba ;-)
>>>
>>> You can disable SSSD machine account password renewal
>>> (ad_maximum_machine_account_password_age = 0) or run a cron
>> job with
>>> something like:
>>>
>>>    adcli update --add-samba-data -v
>> --computer-password-lifetime=0 -D
>>> <your domain>
>>>
>>> The --add-samba-data is a new option that exists on adcli
>> (at least on
>>> RHEL/CentOS 8) but the SSSD configuration parameter
>>> (ad_update_samba_machine_account_password) is upstream but
>> not yet on
>>> the distro version
>> I do not understand why the red-hat tools are used on a Samba server,
>> what is wrong with the Samba tools ?
>>> Hope this helps, but remember any problems with this configuration
>>> should be tried without using SSSD in order to know if it
>> is a Samba
>>> issue of SSSD one.
>>
>> Any sssd problems should be reported to sssd, we do not
>> produce it, so
>> we cannot fix it ;-)
>>
>> Rowland
>>
>>
>>
>> -- 
>> To unsubscribe from this list go to the following URL and read the
>> instructions:  https://lists.samba.org/mailman/options/samba
>>
>>
> 
>