Bug 484

Can you try setting the following in /etc/ldap.conf?

sudoers_debug 3

And run "sudo -l" when CaseExactAccountName=yes?  Also, are you using netgroups for users or hosts?

For sudo we allow both netgroups for users and hosts - this one is failing on user netgroups ( they don't do triples!).

Set sudoers_debug to 3 - this account currently has two allowed commands:
/usr/bin/su - set on host and user name

and

    (root) NOPASSWD: /opt/VRTSvcs/bin/haclus -value ClusterName
set on hosts ALL

Should match against netgroup +midrangesupport-real-sudo (as it does when caseExactAccountName: no is set)

I've left a load of netgroup matches=not out!

uknwsaviv659:heald:/home/users/heald $ sudo -l
LDAP Config Summary
===================
host             midlogin.via.novonet:389
port             -1
ldap_version     3
sudoers_base     ou=SUDOers,cn=profiles,dc=norwich-union,dc=com
binddn           cn=sudoproxy,cn=profiles,dc=norwich-union,dc=com
bindpw           a1xpr0xy
timelimit        30
ssl              (no)
===================
sudo: ldap_init(midlogin.via.novonet:389, 389)
sudo: ldap_set_option: ldap_version -> 3
sudo: ldap_set_option: timelimit -> 30
sudo: ldap_sasl_bind_s() ok
sudo: found:cn=defaults,ou=SUDOers,cn=profiles,dc=norwich-union,dc=com
sudo: ldap sudoOption: 'authenticate'
sudo: ldap sudoOption: 'ignore_local_sudoers'
sudo: ldap sudoOption: 'logfile=/var/log/sudo.log'
sudo: ldap sudoOption: 'log_host'
sudo: ldap sudoOption: 'log_year'
sudo: ldap sudoOption: '!syslog'
sudo: ldap sudoOption: 'timestamp_timeout=0'
sudo: ldap sudoOption: 'passprompt=Enter your user password:'
sudo: ldap sudoOption: '!lecture'
sudo: ldap sudoOption: '!listpw'
sudo: ldap sudoOption: '!env_reset'
sudo: ldap sudoHost '+midrange-ldap-hosts' ... not
sudo: ldap sudoHost 'ALL' ... MATCH!
sudo: user_matches=1
sudo: host_matches=1
sudo: sudo_ldap_lookup(52)=0x02
Matching Defaults entries for heald on this host:
    authenticate, ignore_local_sudoers, logfile=/var/log/sudo.log, log_host, log_year, !syslog, timestamp_timeout=0, passprompt=Enter
    your user password:, !lecture, !listpw, !env_reset

Runas and Command-specific defaults for heald:


User heald may run the following commands on this host:
sudo: ldap search '(|(sudoUser=heald)(sudoUser=%nuadm)(sudoUser=%secadm)(sudoUser=%webserv)(sudoUser=ALL))'
sudo: ldap sudoHost '+midrange-ldap-hosts' ... not
sudo: ldap sudoHost 'ALL' ... MATCH!
    (root) NOPASSWD: /opt/VRTSvcs/bin/haclus -value ClusterName
sudo: ldap sudoHost 'uknwsaviv659' ... MATCH!
    (root) NOPASSWD: /usr/bin/su -
sudo: ldap search 'sudoUser=+*'
sudo: ldap sudoUser netgroup '+managedaddressing-real-sudo' ... not
sudo: ldap sudoUser netgroup '+midrangebuild-real-sudo' ... not
sudo: ldap sudoUser netgroup '+ondemandadmin-real-sudo' ... not
sudo: ldap sudoUser netgroup '+midrangesupport-real-sudo' ... not
.....
sudo: ldap sudoUser netgroup '+ws3nexussit-real-sudo' ... not
sudo: ldap sudoUser netgroup '+monitoringteam-real-sudo' ... not

Could there be a mismatch in the case of the username in the password database and the contents of the midrange-ldap-hosts netgroup?  Sudo just uses the system's innetgr() function to determine whether a user is a member of a netgroup.

I don't think so Todd - however they don't use triples here. So the netgroups are a collection of UIDs, or a collection of hosts.

So this lookup with caseexact match yes set should pickup:
cn=midrangesupport-real-sudo,ou=netgroup,cn=nisdata,cn=aixdata,dc=norwich-union,dc=com
cn=midrangesupport-real-sudo
objectclass=nisNetGroup
objectclass=top
nisNetgroupTriple=(,collia1,)
nisNetgroupTriple=(,goodhc1,)
nisNetgroupTriple=(,marss10,)
nisNetgroupTriple=(,swaffec,)
nisNetgroupTriple=(,wardj13,)
nisNetgroupTriple=(,gallos1,)
nisNetgroupTriple=(,heald,)

and sudo LDAP entries:
Role    : midrangesupport-admin-role
User    : +midrangesupport-real-sudo
Host    : ALL
Command : ALL
Runas   : root
Options : !authenticate


Is the issue then that sudo is expecting normal netgroup triples? Or did I read that completely wrong!

I am running into the same issue on Solaris 10. 
I have installed the below version of sudo on solaris.

application TCMsudo-ldap                     sudo-ldap 1.8.1p2

It appears the issue is related to the innetgr system call on Solaris 10. 
We currently use netgroups to define host-based access control on which users can login in which hosts. 
The nisNetgroupTriple(s) are set to have the users the sudo -l is being run as (in this case has been changed to foo)

However, it fails to match the user.
Digging through the source, it appears it is the innetgr system call and the host and domain portions of the nisNetgroupTriple don't matter as they are being passed in as NULL. 
Any advise/pointers will be much appreciated. 
Thanks. 

ldap.c : sudo_ldap_check_user_netgroup(LDAP *ld, LDAPMessage *entry, char *user)
ldap.c : netgr_matches(val, NULL, NULL, user)


--Display of the netgroup

ldaplist -l netgroups host1
dn: CN=host1,OU=netgroups,OU=base,DC=example,DC=com
        objectClass: top
        objectClass: nisNetgroup
        cn: host1
        distinguishedName: CN=host1,OU=netgroups,OU=base,DC=example,DC=com
        instanceType: 4
        whenCreated: 20110510192030.0Z
        whenChanged: 20110513182056.0Z
        uSNCreated: 4480589
        uSNChanged: 4485694
        showInAdvancedViewOnly: TRUE
        name: host1
        objectCategory: CN=NisNetgroup,CN=Schema,CN=Configuration,OU=base,DC=example,DC=com
        dSCorePropagationData: 16010101000000.0Z
        memberNisNetgroup: (,foo,)


--sudo output


sudo: ldap sudoOption: '!authenticate'
sudo: ldap search '(|(sudoUser=foo)(sudoUser=%foog)(sudoUser=ALL))'
sudo: searching from base 'DC=base,DC=example,DC=com'
sudo: adding search result
sudo: result now has 0 entries
sudo: ldap search '(sudoUser=+*)'
sudo: searching from base 'DC=base,DC=example,DC=com'
sudo: adding search result
sudo: ldap sudoUser netgroup '+host1' ... not
sudo: ldap sudoUser netgroup '+host2' ... not
sudo: ldap sudoUser netgroup '+host3' ... not
sudo: result now has 0 entries
sudo: sorting remaining 0 entries
sudo: perform search for pwflag 52
sudo: done with LDAP searches
sudo: user_matches=1
sudo: host_matches=0
sudo: sudo_ldap_lookup(52)=0x42
sudo: ldap search for command list
sudo: reusing previous result (user foo) with 0 entries