[Freeipa-users] IPA trust integration in AD Forests that been upgraded to higher functional level

Sat Jan 3 19:13:50 UTC 2015

On 01/02/2015 10:13 PM, Genadi Postrilko wrote:
>
> 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 <http://red.com>
>
> Second Domain tree      : blue.com <http://blue.com>
>
> IPA                             : linux.blue.com <http://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 
> <http://red.com> and blue.com <http://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 
> althoughusers 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 <http://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 
> responsecontained *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 <http://red.com> is set to 0x0000000.
>
> But *TrustAttribute *of blue.com <http://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 <http://red.com> and 
> blue.com <http://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 <http://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).
>
> Genadi
>
>
>
Wow!

Sounds like a ticket is due...

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20150103/bc46ad42/attachment.htm>