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.
--
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
