| Author | Messages | |
decrosby
Posts:64
 | | 02/04/2010 11:33 AM |
| Hi.
Working on getting xrealm authentication working between our Window Forest and our Kerberos Realm
If I want to get xrealm authentication working between the above I have created a transitive realm trust between the forest root domain and our Kerberos realm I have added a TLN suffix to allow Kerberos referrals to walk the trust path to get the appropriate TGT. This is working well in my test environment.
My question is really about our production environment which is slightly more complex in terms of trusts and realnames and dns domain names and I am concerned that if I add the incorrect TLN I may cause Kerberos to fail intra forest.
In terms of structure
* Forest root domain xy.com
* Child domain ab.xy.com
* Kerberos Realm myrealm.com
* DNS domain name xy.com
We have delegation with namespace overlap ie the Windows 2003 Forest uses the same DNS domain name (xy.com) as the one hosted on the legacy DNS. In this scenario we delegate the specific windows sub domains from legacy DNS to Windows DNS servers (typically DC's) including _msdcs, _sites, _tcp, _udp, etc etc. Child domains within the forest are also delegated.
if I want to access http://myapache.xy.com to route this appropriately I could use netdom.exe trust XY.COM /domain:myrealm.com /addtln:xy.com but I am concerned this will cause a name routing clash. Would anyone be able to help elaborate on how name suffixes are handled when using a realm trust
Unfortunately my test environment does not suffer from the same DNS namespace overlap so I cant test with any degree of certainty..
Thanks.
Damian.
--------------------------------------------------------------------------
NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law.
| | | |
| rwilper
Posts:20
| | 02/04/2010 3:38 PM |
| This is similar to our cross-realm situation, though in our case, the Non-AD realm has the same name as our dns zone.
The important thing is host-to-realm mapping. Windows clients use Active Directory lookups for host-to-realm mapping by default, but specific mappings can be set in the clients' registry.
When you set a TLN on a forest trust, the active directory will refer all ticket requests with the suffix to follow that trust. AD will fail to map any that it both doesn't know and has no TLN for.
In our case, this meant that every computer that fails to register it's SPN properly gets forwarded across and fails.
In your case, this most likely means that host-to-realm registry will need to be set on any client that needs to get tickets to hosts in the exterior realm.
I have not found any good documentation on host-to-realm and have not had to try it - I only researched because I considered setting it for the 2-3 hosts in the external realm and removing the TLN mapping- but here is what I think I know...
HostToRealm
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\HostToRealm
Add Key for the Realm Name (myrealm.com)
Add Value SPNMappings (REG_MULTI_SZ)
Values = names to forward to the other realm
*. myrealm.com
weblogin. myrealm.com
-Ross
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Crosby, Damian
Sent: Thursday, February 04, 2010 3:32 AM
To: activedir@mail.activedir.org
Subject: [ActiveDir] Name Suffix Routing and a Realm Trust
Hi.
Working on getting xrealm authentication working between our Window Forest and our Kerberos Realm
If I want to get xrealm authentication working between the above I have created a transitive realm trust between the forest root domain and our Kerberos realm I have added a TLN suffix to allow Kerberos referrals to walk the trust path to get the appropriate TGT. This is working well in my test environment.
My question is really about our production environment which is slightly more complex in terms of trusts and realnames and dns domain names and I am concerned that if I add the incorrect TLN I may cause Kerberos to fail intra forest.
In terms of structure
* Forest root domain xy.com
* Child domain ab.xy.com
* Kerberos Realm myrealm.com
* DNS domain name xy.com
We have delegation with namespace overlap ie the Windows 2003 Forest uses the same DNS domain name (xy.com) as the one hosted on the legacy DNS. In this scenario we delegate the specific windows sub domains from legacy DNS to Windows DNS servers (typically DC's) including _msdcs, _sites, _tcp, _udp, etc etc. Child domains within the forest are also delegated.
if I want to access http://myapache.xy.com to route this appropriately I could use netdom.exe trust XY.COM /domain:myrealm.com /addtln:xy.com but I am concerned this will cause a name routing clash. Would anyone be able to help elaborate on how name suffixes are handled when using a realm trust
Unfortunately my test environment does not suffer from the same DNS namespace overlap so I cant test with any degree of certainty..
Thanks.
Damian.
________________________________
NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law.
| | | |
| decrosby
Posts:64
| | 02/04/2010 3:50 PM |
| Thanks Ross.
This doesn't scale particularly well and I have indeed tested this.
My concern is really what you have stated below
When you set a TLN on a forest trust, the active directory will refer all ticket requests with the suffix to follow that trust
what happens when a SPN needs to be resolved for to a principal in the forest with the valid FQDN of xy.com? Will AD try and route it over the trust or will it resolve it within the forest first via a GC lookup and stop. I am unclear on how this clash will be handled via the GC's and TDO objects within the forest.
Thanks.
Damian.
________________________________
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Wilper, Ross A
Sent: 04 February 2010 15:36
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Name Suffix Routing and a Realm Trust
This is similar to our cross-realm situation, though in our case, the Non-AD realm has the same name as our dns zone.
The important thing is host-to-realm mapping. Windows clients use Active Directory lookups for host-to-realm mapping by default, but specific mappings can be set in the clients' registry.
When you set a TLN on a forest trust, the active directory will refer all ticket requests with the suffix to follow that trust. AD will fail to map any that it both doesn't know and has no TLN for.
In our case, this meant that every computer that fails to register it's SPN properly gets forwarded across and fails.
In your case, this most likely means that host-to-realm registry will need to be set on any client that needs to get tickets to hosts in the exterior realm.
I have not found any good documentation on host-to-realm and have not had to try it - I only researched because I considered setting it for the 2-3 hosts in the external realm and removing the TLN mapping- but here is what I think I know...
HostToRealm
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\HostToRealm
Add Key for the Realm Name (myrealm.com)
Add Value SPNMappings (REG_MULTI_SZ)
Values = names to forward to the other realm
*. myrealm.com
weblogin. myrealm.com
-Ross
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Crosby, Damian
Sent: Thursday, February 04, 2010 3:32 AM
To: activedir@mail.activedir.org
Subject: [ActiveDir] Name Suffix Routing and a Realm Trust
Hi.
Working on getting xrealm authentication working between our Window Forest and our Kerberos Realm
If I want to get xrealm authentication working between the above I have created a transitive realm trust between the forest root domain and our Kerberos realm I have added a TLN suffix to allow Kerberos referrals to walk the trust path to get the appropriate TGT. This is working well in my test environment.
My question is really about our production environment which is slightly more complex in terms of trusts and realnames and dns domain names and I am concerned that if I add the incorrect TLN I may cause Kerberos to fail intra forest.
In terms of structure
* Forest root domain xy.com
* Child domain ab.xy.com
* Kerberos Realm myrealm.com
* DNS domain name xy.com
We have delegation with namespace overlap ie the Windows 2003 Forest uses the same DNS domain name (xy.com) as the one hosted on the legacy DNS. In this scenario we delegate the specific windows sub domains from legacy DNS to Windows DNS servers (typically DC's) including _msdcs, _sites, _tcp, _udp, etc etc. Child domains within the forest are also delegated.
if I want to access http://myapache.xy.com to route this appropriately I could use netdom.exe trust XY.COM /domain:myrealm.com /addtln:xy.com but I am concerned this will cause a name routing clash. Would anyone be able to help elaborate on how name suffixes are handled when using a realm trust
Unfortunately my test environment does not suffer from the same DNS namespace overlap so I cant test with any degree of certainty..
Thanks.
Damian.
________________________________
NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law.
--------------------------------------------------------------------------
NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law.
| | | |
| rwilper
Posts:20
| | 02/04/2010 3:56 PM |
| If the SPN is in Active Directory, the GC lookup will win or the TLN mapping.
-Ross
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Crosby, Damian
Sent: Thursday, February 04, 2010 7:50 AM
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Name Suffix Routing and a Realm Trust
Thanks Ross.
This doesn't scale particularly well and I have indeed tested this.
My concern is really what you have stated below
When you set a TLN on a forest trust, the active directory will refer all ticket requests with the suffix to follow that trust
what happens when a SPN needs to be resolved for to a principal in the forest with the valid FQDN of xy.com? Will AD try and route it over the trust or will it resolve it within the forest first via a GC lookup and stop. I am unclear on how this clash will be handled via the GC's and TDO objects within the forest.
Thanks.
Damian.
________________________________
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Wilper, Ross A
Sent: 04 February 2010 15:36
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Name Suffix Routing and a Realm Trust
This is similar to our cross-realm situation, though in our case, the Non-AD realm has the same name as our dns zone.
The important thing is host-to-realm mapping. Windows clients use Active Directory lookups for host-to-realm mapping by default, but specific mappings can be set in the clients' registry.
When you set a TLN on a forest trust, the active directory will refer all ticket requests with the suffix to follow that trust. AD will fail to map any that it both doesn't know and has no TLN for.
In our case, this meant that every computer that fails to register it's SPN properly gets forwarded across and fails.
In your case, this most likely means that host-to-realm registry will need to be set on any client that needs to get tickets to hosts in the exterior realm.
I have not found any good documentation on host-to-realm and have not had to try it - I only researched because I considered setting it for the 2-3 hosts in the external realm and removing the TLN mapping- but here is what I think I know...
HostToRealm
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\HostToRealm
Add Key for the Realm Name (myrealm.com)
Add Value SPNMappings (REG_MULTI_SZ)
Values = names to forward to the other realm
*. myrealm.com
weblogin. myrealm.com
-Ross
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Crosby, Damian
Sent: Thursday, February 04, 2010 3:32 AM
To: activedir@mail.activedir.org
Subject: [ActiveDir] Name Suffix Routing and a Realm Trust
Hi.
Working on getting xrealm authentication working between our Window Forest and our Kerberos Realm
If I want to get xrealm authentication working between the above I have created a transitive realm trust between the forest root domain and our Kerberos realm I have added a TLN suffix to allow Kerberos referrals to walk the trust path to get the appropriate TGT. This is working well in my test environment.
My question is really about our production environment which is slightly more complex in terms of trusts and realnames and dns domain names and I am concerned that if I add the incorrect TLN I may cause Kerberos to fail intra forest.
In terms of structure
* Forest root domain xy.com
* Child domain ab.xy.com
* Kerberos Realm myrealm.com
* DNS domain name xy.com
We have delegation with namespace overlap ie the Windows 2003 Forest uses the same DNS domain name (xy.com) as the one hosted on the legacy DNS. In this scenario we delegate the specific windows sub domains from legacy DNS to Windows DNS servers (typically DC's) including _msdcs, _sites, _tcp, _udp, etc etc. Child domains within the forest are also delegated.
if I want to access http://myapache.xy.com to route this appropriately I could use netdom.exe trust XY.COM /domain:myrealm.com /addtln:xy.com but I am concerned this will cause a name routing clash. Would anyone be able to help elaborate on how name suffixes are handled when using a realm trust
Unfortunately my test environment does not suffer from the same DNS namespace overlap so I cant test with any degree of certainty..
Thanks.
Damian.
________________________________
NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law.
________________________________
NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law.
| | | |
| decrosby
Posts:64
| | 02/04/2010 4:06 PM |
| That's what I would surmise and thus preserve Kerberos within the forest. I have some time with MSFT on this so I will ask the question.
Do you see this working in your environment today?
Thanks.
Damian.
________________________________
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Wilper, Ross A
Sent: 04 February 2010 15:56
To: Wilper, Ross A; activedir@mail.activedir.org
Subject: RE: [ActiveDir] Name Suffix Routing and a Realm Trust
"over"... darn typo
-Ross
From: Wilper, Ross A
Sent: Thursday, February 04, 2010 7:55 AM
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Name Suffix Routing and a Realm Trust
If the SPN is in Active Directory, the GC lookup will win or the TLN mapping.
-Ross
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Crosby, Damian
Sent: Thursday, February 04, 2010 7:50 AM
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Name Suffix Routing and a Realm Trust
Thanks Ross.
This doesn't scale particularly well and I have indeed tested this.
My concern is really what you have stated below
When you set a TLN on a forest trust, the active directory will refer all ticket requests with the suffix to follow that trust
what happens when a SPN needs to be resolved for to a principal in the forest with the valid FQDN of xy.com? Will AD try and route it over the trust or will it resolve it within the forest first via a GC lookup and stop. I am unclear on how this clash will be handled via the GC's and TDO objects within the forest.
Thanks.
Damian.
________________________________
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Wilper, Ross A
Sent: 04 February 2010 15:36
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Name Suffix Routing and a Realm Trust
This is similar to our cross-realm situation, though in our case, the Non-AD realm has the same name as our dns zone.
The important thing is host-to-realm mapping. Windows clients use Active Directory lookups for host-to-realm mapping by default, but specific mappings can be set in the clients' registry.
When you set a TLN on a forest trust, the active directory will refer all ticket requests with the suffix to follow that trust. AD will fail to map any that it both doesn't know and has no TLN for.
In our case, this meant that every computer that fails to register it's SPN properly gets forwarded across and fails.
In your case, this most likely means that host-to-realm registry will need to be set on any client that needs to get tickets to hosts in the exterior realm.
I have not found any good documentation on host-to-realm and have not had to try it - I only researched because I considered setting it for the 2-3 hosts in the external realm and removing the TLN mapping- but here is what I think I know...
HostToRealm
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\HostToRealm
Add Key for the Realm Name (myrealm.com)
Add Value SPNMappings (REG_MULTI_SZ)
Values = names to forward to the other realm
*. myrealm.com
weblogin. myrealm.com
-Ross
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Crosby, Damian
Sent: Thursday, February 04, 2010 3:32 AM
To: activedir@mail.activedir.org
Subject: [ActiveDir] Name Suffix Routing and a Realm Trust
Hi.
Working on getting xrealm authentication working between our Window Forest and our Kerberos Realm
If I want to get xrealm authentication working between the above I have created a transitive realm trust between the forest root domain and our Kerberos realm I have added a TLN suffix to allow Kerberos referrals to walk the trust path to get the appropriate TGT. This is working well in my test environment.
My question is really about our production environment which is slightly more complex in terms of trusts and realnames and dns domain names and I am concerned that if I add the incorrect TLN I may cause Kerberos to fail intra forest.
In terms of structure
* Forest root domain xy.com
* Child domain ab.xy.com
* Kerberos Realm myrealm.com
* DNS domain name xy.com
We have delegation with namespace overlap ie the Windows 2003 Forest uses the same DNS domain name (xy.com) as the one hosted on the legacy DNS. In this scenario we delegate the specific windows sub domains from legacy DNS to Windows DNS servers (typically DC's) including _msdcs, _sites, _tcp, _udp, etc etc. Child domains within the forest are also delegated.
if I want to access http://myapache.xy.com to route this appropriately I could use netdom.exe trust XY.COM /domain:myrealm.com /addtln:xy.com but I am concerned this will cause a name routing clash. Would anyone be able to help elaborate on how name suffixes are handled when using a realm trust
Unfortunately my test environment does not suffer from the same DNS namespace overlap so I cant test with any degree of certainty..
Thanks.
Damian.
________________________________
NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law.
________________________________
NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law.
--------------------------------------------------------------------------
NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law.
| | | |
| rwilper
Posts:20
| | 02/04/2010 4:56 PM |
| Yes.
Re-reading your original post more clearly your situation is more identical to my own than I had first understood.
Windows domain machine xx.xy.com would have an SPN and would get HostToRealm to the AD
External realm machine yy.xy.com would not have an SPN, so the *.xy.com TLN mapping would trigger the forward.
Again, if windows domain machine fails to register a SPN (or no manually created SPN for HTTP/ for an LB web site service account, Clusters, etc.) then they will break.
-Ross
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Crosby, Damian
Sent: Thursday, February 04, 2010 8:06 AM
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Name Suffix Routing and a Realm Trust
That's what I would surmise and thus preserve Kerberos within the forest. I have some time with MSFT on this so I will ask the question.
Do you see this working in your environment today?
Thanks.
Damian.
________________________________
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Wilper, Ross A
Sent: 04 February 2010 15:56
To: Wilper, Ross A; activedir@mail.activedir.org
Subject: RE: [ActiveDir] Name Suffix Routing and a Realm Trust
"over"... darn typo
-Ross
From: Wilper, Ross A
Sent: Thursday, February 04, 2010 7:55 AM
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Name Suffix Routing and a Realm Trust
If the SPN is in Active Directory, the GC lookup will win or the TLN mapping.
-Ross
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Crosby, Damian
Sent: Thursday, February 04, 2010 7:50 AM
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Name Suffix Routing and a Realm Trust
Thanks Ross.
This doesn't scale particularly well and I have indeed tested this.
My concern is really what you have stated below
When you set a TLN on a forest trust, the active directory will refer all ticket requests with the suffix to follow that trust
what happens when a SPN needs to be resolved for to a principal in the forest with the valid FQDN of xy.com? Will AD try and route it over the trust or will it resolve it within the forest first via a GC lookup and stop. I am unclear on how this clash will be handled via the GC's and TDO objects within the forest.
Thanks.
Damian.
________________________________
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Wilper, Ross A
Sent: 04 February 2010 15:36
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Name Suffix Routing and a Realm Trust
This is similar to our cross-realm situation, though in our case, the Non-AD realm has the same name as our dns zone.
The important thing is host-to-realm mapping. Windows clients use Active Directory lookups for host-to-realm mapping by default, but specific mappings can be set in the clients' registry.
When you set a TLN on a forest trust, the active directory will refer all ticket requests with the suffix to follow that trust. AD will fail to map any that it both doesn't know and has no TLN for.
In our case, this meant that every computer that fails to register it's SPN properly gets forwarded across and fails.
In your case, this most likely means that host-to-realm registry will need to be set on any client that needs to get tickets to hosts in the exterior realm.
I have not found any good documentation on host-to-realm and have not had to try it - I only researched because I considered setting it for the 2-3 hosts in the external realm and removing the TLN mapping- but here is what I think I know...
HostToRealm
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\HostToRealm
Add Key for the Realm Name (myrealm.com)
Add Value SPNMappings (REG_MULTI_SZ)
Values = names to forward to the other realm
*. myrealm.com
weblogin. myrealm.com
-Ross
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Crosby, Damian
Sent: Thursday, February 04, 2010 3:32 AM
To: activedir@mail.activedir.org
Subject: [ActiveDir] Name Suffix Routing and a Realm Trust
Hi.
Working on getting xrealm authentication working between our Window Forest and our Kerberos Realm
If I want to get xrealm authentication working between the above I have created a transitive realm trust between the forest root domain and our Kerberos realm I have added a TLN suffix to allow Kerberos referrals to walk the trust path to get the appropriate TGT. This is working well in my test environment.
My question is really about our production environment which is slightly more complex in terms of trusts and realnames and dns domain names and I am concerned that if I add the incorrect TLN I may cause Kerberos to fail intra forest.
In terms of structure
* Forest root domain xy.com
* Child domain ab.xy.com
* Kerberos Realm myrealm.com
* DNS domain name xy.com
We have delegation with namespace overlap ie the Windows 2003 Forest uses the same DNS domain name (xy.com) as the one hosted on the legacy DNS. In this scenario we delegate the specific windows sub domains from legacy DNS to Windows DNS servers (typically DC's) including _msdcs, _sites, _tcp, _udp, etc etc. Child domains within the forest are also delegated.
if I want to access http://myapache.xy.com to route this appropriately I could use netdom.exe trust XY.COM /domain:myrealm.com /addtln:xy.com but I am concerned this will cause a name routing clash. Would anyone be able to help elaborate on how name suffixes are handled when using a realm trust
Unfortunately my test environment does not suffer from the same DNS namespace overlap so I cant test with any degree of certainty..
Thanks.
Damian.
________________________________
NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law.
________________________________
NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law.
________________________________
NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law.
| | | |
| barkills
Posts:128
| | 02/08/2010 5:38 PM |
| I'll throw in that I have seen inconsistent behavior when there is an overlap with the external Kerberos realm namespace and a Windows domain host when you add domain/forest trusts into the mix.
So in the context of the examples used, forest root domain xy.com has an incoming 1-way forest trust from pq.xy.com. A Windows domain host in pq.xy.com wants to get to a Windows domain host zz.myrealm.com which is a domain member of xy.com. And xy.com has a Kerberos realm trust with myrealm.com.
I've never bothered to try and isolate the specifics of when this scenario works and when it doesn't, but I know I've seen both success and failure. My assumption is that the Kerberos realm trust is sometimes preferred. My workaround has always been to tell folks not to name their Windows domain hosts zz.myrealm.com. 
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Wilper, Ross A
Sent: Thursday, February 04, 2010 8:54 AM
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Name Suffix Routing and a Realm Trust
Yes.
Re-reading your original post more clearly your situation is more identical to my own than I had first understood.
Windows domain machine xx.xy.com would have an SPN and would get HostToRealm to the AD
External realm machine yy.xy.com would not have an SPN, so the *.xy.com TLN mapping would trigger the forward.
Again, if windows domain machine fails to register a SPN (or no manually created SPN for HTTP/ for an LB web site service account, Clusters, etc.) then they will break.
-Ross
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Crosby, Damian
Sent: Thursday, February 04, 2010 8:06 AM
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Name Suffix Routing and a Realm Trust
That's what I would surmise and thus preserve Kerberos within the forest. I have some time with MSFT on this so I will ask the question.
Do you see this working in your environment today?
Thanks.
Damian.
________________________________
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Wilper, Ross A
Sent: 04 February 2010 15:56
To: Wilper, Ross A; activedir@mail.activedir.org
Subject: RE: [ActiveDir] Name Suffix Routing and a Realm Trust
"over"... darn typo
-Ross
From: Wilper, Ross A
Sent: Thursday, February 04, 2010 7:55 AM
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Name Suffix Routing and a Realm Trust
If the SPN is in Active Directory, the GC lookup will win or the TLN mapping.
-Ross
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Crosby, Damian
Sent: Thursday, February 04, 2010 7:50 AM
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Name Suffix Routing and a Realm Trust
Thanks Ross.
This doesn't scale particularly well and I have indeed tested this.
My concern is really what you have stated below
When you set a TLN on a forest trust, the active directory will refer all ticket requests with the suffix to follow that trust
what happens when a SPN needs to be resolved for to a principal in the forest with the valid FQDN of xy.com? Will AD try and route it over the trust or will it resolve it within the forest first via a GC lookup and stop. I am unclear on how this clash will be handled via the GC's and TDO objects within the forest.
Thanks.
Damian.
________________________________
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Wilper, Ross A
Sent: 04 February 2010 15:36
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Name Suffix Routing and a Realm Trust
This is similar to our cross-realm situation, though in our case, the Non-AD realm has the same name as our dns zone.
The important thing is host-to-realm mapping. Windows clients use Active Directory lookups for host-to-realm mapping by default, but specific mappings can be set in the clients' registry.
When you set a TLN on a forest trust, the active directory will refer all ticket requests with the suffix to follow that trust. AD will fail to map any that it both doesn't know and has no TLN for.
In our case, this meant that every computer that fails to register it's SPN properly gets forwarded across and fails.
In your case, this most likely means that host-to-realm registry will need to be set on any client that needs to get tickets to hosts in the exterior realm.
I have not found any good documentation on host-to-realm and have not had to try it - I only researched because I considered setting it for the 2-3 hosts in the external realm and removing the TLN mapping- but here is what I think I know...
HostToRealm
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\HostToRealm
Add Key for the Realm Name (myrealm.com)
Add Value SPNMappings (REG_MULTI_SZ)
Values = names to forward to the other realm
*. myrealm.com
weblogin. myrealm.com
-Ross
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Crosby, Damian
Sent: Thursday, February 04, 2010 3:32 AM
To: activedir@mail.activedir.org
Subject: [ActiveDir] Name Suffix Routing and a Realm Trust
Hi.
Working on getting xrealm authentication working between our Window Forest and our Kerberos Realm
If I want to get xrealm authentication working between the above I have created a transitive realm trust between the forest root domain and our Kerberos realm I have added a TLN suffix to allow Kerberos referrals to walk the trust path to get the appropriate TGT. This is working well in my test environment.
My question is really about our production environment which is slightly more complex in terms of trusts and realnames and dns domain names and I am concerned that if I add the incorrect TLN I may cause Kerberos to fail intra forest.
In terms of structure
* Forest root domain xy.com
* Child domain ab.xy.com
* Kerberos Realm myrealm.com
* DNS domain name xy.com
We have delegation with namespace overlap ie the Windows 2003 Forest uses the same DNS domain name (xy.com) as the one hosted on the legacy DNS. In this scenario we delegate the specific windows sub domains from legacy DNS to Windows DNS servers (typically DC's) including _msdcs, _sites, _tcp, _udp, etc etc. Child domains within the forest are also delegated.
if I want to access http://myapache.xy.com to route this appropriately I could use netdom.exe trust XY.COM /domain:myrealm.com /addtln:xy.com but I am concerned this will cause a name routing clash. Would anyone be able to help elaborate on how name suffixes are handled when using a realm trust
Unfortunately my test environment does not suffer from the same DNS namespace overlap so I cant test with any degree of certainty..
Thanks.
Damian.
________________________________
NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law.
________________________________
NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law.
________________________________
NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law.
| | | |
| decrosby
Posts:64
| | 02/08/2010 5:58 PM |
| Thanks.
In our configuration where we have a clear namespace clash we fail to route across the trust. What is interesting is that subordinate references within the fqdn that have no matching reference on an existing TDO works...
In testing the only way I seem to be able to route a referral across the realm trust (Via TGT Referrals) is if the SPN I am looking for explicitly matches the TLN I have specified at the Forest Root. All ambiguous searches fail.
Host SPN TLN Success
http://server.xx.yy.zz.com<http://server.xx.yy.zz.com/> xx.yy.zz.com Yes
http://server.yy.zz.com<http://server.yy.zz.com/> xx.yy.zz.com ERR_S_PRINCIPAL_UNKNOWN
http://server.xx.yy.zz.com<http://server.xx.yy.zz.com/> yy.zz.com ERR_S_PRINCIPAL_UNKNOWN
http://server.yy.zz.com<http://server.yy.zz.com/> yy.zz.com ERR_S_PRINCIPAL_UNKNOWN
http://server.xx.yy.zz.com<http://server.xx.yy.zz.com/> zz.com ERR_S_PRINCIPAL_UNKNOWN
http://server.yy.zz.com<http://server.yy.zz.com/> zz.com ERR_S_PRINCIPAL_UNKNOWN
http://server.xx.yy.zz.com<http://server.xx.yy.zz.com/> .com ERR_S_PRINCIPAL_UNKNOWN
http://server.yy.zz.com<http://server.yy.zz.com/> .com ERR_S_PRINCIPAL_UNKNOWN
Thanks.
Damian.
________________________________
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Brian Arkills
Sent: 08 February 2010 17:34
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Name Suffix Routing and a Realm Trust
I'll throw in that I have seen inconsistent behavior when there is an overlap with the external Kerberos realm namespace and a Windows domain host when you add domain/forest trusts into the mix.
So in the context of the examples used, forest root domain xy.com has an incoming 1-way forest trust from pq.xy.com. A Windows domain host in pq.xy.com wants to get to a Windows domain host zz.myrealm.com which is a domain member of xy.com. And xy.com has a Kerberos realm trust with myrealm.com.
I've never bothered to try and isolate the specifics of when this scenario works and when it doesn't, but I know I've seen both success and failure. My assumption is that the Kerberos realm trust is sometimes preferred. My workaround has always been to tell folks not to name their Windows domain hosts zz.myrealm.com.
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Wilper, Ross A
Sent: Thursday, February 04, 2010 8:54 AM
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Name Suffix Routing and a Realm Trust
Yes.
Re-reading your original post more clearly your situation is more identical to my own than I had first understood.
Windows domain machine xx.xy.com would have an SPN and would get HostToRealm to the AD
External realm machine yy.xy.com would not have an SPN, so the *.xy.com TLN mapping would trigger the forward.
Again, if windows domain machine fails to register a SPN (or no manually created SPN for HTTP/ for an LB web site service account, Clusters, etc.) then they will break.
-Ross
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Crosby, Damian
Sent: Thursday, February 04, 2010 8:06 AM
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Name Suffix Routing and a Realm Trust
That's what I would surmise and thus preserve Kerberos within the forest. I have some time with MSFT on this so I will ask the question.
Do you see this working in your environment today?
Thanks.
Damian.
________________________________
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Wilper, Ross A
Sent: 04 February 2010 15:56
To: Wilper, Ross A; activedir@mail.activedir.org
Subject: RE: [ActiveDir] Name Suffix Routing and a Realm Trust
"over"... darn typo
-Ross
From: Wilper, Ross A
Sent: Thursday, February 04, 2010 7:55 AM
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Name Suffix Routing and a Realm Trust
If the SPN is in Active Directory, the GC lookup will win or the TLN mapping.
-Ross
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Crosby, Damian
Sent: Thursday, February 04, 2010 7:50 AM
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Name Suffix Routing and a Realm Trust
Thanks Ross.
This doesn't scale particularly well and I have indeed tested this.
My concern is really what you have stated below
When you set a TLN on a forest trust, the active directory will refer all ticket requests with the suffix to follow that trust
what happens when a SPN needs to be resolved for to a principal in the forest with the valid FQDN of xy.com? Will AD try and route it over the trust or will it resolve it within the forest first via a GC lookup and stop. I am unclear on how this clash will be handled via the GC's and TDO objects within the forest.
Thanks.
Damian.
________________________________
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Wilper, Ross A
Sent: 04 February 2010 15:36
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Name Suffix Routing and a Realm Trust
This is similar to our cross-realm situation, though in our case, the Non-AD realm has the same name as our dns zone.
The important thing is host-to-realm mapping. Windows clients use Active Directory lookups for host-to-realm mapping by default, but specific mappings can be set in the clients' registry.
When you set a TLN on a forest trust, the active directory will refer all ticket requests with the suffix to follow that trust. AD will fail to map any that it both doesn't know and has no TLN for.
In our case, this meant that every computer that fails to register it's SPN properly gets forwarded across and fails.
In your case, this most likely means that host-to-realm registry will need to be set on any client that needs to get tickets to hosts in the exterior realm.
I have not found any good documentation on host-to-realm and have not had to try it - I only researched because I considered setting it for the 2-3 hosts in the external realm and removing the TLN mapping- but here is what I think I know...
HostToRealm
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\HostToRealm
Add Key for the Realm Name (myrealm.com)
Add Value SPNMappings (REG_MULTI_SZ)
Values = names to forward to the other realm
*. myrealm.com
weblogin. myrealm.com
-Ross
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Crosby, Damian
Sent: Thursday, February 04, 2010 3:32 AM
To: activedir@mail.activedir.org
Subject: [ActiveDir] Name Suffix Routing and a Realm Trust
Hi.
Working on getting xrealm authentication working between our Window Forest and our Kerberos Realm
If I want to get xrealm authentication working between the above I have created a transitive realm trust between the forest root domain and our Kerberos realm I have added a TLN suffix to allow Kerberos referrals to walk the trust path to get the appropriate TGT. This is working well in my test environment.
My question is really about our production environment which is slightly more complex in terms of trusts and realnames and dns domain names and I am concerned that if I add the incorrect TLN I may cause Kerberos to fail intra forest.
In terms of structure
* Forest root domain xy.com
* Child domain ab.xy.com
* Kerberos Realm myrealm.com
* DNS domain name xy.com
We have delegation with namespace overlap ie the Windows 2003 Forest uses the same DNS domain name (xy.com) as the one hosted on the legacy DNS. In this scenario we delegate the specific windows sub domains from legacy DNS to Windows DNS servers (typically DC's) including _msdcs, _sites, _tcp, _udp, etc etc. Child domains within the forest are also delegated.
if I want to access http://myapache.xy.com to route this appropriately I could use netdom.exe trust XY.COM /domain:myrealm.com /addtln:xy.com but I am concerned this will cause a name routing clash. Would anyone be able to help elaborate on how name suffixes are handled when using a realm trust
Unfortunately my test environment does not suffer from the same DNS namespace overlap so I cant test with any degree of certainty..
Thanks.
Damian.
________________________________
NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law.
________________________________
NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law.
________________________________
NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law.
--------------------------------------------------------------------------
NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law.
| | | |
| decrosby
Posts:64
| | 04/27/2010 9:04 AM |
| Hi,
I thought I would retrospectively share what I have learned on this subject with the group for future information
Q. We are in the process of creating a xrealm trust between our Windows 2003 R2 AD Domain and an external MIT Realm. The user accounts will live in AD and access services in the MIT Realm.The MIT Realm is listening on non standard ports for Kerberos (ie not UDP 88). Can Windows be configured to connect to these non standard ports?
A. IE Can windows discover non Windows KDC's through the use of an SRV record that has the unique port or is that not possible.
Q. What support for HosttoRealm Mappings exist on client side OS's?
A. Windows 7 support full use of the HostToRealm Functionality using Ksetup down level OS dont
Q - Will these keys be available on XP? If not why not?
A.XP does not have the HostToRealm mapping functionality and it will not be added as it is in Extended Support nearing the end of life of support.
Q. - What's the maximum number of SPN mappings we can store in the registry?
A.I am not aware of any specific limit. I will investigate this further and get back to you.
Q. - What's the limitation / constraint that prevents us routing natively cross realm when a direct domain : realm trust is in place that these keys actually fix?
A.This limitation/constraint is not specific to Windows. In fact, within the forest you can have computer accounts with various overlapping SPNs because we use the GC to search for the computer account and will generate a referral to the proper domain in the forest should the target account be in a different domain. Since the MIT accounts are not stored in the AD we cannot use the GC for this search. So instead we rely on mapping the REALM name to a DNS suffix which by default is a match. We introduced the HostToRealm mapping entries in Vista+ to allow greater flexibility in mapping SPNs to the appropriate REALM for situations where the namespaces are overlapping or do not match. MIT does mapping in a similar way HostToRealm mapping in the krb5.conf file. You have the ability to map a specific DNS name to a realm or map a DNS suffix. So if you could partition the SPN targets of a given realm to a specific DNS suffix this would reduce the number of entries you would need to add.
TLN mappings - We created 1000 and in my limited testing it worked without issue. How many TLNs are you looking at adding?
HostToRealm mappings - This would be limited to the size constraints of the registry. Which according to: http://msdn.microsoft.com/en-us/library/ms724872(VS.85).aspx<blocked::http://msdn.microsoft.com/en-us/library/ms724872(VS.85).aspx> the limit is 1mb. If each FQDN was 20 characters long then you should be able to get just under 25 thousand entries. I would encourage you to try and minimize this for management purposes though.
Q. Would it be also possible to put a hostname as a TLN rather than a domain suffix?
A. No, the TLN would need to be a domain suffix.
Thanks.
Damian.
________________________________
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Brian Arkills
Sent: 08 February 2010 17:34
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Name Suffix Routing and a Realm Trust
I'll throw in that I have seen inconsistent behavior when there is an overlap with the external Kerberos realm namespace and a Windows domain host when you add domain/forest trusts into the mix.
So in the context of the examples used, forest root domain xy.com has an incoming 1-way forest trust from pq.xy.com. A Windows domain host in pq.xy.com wants to get to a Windows domain host zz.myrealm.com which is a domain member of xy.com. And xy.com has a Kerberos realm trust with myrealm.com.
I've never bothered to try and isolate the specifics of when this scenario works and when it doesn't, but I know I've seen both success and failure. My assumption is that the Kerberos realm trust is sometimes preferred. My workaround has always been to tell folks not to name their Windows domain hosts zz.myrealm.com.
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Wilper, Ross A
Sent: Thursday, February 04, 2010 8:54 AM
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Name Suffix Routing and a Realm Trust
Yes.
Re-reading your original post more clearly your situation is more identical to my own than I had first understood.
Windows domain machine xx.xy.com would have an SPN and would get HostToRealm to the AD
External realm machine yy.xy.com would not have an SPN, so the *.xy.com TLN mapping would trigger the forward.
Again, if windows domain machine fails to register a SPN (or no manually created SPN for HTTP/ for an LB web site service account, Clusters, etc.) then they will break.
-Ross
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Crosby, Damian
Sent: Thursday, February 04, 2010 8:06 AM
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Name Suffix Routing and a Realm Trust
That's what I would surmise and thus preserve Kerberos within the forest. I have some time with MSFT on this so I will ask the question.
Do you see this working in your environment today?
Thanks.
Damian.
________________________________
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Wilper, Ross A
Sent: 04 February 2010 15:56
To: Wilper, Ross A; activedir@mail.activedir.org
Subject: RE: [ActiveDir] Name Suffix Routing and a Realm Trust
"over"... darn typo
-Ross
From: Wilper, Ross A
Sent: Thursday, February 04, 2010 7:55 AM
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Name Suffix Routing and a Realm Trust
If the SPN is in Active Directory, the GC lookup will win or the TLN mapping.
-Ross
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Crosby, Damian
Sent: Thursday, February 04, 2010 7:50 AM
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Name Suffix Routing and a Realm Trust
Thanks Ross.
This doesn't scale particularly well and I have indeed tested this.
My concern is really what you have stated below
When you set a TLN on a forest trust, the active directory will refer all ticket requests with the suffix to follow that trust
what happens when a SPN needs to be resolved for to a principal in the forest with the valid FQDN of xy.com? Will AD try and route it over the trust or will it resolve it within the forest first via a GC lookup and stop. I am unclear on how this clash will be handled via the GC's and TDO objects within the forest.
Thanks.
Damian.
________________________________
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Wilper, Ross A
Sent: 04 February 2010 15:36
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Name Suffix Routing and a Realm Trust
This is similar to our cross-realm situation, though in our case, the Non-AD realm has the same name as our dns zone.
The important thing is host-to-realm mapping. Windows clients use Active Directory lookups for host-to-realm mapping by default, but specific mappings can be set in the clients' registry.
When you set a TLN on a forest trust, the active directory will refer all ticket requests with the suffix to follow that trust. AD will fail to map any that it both doesn't know and has no TLN for.
In our case, this meant that every computer that fails to register it's SPN properly gets forwarded across and fails.
In your case, this most likely means that host-to-realm registry will need to be set on any client that needs to get tickets to hosts in the exterior realm.
I have not found any good documentation on host-to-realm and have not had to try it - I only researched because I considered setting it for the 2-3 hosts in the external realm and removing the TLN mapping- but here is what I think I know...
HostToRealm
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\HostToRealm
Add Key for the Realm Name (myrealm.com)
Add Value SPNMappings (REG_MULTI_SZ)
Values = names to forward to the other realm
*. myrealm.com
weblogin. myrealm.com
-Ross
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Crosby, Damian
Sent: Thursday, February 04, 2010 3:32 AM
To: activedir@mail.activedir.org
Subject: [ActiveDir] Name Suffix Routing and a Realm Trust
Hi.
Working on getting xrealm authentication working between our Window Forest and our Kerberos Realm
If I want to get xrealm authentication working between the above I have created a transitive realm trust between the forest root domain and our Kerberos realm I have added a TLN suffix to allow Kerberos referrals to walk the trust path to get the appropriate TGT. This is working well in my test environment.
My question is really about our production environment which is slightly more complex in terms of trusts and realnames and dns domain names and I am concerned that if I add the incorrect TLN I may cause Kerberos to fail intra forest.
In terms of structure
* Forest root domain xy.com
* Child domain ab.xy.com
* Kerberos Realm myrealm.com
* DNS domain name xy.com
We have delegation with namespace overlap ie the Windows 2003 Forest uses the same DNS domain name (xy.com) as the one hosted on the legacy DNS. In this scenario we delegate the specific windows sub domains from legacy DNS to Windows DNS servers (typically DC's) including _msdcs, _sites, _tcp, _udp, etc etc. Child domains within the forest are also delegated.
if I want to access http://myapache.xy.com to route this appropriately I could use netdom.exe trust XY.COM /domain:myrealm.com /addtln:xy.com but I am concerned this will cause a name routing clash. Would anyone be able to help elaborate on how name suffixes are handled when using a realm trust
Unfortunately my test environment does not suffer from the same DNS namespace overlap so I cant test with any degree of certainty..
Thanks.
Damian.
________________________________
NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law.
________________________________
NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law.
________________________________
NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law.
--------------------------------------------------------------------------
NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law.
| | | |
|
|