L.P.H. van Belle
2020-Aug-12 13:11 UTC
[Samba] 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: lists.samba.org/mailman/options/samba > >
Robert Marcano
2020-Aug-12 13:18 UTC
[Samba] Using SSSD + AD with Samba seems to require Winbind be running
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: lists.samba.org/mailman/options/samba >> >> > >
Rowland penny
2020-Aug-12 13:27 UTC
[Samba] Using SSSD + AD with Samba seems to require Winbind be running
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
L.P.H. van Belle
2020-Aug-12 13:45 UTC
[Samba] Using SSSD + AD with Samba seems to require Winbind be running
> > 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,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
Rowland penny
2020-Aug-12 14:06 UTC
[Samba] Using SSSD + AD with Samba seems to require Winbind be running
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
Robert Marcano
2020-Aug-12 14:12 UTC
[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, > 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 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 >
L.P.H. van Belle
2020-Aug-12 14:49 UTC
[Samba] Using SSSD + AD with Samba seems to require Winbind be running
> -----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, > > > 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 > sssd.io/docs/design_pages/active_directory_gpo_integra > tion.htmlAh,, 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 SSSDYes, this helped my a lot in understanding why SSSD is used. Most welkom. Thanks. Greetz, Louis
Maybe Matching Threads
- Using SSSD + AD with Samba seems to require Winbind be running
- Using SSSD + AD with Samba seems to require Winbind be running
- Using SSSD + AD with Samba seems to require Winbind be running
- Using SSSD + AD with Samba seems to require Winbind be running
- Using SSSD + AD with Samba seems to require Winbind be running