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

Sun Jan 4 15:01:34 UTC 2015

It will take some time to bring the new packages into organizations network.
But as soon as it happens, ill inform you on the results.

Thank you.

2015-01-04 10:17 GMT+02:00 Alexander Bokovoy <abokovoy at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20150104/fccad75b/attachment.htm>