#3199 No supplementary groups are resolved for users in nested OUs when domain stanza differs from AD domain
Closed: Fixed None Opened 2 years ago by jhrozek.

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

Description of problem:

No supplementary groups are resolved for nested users when the [domain] stanza
in sssd.conf differs from the AD domain, i.e. [default].

Quote from an email thread with Jakub.

"It's a bit bizzare, because the bug only happens when the [domain] stanza in
sssd.conf is named differently than the AD domain... Then, we look up a
user in Global Catalog, which returns two entries because the domains
(and thus the search bases) are nested under one another. So we proceed
to mapping the DN to SSSD domain, but fail, because the name of the SSSD
domain is totally different from the DN.. I /thought/ we also tried to
match against DN derived from the search base as a fallback, but
apparently not."

Test Suite: ad parameters
Test Case: account_password_policy_003:User account disabled

NOTE: The test is failing because of this bug, but this test case is NOT
actually testing this bug.

Version-Release number of selected component (if applicable):

How reproducible:

Always

Steps to Reproduce:
1. Run ad_parameters suite

Actual results:

:: [   PASS   ] :: Expected: login failure for testuser01-1511559 with password
(Expected 255, got 255)
:: [   FAIL   ] :: File '/var/log/secure' should contain 'User account has
expired'
:: [  BEGIN   ] :: Expected: login failure for testuser01-1511559 with ssh key
:: actually running 'ssh_user_key_login testuser01-1511559'
spawn ssh -o StrictHostKeyChecking=no -o GSSAPIAuthentication=no -o
PasswordAuthentication=no -l testuser01-1511559 localhost
Connection closed by ::1

Expected results:

:: [   PASS   ] :: Expected: login failure for testuser01-1511559 with password
(Expected 255, got 255)
:: [   PASS   ] :: File '/var/log/secure' should contain 'User account has
expired'
:: [  BEGIN   ] :: Expected: login failure for testuser01-1511559 with ssh key
:: actually running 'ssh_user_key_login testuser01-1511559'
spawn ssh -o StrictHostKeyChecking=no -o GSSAPIAuthentication=no -o
PasswordAuthentication=no -l testuser01-1511559 localhost
Connection closed by ::1

Additional info:

According to Jakub, this is a side effect of fixing the following
https://bugzilla.redhat.com/show_bug.cgi?id=1293168

Fields changed

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

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.14.2

I can reproduce this locally, so I'm picking the ticket up.

owner: somebody => jhrozek
status: new => assigned

Fields changed

patch: 0 => 1

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

resolution: => fixed
status: assigned => closed

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

2 years ago

Login to comment on this ticket.

Metadata