Re: [Freeipa-users] SUDO and group lookup in AD trust

2016-11-07 Thread Troels Hansen 

> I'm not completely sure which release notes are you referring to, but
> this bug was fixed in sssd-1.14.0-32.el7. It's also listed in the
> changelog:
> 
> * Fri Sep  2 2016 Jakub Hrozek  - 1.14.0-32
> - Resolves: rhbz#1371152 - SSSD qualifies principal twice in IPA-AD trust
>   if the principal attribute doesn't exist on the
>AD side

I was checking the changelog on:
https://access.redhat.com/downloads/content/rhel---7/x86_64/2456/sssd/1.14.0-43.el7/x86_64/fd431d51/package-changelog

Apparently they have a "feature" that truncates the view of the release log to 
the last 10(-ish) entries.

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

Re: [Freeipa-users] SUDO and group lookup in AD trust

2016-11-07 Thread Jakub Hrozek 
On Mon, Nov 07, 2016 at 08:28:45AM +0100, Troels Hansen wrote:
> Hi there, I can see that RHEL 7.3 have left beta, and wanted to check this 
> shiny new release that should fix a lot of the problems and current quirks we 
> have, so I went through the release notes on SSSD in RHEL 7.3 and can't see 
> any patched being added since end September, and in particular a patch for 
> RHBZ# 1371152 in the SSSD 1.14 release ?

I'm not completely sure which release notes are you referring to, but
this bug was fixed in sssd-1.14.0-32.el7. It's also listed in the
changelog:

* Fri Sep  2 2016 Jakub Hrozek  - 1.14.0-32
- Resolves: rhbz#1371152 - SSSD qualifies principal twice in IPA-AD trust
   if the principal attribute doesn't exist on the
   AD side

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

Re: [Freeipa-users] SUDO and group lookup in AD trust

2016-11-06 Thread Troels Hansen 
Hi there, I can see that RHEL 7.3 have left beta, and wanted to check this 
shiny new release that should fix a lot of the problems and current quirks we 
have, so I went through the release notes on SSSD in RHEL 7.3 and can't see any 
patched being added since end September, and in particular a patch for RHBZ# 
1371152 in the SSSD 1.14 release ?


>> Will RHEL7.3 have the currently working SSSD 1.14.1 from jhrozek's COPR repo
>> (test build
>> https://copr.fedorainfracloud.org/coprs/jhrozek/sssd-principal-test/)
> 
> Not 1.14.1, but 7.3 will have the patch I put in my COPR repo (that's in
> general how RHEL works, we can rebase only up to a certain point and then
> we cherry-pick selected approved patches to avoid breaking RHEL with some
> unrelated upstream change..)

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

Re: [Freeipa-users] SUDO and group lookup in AD trust

2016-09-05 Thread Jakub Hrozek 
On Mon, Sep 05, 2016 at 09:02:04AM +0200, Troels Hansen wrote:
> 
> 
> - On Sep 2, 2016, at 9:56 AM, Jakub Hrozek jhro...@redhat.com wrote:
> >> >We were debugging this yesterday with Troels and the logs said it's:
> >> >https://fedorahosted.org/sssd/ticket/3127
> >> >
> >> Fixed version is in 1.14 copr
> > 
> > Thank you, btw another affected user confirmed that the patch fixes the
> > problem.
> > 
> 
> 
> Hi, one question. I can see that ticket 2919 targeted for 1.14.0 and 3127 
> which fixes our problem is targeted for SSSD 1.14.2 and RHEL 7.3beta 
> currently runs 1.14.0
> 
> Will RHEL7.3 have the currently working SSSD 1.14.1 from jhrozek's COPR repo 
> (test build 
> https://copr.fedorainfracloud.org/coprs/jhrozek/sssd-principal-test/)

Not 1.14.1, but 7.3 will have the patch I put in my COPR repo (that's in
general how RHEL works, we can rebase only up to a certain point and then
we cherry-pick selected approved patches to avoid breaking RHEL with some
unrelated upstream change..)

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

Re: [Freeipa-users] SUDO and group lookup in AD trust

2016-09-05 Thread Troels Hansen 


- On Sep 2, 2016, at 9:56 AM, Jakub Hrozek jhro...@redhat.com wrote:
>> >We were debugging this yesterday with Troels and the logs said it's:
>> >https://fedorahosted.org/sssd/ticket/3127
>> >
>> Fixed version is in 1.14 copr
> 
> Thank you, btw another affected user confirmed that the patch fixes the
> problem.
> 


Hi, one question. I can see that ticket 2919 targeted for 1.14.0 and 3127 which 
fixes our problem is targeted for SSSD 1.14.2 and RHEL 7.3beta currently runs 
1.14.0

Will RHEL7.3 have the currently working SSSD 1.14.1 from jhrozek's COPR repo 
(test build 
https://copr.fedorainfracloud.org/coprs/jhrozek/sssd-principal-test/)

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

Re: [Freeipa-users] SUDO and group lookup in AD trust

2016-09-02 Thread Jakub Hrozek 
On Fri, Sep 02, 2016 at 09:27:57AM +0200, Lukas Slebodnik wrote:
> On (26/08/16 07:54), Jakub Hrozek wrote:
> >On Thu, Aug 25, 2016 at 10:41:53PM +0200, Lukas Slebodnik wrote:
> >> On (25/08/16 11:30), Troels Hansen wrote:
> >> >Hmm, adding the CentOS SSSD 1.14 copr repo and running yum upgrade,
> >> >getting a version 1.14.1, clean cache DB (complaing about cache being
> >> >old version),
> >> Upgrade to 1.14.1 should not require puring sssd cache.
> >> If you are able to reproduce then please provide steps.
> >> Or file a sssd bug https://fedorahosted.org/sssd/newticket
> >> 
> >> >I can getent users, but log log in for no obvious reason (system error in 
> >> >secure.log).
> >> >
> >> system error sounds bad. Please provide log files with
> >> high debug level in domain section sssd.conf
> >> 
> >> https://fedorahosted.org/sssd/wiki/Troubleshooting#SSSDdebuglogs
> >
> >We were debugging this yesterday with Troels and the logs said it's:
> >https://fedorahosted.org/sssd/ticket/3127
> >
> Fixed version is in 1.14 copr

Thank you, btw another affected user confirmed that the patch fixes the
problem.

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

Re: [Freeipa-users] SUDO and group lookup in AD trust

2016-09-02 Thread Lukas Slebodnik 
On (26/08/16 07:54), Jakub Hrozek wrote:
>On Thu, Aug 25, 2016 at 10:41:53PM +0200, Lukas Slebodnik wrote:
>> On (25/08/16 11:30), Troels Hansen wrote:
>> >Hmm, adding the CentOS SSSD 1.14 copr repo and running yum upgrade,
>> >getting a version 1.14.1, clean cache DB (complaing about cache being
>> >old version),
>> Upgrade to 1.14.1 should not require puring sssd cache.
>> If you are able to reproduce then please provide steps.
>> Or file a sssd bug https://fedorahosted.org/sssd/newticket
>> 
>> >I can getent users, but log log in for no obvious reason (system error in 
>> >secure.log).
>> >
>> system error sounds bad. Please provide log files with
>> high debug level in domain section sssd.conf
>> 
>> https://fedorahosted.org/sssd/wiki/Troubleshooting#SSSDdebuglogs
>
>We were debugging this yesterday with Troels and the logs said it's:
>https://fedorahosted.org/sssd/ticket/3127
>
Fixed version is in 1.14 copr

LS

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

Re: [Freeipa-users] SUDO and group lookup in AD trust

2016-08-26 Thread Jakub Hrozek 
On Thu, Aug 25, 2016 at 10:41:53PM +0200, Lukas Slebodnik wrote:
> On (25/08/16 11:30), Troels Hansen wrote:
> >Hmm, adding the CentOS SSSD 1.14 copr repo and running yum upgrade,
> >getting a version 1.14.1, clean cache DB (complaing about cache being
> >old version),
> Upgrade to 1.14.1 should not require puring sssd cache.
> If you are able to reproduce then please provide steps.
> Or file a sssd bug https://fedorahosted.org/sssd/newticket
> 
> >I can getent users, but log log in for no obvious reason (system error in 
> >secure.log).
> >
> system error sounds bad. Please provide log files with
> high debug level in domain section sssd.conf
> 
> https://fedorahosted.org/sssd/wiki/Troubleshooting#SSSDdebuglogs

We were debugging this yesterday with Troels and the logs said it's:
https://fedorahosted.org/sssd/ticket/3127

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

Re: [Freeipa-users] SUDO and group lookup in AD trust

2016-08-25 Thread Lukas Slebodnik 
On (25/08/16 11:30), Troels Hansen wrote:
>Hmm, adding the CentOS SSSD 1.14 copr repo and running yum upgrade,
>getting a version 1.14.1, clean cache DB (complaing about cache being
>old version),
Upgrade to 1.14.1 should not require puring sssd cache.
If you are able to reproduce then please provide steps.
Or file a sssd bug https://fedorahosted.org/sssd/newticket

>I can getent users, but log log in for no obvious reason (system error in 
>secure.log).
>
system error sounds bad. Please provide log files with
high debug level in domain section sssd.conf

https://fedorahosted.org/sssd/wiki/Troubleshooting#SSSDdebuglogs

LS

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

Re: [Freeipa-users] SUDO and group lookup in AD trust

2016-08-25 Thread Jakub Hrozek 
On Thu, Aug 25, 2016 at 11:30:52AM +0200, Troels Hansen wrote:
> Hmm, adding the CentOS SSSD 1.14 copr repo and running yum upgrade, getting a 
> version 1.14.1, clean cache DB (complaing about cache being old version), I 
> can getent users, but log log in for no obvious reason (system error in 
> secure.log).
> 
> Downgrading to official RHEL 7.2 SSSD-1.13 restores logging in. 

Please send some logs..

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

Re: [Freeipa-users] SUDO and group lookup in AD trust

2016-08-25 Thread Troels Hansen 
Hmm, adding the CentOS SSSD 1.14 copr repo and running yum upgrade, getting a 
version 1.14.1, clean cache DB (complaing about cache being old version), I can 
getent users, but log log in for no obvious reason (system error in secure.log).

Downgrading to official RHEL 7.2 SSSD-1.13 restores logging in. 

- On Aug 25, 2016, at 10:48 AM, Lukas Slebodnik lsleb...@redhat.com wrote:

> On (25/08/16 10:05), Troels Hansen wrote:
>>Hmm, seems waiting for RHEL 7.3 and SSSD 1.14 will solve this problem
>>
>>https://fedorahosted.org/sssd/ticket/2919
>>
> Meanwhile, you can test upstream version
> https://copr.fedorainfracloud.org/coprs/g/sssd/sssd-1-14/
> 
> LS

-- 
Med venlig hilsen 

Troels Hansen 

Systemkonsulent 

Casalogic A/S 


T (+45) 70 20 10 63 

M (+45) 22 43 71 57 

Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og 
meget mere.

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

Re: [Freeipa-users] SUDO and group lookup in AD trust

2016-08-25 Thread Lukas Slebodnik 
On (25/08/16 10:05), Troels Hansen wrote:
>Hmm, seems waiting for RHEL 7.3 and SSSD 1.14 will solve this problem
>
>https://fedorahosted.org/sssd/ticket/2919
>
Meanwhile, you can test upstream version
https://copr.fedorainfracloud.org/coprs/g/sssd/sssd-1-14/

LS

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

Re: [Freeipa-users] SUDO and group lookup in AD trust

2016-08-25 Thread Jakub Hrozek 
yes.

On Thu, Aug 25, 2016 at 10:05:36AM +0200, Troels Hansen wrote:
> Hmm, seems waiting for RHEL 7.3 and SSSD 1.14 will solve this problem
> 
> https://fedorahosted.org/sssd/ticket/2919
> 
> Am I correct?
> 
> - On Aug 25, 2016, at 9:24 AM, Troels Hansen t...@casalogic.dk wrote:
> 
> > Hmm, sometimes the man page actually helps
> > 
> > It seems setting "default_domain_suffix" to allow users to log in, without 
> > the
> > domain part changes use_fully_qualified_names default to true, without the
> > option of setting it false.
> > 
> > So, we have two options:
> > - Have users always use their full login including domain
> > - Setting default_domain_suffix to help the users and efficiently break 
> > SUDO?
> > 
> > Can this be true?
> > 
> > 
> > - On Aug 25, 2016, at 8:42 AM, Troels Hansen t...@casalogic.dk wrote:
> > 
> >> Yes and no
> >> 
> >> Have tried setting it to both true and false, but doesn't make a huge
> >> difference.
> >> 
> >> Current result with "use_fully_qualified_names = false"
> >> 
> >> LDAP search from sssd_sudo.log shows SSSD finding a sudo rule...
> >> 
> >> (Thu Aug 25 08:15:27 2016) [sssd[sudo]] [sudosrv_get_sudorules_query_cache]
> >> (0x0200): Searching sysdb with
> >> [(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=drext...@net.dr.dk)(sudoUser=#1349938498)
> >> ...
> >> (sudoUser=%domain_users)(sudoUser=+*)))]
> >> (Thu Aug 25 08:15:27 2016) [sssd[sudo]] [sort_sudo_rules] (0x0400): Sorting
> >> rules with higher-wins logic
> >> (Thu Aug 25 08:15:27 2016) [sssd[sudo]] [sudosrv_get_sudorules_from_cache]
> >> (0x0400): Returning 1 rules for [drext...@net.dr.dk]
> >> 
> >> SSSD cache shows the sudo rule:
> >> 
> >> # ldbsearch -H /var/lib/sss/db/cache_linux.dr.dk.ldb -b cn=sysdb
> >> '(objectClass=sudoRule)'
> >> asq: Unable to register control with rootdse!
> >> # record 1
> >> dn: name=guffe,cn=sudorules,cn=custom,cn=linux.dr.dk,cn=sysdb
> >> cn: guffe
> >> dataExpireTimestamp: 1472110940
> >> entryUSN: 325878
> >> name: guffe
> >> objectClass: sudoRule
> >> originalDN: cn=guffe,ou=sudoers,dc=linux,dc=dr,dc=dk
> >> sudoCommand: /usr/bin/cat /var/log/messages
> >> sudoHost: ALL
> >> sudoRunAsGroup: ALL
> >> sudoRunAsUser: ALL
> >> sudoUser: %domain_users
> >> distinguishedName: 
> >> name=guffe,cn=sudorules,cn=custom,cn=linux.dr.dk,cn=sysdb
> >> 
> >> But still sudo debug log says:
> >> 
> >> Aug 25 08:29:55 sudo[2392] -> user_in_group @ ./pwutil.c:940
> >> Aug 25 08:29:55 sudo[2392] -> sudo_get_grlist @ ./pwutil.c:877
> >> Aug 25 08:29:55 sudo[2392] -> rbfind @ ./redblack.c:273
> >> Aug 25 08:29:55 sudo[2392] <- rbfind @ ./redblack.c:277 := 0x7f877f45d1d0
> >> Aug 25 08:29:55 sudo[2392] <- sudo_get_grlist @ ./pwutil.c:930 := 
> >> 0x7f877f45d348
> >> Aug 25 08:29:55 sudo[2392] -> sudo_getgrnam @ ./pwutil.c:719
> >> Aug 25 08:29:55 sudo[2392] -> rbfind @ ./redblack.c:273
> >> Aug 25 08:29:55 sudo[2392] <- rbfind @ ./redblack.c:280 := (nil)
> >> Aug 25 08:29:55 sudo[2392] -> make_gritem @ ./pwutil.c:474
> >> Aug 25 08:29:55 sudo[2392] <- make_gritem @ ./pwutil.c:524 := 
> >> 0x7f877f44ef20
> >> Aug 25 08:29:55 sudo[2392] -> rbinsert @ ./redblack.c:181
> >> Aug 25 08:29:55 sudo[2392] <- rbinsert @ ./redblack.c:261 := (nil)
> >> Aug 25 08:29:55 sudo[2392] <- sudo_getgrnam @ ./pwutil.c:745 := 
> >> 0x7f877f44ef38
> >> Aug 25 08:29:55 sudo[2392] -> sudo_grlist_delref @ ./pwutil.c:816
> >> Aug 25 08:29:55 sudo[2392] -> sudo_grlist_delref_item @ ./pwutil.c:805
> >> Aug 25 08:29:55 sudo[2392] <- sudo_grlist_delref_item @ ./pwutil.c:810
> >> Aug 25 08:29:55 sudo[2392] <- sudo_grlist_delref @ ./pwutil.c:818
> >> Aug 25 08:29:55 sudo[2392] <- user_in_group @ ./pwutil.c:1010 := false
> >> 
> >> 
> >> I'm quite lost on how to debug further on this.
> >> 
> >> - On Aug 24, 2016, at 9:50 AM, Jakub Hrozek jhro...@redhat.com wrote:
> >> 
> >>> On Tue, Aug 23, 2016 at 03:17:48PM +0200, Troels Hansen wrote:
>  Running RHEL 7.2:
>  
>  ipa-client-4.2.0-15.el7_2.18
>  sssd-ipa-1.13.0-40.el7_2.12.x86_64
>  ipa-server-4.2.0-15.el7_2.18.x86_64
>  
>  I have a sudo rule where I try to give sudo access based on a AD group.
>  
>  # groups drext...@net.dr.dk
>  drext...@net.dr.dk : drext...@net.dr.dk ... 
>  domain_us...@linux.dr.dk
>  
>  I'm member of the group domain_users via AD.
>  
>  SUDO rule in LDAP:
>  
>  # guffe, sudoers, linux.dr.dk
>  dn: cn=guffe,ou=sudoers,dc=linux,dc=dr,dc=dk
>  sudoUser: %domain_users
>  sudoRunAsGroup: ALL
>  objectClass: sudoRole
>  objectClass: top
>  sudoCommand: /usr/bin/cat /var/log/messages
>  sudoRunAsUser: ALL
>  sudoHost: ALL
>  cn: guffe
> >>> 
> >>> domain_users != domain_us...@linux.dr.dk
> >>> 
> >>> I'm also curious why sssd qualifies the IPA group name (domain_users is
> >>> an IPA group name right?)
> >>> 
> >>> do you set use_fully_qualified_names=true by chance in the config file?
> >>> 
> >>> --

Re: [Freeipa-users] SUDO and group lookup in AD trust

2016-08-25 Thread Troels Hansen 
Hmm, seems waiting for RHEL 7.3 and SSSD 1.14 will solve this problem

https://fedorahosted.org/sssd/ticket/2919

Am I correct?

- On Aug 25, 2016, at 9:24 AM, Troels Hansen t...@casalogic.dk wrote:

> Hmm, sometimes the man page actually helps
> 
> It seems setting "default_domain_suffix" to allow users to log in, without the
> domain part changes use_fully_qualified_names default to true, without the
> option of setting it false.
> 
> So, we have two options:
> - Have users always use their full login including domain
> - Setting default_domain_suffix to help the users and efficiently break SUDO?
> 
> Can this be true?
> 
> 
> - On Aug 25, 2016, at 8:42 AM, Troels Hansen t...@casalogic.dk wrote:
> 
>> Yes and no
>> 
>> Have tried setting it to both true and false, but doesn't make a huge
>> difference.
>> 
>> Current result with "use_fully_qualified_names = false"
>> 
>> LDAP search from sssd_sudo.log shows SSSD finding a sudo rule...
>> 
>> (Thu Aug 25 08:15:27 2016) [sssd[sudo]] [sudosrv_get_sudorules_query_cache]
>> (0x0200): Searching sysdb with
>> [(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=drext...@net.dr.dk)(sudoUser=#1349938498)
>> ...
>> (sudoUser=%domain_users)(sudoUser=+*)))]
>> (Thu Aug 25 08:15:27 2016) [sssd[sudo]] [sort_sudo_rules] (0x0400): Sorting
>> rules with higher-wins logic
>> (Thu Aug 25 08:15:27 2016) [sssd[sudo]] [sudosrv_get_sudorules_from_cache]
>> (0x0400): Returning 1 rules for [drext...@net.dr.dk]
>> 
>> SSSD cache shows the sudo rule:
>> 
>> # ldbsearch -H /var/lib/sss/db/cache_linux.dr.dk.ldb -b cn=sysdb
>> '(objectClass=sudoRule)'
>> asq: Unable to register control with rootdse!
>> # record 1
>> dn: name=guffe,cn=sudorules,cn=custom,cn=linux.dr.dk,cn=sysdb
>> cn: guffe
>> dataExpireTimestamp: 1472110940
>> entryUSN: 325878
>> name: guffe
>> objectClass: sudoRule
>> originalDN: cn=guffe,ou=sudoers,dc=linux,dc=dr,dc=dk
>> sudoCommand: /usr/bin/cat /var/log/messages
>> sudoHost: ALL
>> sudoRunAsGroup: ALL
>> sudoRunAsUser: ALL
>> sudoUser: %domain_users
>> distinguishedName: name=guffe,cn=sudorules,cn=custom,cn=linux.dr.dk,cn=sysdb
>> 
>> But still sudo debug log says:
>> 
>> Aug 25 08:29:55 sudo[2392] -> user_in_group @ ./pwutil.c:940
>> Aug 25 08:29:55 sudo[2392] -> sudo_get_grlist @ ./pwutil.c:877
>> Aug 25 08:29:55 sudo[2392] -> rbfind @ ./redblack.c:273
>> Aug 25 08:29:55 sudo[2392] <- rbfind @ ./redblack.c:277 := 0x7f877f45d1d0
>> Aug 25 08:29:55 sudo[2392] <- sudo_get_grlist @ ./pwutil.c:930 := 
>> 0x7f877f45d348
>> Aug 25 08:29:55 sudo[2392] -> sudo_getgrnam @ ./pwutil.c:719
>> Aug 25 08:29:55 sudo[2392] -> rbfind @ ./redblack.c:273
>> Aug 25 08:29:55 sudo[2392] <- rbfind @ ./redblack.c:280 := (nil)
>> Aug 25 08:29:55 sudo[2392] -> make_gritem @ ./pwutil.c:474
>> Aug 25 08:29:55 sudo[2392] <- make_gritem @ ./pwutil.c:524 := 0x7f877f44ef20
>> Aug 25 08:29:55 sudo[2392] -> rbinsert @ ./redblack.c:181
>> Aug 25 08:29:55 sudo[2392] <- rbinsert @ ./redblack.c:261 := (nil)
>> Aug 25 08:29:55 sudo[2392] <- sudo_getgrnam @ ./pwutil.c:745 := 
>> 0x7f877f44ef38
>> Aug 25 08:29:55 sudo[2392] -> sudo_grlist_delref @ ./pwutil.c:816
>> Aug 25 08:29:55 sudo[2392] -> sudo_grlist_delref_item @ ./pwutil.c:805
>> Aug 25 08:29:55 sudo[2392] <- sudo_grlist_delref_item @ ./pwutil.c:810
>> Aug 25 08:29:55 sudo[2392] <- sudo_grlist_delref @ ./pwutil.c:818
>> Aug 25 08:29:55 sudo[2392] <- user_in_group @ ./pwutil.c:1010 := false
>> 
>> 
>> I'm quite lost on how to debug further on this.
>> 
>> - On Aug 24, 2016, at 9:50 AM, Jakub Hrozek jhro...@redhat.com wrote:
>> 
>>> On Tue, Aug 23, 2016 at 03:17:48PM +0200, Troels Hansen wrote:
 Running RHEL 7.2:
 
 ipa-client-4.2.0-15.el7_2.18
 sssd-ipa-1.13.0-40.el7_2.12.x86_64
 ipa-server-4.2.0-15.el7_2.18.x86_64
 
 I have a sudo rule where I try to give sudo access based on a AD group.
 
 # groups drext...@net.dr.dk
 drext...@net.dr.dk : drext...@net.dr.dk ... 
 domain_us...@linux.dr.dk
 
 I'm member of the group domain_users via AD.
 
 SUDO rule in LDAP:
 
 # guffe, sudoers, linux.dr.dk
 dn: cn=guffe,ou=sudoers,dc=linux,dc=dr,dc=dk
 sudoUser: %domain_users
 sudoRunAsGroup: ALL
 objectClass: sudoRole
 objectClass: top
 sudoCommand: /usr/bin/cat /var/log/messages
 sudoRunAsUser: ALL
 sudoHost: ALL
 cn: guffe
>>> 
>>> domain_users != domain_us...@linux.dr.dk
>>> 
>>> I'm also curious why sssd qualifies the IPA group name (domain_users is
>>> an IPA group name right?)
>>> 
>>> do you set use_fully_qualified_names=true by chance in the config file?
>>> 
>>> --
>>> 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
>> 
>> --
>> Med venlig hilsen
>> 
>> Troels Hansen
>> 
>> Systemkonsulent
>> 
>> Casalogic A/S
>> 
>> 
>> T (+45) 70 20 10 63
>> 
>> M (+45) 22 43 71 57
>> 
>>

Re: [Freeipa-users] SUDO and group lookup in AD trust

2016-08-25 Thread Troels Hansen 
Hmm, sometimes the man page actually helps

It seems setting "default_domain_suffix" to allow users to log in, without the 
domain part changes use_fully_qualified_names default to true, without the 
option of setting it false.

So, we have two options:
- Have users always use their full login including domain
- Setting default_domain_suffix to help the users and efficiently break SUDO?

Can this be true?


- On Aug 25, 2016, at 8:42 AM, Troels Hansen t...@casalogic.dk wrote:

> Yes and no
> 
> Have tried setting it to both true and false, but doesn't make a huge
> difference.
> 
> Current result with "use_fully_qualified_names = false"
> 
> LDAP search from sssd_sudo.log shows SSSD finding a sudo rule...
> 
> (Thu Aug 25 08:15:27 2016) [sssd[sudo]] [sudosrv_get_sudorules_query_cache]
> (0x0200): Searching sysdb with
> [(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=drext...@net.dr.dk)(sudoUser=#1349938498)
> ...
> (sudoUser=%domain_users)(sudoUser=+*)))]
> (Thu Aug 25 08:15:27 2016) [sssd[sudo]] [sort_sudo_rules] (0x0400): Sorting
> rules with higher-wins logic
> (Thu Aug 25 08:15:27 2016) [sssd[sudo]] [sudosrv_get_sudorules_from_cache]
> (0x0400): Returning 1 rules for [drext...@net.dr.dk]
> 
> SSSD cache shows the sudo rule:
> 
> # ldbsearch -H /var/lib/sss/db/cache_linux.dr.dk.ldb -b cn=sysdb
> '(objectClass=sudoRule)'
> asq: Unable to register control with rootdse!
> # record 1
> dn: name=guffe,cn=sudorules,cn=custom,cn=linux.dr.dk,cn=sysdb
> cn: guffe
> dataExpireTimestamp: 1472110940
> entryUSN: 325878
> name: guffe
> objectClass: sudoRule
> originalDN: cn=guffe,ou=sudoers,dc=linux,dc=dr,dc=dk
> sudoCommand: /usr/bin/cat /var/log/messages
> sudoHost: ALL
> sudoRunAsGroup: ALL
> sudoRunAsUser: ALL
> sudoUser: %domain_users
> distinguishedName: name=guffe,cn=sudorules,cn=custom,cn=linux.dr.dk,cn=sysdb
> 
> But still sudo debug log says:
> 
> Aug 25 08:29:55 sudo[2392] -> user_in_group @ ./pwutil.c:940
> Aug 25 08:29:55 sudo[2392] -> sudo_get_grlist @ ./pwutil.c:877
> Aug 25 08:29:55 sudo[2392] -> rbfind @ ./redblack.c:273
> Aug 25 08:29:55 sudo[2392] <- rbfind @ ./redblack.c:277 := 0x7f877f45d1d0
> Aug 25 08:29:55 sudo[2392] <- sudo_get_grlist @ ./pwutil.c:930 := 
> 0x7f877f45d348
> Aug 25 08:29:55 sudo[2392] -> sudo_getgrnam @ ./pwutil.c:719
> Aug 25 08:29:55 sudo[2392] -> rbfind @ ./redblack.c:273
> Aug 25 08:29:55 sudo[2392] <- rbfind @ ./redblack.c:280 := (nil)
> Aug 25 08:29:55 sudo[2392] -> make_gritem @ ./pwutil.c:474
> Aug 25 08:29:55 sudo[2392] <- make_gritem @ ./pwutil.c:524 := 0x7f877f44ef20
> Aug 25 08:29:55 sudo[2392] -> rbinsert @ ./redblack.c:181
> Aug 25 08:29:55 sudo[2392] <- rbinsert @ ./redblack.c:261 := (nil)
> Aug 25 08:29:55 sudo[2392] <- sudo_getgrnam @ ./pwutil.c:745 := 0x7f877f44ef38
> Aug 25 08:29:55 sudo[2392] -> sudo_grlist_delref @ ./pwutil.c:816
> Aug 25 08:29:55 sudo[2392] -> sudo_grlist_delref_item @ ./pwutil.c:805
> Aug 25 08:29:55 sudo[2392] <- sudo_grlist_delref_item @ ./pwutil.c:810
> Aug 25 08:29:55 sudo[2392] <- sudo_grlist_delref @ ./pwutil.c:818
> Aug 25 08:29:55 sudo[2392] <- user_in_group @ ./pwutil.c:1010 := false
> 
> 
> I'm quite lost on how to debug further on this.
> 
> - On Aug 24, 2016, at 9:50 AM, Jakub Hrozek jhro...@redhat.com wrote:
> 
>> On Tue, Aug 23, 2016 at 03:17:48PM +0200, Troels Hansen wrote:
>>> Running RHEL 7.2:
>>> 
>>> ipa-client-4.2.0-15.el7_2.18
>>> sssd-ipa-1.13.0-40.el7_2.12.x86_64
>>> ipa-server-4.2.0-15.el7_2.18.x86_64
>>> 
>>> I have a sudo rule where I try to give sudo access based on a AD group.
>>> 
>>> # groups drext...@net.dr.dk
>>> drext...@net.dr.dk : drext...@net.dr.dk ... 
>>> domain_us...@linux.dr.dk
>>> 
>>> I'm member of the group domain_users via AD.
>>> 
>>> SUDO rule in LDAP:
>>> 
>>> # guffe, sudoers, linux.dr.dk
>>> dn: cn=guffe,ou=sudoers,dc=linux,dc=dr,dc=dk
>>> sudoUser: %domain_users
>>> sudoRunAsGroup: ALL
>>> objectClass: sudoRole
>>> objectClass: top
>>> sudoCommand: /usr/bin/cat /var/log/messages
>>> sudoRunAsUser: ALL
>>> sudoHost: ALL
>>> cn: guffe
>> 
>> domain_users != domain_us...@linux.dr.dk
>> 
>> I'm also curious why sssd qualifies the IPA group name (domain_users is
>> an IPA group name right?)
>> 
>> do you set use_fully_qualified_names=true by chance in the config file?
>> 
>> --
>> 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
> 
> --
> Med venlig hilsen
> 
> Troels Hansen
> 
> Systemkonsulent
> 
> Casalogic A/S
> 
> 
> T (+45) 70 20 10 63
> 
> M (+45) 22 43 71 57
> 
> Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og
> meget mere.
> 
> --
> 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

-- 
Med venlig hilsen 

Troels Hansen 

Systemkonsulent 

Casalogic A/S 


T (+45) 70

Re: [Freeipa-users] SUDO and group lookup in AD trust

2016-08-25 Thread Jakub Hrozek 
On Thu, Aug 25, 2016 at 08:42:28AM +0200, Troels Hansen wrote:
> Yes and no
> 
> Have tried setting it to both true and false, but doesn't make a huge 
> difference.
> 
> Current result with "use_fully_qualified_names = false"
> 
> LDAP search from sssd_sudo.log shows SSSD finding a sudo rule...
> 
> (Thu Aug 25 08:15:27 2016) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] 
> (0x0200): Searching sysdb with 
> [(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=drext...@net.dr.dk)(sudoUser=#1349938498)
> ...
> (sudoUser=%domain_users)(sudoUser=+*)))]
> (Thu Aug 25 08:15:27 2016) [sssd[sudo]] [sort_sudo_rules] (0x0400): Sorting 
> rules with higher-wins logic
> (Thu Aug 25 08:15:27 2016) [sssd[sudo]] [sudosrv_get_sudorules_from_cache] 
> (0x0400): Returning 1 rules for [drext...@net.dr.dk]

Does the sudo log indicate that the rule is the one you'd expect?
Because I don't see sudo looking for domain_users below. Can you attach
the complete logs?

> 
> SSSD cache shows the sudo rule:
> 
> # ldbsearch -H /var/lib/sss/db/cache_linux.dr.dk.ldb -b cn=sysdb 
> '(objectClass=sudoRule)'
> asq: Unable to register control with rootdse!
> # record 1
> dn: name=guffe,cn=sudorules,cn=custom,cn=linux.dr.dk,cn=sysdb
> cn: guffe
> dataExpireTimestamp: 1472110940
> entryUSN: 325878
> name: guffe
> objectClass: sudoRule
> originalDN: cn=guffe,ou=sudoers,dc=linux,dc=dr,dc=dk
> sudoCommand: /usr/bin/cat /var/log/messages
> sudoHost: ALL
> sudoRunAsGroup: ALL
> sudoRunAsUser: ALL
> sudoUser: %domain_users
> distinguishedName: name=guffe,cn=sudorules,cn=custom,cn=linux.dr.dk,cn=sysdb
> 
> But still sudo debug log says:
> 
> Aug 25 08:29:55 sudo[2392] -> user_in_group @ ./pwutil.c:940
> Aug 25 08:29:55 sudo[2392] -> sudo_get_grlist @ ./pwutil.c:877
> Aug 25 08:29:55 sudo[2392] -> rbfind @ ./redblack.c:273
> Aug 25 08:29:55 sudo[2392] <- rbfind @ ./redblack.c:277 := 0x7f877f45d1d0
> Aug 25 08:29:55 sudo[2392] <- sudo_get_grlist @ ./pwutil.c:930 := 
> 0x7f877f45d348
> Aug 25 08:29:55 sudo[2392] -> sudo_getgrnam @ ./pwutil.c:719
> Aug 25 08:29:55 sudo[2392] -> rbfind @ ./redblack.c:273
> Aug 25 08:29:55 sudo[2392] <- rbfind @ ./redblack.c:280 := (nil)
> Aug 25 08:29:55 sudo[2392] -> make_gritem @ ./pwutil.c:474
> Aug 25 08:29:55 sudo[2392] <- make_gritem @ ./pwutil.c:524 := 0x7f877f44ef20
> Aug 25 08:29:55 sudo[2392] -> rbinsert @ ./redblack.c:181
> Aug 25 08:29:55 sudo[2392] <- rbinsert @ ./redblack.c:261 := (nil)
> Aug 25 08:29:55 sudo[2392] <- sudo_getgrnam @ ./pwutil.c:745 := 0x7f877f44ef38
> Aug 25 08:29:55 sudo[2392] -> sudo_grlist_delref @ ./pwutil.c:816
> Aug 25 08:29:55 sudo[2392] -> sudo_grlist_delref_item @ ./pwutil.c:805
> Aug 25 08:29:55 sudo[2392] <- sudo_grlist_delref_item @ ./pwutil.c:810
> Aug 25 08:29:55 sudo[2392] <- sudo_grlist_delref @ ./pwutil.c:818
> Aug 25 08:29:55 sudo[2392] <- user_in_group @ ./pwutil.c:1010 := false
> 
> 
> I'm quite lost on how to debug further on this.
> 
> - On Aug 24, 2016, at 9:50 AM, Jakub Hrozek jhro...@redhat.com wrote:
> 
> > On Tue, Aug 23, 2016 at 03:17:48PM +0200, Troels Hansen wrote:
> >> Running RHEL 7.2:
> >> 
> >> ipa-client-4.2.0-15.el7_2.18
> >> sssd-ipa-1.13.0-40.el7_2.12.x86_64
> >> ipa-server-4.2.0-15.el7_2.18.x86_64
> >> 
> >> I have a sudo rule where I try to give sudo access based on a AD group.
> >> 
> >> # groups drext...@net.dr.dk
> >> drext...@net.dr.dk : drext...@net.dr.dk ... 
> >> domain_us...@linux.dr.dk
> >> 
> >> I'm member of the group domain_users via AD.
> >> 
> >> SUDO rule in LDAP:
> >> 
> >> # guffe, sudoers, linux.dr.dk
> >> dn: cn=guffe,ou=sudoers,dc=linux,dc=dr,dc=dk
> >> sudoUser: %domain_users
> >> sudoRunAsGroup: ALL
> >> objectClass: sudoRole
> >> objectClass: top
> >> sudoCommand: /usr/bin/cat /var/log/messages
> >> sudoRunAsUser: ALL
> >> sudoHost: ALL
> >> cn: guffe
> > 
> > domain_users != domain_us...@linux.dr.dk
> > 
> > I'm also curious why sssd qualifies the IPA group name (domain_users is
> > an IPA group name right?)
> > 
> > do you set use_fully_qualified_names=true by chance in the config file?
> > 
> > --
> > 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
> 
> -- 
> Med venlig hilsen 
> 
> Troels Hansen 
> 
> Systemkonsulent 
> 
> Casalogic A/S 
> 
> 
> T (+45) 70 20 10 63 
> 
> M (+45) 22 43 71 57 
> 
> Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og 
> meget mere.

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

Re: [Freeipa-users] SUDO and group lookup in AD trust

2016-08-25 Thread Troels Hansen 
Yes and no

Have tried setting it to both true and false, but doesn't make a huge 
difference.

Current result with "use_fully_qualified_names = false"

LDAP search from sssd_sudo.log shows SSSD finding a sudo rule...

(Thu Aug 25 08:15:27 2016) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] 
(0x0200): Searching sysdb with 
[(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=drext...@net.dr.dk)(sudoUser=#1349938498)
...
(sudoUser=%domain_users)(sudoUser=+*)))]
(Thu Aug 25 08:15:27 2016) [sssd[sudo]] [sort_sudo_rules] (0x0400): Sorting 
rules with higher-wins logic
(Thu Aug 25 08:15:27 2016) [sssd[sudo]] [sudosrv_get_sudorules_from_cache] 
(0x0400): Returning 1 rules for [drext...@net.dr.dk]

SSSD cache shows the sudo rule:

# ldbsearch -H /var/lib/sss/db/cache_linux.dr.dk.ldb -b cn=sysdb 
'(objectClass=sudoRule)'
asq: Unable to register control with rootdse!
# record 1
dn: name=guffe,cn=sudorules,cn=custom,cn=linux.dr.dk,cn=sysdb
cn: guffe
dataExpireTimestamp: 1472110940
entryUSN: 325878
name: guffe
objectClass: sudoRule
originalDN: cn=guffe,ou=sudoers,dc=linux,dc=dr,dc=dk
sudoCommand: /usr/bin/cat /var/log/messages
sudoHost: ALL
sudoRunAsGroup: ALL
sudoRunAsUser: ALL
sudoUser: %domain_users
distinguishedName: name=guffe,cn=sudorules,cn=custom,cn=linux.dr.dk,cn=sysdb

But still sudo debug log says:

Aug 25 08:29:55 sudo[2392] -> user_in_group @ ./pwutil.c:940
Aug 25 08:29:55 sudo[2392] -> sudo_get_grlist @ ./pwutil.c:877
Aug 25 08:29:55 sudo[2392] -> rbfind @ ./redblack.c:273
Aug 25 08:29:55 sudo[2392] <- rbfind @ ./redblack.c:277 := 0x7f877f45d1d0
Aug 25 08:29:55 sudo[2392] <- sudo_get_grlist @ ./pwutil.c:930 := 0x7f877f45d348
Aug 25 08:29:55 sudo[2392] -> sudo_getgrnam @ ./pwutil.c:719
Aug 25 08:29:55 sudo[2392] -> rbfind @ ./redblack.c:273
Aug 25 08:29:55 sudo[2392] <- rbfind @ ./redblack.c:280 := (nil)
Aug 25 08:29:55 sudo[2392] -> make_gritem @ ./pwutil.c:474
Aug 25 08:29:55 sudo[2392] <- make_gritem @ ./pwutil.c:524 := 0x7f877f44ef20
Aug 25 08:29:55 sudo[2392] -> rbinsert @ ./redblack.c:181
Aug 25 08:29:55 sudo[2392] <- rbinsert @ ./redblack.c:261 := (nil)
Aug 25 08:29:55 sudo[2392] <- sudo_getgrnam @ ./pwutil.c:745 := 0x7f877f44ef38
Aug 25 08:29:55 sudo[2392] -> sudo_grlist_delref @ ./pwutil.c:816
Aug 25 08:29:55 sudo[2392] -> sudo_grlist_delref_item @ ./pwutil.c:805
Aug 25 08:29:55 sudo[2392] <- sudo_grlist_delref_item @ ./pwutil.c:810
Aug 25 08:29:55 sudo[2392] <- sudo_grlist_delref @ ./pwutil.c:818
Aug 25 08:29:55 sudo[2392] <- user_in_group @ ./pwutil.c:1010 := false


I'm quite lost on how to debug further on this.

- On Aug 24, 2016, at 9:50 AM, Jakub Hrozek jhro...@redhat.com wrote:

> On Tue, Aug 23, 2016 at 03:17:48PM +0200, Troels Hansen wrote:
>> Running RHEL 7.2:
>> 
>> ipa-client-4.2.0-15.el7_2.18
>> sssd-ipa-1.13.0-40.el7_2.12.x86_64
>> ipa-server-4.2.0-15.el7_2.18.x86_64
>> 
>> I have a sudo rule where I try to give sudo access based on a AD group.
>> 
>> # groups drext...@net.dr.dk
>> drext...@net.dr.dk : drext...@net.dr.dk ... 
>> domain_us...@linux.dr.dk
>> 
>> I'm member of the group domain_users via AD.
>> 
>> SUDO rule in LDAP:
>> 
>> # guffe, sudoers, linux.dr.dk
>> dn: cn=guffe,ou=sudoers,dc=linux,dc=dr,dc=dk
>> sudoUser: %domain_users
>> sudoRunAsGroup: ALL
>> objectClass: sudoRole
>> objectClass: top
>> sudoCommand: /usr/bin/cat /var/log/messages
>> sudoRunAsUser: ALL
>> sudoHost: ALL
>> cn: guffe
> 
> domain_users != domain_us...@linux.dr.dk
> 
> I'm also curious why sssd qualifies the IPA group name (domain_users is
> an IPA group name right?)
> 
> do you set use_fully_qualified_names=true by chance in the config file?
> 
> --
> 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

-- 
Med venlig hilsen 

Troels Hansen 

Systemkonsulent 

Casalogic A/S 


T (+45) 70 20 10 63 

M (+45) 22 43 71 57 

Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og 
meget mere.

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

[Freeipa-users] SUDO and group lookup in AD trust

2016-08-23 Thread Troels Hansen 
Running RHEL 7.2: 

ipa-client-4.2.0-15.el7_2.18 
sssd-ipa-1.13.0-40.el7_2.12.x86_64 
ipa-server-4.2.0-15.el7_2.18.x86_64 

I have a sudo rule where I try to give sudo access based on a AD group. 

# groups drext...@net.dr.dk 
drext...@net.dr.dk : drext...@net.dr.dk ... 
domain_us...@linux.dr.dk 

I'm member of the group domain_users via AD. 

SUDO rule in LDAP: 

# guffe, sudoers, linux.dr.dk 
dn: cn=guffe,ou=sudoers,dc=linux,dc=dr,dc=dk 
sudoUser: %domain_users 
sudoRunAsGroup: ALL 
objectClass: sudoRole 
objectClass: top 
sudoCommand: /usr/bin/cat /var/log/messages 
sudoRunAsUser: ALL 
sudoHost: ALL 
cn: guffe 


sudo debug log shows: 
 
Aug 23 14:48:26 sudo[27307] Received 1 rule(s) 
 

 
Aug 23 14:48:26 sudo[27307] val[0]=%domain_users 
Aug 23 14:48:26 sudo[27307] -> usergr_matches @ ./match.c:802 
Aug 23 14:48:26 sudo[27307] -> user_in_group @ ./pwutil.c:940 
Aug 23 14:48:26 sudo[27307] -> sudo_get_grlist @ ./pwutil.c:877 
Aug 23 14:48:26 sudo[27307] -> rbfind @ ./redblack.c:273 
Aug 23 14:48:26 sudo[27307] <- rbfind @ ./redblack.c:277 := 0x7ff224cb31d0 
Aug 23 14:48:26 sudo[27307] <- sudo_get_grlist @ ./pwutil.c:930 := 
0x7ff224cb3348 
Aug 23 14:48:26 sudo[27307] -> sudo_getgrnam @ ./pwutil.c:719 
Aug 23 14:48:26 sudo[27307] -> rbfind @ ./redblack.c:273 
Aug 23 14:48:26 sudo[27307] <- rbfind @ ./redblack.c:280 := (nil) 
Aug 23 14:48:26 sudo[27307] -> rbinsert @ ./redblack.c:181 
Aug 23 14:48:26 sudo[27307] <- rbinsert @ ./redblack.c:261 := (nil) 
Aug 23 14:48:26 sudo[27307] <- sudo_getgrnam @ ./pwutil.c:745 := (nil) 
Aug 23 14:48:26 sudo[27307] -> sudo_grlist_delref @ ./pwutil.c:816 
Aug 23 14:48:26 sudo[27307] -> sudo_grlist_delref_item @ ./pwutil.c:805 
Aug 23 14:48:26 sudo[27307] <- sudo_grlist_delref_item @ ./pwutil.c:810 
Aug 23 14:48:26 sudo[27307] <- sudo_grlist_delref @ ./pwutil.c:818 
Aug 23 14:48:26 sudo[27307] <- user_in_group @ ./pwutil.c:1010 := false 
Aug 23 14:48:26 sudo[27307] <- usergr_matches @ ./match.c:835 := false 
Aug 23 14:48:26 sudo[27307] <- sudo_sss_filter_sudoUser @ ./sssd.c:683 := false 
 

Soo, a rule is matched, but I'm not in the group? 



I have tried setting 
use_fully_qualified_names = true 

in sssd.conf, but no luck. The sudo is still denied. 

Am I missing something? 


-- 


Med venlig hilsen 

Troels Hansen 

Systemkonsulent 

Casalogic A/S 


T (+45) 70 20 10 63 

M (+45) 22 43 71 57 

Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og 
meget mere. 
-- 
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