[Samba] Winbind and GPO access restrictions?

[Patrick Goetz]

On 10/1/21 16:27, Rowland Penny via samba wrote:
> On Fri, 2021-10-01 at 17:01 -0400, Robert Marcano via samba wrote:
>> On 10/1/21 3:25 PM, Rowland Penny via samba wrote:
>>> On Fri, 2021-10-01 at 14:52 -0400, Robert Marcano via samba wrote:
>>>> On 10/1/21 2:21 PM, Patrick Goetz via samba wrote:
>>>>>
>>>
>>> I know I wasn't going to reply to any post that mentioned sssd,
>>> but,
>>> have you seen this:
>>>
>>> https://wiki.samba.org/index.php/Group_Policy
>>
>> Never, ever refrain from posting. We could skip knowledge we don't
>> know.
> 
> I will not post about sssd. I do not believe that you need to use sssd
> with Samba. Just about everything that sssd can do, Samba can do, or
> you can use another program with the data in AD. sudo is one such
> program, you can place the sudo rules in AD and then set up sudo to
> pull these rules from AD.
> 
> Samba does not produce sssd, so cannot provide good support for it,
> this is the province of the sssd-mailing list.
> 
> I have absolutely nothing against sssd, I used to use it years ago,
> until I realised that I did not need it. It is just something else to
> set up, for (in my opinion) no extra benefit.
> 
>> The wiki say: "Password and Kerberos policies, found in Computer
> Configuration > Policies > OS Settings > Security Settings > Account
> Policy, are only applicable to Samba Domain Controllers. "
> 
>> We are talking about login on workstations, restricting user login
>> based
>>
>> on groups, on workstations. If these kind of policies are now
>> supported,
>> cool, then the Wiki needs an update.
> 
> David Mulder has done quite a lot of work on GPO's recently, I am not
> certain just what applies and where, but it is likely that if what you
> are referring to isn't there now, then there is a good chance it will
> turn up fairly soon.
> 
> Are you aware that you can join a Unix domain member with samba-tool
> from Samba 4.15.0 ? Of course you will still need to create a smb.conf
> before attempting the join, but this could be created during the join
> if the command was extended to this, it just needs to ask a few
> questions, or provide options to the command
> 

The issue though is authentication access restrictions on domain 
members. I'm not a Windows guy and have only recently been using AD, but 
it's my understanding that a GPO is the standard way in AD-world to 
implement host-based access restrictions.

sssd is able to access group and user access permissions in GPO's (but 
this is pretty much the only GPO functionality implemented for linux 
hosts so far AFAIK).  sssd also has a key called ad_access_filter which 
you can set in the domain section of /etc/sssd/sssd.conf; e.g.

   ad_access_filter = 
samdom:(memberOf=cn=my_special_group,ou=groups,dc=samdom,dc-example,dc=com)

This isn't needed if you use GPO's.


It looks like this was already an issue on Samba 11 years ago:

 
https://serverfault.com/questions/159795/linux-active-directory-authentication-only-letting-certain-groups-login

Looking over the offered solutions:

  - Use /etc/security/access.conf  for this; e.g. add something like:

   + : administrator : ALL
   + : my_special_group : ALL
   - : ALL : ALL

I've only ever done this with local groups in /etc/group.  But 
presumably if you have winbind set in /etc/nsswitch.con:

   passwd:         compat systemd winbind
   group:          compat systemd winbind

pam_access.so will use this to verify group membership. I think the LDAP 
functions are built in to glibc; not sure how this works with AD 
authentication. Also couldn't find confirmation online that this 
actually works with AD Security Groups -- all the examples I saw were 
using generic LDAP.

It's also been suggested that you can use the pam_require.so module for 
this, say by adding this line to /etc/pam.d/common-auth on Debian-based 
systems:

   auth  required  pam_require.so  @my_special_group


But I haven't been able to confirm this works with AD Security Groups, 
either.  Is there another way of doing this with pam? Not sure.

Even if they work, the problem with the pam-based solutions (and sssd's 
ad_access_filter approach) is that I'm explicating @my_special_group in 
the host system's filesystem.  On some other host I might want to 
restrict access to @my_other_special_group. The whole point of using a 
Directory is centralizing the management of users and groups, and these 
methods deviates from that.


> Rowland
> 
> 
>