Sudo permissions by ldap groups via nslcd
Solution 1
Sorry about the long post, but it seems to work. I just had a typo in sudoers file. Took me a bit long to find it though, since the syntax was still correct but I couldn't execute any commands.
However, it's working now.
// Problem was that one ALL was missing, allowing me to execute no root cmds.
%group1 ALL=(root) !/bin/su
// Fixed it
%group1 ALL=(root) ALL, !/bin/su
Update: I realized a bit late but I also changed the following in /etc/nsswitch.conf
sudoers: ldap files
I just didn't think it was the fix because I still had the above mentioned sudoers typo.
Problem solved :)
Solution 2
I went with assigning local groups to users through pam_group to get the same functionality. In /etc/security/groups.conf
I added the following line
*;*;%administrators;Al0000-2400;adm,sudo,lpadmin
So any LDAP user that belongs to the LDAP group administrators
gets mapped to the local adm
, sudo
, and lpadmin
groups on the box. Seems simpler than having to install sudo-ldap
, unless I am missing something?
Related videos on Youtube
mohrphium
Updated on September 18, 2022Comments
-
mohrphium over 1 year
I have a problem with my sudo permissions in an MS ActiveDirectory to Debian LDAP authentication/authorization setup.
What I have so far
I've configured nslcd with libpam-ldap via ldaps and ssh login is working great.getent passwd myuser myuser:*:10001:10015:myuser:/home/myuser:/bin/bash
On my ActiveDirectory Server, the Unix Package is installed which adds the necessary attributes like posixGroup, posixAccount, gid, gidNumber, uid, uidNumber and so on.
My example user looks like this:
(I choose 10000+ to be on the safe side)cn: myuser uid: myuser uidNumber: 10015 gidNumber: 10000
I can restrict SSH logins by adding the following to /etc/nslcd.conf
filter passwd (&(objectClass=posixAccount)(|(memberOf=CN=group1,OU=groups,DC=domain,DC=com)(memberOf=CN=group2,OU=groups,DC=domain,DC=com)))
This specifies that only users with objecClass=posixAccount and group either group1 or group2 can login.
So far so good. However, I can't tell sudo to use those groups.
Here is what I tried
in /etc/sudoers// This one works, but only because the user has gidNumber=10000 set. // It doesn't matter if a group with this ID actually exist or not. // So it's not really permission by LDAP group. %#10000 ALL=(root) ALL // This is what I want, but it doesn't work. %group1 ALL=(root) ALL
The Problem
Somehow I need to tell sudo to take the requesting username, check what ldap-groups it belongs to and then see if the permissions for that group are sufficient to execute the command or not.Unfortuntely I have no idea where to start. Everything else works so far and I'm only stuck with sudo permissions. I thought about mapping the users gidNumber field to the groups gidNumber field but I don't know if mapping a user field to a group field is even possible.
I don't think so, since mapping in nslcd is specified like this
map passwd field1 field2
and passwd tells nslcd that it has to mapp user fields. Instead of passwd I could use groups, but not both of them.
-
user3731606 about 10 yearsIncidentally, why do you negate /bin/su? If you want to prevent a user from getting a root shell, then your !/bin/su is insufficient. sudo bash or cp /bin/su /tmp/su && sudo /tmp/su are just two of many ways to still get a root shell on most systems. (ignoring grsec, systrace policies, etc.)
-
mohrphium about 10 yearsThanks for the tip, also !/usr/sbin/visudo is missing. it was essentially just a test to see if a command is really blocked.
-
Dwight Spencer over 8 years@etherfish your correct on that but one really should be mounting tmp, var, /dev/shm, /home and the like as noexec thus leaving only /{,usr,usr/local}/[s]bin as the only spots that are mounted with exec perms.
-
FreeSoftwareServers over 7 yearsI like the idea, but it didn't work for me, can you improve your answer? Full answers should link to another page