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@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@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 _______________________________________________ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users