[Freeipa-users] rhel 6.7 upgrade - sssd/sudo

[Andy Thompson]

> On Mon, Sep 21, 2015 at 07:39:01PM +0000, Andy Thompson wrote:
> > > -----Original Message-----
> > > From: Jakub Hrozek [mailto:jhrozek at redhat.com]
> > > Sent: Monday, September 21, 2015 3:29 PM
> > > To: Andy Thompson <Andy.Thompson at e-tcc.com>
> > > Cc: freeipa-users at redhat.com; pbrezina at redhat.com
> > > 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