On 10/1/21 13:52, Robert Marcano via samba wrote:> On 10/1/21 2:21 PM, Patrick Goetz via samba wrote:
>>
>>
>> On 10/1/21 12:52, Robert Marcano via samba wrote:
>>> On 10/1/21 12:02 PM, Patrick Goetz via samba wrote:
>>>> While most of my campus Samba projects are still going to need
to
>>>> play nice with at least sssd id mapping, I do have one project
>>>> which, based on discussions on this list, I was planning to
>>>> configure strictly with winbind, since the AD DC is going to be
>>>> Samba and it's the rare luxury where I get to control
everything.
>>>>
>>>> However, a couple of days ago I had an anxiety-inducing
thought.
>>>> This is a mixed windows/linux environment, and one of the
features
>>>> the end users would like and which I've already promised
them is
>>>> that the linux machines would have different access
restrictions
>>>> from the Windows desktops. The way I've been doing this
with sssd is
>>>> creating a GPO applied to the host (or set of hosts) which
restricts
>>>> access to a particular security group.
>>>>
>>>> Reading through this page:
>>>> https://wiki.samba.org/index.php/Group_Policy
>>>> it's not clear this would also be possible with winbind.?
Would such
>>>> a thing fall under the category of "smb.conf
Policies"?? It doesn't
>>>> seem like it, since smb.conf access restrictions are most aimed
at
>>>> share control.
>>>>
>>>
>>> With winbind alone you will not be able to do that, you will need
to
>>> use classic Linux mechanism to control login (pam files editing for
>>> example) and maybe automate the deployment on all machines by other
>>> means (Ansible, Puppet, etc)
>>>
>>> Samba doesn't apply any GPO rules to Linux hosts. It is a sssd
>>> feature to apply login restriction policies if enabled (and only a
>>> few of them that make sense to Linux hosts)
>>>
>>
>> Oh wow. So I guess winbind can not do everything sssd does, and I'm
>> guessing that using idmap_sss doesn't help with this issue, either.
>>
>> Looks like I'm back to using RFC 2307 mapping and doing what
Rowland
>> said not to do: just matching the UIDs/GIDs on the linux systems. But
>> that's headache equivalent to using Ansible to copy around modified
>> PAM configuration files and solves the other problem I have of at
>> least one linux machine that needs file access being behind someone
>> else's AD domain.
>
> In the case of PAM files, these files are very security sensitive and I
> think people should embrace Red Hat auth select. Create customized
> configuration, probably based on /usr/share/authselect/default/winbind/
>
> Install that authselect profile as an RPM and the only thing you need to
> execute on you clients is to switch to your custom profile. At work I
> will never trust a young sysadmin to modify these files directly, it is
> too easy to make a security hole, only by a senior admin defining
> templates.
>
And when using common-auth files, even easier to lock everyone out of
the system so that you have to boot from USB or over IPMI to repair.
I didn't know about authselect and will need to look this up.
>>
>> Now I'm mystified at how people are using newer versions of Samba
in a
>> mixed Windows/Linux environment. If your linux workstations (i.e. not
>> fileservers) are bound to the domain, you most certainly want them to
>> be using domain authentication restrictions and not some ad hoc thing
>> you have to cobble together and deploy with CMS every time the
>> directory changes. I guess this is the problem that RHEL idM solves by
>> foresting with a Samba DC; no idea; I have no experience with this
>> whatsoever.
>>
>> Out of curiosity, is anyone out there using full blown sssd with a
>> Samba version > 4.8?? Is that even a thing?
>>
>>>> Thanks.
>>>>
>>>
>>>
>>
>
>