Sudo permissions by ldap groups via nslcd

29,548

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?

Share:
29,548

Related videos on Youtube

mohrphium
Author by

mohrphium

Updated on September 18, 2022

Comments

  • mohrphium
    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
    user3731606 about 10 years
    Incidentally, 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
    mohrphium about 10 years
    Thanks 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
    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
    FreeSoftwareServers over 7 years
    I like the idea, but it didn't work for me, can you improve your answer? Full answers should link to another page