[Samba] Fwd: Winbind and GPO access restrictions?
Kees van Vloten
keesvanvloten at gmail.com
Sat Oct 2 19:31:56 UTC 2021
On 02-10-2021 21:18, Patrick Goetz via samba wrote:
> 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?
>
The man page pam_winbind, says
require_membership_of=[SID or NAME]
If this option is set, pam_winbind will only succeed if the
user is a member of the given
SID or NAME. A SID can be either a group-SID, an alias-SID
or even an user-SID. It is also
possible to give a NAME instead of the SID. That name must
have the form: MYDOMAIN\mygroup
or MYDOMAIN\myuser (where '\' character corresponds to the
value of winbind separator
parameter). It is also possible to use a UPN in the form
user at REALM or group at REALM.
pam_winbind will, in that case, lookup the SID internally.
Note that NAME may not contain
any spaces. It is thus recommended to only use SIDs. You can
verify the list of SIDs a user
is a member of with wbinfo --user-sids=SID.
This option must only be specified on a auth module
declaration, as it only operates in
conjunction with password authentication.
There are many options on how to specify it. I did not want to take the
risk of doing it wrong, so I decided to do a lookup of the SID with:
wbinfo --group-info acl-desktops_access | awk -F : '{print $3}' | xargs
wbinfo -G
For creation of the home-dir I use pam-mkhomedir, the debian packages
are: oddjob oddjob-mkhomedir
It does need a corrected config file in /usr/share/pam-configs/mkhomedir:
Name: activate mkhomedir
Default: yes
Priority: 127
Session-Interactive-Only: yes
Session-Type: Additional
Session-Final:
optional pam_mkhomedir.so skel=/etc/skel umask=0022
Which you activate with: pam-auth-update --enable mkhomedir
- Kees
> 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
>>
>>
>
More information about the samba
mailing list