#3206 AD provider: SSSD does not retrieve a domain-local group with the AD provider when following AGGUDLP group structure across domains
Closed: Fixed None Opened 7 years ago by jhrozek.

Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 7): Bug 1372075

Please note that this Bug is private and may not be accessible as it contains confidential Red Hat customer information.

Created attachment 1196496
sssd logs of id command which fails to retrieve domain_local group

Description of problem:
AD provider: SSSD does not retrieve a domain-local group with the AD provider
when following AGGUDLP group structure across domains

http://blogs.msmvps.com/acefekay/2012/01/06/using-group-nesting-strategy-ad-bes
t-practices-for-group-strategy/

Add accounts to a Global Group, add the Global Group to a Universal Group, add
the Universal Group to a Domain Local Group, apply permissions for the Domain
Local Group to a resource. The accounts in the original Domain Local Group will
have access to the resource with the permissions levels based on the
permissions applied to the Domain Local Group.

Version-Release number of selected component (if applicable):
sssd-1.13.0-40.el7_2.4.x86_64

How reproducible:
100% reproducible

Create sssduser in parent domain TEST.COM
Create global_group in parent domain TEST.COM
Create universal_group in parent domain TEST.COM

Create domain_local group in CHILD.TEST.COM
Join SSSD to AD domain CHILD.TEST.COM

--> In the parent AD domain
sssduser is a member of global_group
global_group is a member of universal_group

--> In the child domain
universal_group is a member of domain_local_group

Actual results:

# id sssduser
uid=489247064(sssduser@jstephen.local) gid=489247064(sssduser@jstephen.local) g
roups=489247064(sssduser@jstephen.local),489247065(universal_group@jstephen.loc
al),489247063(global_group@jstephen.local),489200513(domain
users@jstephen.local),489247023(nestedtestgroup@jstephen.local)

The domain-local group is not found, only global_group and universal_group are
visible. Querying the group directly with getent group allows the id command to
find the group properly until the SSSD cache is reset/invalidated

# getent group domain_local@adcorp.jstephen.local
domain_local@ADCORP.jstephen.local:*:481401122:sssduser@jstephen.local

# id sssduser@jstephen.local
uid=489247064(sssduser@jstephen.local) gid=489247064(sssduser@jstephen.local) g
roups=489247064(sssduser@jstephen.local),489247063(global_group@jstephen.local)
,489247065(universal_group@jstephen.local),481401122(domain_local@ADCORP.jsteph
en.local)


Expected results:
domain_local group should be visible in 'id' command output without having to
run getent group first

Additional info:
Testing using combinations of the following options does not fix this issue

ad_enable_gc = false
ldap_use_tokengroups = false
ad_server =

The objectSID of domain_local is S-1-5-21-2058409190-3331408712-3548322839-1122

Fields changed

blockedby: =>
blocking: =>
changelog: =>
coverity: =>
design: =>
design_review: => 0
feature_milestone: =>
fedora_test_page: =>
mark: no => 0
owner: somebody => sbose
priority: major => critical
review: True => 0
selected: =>
testsupdated: => 0

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.14.2

Fields changed

patch: 0 => 1
status: new => assigned

Moving tickets that didn't make it into the 1.14.2 release into the next point release.

milestone: SSSD 1.14.2 => SSSD 1.14.3

- master:
    - 2569984
    - 49d3f0a
    - 3dd4c3e
- sssd-1-14:
    - c1f3b29
    - f38c62f
    - 9a243dc

resolution: => fixed
status: assigned => closed

Metadata Update from @jhrozek:
- Issue assigned to sbose
- Issue set to the milestone: SSSD 1.14.3

7 years ago

Metadata Update from @lslebodn:
- Custom field design_review reset (from 0)
- Custom field mark reset (from 0)
- Custom field patch adjusted to on (was: 1)
- Custom field review reset (from 0)
- Custom field sensitive reset (from 0)
- Custom field testsupdated reset (from 0)

6 years ago

Metadata Update from @sbose:
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)

6 years ago

Metadata Update from @lslebodn:
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)

6 years ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/4239

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata