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
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 > >
On Sat, 2021-10-02 at 20:20 +0200, Kees van Vloten via samba wrote:> > #! /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,lpadmi > n,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 > >Interesting, but libvirt looks like you can use kerberos and you do not need to be a local member of sudo (or to put another way, your user does not need to be in /etc/sudoers): rowland at devstation:~$ id rowland | grep 'sudo' rowland at devstation:~$ samba -V bash: samba: command not found rowland at devstation:~$ sudo samba -V Version 4.14.7-Debian Care to explain how I can run sudo without apparently being a member of the group 'sudo' ? Rowland