[Samba] Fwd: Winbind and GPO access restrictions?
Kees van Vloten
keesvanvloten at gmail.com
Mon Oct 4 17:09:41 UTC 2021
On 04-10-2021 16:11, Patrick Goetz wrote:
>
>
> On 10/2/21 2:31 PM, Kees van Vloten wrote:
>> 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
>
> pam_mkhomedir works great if your home directories are on a filesystem
> the host system root user can write too. The problem is I have new
> (AD-authenticated) users logging in on workstations that automount
> home directories from an NFS server, and root on the workstations is
> squashed on the NFS server for security reasons. However, since the
> NFS server doesn't allow user logins at all, I am able to set 1777
> permissions on nfs-server:/home. When a user attempts to log in,
> pam_script runs a script which mounts nfs-server:/home to a /tmp
> location, checks to see if the user already has a home directory, and
> if not creates one in the temp location, then unmounts it. There are
> some timing issues with this and autofs, but it mostly works. I was
> unable to come up with anything better that works on user demand.
>
On some machines I have Kerberized-NFS setup, but I have not had new
users for some time. Thanks to your remark, I just verified with a test
user that pam_mkhomedir is no good.
Pam_winbind has an option in its config:
mkhomedir = yes
But on login no homedir is created.
Unfortunately auth.log has not entries related to homedir creation nor
is there any clue in /var/log/samba/*. Without that I cannot tell if the
conf setting is ignored / wrong or the creation of the homedir fails
similar to pam_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