samba - Aug 2020 - Using SSSD + AD with Samba seems to require Winbind be running

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? 


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
> 
>

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
>>
>>
> 
>

On 12/08/2020 14:18, Robert Marcano via samba wrote:
> 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)
The GPO one is just about the only thing that sssd does that Samba 
doesn't and you do not need private groups, you want them, but you do 
not need them.
>
> 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.
Please advertise it somewhere else :D

Rowland

> 
> 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,
https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/enforce-user-logon-restrictions
If its a setting like that, sure you can enforce it (for windows). 

For linux, well, there is no GPO for linux.. but what would or are you doing /
need here?
Still trying to understand this more. 
> 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)
Why in earth would you do that. This makes you maintainenace only more complex. 
And, in my personal opinion more prone to errors. 
> 
> 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.
Thanks for you replies. 
It might help me understand better why people use/want to use SSSD.


So far, 

Greetz, 

Louis

On 12/08/2020 14:45, L.P.H. van Belle via samba wrote:
> Thanks for you replies.
> It might help me understand better why people use/want to use SSSD.
That is one I do not understand either, apart from the GPO option (which 
must be limited, GPO's generally do not work on Linux), everything that 
sssd does can be done by other means. I for instance use sudo rules from AD.

If you use sssd with Samba, then you need to setup two conf files (with 
a lot of duplicate info) and only use a version of Samba < 4.8.0. 
Whereas, with Samba, you only have one conf file and can use any version 
of Samba.

Rowland

On 8/12/20 9:45 AM, L.P.H. van Belle wrote:
>>
>> 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,
>
https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/enforce-user-logon-restrictions
> If its a setting like that, sure you can enforce it (for windows).
> 
> For linux, well, there is no GPO for linux.. but what would or are you
doing / need here?
> Still trying to understand this more.
SSSD can use Windows GPO rules related to authentication. You can read 
the original design document for that feature here 
https://sssd.io/docs/design_pages/active_directory_gpo_integration.html

Some of our installations use that (those small enough that aren't using 
FreeIPA for Linux servers and workstations)
> 
>> 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)
> 
> Why in earth would you do that. This makes you maintainenace only more
complex.
> And, in my personal opinion more prone to errors.
There is no extra maintenance, these groups are not groups to be managed 
on AD, they are only exposed as the primary group on an SSSD based 
domain member, it doesn't fill you AD tree with extra groups. SSSD just 
expose a virtual group with the same user name via the nsswitch module.

Without this feature, Having files created by any domain user to be 
assigned access to a group like "Domain Users" unless you manage for 
each user a gid on the AD user entry, or go to all workstations and 
server and change the users default umask in order to avoid exposing 
files by mistake is more error prone. All users having immediately a 
private group is simpler. And yes I need this by company policy.

Note: Even FreeIPA tried to discourage the use of private groups and use 
ipausers as the primary user group, a long time ago and they reverted 
later to have them by default.
> 
>>
>> 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.
> 
> Thanks for you replies.
> It might help me understand better why people use/want to use SSSD.
Our servers run with this configuration without problems, I know it is 
not what the Samba list recommend but when you have to use SSSD 
features, you  have to.

Note: The DC servers run Samba AD on a container, no SSSD in sight.

Hope this helps clarify why some of use use SSSD
> 
> 
> So far,
> 
> Greetz,
> 
> Louis
>

> -----Oorspronkelijk bericht-----
> Van: samba [mailto:samba-bounces at lists.samba.org] Namens 
> Robert Marcano via samba
> Verzonden: woensdag 12 augustus 2020 16:12
> Aan: samba at lists.samba.org
> Onderwerp: Re: [Samba] Using SSSD + AD with Samba seems to 
> require Winbind be running
> 
> On 8/12/20 9:45 AM, L.P.H. van Belle wrote:
> >>
> >> 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,
> > 
> https://docs.microsoft.com/en-us/windows/security/threat-prote
ction/security-policy-settings/enforce-user-logon-restrictions
> > If its a setting like that, sure you can enforce it (for windows).
> > 
> > For linux, well, there is no GPO for linux.. but what would 
> or are you doing / need here?
> > Still trying to understand this more.
> 
> SSSD can use Windows GPO rules related to authentication. You 
> can read 
> the original design document for that feature here 
> https://sssd.io/docs/design_pages/active_directory_gpo_integra
> tion.html
Ah,, now this is new to me.. I'll go read this..
Thank you.

> 
> Some of our installations use that (those small enough that 
> aren't using 
> FreeIPA for Linux servers and workstations)
> 
> > 
> >> 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)
> > 
> > Why in earth would you do that. This makes you 
> maintainenace only more complex.
> > And, in my personal opinion more prone to errors.
> 
> There is no extra maintenance, these groups are not groups to 
> be managed 
> on AD, they are only exposed as the primary group on an SSSD based 
> domain member, it doesn't fill you AD tree with extra groups. 
> SSSD just 
> expose a virtual group with the same user name via the 
> nsswitch module.
As primary group.. Ok, but a "local" group an AD-DC or domain joined
member
is BUILTIN\groupname 

I know why people use this part, its because they use chmod and have problems
setting ACL's.
If you set an ACL in linux and chmod over a folder and... Your ACL is gone.. 
Thats where most people there "problem" is. 
> 
> Without this feature, Having files created by any domain user to be 
> assigned access to a group like "Domain Users" 
Exacly , just like windows does. 

> unless you manage for 
> each user a gid on the AD user entry, or go to all workstations and 
> server and change the users default umask in order to avoid exposing 
> files by mistake is more error prone. All users having immediately a 
> private group is simpler. And yes I need this by company policy.
I get that, but this "All users having immediately a private group is
simpler"
Is just an opinion, mine is different but again, i understand the reasons. 

I worked 20years out in the field as IT guys for companies so yes i know 
What you mean with "company policy".. ;-) 

> 
> Note: Even FreeIPA tried to discourage the use of private 
> groups and use 
> ipausers as the primary user group, a long time ago and they reverted 
> later to have them by default.
Again a choise.. 
What i do with you primary groups.. I do different.
All my users have Domain users is primary group. 
Just because its not needed to change it. 
Only groups determin what people can see or read/write into, or which GPOs needs
to apply.
But you know you stuff.. I see that in your responce, "company
policy".. I know..
> 
> > 
> >>
> >> 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.
> > 
> > Thanks for you replies.
> > It might help me understand better why people use/want to use SSSD.
> 
> Our servers run with this configuration without problems, I 
> know it is 
> not what the Samba list recommend but when you have to use SSSD 
> features, you  have to.
> 
> Note: The DC servers run Samba AD on a container, no SSSD in sight.
> 
> Hope this helps clarify why some of use use SSSD
Yes, this helped my a lot in understanding why SSSD is used. 
Most welkom. 
Thanks. 


Greetz, 

Louis