[Samba] Fwd: Winbind and GPO access restrictions?

Sat Oct 2 18:20:09 UTC 2021

On 02-10-2021 18:18, Patrick Goetz via samba wrote:
>
>
> 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
>>
>>
>>
>
Allowing login for a certain group only is pretty simple in both sssd 
and winbind. Depending on the situation I use both of these:

Indeed set /etc/nsswitch.conf to resolv users and groups

passwd:         files systemd winbind
group:          files systemd winbind

Or

passwd:         files systemd sss
group:          files systemd sss

For winbind set /etc/security/pam_winbind.conf

[global]
warn_pwd_expire = 30

# winbind will keep your Ticket Granting Ticket (TGT) up-to-date by 
refreshing it whenever necessary
# (needs "winbind refresh tickets = yes" in smb.conf)
krb5_auth = yes

# succeed only if the user is a member of the given SID or NAME
# SID of "acl-desktops_acces" is:
require_membership_of = S-1-5-21-4190054395-3630394414-2036191173-1118

For sssd add below keys in /etc/sssd/sssd.conf:

[domain/example.com]
id_provider = ldap
access_provider = ldap
auth_provider = krb5
chpass_provider = krb5

# Access for member of specifed group(s)
access_provider = simple
simple_allow_groups = acl-desktops_access

use_fully_qualified_names = false
pwd_expiration_warning = 30

in Debian Bullseye sssd-ad is broken 
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=979995), i.e. use 
ldap+krb5.

In addition I tried pam_group a make users in AD-groups members of a 
local (access-)groups (for example 'sudo' or 'libvirt'). That works when 
viewed from the user that logged in, i.e. if I do 'id', I see myself as 
member of sudo and libvirt. But if the libvirt daemon checks 
group-memberships it does not see me as a member.
The only solution I could come up with is to write a script to really 
add my groups to the local-groups on login and remove the memberships on 
logout. pam_script can facilitate this, the script goes into 
/usr/share/libpam-script/pam_script_ses_open and create a symlink 
pam_script_ses_close to pam_script_ses_open.
The script:

#! /bin/bash
#
SUPPORTED_SERVICES="login sshd sddm-helper"
SCRIPT_CALLED_AS="$(basename $0)"

[[ -n "${PAM_USER}" ]] || exit 0
[[ -n "${PAM_SERVICE}" ]] || exit 0
! grep -q "^${PAM_USER}:" /etc/passwd || exit 0  # Do not do this for 
local users !!
echo "${SUPPORTED_SERVICES}" | grep -wq "${PAM_SERVICE}" || exit 0

declare -A GROUP_MAP
GROUP_MAP["acl-app_libvirt-access"]="libvirt"
# Allow sudo to root for:
GROUP_MAP["acl-desktops_sudo_root"]="sudo"

# https://wiki.debian.org/SystemGroups
# Allow access to devices:
GROUP_MAP["grp_${PAM_USER}"]="audio,video,dialout,cdrom,floppy,lpadmin,plugdev,bluetooth,netdev,pulse-access,users"

if [[ "${SCRIPT_CALLED_AS}" == "pam_script_ses_close" ]]; then
    N_LOGINS=$(who | awk '{print $1}' | grep "${PAM_USER}" | wc -l)
     if [[ ${N_LOGINS} -eq 0 ]]; then
         usermod -G "" ${PAM_USER}
     fi

elif [[ "${SCRIPT_CALLED_AS}" == "pam_script_ses_open" ]]; then
     USER_GROUPS="$(id -Gn ${PAM_USER})"
     for DOMAIN_GROUP in "${!GROUP_MAP[@]}"; do
         if echo "${USER_GROUPS}" | grep -wq "${DOMAIN_GROUP}"; then
             LOCAL_GROUPS="$(echo "${GROUP_MAP[$DOMAIN_GROUP]}" | sed 
's/,/ /g')"
             for LOCAL_GROUP in $LOCAL_GROUPS; do
                 grep -q "^${LOCAL_GROUP}:" /etc/group || continue
                 usermod -a -G "${LOCAL_GROUP}" ${PAM_USER}
             done
         fi
     done
fi
exit 0

Now /etc/group is actually updated when ou login or logout and even 
libvirtd sees the memberships correctly.

- Kees