Hi,
To quote myself,
Try a reboot...oh god a windows solution
so sssd cache problem?
The rc.local was missing so I put it in and restarted ssh, proof,
[root@vuwunicobandbt1 ~]# history |grep service
19 service sssd restart
25 service sssd restart
75 history |grep service
[root@vuwunicobandbt1 ~]# history |grep vi
17 vi /etc/rc.d/rc.local
24 vi /etc/sudo-ldap.conf
76 history |grep vi
[root@vuwunicobandbt1 ~]#
=
hrmmmdid I miss anything?
regards
Steven Jones
Technical Specialist - Linux RHCE
Victoria University, Wellington, NZ
0064 4 463 6272
From: Rob Crittenden [rcrit...@redhat.com]
Sent: Thursday, 23 August 2012 9:42 a.m.
To: Steven Jones
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] sudo su - works on one server for a user but not
on another (its twin)
Steven Jones wrote:
Hi,
Im trying to fault find why a user can sudo su - on a server but not its
twin.
I have nisdoaminnamae ods.vuw.ac.nz in rc.local.
and sudo-ldap.conf and nsswitch.conf appear to be identical but the
hostname match fails.
So for the working server,
sudo: ldap sudoHost '+servers-saas-root' ... MATCH!
sudo: ldap sudoCommand '/bin/su -' ... MATCH!
sudo: ldap sudoCommand '/bin/su - banner' ... MATCH!
sudo: Command allowed sudo: user_matches=1 sudo: host_matches=1
For the failing server,
sudo: ldap sudoHost '+servers-saas-root' ... not
sudo: ldap search 'sudoUser=+*'
sudo: user_matches=1
sudo: host_matches=0
I have a host failure, yet the server is in that host group...the HBAC
rule allows ssh and sudossh works for both, so HBAC rule should be OK.
The sudo command uses the same user and host groups as the HBAC...
Damned if I can see a setup error.
Ideas where to go looking next please?
Try temporarily enabling the allow_all HBAC rule so you can see if it is
an HBAC or a sudo problem?
rob
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
