Learn more about these different git repos.
Other Git URLs
Ticket was cloned from Red Hat Bugzilla (product Fedora): Bug 988360
Created attachment 778238 sssd logs with debug level 10 Description of problem: sssd doesn't show users from newly added Active Directory domain, when multiple trusts are created Version-Release number of selected component (if applicable): sssd-1.11.0-0.1.beta2.fc19.x86_64 sssd-krb5-common-1.11.0-0.1.beta2.fc19.x86_64 sssd-ldap-1.11.0-0.1.beta2.fc19.x86_64 sssd-client-1.11.0-0.1.beta2.fc19.x86_64 sssd-ipa-1.11.0-0.1.beta2.fc19.x86_64 sssd-common-1.11.0-0.1.beta2.fc19.x86_64 sssd-ad-1.11.0-0.1.beta2.fc19.x86_64 sssd-proxy-1.11.0-0.1.beta2.fc19.x86_64 sssd-krb5-1.11.0-0.1.beta2.fc19.x86_64 freeipa-python-3.3.0-0.2.beta1.fc19.x86_64 freeipa-server-trust-ad-3.3.0-0.2.beta1.fc19.x86_64 libipa_hbac-1.11.0-0.1.beta2.fc19.x86_64 sssd-ipa-1.11.0-0.1.beta2.fc19.x86_64 freeipa-admintools-3.3.0-0.2.beta1.fc19.x86_64 freeipa-server-3.3.0-0.2.beta1.fc19.x86_64 libipa_hbac-python-1.11.0-0.1.beta2.fc19.x86_64 iniparser-3.1-2.fc19.x86_64 python-iniparse-0.4-7.fc19.noarch freeipa-client-3.3.0-0.2.beta1.fc19.x86_64 How reproducible: Have 2 AD Domains: (with posix Attributes) win2.ceres.site win1.philip.site 1. Configure freeipa server on F-19 2. Create ipa trust with win2.ceres.site [root@master1 sssd]# ipa trust-show Realm name: win2.ceres.site Realm name: win2.ceres.site Domain NetBIOS name: WIN2 Domain Security Identifier: S-1-5-21-3788982561-4130956705-2391027395 Trust direction: Two-way trust Trust type: Active Directory domain 3. Create ipa trust with win1.philip.site [root@master1 sssd]# ipa trust-show Realm name: win1.philip.site Realm name: win1.philip.site Domain NetBIOS name: WIN1 Domain Security Identifier: S-1-5-21-1931677605-3808565714-2911731196 Trust direction: Two-way trust Trust type: Active Directory domain 4. Create AD user testaduser1 in win2.ceres.site and apply posix attributes. 5. from ipa server, getent passwd testaduser1@win2.ceres.site returns [root@master1 sssd]# getent passwd testaduser1@win2.ceres.site testaduser1@win2.ceres.site:*:1343201107:1343201107:testad user1:/home/testaduser1:/bin/sh 6. Create AD user philip_testaduser1 in win1.philip.site and on ipa server getent passwd philip_testaduser1@win1.philip.site doesn't return user info Actual results: sssd doesn't return users from 2nd AD (win1.philip.site) Expected results: sssd should also return user's from 2nd AD also. Additional info: 2nd AD win1.philip.site is not in the same timezone as IPA. Attaching sssd logs
Fields changed
blockedby: => blocking: => changelog: => coverity: => design: => design_review: => 0 feature_milestone: => fedora_test_page: => milestone: NEEDS_TRIAGE => SSSD 1.11 review: True => 0 selected: => testsupdated: => 0
Multiple trusts are more of a nice to have. Lowering priority.
priority: major => minor
milestone: SSSD 1.11.1 => SSSD 1.11.2
priority: minor => major
owner: somebody => jhrozek
This bug is already fixed since commit 794bfc6 which removed the too strict check that was causing the error. With freeipa server from today's master and sssd master I'm able to resolve users and groups from both trusts:
# getent passwd administrator@win.example.com administrator@win.example.com:*:388000500:388000500:Administrator:/: # getent passwd administrator@subdom.win administrator@subdom.win:*:78000500:78000500:Administrator:/: # getent passwd foobar@subdom.win foobar@subdom.win:*:78001105:78001105:foo bar:/: # ipa trust-find ---------------- 2 trusts matched ---------------- Realm name: SUBDOM.WIN Domain NetBIOS name: SUBDOM Domain Security Identifier: S-1-5-21-1365119850-1357197216-3885893077 SID blacklist incoming: S-1-0, S-1-1, S-1-2, S-1-3, S-1-5-1, S-1-5-2, S-1-5-3, S-1-5-4, S-1-5-5, S-1-5-6, S-1-5-7, S-1-5-8, S-1-5-9, S-1-5-10, S-1-5-11, S-1-5-12, S-1-5-13, S-1-5-14, S-1-5-15, S-1-5-16, S-1-5-17, S-1-5-18, S-1-5-19, S-1-5-20 SID blacklist outgoing: S-1-0, S-1-1, S-1-2, S-1-3, S-1-5-1, S-1-5-2, S-1-5-3, S-1-5-4, S-1-5-5, S-1-5-6, S-1-5-7, S-1-5-8, S-1-5-9, S-1-5-10, S-1-5-11, S-1-5-12, S-1-5-13, S-1-5-14, S-1-5-15, S-1-5-16, S-1-5-17, S-1-5-18, S-1-5-19, S-1-5-20 Trust type: Active Directory domain Realm name: WIN.EXAMPLE.COM Domain NetBIOS name: WIN Domain Security Identifier: S-1-5-21-1071950027-2292564753-1642059312 SID blacklist incoming: S-1-0, S-1-1, S-1-2, S-1-3, S-1-5-1, S-1-5-2, S-1-5-3, S-1-5-4, S-1-5-5, S-1-5-6, S-1-5-7, S-1-5-8, S-1-5-9, S-1-5-10, S-1-5-11, S-1-5-12, S-1-5-13, S-1-5-14, S-1-5-15, S-1-5-16, S-1-5-17, S-1-5-18, S-1-5-19, S-1-5-20 SID blacklist outgoing: S-1-0, S-1-1, S-1-2, S-1-3, S-1-5-1, S-1-5-2, S-1-5-3, S-1-5-4, S-1-5-5, S-1-5-6, S-1-5-7, S-1-5-8, S-1-5-9, S-1-5-10, S-1-5-11, S-1-5-12, S-1-5-13, S-1-5-14, S-1-5-15, S-1-5-16, S-1-5-17, S-1-5-18, S-1-5-19, S-1-5-20 Trust type: Active Directory domain ---------------------------- Number of entries returned 2 ----------------------------
Despite the name, subdom.win is not a subdomain of win.example.com, but a standalone forest.
The logs in the original bugzilla also prove that the issue was fixed by removing the errorneous check:
[sssd[be[ipa.europa.site]]] [sdap_domain_subdom_add] (0x0400): subdomain win2.ceres.site is a new one, will create a new sdap domain object [sssd[be[ipa.europa.site]]] [sdap_domain_subdom_add] (0x0400): subdomain win1.philip.site is a new one, will create a new sdap domain object [sssd[be[ipa.europa.site]]] [sdap_domain_add] (0x0040): Domain win1.philip.site is not a subdomain of win2.ceres.site [sssd[be[ipa.europa.site]]] [sdap_domain_subdom_add] (0x0040): Cannot add new sdap domain for domain ipa.europa.site [22]: Invalid argument [sssd[be[ipa.europa.site]]] [ipa_ad_ctx_new] (0x0040): Cannot initialize sdap domain
Closing.
_comment0: This bug is already fixed since commit 794bfc6 which removed the too strict check that was causing the error. With freeipa server from today's master and sssd master I'm able to resolve users and groups from both trusts:
{{{
administrator@subdom.win:*:78000500:78000500:Administrator:/:
foobar@subdom.win:*:78001105:78001105:foo bar:/:
Realm name: SUBDOM.WIN Domain NetBIOS name: SUBDOM Domain Security Identifier: S-1-5-21-1365119850-1357197216-3885893077 SID blacklist incoming: S-1-0, S-1-1, S-1-2, S-1-3, S-1-5-1, S-1-5-2, S-1-5-3, S-1-5-4, S-1-5-5, S-1-5-6, S-1-5-7, S-1-5-8, S-1-5-9, S-1-5-10, S-1-5-11, S-1-5-12, S-1-5-13, S-1-5-14, S-1-5-15, S-1-5-16, S-1-5-17, S-1-5-18, S-1-5-19, S-1-5-20 SID blacklist outgoing: S-1-0, S-1-1, S-1-2, S-1-3, S-1-5-1, S-1-5-2, S-1-5-3, S-1-5-4, S-1-5-5, S-1-5-6, S-1-5-7, S-1-5-8, S-1-5-9, S-1-5-10, S-1-5-11, S-1-5-12, S-1-5-13, S-1-5-14, S-1-5-15, S-1-5-16, S-1-5-17, S-1-5-18, S-1-5-19, S-1-5-20 Trust type: Active Directory domain
Realm name: WIN.EXAMPLE.COM Domain NetBIOS name: WIN Domain Security Identifier: S-1-5-21-1071950027-2292564753-1642059312 SID blacklist incoming: S-1-0, S-1-1, S-1-2, S-1-3, S-1-5-1, S-1-5-2, S-1-5-3, S-1-5-4, S-1-5-5, S-1-5-6, S-1-5-7, S-1-5-8, S-1-5-9, S-1-5-10, S-1-5-11, S-1-5-12, S-1-5-13, S-1-5-14, S-1-5-15, S-1-5-16, S-1-5-17, S-1-5-18, S-1-5-19, S-1-5-20 SID blacklist outgoing: S-1-0, S-1-1, S-1-2, S-1-3, S-1-5-1, S-1-5-2, S-1-5-3, S-1-5-4, S-1-5-5, S-1-5-6, S-1-5-7, S-1-5-8, S-1-5-9, S-1-5-10, S-1-5-11, S-1-5-12, S-1-5-13, S-1-5-14, S-1-5-15, S-1-5-16, S-1-5-17, S-1-5-18, S-1-5-19, S-1-5-20 Trust type: Active Directory domain
}}}
The logs in the original bugzilla also prove that the issue was fixed by removing the errorneous check: {{{ [sssd[be[ipa.europa.site]]] [sdap_domain_subdom_add] (0x0400): subdomain win2.ceres.site is a new one, will create a new sdap domain object [sssd[be[ipa.europa.site]]] [sdap_domain_subdom_add] (0x0400): subdomain win1.philip.site is a new one, will create a new sdap domain object [sssd[be[ipa.europa.site]]] [sdap_domain_add] (0x0040): Domain win1.philip.site is not a subdomain of win2.ceres.site [sssd[be[ipa.europa.site]]] [sdap_domain_subdom_add] (0x0040): Cannot add new sdap domain for domain ipa.europa.site [22]: Invalid argument [sssd[be[ipa.europa.site]]] [ipa_ad_ctx_new] (0x0040): Cannot initialize sdap domain }}}
Closing. => 1382543092586555 resolution: => worksforme status: new => closed
Metadata Update from @jhrozek: - Issue assigned to jhrozek - Issue set to the milestone: SSSD 1.11.2
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/3075
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.