SSSD / sssd

#2396 Bug: resolving universal groups from subdomains
Closed: Invalid Opened by ntamm.

Closed: Invalid
Reopen Issue

Versions below cannot resolve universal groups from subdomains

{{{#!python
sssd --version
1.11.3, 1.11.4, 1.11.5 1.11.6, 1.12.0

id testuser

uid=828204770(testuser) gid=828200513(earth testers)
Gruppen=828200513(earth testers),828201828(executiveearth),
828203299(frcontrolling),828203283(frpoljolsharfpgmtquake-ml5101c),
828203284(frpoljolsharfquake-ml510c),828203292(frpoljolsharfletmile-d750),
828201820(dl_frstoyakconnection),828201856(tele_frstoyakconnection),
828205194(dl_frsellreporting),828205195(tele_frsellreporting),
1208401201(s-1-5-21-591616882-169932104-861977067-1201),
1208401200(s-1-5-21-591616882-169932104-861977067-1200),
1208401198(s-1-5-21-591616882-169932104-861977067-1198),
828205140(earthdomain testers),
1208401195(s-1-5-21-591616882-169932104-861977067-1195),
1208401199(s-1-5-21-591616882-169932104-861977067-1199),
1208401196(s-1-5-21-591616882-169932104-861977067-1196),
1208401194(s-1-5-21-591616882-169932104-861977067-1194),
1208401197(s-1-5-21-591616882-169932104-861977067-1197)

We have checked all versions above, the problem appears always.

When we rollback to version 1.11.2, we are able to get our groups from the subdomain. Please take a look at our code boxes. Here are our result of
the 'id' command.

{{{#!python
# sssd --version
1.11.2

id testuser

uid=828204770(testuser) gid=828200513(earth testers)
Gruppen=828200513(earth testers),828201828(executiveearth),828203299(frcontrolling),
828203283(frpoljolsharfpgmtquake-ml5101c),828203284(frpoljolsharfquake-ml510c),828203292(frpoljolsharfletmile-d750),828201820(dl_frstoyakconnection),828201856(tele_frstoyakconnection),
828205194(dl_frsellreporting),828205195(tele_frsellreporting),
828205140(earthdomain testers),1208401195(tele_itchildrengate@it.domain.a),
1208401201(tele_itbilling@it.domain.a),1208401200(tele_itparty@it.domain.a),
1208401198(tele_itarrival@it.domain.a),1208401199(tele_itpurchase@it.domain.a),
1208401196(tele_itboard@it.domain.a),1208401194(tele_itcommercial@it.domain.a),
1208401197(tele_itadvertising@it.domain.a)
}}}

We have created a debug log with 1.12.0:
{{{#!python

(Fri Aug 1 17:43:52 2014) [sssd[be[domain.a]]] [simple_check_get_groups_send] (0x0400): User testuser is a member of 28 supplemental groups
(Fri Aug 1 17:43:52 2014) [sssd[be[domain.a]]] [simple_check_process_group] (0x2000): Adding group ExecutiveEarth
(Fri Aug 1 17:43:52 2014) [sssd[be[domain.a]]] [simple_check_process_group] (0x2000): Adding group frControlling
(Fri Aug 1 17:43:52 2014) [sssd[be[domain.a]]] [simple_check_process_group] (0x2000): Adding group TELE_itCommercial
(Fri Aug 1 17:43:52 2014) [sssd[be[domain.a]]] [simple_check_process_group] (0x2000): Adding group TELE_itChildrenGate
(Fri Aug 1 17:43:52 2014) [sssd[be[domain.a]]] [simple_check_process_group] (0x2000): Adding group TELE_itBoard
(Fri Aug 1 17:43:52 2014) [sssd[be[domain.a]]] [simple_check_process_group] (0x2000): Adding group TELE_itAdvertising
(Fri Aug 1 17:43:52 2014) [sssd[be[domain.a]]] [simple_check_process_group] (0x2000): Adding group TELE_itArrival
(Fri Aug 1 17:43:52 2014) [sssd[be[domain.a]]] [simple_check_process_group] (0x2000): Adding group TELE_itPurchase
(Fri Aug 1 17:43:52 2014) [sssd[be[domain.a]]] [simple_check_process_group] (0x2000): Adding group TELE_itparty
(Fri Aug 1 17:43:52 2014) [sssd[be[domain.a]]] [simple_check_process_group] (0x2000): Adding group TELE_itBilling
(Fri Aug 1 17:43:52 2014) [sssd[be[domain.a]]] [simple_check_process_group] (0x2000): Adding group frPolJolSharfQuake-ML510C
(Fri Aug 1 17:43:52 2014) [sssd[be[domain.a]]] [simple_check_process_group] (0x2000): Adding group frPolJolSharfPgmtQuake-ML5101C
(Fri Aug 1 17:43:52 2014) [sssd[be[domain.a]]] [simple_check_process_group] (0x2000): Adding group frPolJolSharfLetmile-D750
(Fri Aug 1 17:43:52 2014) [sssd[be[domain.a]]] [simple_check_process_group] (0x2000): Adding group DL_frStoyakConnection
(Fri Aug 1 17:43:52 2014) [sssd[be[domain.a]]] [simple_check_process_group] (0x2000): Adding group TELE_frStoyakConnection
(Fri Aug 1 17:43:52 2014) [sssd[be[domain.a]]] [simple_check_process_group] (0x2000): Adding group DL_frSellReporting
(Fri Aug 1 17:43:52 2014) [sssd[be[domain.a]]] [simple_check_process_group] (0x2000): Adding group TELE_frSellReporting
(Fri Aug 1 17:43:52 2014) [sssd[be[domain.a]]] [simple_check_process_group] (0x2000): Adding GID 1208401200
(Fri Aug 1 17:43:52 2014) [sssd[be[domain.a]]] [simple_check_process_group] (0x2000): Adding GID 1208401198
(Fri Aug 1 17:43:52 2014) [sssd[be[domain.a]]] [simple_check_process_group] (0x2000): Adding group Benutzer
(Fri Aug 1 17:43:52 2014) [sssd[be[domain.a]]] [simple_check_process_group] (0x2000): Adding group EarthDomain Testers
(Fri Aug 1 17:43:52 2014) [sssd[be[domain.a]]] [simple_check_process_group] (0x2000): Adding group Earth Testers
(Fri Aug 1 17:43:52 2014) [sssd[be[domain.a]]] [simple_check_process_group] (0x2000): Adding GID 1208401199
(Fri Aug 1 17:43:52 2014) [sssd[be[domain.a]]] [simple_check_process_group] (0x2000): Adding GID 1208401196
(Fri Aug 1 17:43:52 2014) [sssd[be[domain.a]]] [simple_check_process_group] (0x2000): Adding GID 1208401194
(Fri Aug 1 17:43:52 2014) [sssd[be[domain.a]]] [simple_check_process_group] (0x2000): Adding GID 1208401197
(Fri Aug 1 17:43:52 2014) [sssd[be[domain.a]]] [simple_check_process_group] (0x2000): Adding GID 1208401195
(Fri Aug 1 17:43:52 2014) [sssd[be[domain.a]]] [simple_check_process_group] (0x2000): Adding GID 1208401201
(Fri Aug 1 17:43:52 2014) [sssd[be[domain.a]]] [simple_check_process_group] (0x2000): Adding group Earth Users
(Fri Aug 1 17:43:52 2014) [sssd[be[domain.a]]] [simple_check_get_groups_send] (0x0400): Need to resolve 8 groups
(Fri Aug 1 17:43:52 2014) [sssd[be[domain.a]]] [simple_resolve_group_check] (0x1000): The group is still non-POSIX
(Fri Aug 1 17:43:52 2014) [sssd[be[domain.a]]] [be_req_set_domain] (0x0400): Changing request domain from [domain.a] to [it.domain.a]
(Fri Aug 1 17:43:52 2014) [sssd[be[domain.a]]] [simple_resolve_group_done] (0x0080): Cannot refresh data from DP: 1,11: Offline
(Fri Aug 1 17:43:52 2014) [sssd[be[domain.a]]] [simple_check_get_groups_next] (0x0040): Could not resolve name of group with GID 1208401200
(Fri Aug 1 17:43:52 2014) [sssd[be[domain.a]]] [simple_access_check_done] (0x0040): Could not collect groups of user testuser
(Fri Aug 1 17:43:52 2014) [sssd[be[domain.a]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 4, ) [Success]
(Fri Aug 1 17:43:52 2014) [sssd[be[domain.a]]] [be_pam_handler_callback] (0x0100): Sending result [4][domain.a]
(Fri Aug 1 17:43:52 2014) [sssd[be[domain.a]]] [be_pam_handler_callback] (0x0100): Sent result [4][domain.a]
}}}

Here is our sssd.conf file:
{{{#!python
[sssd]
config_file_version = 2
reconnection_retries = 3
sbus_timeout = 30
services = nss, pam
domains = domain.a
debug_level = 0

[nss]
reconnection_retries = 3
override_shell = /bin/bash
override_homedir = /home/%u
debug_level = 0

[pam]
reconnection_retries = 3
debug_level = 0

[domain/domain.a]
enumerate = true
cache_credentials = true
min_id = 500
ad_domain = domain.a
access_provider = simple
simple_allow_groups = tele_itcommercial, ExecutiveEarth
auth_provider = ad
chpass_provider = ad
id_provider = ad
ldap_sasl_mech = GSSAPI
ldap_schema = ad
ldap_referrals = false
ldap_id_mapping = true
ldap_force_upper_case_realm = true
debug_level = 0

Hi,

thank you for the bug report. Can you put a higher debug_level (maybe 7) into the domain section and attach the logs? If they are too sensitive, you can send them to me and pbrezina directly.

From the current log snippet I see the provider is offline, which should never happen.

For the testing I would recommend using enumerate=false, because then the requests are visible at the time you call getent or id from the command line. With enumerate=true, there is a cron-like background job that periodically refreshes the records and the logs might not catch the moment the groups are refreshed.

Fields changed

milestone: SSSD 1.12.1 => NEEDS_TRIAGE

Replying to [comment:1 jhrozek]:

Hi,

thank you for the bug report. Can you put a higher debug_level (maybe 7) into the domain section and attach the logs? If they are too sensitive, you can send them to me and pbrezina directly.

Dear jhrozek,

can you please send me your and pbrezinas email address? We would like to send you directly a more detailed bug report, because we are not allowed to make it public.

Thank you for sssd it helps us alot to have a central user managment!

pbrezina@redhat.com and jhrozek@redhat.com

Fields changed

mark: => 0
owner: somebody => preichl

Hello Nicole,

could you please do following on server where group resolution failed:

run 'kinit $principal' using principal from 'klist -k'

and then run on global catalog some ldapsearch 'ldapsearch -h ad-host:3268 -Y GSSAPI...'

To verify that principals are OK.

If these goes well could you downgrade to SSSD 1.11.2 which you reported to be working on the other machine to exclude possible misconfiguration of this machine?

Thanks!

preichl tells me there's been no activity for some time. We've been unable to reproduce the problem in-house, so I'm closing the ticket.

resolution: => worksforme
status: new => closed

Metadata Update from @ntamm:
- Issue assigned to preichl
- Issue set to the milestone: NEEDS_TRIAGE

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

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.
Metadata
None
None
None
Low
defect
SSSD
1.12.0
None
None
0
0
None
0
0
0
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.