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

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

They key to making the IPA sudo rules work in 1.12 is to remove
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 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?


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 -> AD-GROUP -> IPA->GROUP, right? What types of groups are used?

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.

Do you have any test machine we can ssh to?

Thank you!

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

Reply via email to