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

Wed Sep 30 12:42:19 UTC 2015

On Wed, Sep 30, 2015 at 12:17:22PM +0000, Andy Thompson wrote:
> > On 09/21/2015 10:42 PM, Andy Thompson wrote:
> > >> 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
> > >
> > 
> > Hi, since none of us is able to reproduce this in house, can you give us more
> > precise steps how to reproduce and more information? What I have in mind
> > at this moment is:
> > 
> > 1) How is membership defined? I suspect it goes as AD-USER -> AD-GROUP
> > -> IPA->GROUP, right? What types of groups are used?
> > 
> 
> I have AD user->AD group->external IPA group->IPA group
> 
> > 2) sssd.conf might also turn out to be useful
> > 
> > 3) Remove SSSD and sudo logs, reproduce and send us all the logs please
> > with the commands to reproduce. Not just snippets.
> >
> 
> I can gather this up and get it over to you. 
> 
> Actually I just realized I have two other environments and this is working without issue in those environments.  I haven't done a full sudo rollout in those environments yet so I didn't think to check those, but the admins rule is working correctly and I haven't renamed any ad groups to match my IPA groups.
> 
> Could it be something in a sudo rule or something in AD that's interfering with this working correctly?

I would first try to find the difference in the environment. Are sssd
versions the same on the clients and servers? Are sudo versions the
same?

...etc.

Pavel has a sudo troubleshooting guide in the works, maybe it would
help..