Re: [Freeipa-users] IPA trust integration in AD Forests that been upgraded to higher functional level
Sorry for the late response. I can confirm that with 3.3.3-28.el7_0.3, i'm able to fetch the sub-domains and to log with its users. Thank you ! 2015-01-04 10:17 GMT+02:00 Alexander Bokovoy aboko...@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 0x000. But *TrustAttribute *of blue.com is set to 0x0020 ( TRUST_ATTRIBUTE_WITHIN_FOREST) in the clean environment and to 0x0080 in the test environment. Reading MSDN for *TrustAttribute*, explains the following: http://msdn.microsoft.com/en-us/library/cc223779.aspx (TRUST_ATTRIBUTE_WITHIN_FOREST) 0x0020 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 0x0080, but this: 0x0040 - 0x0080 Previously used trust bits, and are obsolete. I did not find more information on 0x0080 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 = 0x0001, NETR_TRUST_ATTRIBUTE_UPLEVEL_ONLY = 0x0002, NETR_TRUST_ATTRIBUTE_QUARANTINED_DOMAIN = 0x0004, NETR_TRUST_ATTRIBUTE_FOREST_TRANSITIVE = 0x0008, NETR_TRUST_ATTRIBUTE_CROSS_ORGANIZATION = 0x0010, NETR_TRUST_ATTRIBUTE_WITHIN_FOREST = 0x0020, NETR_TRUST_ATTRIBUTE_TREAT_AS_EXTERNAL = 0x0040) . . . 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)
Re: [Freeipa-users] IPA trust integration in AD Forests that been upgraded to higher functional level
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 aboko...@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 0x000. But *TrustAttribute *of blue.com is set to 0x0020 ( TRUST_ATTRIBUTE_WITHIN_FOREST) in the clean environment and to 0x0080 in the test environment. Reading MSDN for *TrustAttribute*, explains the following: http://msdn.microsoft.com/en-us/library/cc223779.aspx (TRUST_ATTRIBUTE_WITHIN_FOREST) 0x0020 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 0x0080, but this: 0x0040 - 0x0080 Previously used trust bits, and are obsolete. I did not find more information on 0x0080 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 = 0x0001, NETR_TRUST_ATTRIBUTE_UPLEVEL_ONLY = 0x0002, NETR_TRUST_ATTRIBUTE_QUARANTINED_DOMAIN = 0x0004, NETR_TRUST_ATTRIBUTE_FOREST_TRANSITIVE = 0x0008, NETR_TRUST_ATTRIBUTE_CROSS_ORGANIZATION = 0x0010, NETR_TRUST_ATTRIBUTE_WITHIN_FOREST = 0x0020, NETR_TRUST_ATTRIBUTE_TREAT_AS_EXTERNAL = 0x0040) . . . 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)
Re: [Freeipa-users] IPA trust integration in AD Forests that been upgraded to higher functional level
- 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 0x000. But TrustAttribute of blue.com is set to 0x0020 ( TRUST_ATTRIBUTE_WITHIN_FOREST ) in the clean environment and to 0x0080 in the test environment. Reading MSDN for TrustAttribute , explains the following: http://msdn.microsoft.com/en-us/library/cc223779.aspx (TRUST_ATTRIBUTE_WITHIN_FOREST) 0x0020 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 0x0080, but this: 0x0040 - 0x0080 Previously used trust bits, and are obsolete. I did not find more information on 0x0080 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 = 0x0001, NETR_TRUST_ATTRIBUTE_UPLEVEL_ONLY = 0x0002, NETR_TRUST_ATTRIBUTE_QUARANTINED_DOMAIN = 0x0004, NETR_TRUST_ATTRIBUTE_FOREST_TRANSITIVE = 0x0008, NETR_TRUST_ATTRIBUTE_CROSS_ORGANIZATION = 0x0010, NETR_TRUST_ATTRIBUTE_WITHIN_FOREST = 0x0020, NETR_TRUST_ATTRIBUTE_TREAT_AS_EXTERNAL = 0x0040) . . . 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 (0x0020) and if so, the trust is added to result array. It seems the value of TrustAttribute set to 0x0080 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 0x0080)) 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
Re: [Freeipa-users] IPA trust integration in AD Forests that been upgraded to higher functional level
I would like to make a correction. The change i made is: if ((t.trust_attributes trust_attributes['NETR_TRUST_ATTRIBUTE_WITHIN_FOREST'] *or* (t.trust_attributes 0x0080)) and (t.trust_flags trust_flags['NETR_TRUST_FLAG_IN_FOREST'])): and not: if ((t.trust_attributes trust_attributes['NETR_TRUST_ATTRIBUTE_WITHIN_FOREST'] *||* (t.trust_attributes 0x0080)) and (t.trust_flags trust_flags['NETR_TRUST_FLAG_IN_FOREST'])): -- 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
Re: [Freeipa-users] IPA trust integration in AD Forests that been upgraded to higher functional level
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 0x000. But *TrustAttribute *of blue.com http://blue.com is set to 0x0020 (TRUST_ATTRIBUTE_WITHIN_FOREST) in the clean environment and to 0x0080 in the test environment. Reading MSDN for *TrustAttribute*, explains the following: http://msdn.microsoft.com/en-us/library/cc223779.aspx (TRUST_ATTRIBUTE_WITHIN_FOREST) 0x0020 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 0x0080, but this: 0x0040 - 0x0080 Previously used trust bits, and are obsolete. I did not find more information on 0x0080 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 = 0x0001, NETR_TRUST_ATTRIBUTE_UPLEVEL_ONLY = 0x0002, NETR_TRUST_ATTRIBUTE_QUARANTINED_DOMAIN = 0x0004, NETR_TRUST_ATTRIBUTE_FOREST_TRANSITIVE = 0x0008, NETR_TRUST_ATTRIBUTE_CROSS_ORGANIZATION = 0x0010, NETR_TRUST_ATTRIBUTE_WITHIN_FOREST = 0x0020, NETR_TRUST_ATTRIBUTE_TREAT_AS_EXTERNAL = 0x0040) . . . 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 (0x0020) and if so, the trust is added to result array. It seems the value
[Freeipa-users] IPA trust integration in AD Forests that been upgraded to higher functional level
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 0x000. But *TrustAttribute *of blue.com is set to 0x0020 ( TRUST_ATTRIBUTE_WITHIN_FOREST) in the clean environment and to 0x0080 in the test environment. Reading MSDN for *TrustAttribute*, explains the following: http://msdn.microsoft.com/en-us/library/cc223779.aspx (TRUST_ATTRIBUTE_WITHIN_FOREST) 0x0020 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 0x0080, but this: 0x0040 - 0x0080 Previously used trust bits, and are obsolete. I did not find more information on 0x0080 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 = 0x0001, NETR_TRUST_ATTRIBUTE_UPLEVEL_ONLY = 0x0002, NETR_TRUST_ATTRIBUTE_QUARANTINED_DOMAIN = 0x0004, NETR_TRUST_ATTRIBUTE_FOREST_TRANSITIVE = 0x0008, NETR_TRUST_ATTRIBUTE_CROSS_ORGANIZATION = 0x0010, NETR_TRUST_ATTRIBUTE_WITHIN_FOREST = 0x0020, NETR_TRUST_ATTRIBUTE_TREAT_AS_EXTERNAL = 0x0040) . . . 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 (0x0020) and if so, the trust is added to result array. It seems the value of *TrustAttribute *set to 0x0080 is the reason the domain
