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.
> 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
>>>
>>>
>>
>