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

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

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

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
downgrading all the dependencies and got in a loop and stopped
trying.  Are there any tricks you can think of to downgrade the


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

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.


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

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?


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.

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.


Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project

Reply via email to