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?>> Thanks. >> > >
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. 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. 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.
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.> > 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. >>> >> >> >