Sorry for the late response. I can confirm that with 3.3.3-28.el7_0.3, i'm able to fetch the sub-domains and to log with its users.
Thank you ! 2015-01-04 10:17 GMT+02:00 Alexander Bokovoy <aboko...@redhat.com>: > > > ------------------------------ > > Hello all. > > I'm working on integrating AD trust feature in the forest of a large > organization (Its network is not connected to the internet). > > First I tested the trust in "clean" environment (that i have deployed) to > simulate production forest deployment , in the following configuration: > > > The forest root domain : red.com > > Second Domain tree : blue.com > > IPA : linux.blue.com > > All the AD DCs are 2008 R2 server and 2008 R2 functional level. > > IPA server in installed on RHEL 7. > > ipa-server-3.3.3-28.el7_0.1.x86_64 > > ipa-server-trust-ad-3.3.3-28.el7_0.1.x86_64 > > ipa-python-3.3.3-28.el7_0.1.x86_64 > > > > With help of the mailing list, all works fine. Users from both red.com > and blue.com are able to log into IPA domain. > > After the success, I proceeded to test the trust in organization's test > environment. > > The installation of the trust itself has completed successfully. But > although users from *red.com <http://red.com>* were able to log into IPA > domain, users from *blue.com <http://blue.com>* couldn't. > > After checking the sssd logs it seemed as blue.com domain is unknown to > IPA. > > Therefore I ran "*ipa trustdomain-find red.com <http://red.com>" *in both > environments, to see if there are any differences. > > And indeed there were: > > While in the "clean" environment, the command returned both *red.com > <http://red.com>* and *blue.com <http://blue.com>* domains, in > organization's test environment it returned only *red.com > <http://red.com>*. > > I tried to re fetch the domain with "*ipa trust-fetch-domains red.com > <http://red.com>" *but it returned the message - " No new trust domains > were found". > > > > It made me think that maybe the AD is not returning all domains in the > forest. > > I opened wireshark on both environments and ran "*ipa > trust-fetch-domains red.com <http://red.com>" *to see what is been sent > from AD to IPA. > > > > In both environments I seen the DsrEnumerateDomainTrusts request and > response. > > Reading the content of response showed that in both environments, the > response contained *red.com <http://red.com>* and *blue.com > <http://blue.com>* domain. > > After inspecting the structures that contain domains information > (DS_DOMAIN_TRUSTS) , I noticed that in both environments the *TrustAttribute > *of red.com is set to 0x0000000. > > But *TrustAttribute *of blue.com is set to 0x00000020 ( > TRUST_ATTRIBUTE_WITHIN_FOREST) in the "clean" environment and to > 0x00800000 in the test environment. > > Reading MSDN for *TrustAttribute*, explains the following: > > http://msdn.microsoft.com/en-us/library/cc223779.aspx > > (TRUST_ATTRIBUTE_WITHIN_FOREST) > > 0x00000020 > > If this bit is set, then the trusted domain is within the same forest. > > Only evaluated on Windows Server 2003, Windows Server 2008, Windows > Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2. > > While I couldn't find specific information about 0x00800000, but this: > > 0x00400000 - 0x00800000 > > Previously used trust bits, and are obsolete. > > > > I did not find more information on 0x00800000 or a reason why the > attributes would be different in the two deployments. > > I asked for advice from Microsoft IT guy in the organization. He said that > difference in the *TrustAttribute *is caused by the fact, that the > "clean" environment was created as Windows Server 2008, while the test (and > production) forest was created as windows 2000 servers (about 12 years > ago) and the forest was gradually upgraded to 2003 and 2008 along the years. > > Couldn't find more information on the attribute for windows server > 2000/2003 but the theory sounds quite logical. > > I decided to check if *TrustAttribute *influences IPA's domain fetch. > > fetch_domains function in > /usr/lib/python2.7/site-packages/ipaserver/dcerpc.py > > contains the following lines of code: > > trust_attributes = dict( > > NETR_TRUST_ATTRIBUTE_NON_TRANSITIVE = 0x00000001, > > NETR_TRUST_ATTRIBUTE_UPLEVEL_ONLY = 0x00000002, > > NETR_TRUST_ATTRIBUTE_QUARANTINED_DOMAIN = 0x00000004, > > NETR_TRUST_ATTRIBUTE_FOREST_TRANSITIVE = 0x00000008, > > NETR_TRUST_ATTRIBUTE_CROSS_ORGANIZATION = 0x00000010, > > NETR_TRUST_ATTRIBUTE_WITHIN_FOREST = 0x00000020, > > NETR_TRUST_ATTRIBUTE_TREAT_AS_EXTERNAL = 0x00000040) > > . > > . > > . > > > > result = [] > > for t in domains.array: > > *if ((t.trust_attributes & > trust_attributes['NETR_TRUST_ATTRIBUTE_WITHIN_FOREST']) and* > > * (t.trust_flags & trust_flags['NETR_TRUST_FLAG_IN_FOREST'])):* > > res = dict() > > res['cn'] = unicode(t.dns_name) > > res['ipantflatname'] = unicode(t.netbios_name) > > res['ipanttrusteddomainsid'] = unicode(t.sid) > > res['ipanttrustpartner'] = res['cn'] > > result.append(res) > > The bit-wise operation is preformed to check if the trust attribute is set > to TRUST_ATTRIBUTE_WITHIN_FOREST (0x00000020) and if so, the trust is > added to result array. > > It seems the value of *TrustAttribute *set to 0x00800000 is the reason > the domain wasn't fetched. > > To confirm it I changed the if statement to: > > if ((t.trust_attributes & > trust_attributes['NETR_TRUST_ATTRIBUTE_WITHIN_FOREST'] *|| * > > *(t.trust_attributes & 0x00800000)) *and (t.trust_flags & > trust_flags['NETR_TRUST_FLAG_IN_FOREST'])): > > > > Then deleted and recreated the trust and finally ran "*ipa > trust-fetch-domains red.com <http://red.com>"-* > > this time the *blue.com <http://blue.com>* domain did appear! > > I was able to login with users from both red.com and blue.com to IPA > domain. > > > > Checking both upstream 3.3 and 4.1 shows that the if statement was changed > to : > > > > *if* (*not* (t.trust_flags & trust_flags['NETR_TRUST_FLAG_PRIMARY']) *and* > > (t.trust_flags & trust_flags['NETR_TRUST_FLAG_IN_FOREST'])): > > > > > https://git.fedorahosted.org/cgit/freeipa.git/tree/ipaserver/dcerpc.py?h=ipa-3-3#n1039 > > > > > https://git.fedorahosted.org/cgit/freeipa.git/tree/ipaserver/dcerpc.py?h=ipa-4-1#n1102 > > > > From first sight it looks like blue.com will fetched. > > Haven't yet tested if upstream works in the test environment. > > > > Any thoughts on the subject will be great. > > (I hope i'm not mentioning something that was solved long ago). > > The fix you see in the git repo was released in 3.3.3-28.el7_0.3, as > https://rhn.redhat.com/errata/RHBA-2014-1828.html > > Can you please confirm that this version fixes the issue for you? > > > -- > / Alexander Bokovoy >
-- 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
