----- Original Message ----- > 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 were able to log into IPA domain, users from 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 " 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 and > blue.com domains, in organization's test environment it returned only > red.com . > I tried to re fetch the domain with " ipa trust-fetch-domains 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 " 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 and 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 "- > this time the 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
