> On Mon, Sep 21, 2015 at 07:39:01PM +0000, Andy Thompson wrote: > > > -----Original Message----- > > > From: Jakub Hrozek [mailto:[email protected]] > > > Sent: Monday, September 21, 2015 3:29 PM > > > To: Andy Thompson <[email protected]> > > > Cc: [email protected]; [email protected] > > > Subject: Re: [Freeipa-users] rhel 6.7 upgrade - sssd/sudo > > > > > > On Mon, Sep 21, 2015 at 02:22:54PM +0000, Andy Thompson wrote: > > > > > > > > > > On Thu, Sep 17, 2015 at 11:42:54AM +0000, Andy Thompson wrote: > > > > > > I've narrowed it down a bit doing some testing. The sudo > > > > > > rules work when > > > > > I remove the user group restriction from them. My sudo rules > > > > > all have my ad groups in the rule > > > > > > > > > > > > Rule name: ad_linux_admins > > > > > > Enabled: TRUE > > > > > > Host category: all > > > > > > Command category: all > > > > > > RunAs User category: all > > > > > > RunAs Group category: all > > > > > > User Groups: ad_linux_admins <- if I remove this then the > > > > > > rule gets > > > > > applied > > > > > > > > > > Nice catch. Is the group visible after you login and run id? > > > > > > > > > > What is the exact IPA server version? > > > > > > > > Ok I also figured out if I rename my AD groups to match my IPA > > > > groups then > > > the sudo rules are applied. > > > > > > > > I tested a couple things though, if I put a rule in the local > > > > sudoers file on a server running sssd 1.11 > > > > > > > > %<groupname>@<IPA domain> "sudo commands" > > > > > > > > That rule was not applied. If I remove the <IPA domain> then the > > > > rule got > > > applied. > > > > > > > > On a server running sssd 1.12 that rule works, but does not work > > > > if I > > > remove the <IPA domain>. And none of the IPA sudo rules work. So > > > something changed with the domain suffix between versions it would > > > appear. > > > > > > > > They key to making the IPA sudo rules work in 1.12 is to remove > > > > the > > > default_domain_suffix setting in the sssd.conf, but that's not an > > > option in my environment. > > > > > > > > So all the moving parts together, it appears that having AD groups > > > > with a different name than the IPA groups in conjunction with the > > > > default_domain_suffix setting breaks things right now in 1.12. > > > > Appears since I renamed the ad group to match then the rule > > > > without a domain suffix will get matched now > > > > > > Hello Andy, > > > > > > I'm sorry for the constant delays, but I was busy with some > > > trust-related fixes lately. > > > > > > Did you have a chance to confirm that just swapping sssd /on the > > > client/ while keeping the same version on the server fixes the issue for > you? > > > > > > Pavel (CC), can you help me out here, please? I have the setup ready > > > on my machine, so tomorrow we can take a look and experiment (I can > > > give you access to my environment via tmate maybe..), but I wasn't > > > able to reproduce the issue locally yet. > > > > It's fine I understand the backlog. > > > > I was not able to backrev the sssd due to dependency issues. I tried > downgrading all the dependencies and got in a loop and stopped trying. Are > there any tricks you can think of to downgrade the sssd cleanly? > > > > -andy > > > > What failures are you getting? I normally just download all \*sss\* packages > and then downgrade with rpm -U --oldpackage.
I'm just trying to use yum. If I yum downgrade sssd I get a ton of deps. If include all the deps it lists yum downgrade sssd sssd-proxy sssd-ipa sssd-common-pac sssd-krb5 sssd-krb5-common sssd-ldap sssd-ad libipa_hbac libipa_hbac-python python-sssdconfig I get multilib errors with libsss_idmap. Looks like my local repo doesn't have libsss_idmap 1.11 available. Let me look into that and see what repo it sits in and see if I can figure out why it's not pulling in. -andy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
