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

Andy Thompson Andy.Thompson at e-tcc.com
Thu Oct 1 12:53:14 UTC 2015


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




More information about the Freeipa-users mailing list