> On 09/30/2015 09:04 PM, Andy Thompson wrote: > >> 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: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? > >> > >> 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.. > > > > All updates are controlled from the same repo so versions are all the same > between the environments, that's why I'm wondering if something in AD > could cause this. Can't imagine what it would be though. Groups are all > mapped in the same way. > >Sudo is setup the same and works fine it was just the AD group name being > different that is throwing it fits in this one environment. Once I renamed > the > AD groups to match it all started pulling in without any issue. > > I think I don't really understand this paragraph. Can you be more descriptive > and specific here, please? Please, give us specific examples of the groups, > names, rules, etc. >
For example, in my environments I have a group in AD called "Linux Admins". I've got that mapped into IPA as below Linux Admins-> ad_linux_admins_external -> ad_linux_admins (posix) In the environment displaying this behavior I had to rename the AD group to "ad_linux_admins" to match the posix group name in IPA in order for sudo rules to work in conjunction with the default_domain_suffix configured in sssd. -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
