[sudo-users] can I prevent sudo on Solaris from performing ldap searches for local users?

[Josh Daynard]

Thanks Todd!

By the way, it looks like we’re using a rather old build of sudo:

pkginfo -l SMCsudo
   PKGINST:  SMCsudo
      NAME:  sudo
  CATEGORY:  application
      ARCH:  sparc
   VERSION:  1.6.8p4
   BASEDIR:  /usr/local
    VENDOR:  Todd Miller et al
    PSTAMP:  Steve Christensen
  INSTDATE:  Jul 25 2014 22:50
     EMAIL:  steve at smc.vnet.net
    STATUS:  completely installed
     FILES:       34 installed pathnames
                   5 shared pathnames
                   2 linked files
                   9 directories
                   3 executables
                   1 setuid/setgid executables
                 883 blocks used (approx)

I had previously tried adding both local users (the one performing the sudo and the target user) to /etc/user_attr in this fashion:

nsmail::::
nagios::::

Which seemed to quiet things down a bit but did not completely stop the lookups, both the one where it’s searching on objectclass=SolarisUserAttr and also where it appears to be trying to enumerate groups:

filter: (&(objectclass=posixgroup)(memberuid=nsmail))  attr list: cn, gidNumber, userpassword, memberUid

Also I’m not sure if a restart of any services such as ldap-client or clearing nscd user_attr cache might be required to pickup the change so I need to test further …

My goal is to have 0 ldapsearches triggered by sudo between two local users if possible … I’m hoping to find the magic config for this as that would be easier to push out but if I need to rebuild a new package from source, I’m happy to go that route ultimately (especially since our version is old anyway).

Thanks,
Josh

> On Feb 3, 2016, at 6:38 AM, Todd C. Miller <Todd.Miller at courtesan.com> wrote:
> 
> This might be triggered by the support for Solaris project resource
> limits.  You could rebuild sudo with that support disabled using
> the --without-project configure option.
> 
> However, it might be easier to just add an entry for the user to
> /etc/user_attr or /etc/user_attr.d/ on the affected systems.  If
> the user is found in the local file, ldap should not be consulted.
> 
> - todd