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?
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:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
