[Samba] Fwd: Winbind and GPO access restrictions?

[Patrick Goetz]

That was extremely helpful, thanks. Also, clever use of pam_script. I've 
had to invoke this to facilitate automatic home directory creation on 
workstations where the home directory folder is automounted from an NFS 
server and workstations are root_squash'ed. Very kludgy; linux needs 
better default ACLs.

Does "require_membership_of" in /etc/security/pam_winbind.conf insist on 
the use of SIDs, or can you use userName and/or a Security Group name here?

On 10/2/21 13:20, Kees van Vloten via samba wrote:
> 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
> 
>