> 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 will add the finer grained rules in the other environments when I start 
rolling it out there one at a time and see if I can tie it to any of those.

-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

Reply via email to