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

L.P.H. van Belle belle at bazuin.nl
Wed Aug 12 14:49:10 UTC 2020


 

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




More information about the samba mailing list