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:[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 > > > > > > > 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.. -- 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
