[Samba] Winbind and GPO access restrictions?

Robert Marcano robert at marcanoonline.com
Fri Oct 1 20:00:21 UTC 2021


On 10/1/21 3:50 PM, Patrick Goetz via samba wrote:
> 
> 
> On 10/1/21 13:43, 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.
>>>
>>> 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?
>>
>> The semi official stance of the list is that SSSD isn't supported. But 
>> my real world usage tell that a Samba member file server, with active 
>> shares published and ACLs and everything else for it, works, I am not 
>> sure if a Samba usage more complex than that doesn´t work, but for my 
>> use case, works.
>>
>> CentOS 8 provided packages:
>>
>> sssd-2.4.0-9.el8_4.2
>> samba-4.13.3-4.el8_4
>>
>> The magic is that Samba requires winbind, you should run winbind, but 
>> that doen't means that /etc/nsswitch.conf must include winbind, mine 
>> doesn't. it only include sssd. Winbind id mapping is configured to 
>> match SSSD id mapping for AD domains. Winbind and SSSD use of 
>> /etc/nsswitch.conf to map user and group names to and from ids.
> 
> 
> Brilliant. I'm kicking myself that I didn't think of this.
> 
> 
>>
>> SSSD can use more nsswitch tables like sudoers but groups and users 
>> are the main conflict between winbind and sssd on nsswitch.conf
>>
>> Another tip is to use ad_maximum_machine_account_password_age = 0 on 
>> sssd.conf, probably doesn't needed anymore, latest SSSD has a new 
>> setting to sync passwords changes with the local Samba instance, but 
>> that wasn't on the SSSD packages for RHEL/CentOS 8 at the time I setup 
>> everything.
>>
> 
> But if you're using
> 
>     idmap config SAMDOM : backend = sss
> 
> then Windbind isn't keeping a local database?

You still need a default updatable database because there are some users 
and groups like the local administrators group, etc that need to be 
created. I add the default id map (the * named) run the initial samba 
server and copy that database to every other new member server, just to 
guarantee the same id for all these local groups an users on all servers.

SSSD mapping for AD domains is algorithm generated, not a database, much 
like some internal Samba id mappers.

> 
> 
> 
>> I will write a little howto in the future, now that there was some 
>> discussions about SSSD on the list, but for know I am too busy with 
>> some changes on my country at work (currency exchange switch caused bt 
>> high inflation, yea yea Venezuela :P). Maybe ping me in a few weeks if 
>> I haven´t published anything.
>>
> 
> Oh goodness. Hang in there; it sounds awful.  My great-grandfather kept 
> a scrap book of German currency during the 1920's inflation spiral. The 
> last banknote in his book was a one million DM note that had been 
> stamped over with one billion because it wasn't worth the paper to 
> reprint them from scratch.
> 
> 




More information about the samba mailing list