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

Sun Jan 4 08:17:41 UTC 2015

----- 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 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20150104/564d80ab/attachment.htm>