> 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:jhro...@redhat.com] > >>>> Sent: Monday, September 21, 2015 3:29 PM > >>>> To: Andy Thompson <andy.thomp...@e-tcc.com> > >>>> Cc: freeipa-users@redhat.com; pbrez...@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? -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
