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

Reply via email to