[Freeipa-users] Sudo works for full access, but not on a per command or host level.

[Simo Sorce]

On Wed, 2012-10-17 at 09:53 -0600, Rich Megginson wrote:
> On 10/17/2012 07:26 AM, Macklin, Jason wrote:
> > Okay,
> >
> >    Rule name: test4
> >    Enabled: TRUE
> >    Command category: all
> >    Users: asteinfeld
> >    Hosts: dbduwdu062.dbr.roche.com
> >    Host Groups: tempsudo
> >
> > Client dbduwdu062 is matched in the rule by both the hosts and groups entry.
> >
> > /etc/nsswitch.conf has:
> >
> > 	Netgroups: files sss
> >
> > Getent netgroup tempsudo returns:
> >
> > 	[jmacklin at dbduwdu062 Desktop]$ getent netgroup tempsudo
> > 	tempsudo              (dbduwdu063.dbr.roche.com, -, dbr.roche.com) (dbduwdu062.dbr.roche.com, -, dbr.roche.com)
> >
> > To the previous ldapsearch request:
> >
> > 	[jmacklin at dbduwdu062 Desktop]$ ldapsearch -Y GSSAPI -H ldap://dbduvdu145.dbr.roche.com "ou=SUDOers,dc=dbr,dc=roche,dc=com"
> > 	SASL/GSSAPI authentication started
> > 	ldap_sasl_interactive_bind_s: Server is unwilling to perform (53)
> > 	additional info: Entry permanently locked.
> >
> > I am still scratching my head on this one...
> 
> This means you cannot search using your kerberos ticket because the 
> corresponding entry is locked.  Try using directory manager:
> 
> ldapsearch -x -D "cn=directory manager" -W -H 
> ldap://dbduvdu145.dbr.roche.com "ou=SUDOers,dc=dbr,dc=roche,dc=com"
> 

This sounds very wrong.

If the user had a kerberos ticket in the first place it meant it
successfully authenticated.

If no krb ticket was available GSSAPI would have not started at all.

This look like some odd error in directory server failing to recognize
valid users ?

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York