RE: [ActiveDir] Cross forest trust and DNS

[Tony Murray]

Agreed, although it’s nice to have a documented model to hand alongside the testing, as there are sometimes environmental variables that could skew the results.   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bernard, Aric Sent: Wednesday, 14 December 2005 2:39 p.m. To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Cross forest trust and DNS   A network monitor and a test environment is often better than any other source. J   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony Murray Sent: Tuesday, December 13, 2005 5:26 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Cross forest trust and DNS   Thanks very much for the detailed information Bernard.  Good point about the site sync too.   Where did you find the information?  Is it hidden in a safe somewhere within HP, or is it publicly available? J  My Google mojo let me down on this one.   Tony   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bernard, Aric Sent: Wednesday, 14 December 2005 1:59 p.m. To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Cross forest trust and DNS   More information…   The DNS interactions work as follows (note that I have excluded most other transactions that occur):   Forest A client queries DNS for ResourceServer.ForestB.com Client receives response for resource server. Client queries for _kerberos._tcp.ClientSiteName._sites.dc._msdcs.ForestB.com. Assuming that sites are not synced between forests, or more specifically that the clients site does not exist in ForestB, the query fails (Name does not exist). Client queries for _kerberos._tcp.dc._msdcs.ForestB.com. This is equal to a request for “any” KDC in ForestB. Client will receive a response for all KDCs registered in _kerberos._tcp.dc._msdcs.ForestB.com for ForestB. Client attempts to contact KDC based on the ordered response were returned from DNS. I attempt fails client will attempt to contact the next KDC based on the ordered response were returned from DNS.   As you have already concluded, tweaking what priority of the SRV records is the best way to ensure that the proper DC/KDCs are tried first.  When attempting to contact a non-accessible DC/KDC, the failover/timeout process is very quick.  Syncing your sites will not necessarily help anything unless the client (forest A) in question belongs to the same site (name) that the DC in forest B does.   Regards   Aric   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony Murray Sent: Tuesday, December 13, 2005 2:00 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Cross forest trust and DNS   Thanks Jorge and Deji for your responses.   It sounds like we’re all pretty much of the same opinion, i.e. that there will be a sequence of attempts against a list of DCs in Forest B.   It would still be good to understand the how the DNS interactions work in this situation.  I’ve searched around for documentation, but with no success so far.   Tweaking the DC locator records for the DCs in the Forest B domain sounds like an interesting idea.  I suspect some adjustmens to SRV priority might do the trick.  As you indicate, I would need to find a way of doing this such that it doesn’t impact anything else.   Tony   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, Jorge de Sent: Wednesday, 14 December 2005 9:39 a.m. To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Cross forest trust and DNS   I would think the client receives a list of referrals and use the DC on top of the list and goes down the list until it finds a DC that responds. A client simply does not know why a certain DC does not respond. It can be anything... firewall, network, DC down or whatever. As there is no sites and subnets synchronization in place yet the DC retrieving the referral does not know in which site to query for a DC, it will query for the DCs in a certain domain. Do you have the possibility to tweak the registration of domain wide DC locator records for the DCs in forest B that are not reachable (taking into account that it does not impact services in forest B)   Cheers, Jorge   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony Murray Sent: Monday, December 12, 2005 22:09 To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Cross forest trust and DNS Hi all   Need a bit of help with this one.  Here’s the scenario.   Two Windows Server 2003 forests federated with a cross forest trust.  Forest A has 4 DCs, all of which are reachable from Forest B.  Forest B has approx. 30 DC, of which only those in main site (10) are reachable from Forest A’s network.  There is no site and subnet synchronisation in place.    My concern is that not all the DCs in Forest B are reachable from Forest A ((because network routes are only in place to the main site).  DNS secondary zones are being used and these obviously contain information about the unreachable DCs in Forest B.  What happens when a client in Forest A need to access a resource in Forest B?  The routing of Kerberos authentication requires DNS lookups for DCs in Forest B.  If the client in Forest A receives a referral to an unreachable DC in Forest B, does the request simply fail or is there some built-in intelligent retry mechanism?  In other words will the client in Forest A eventually be referred to a reachable DC?   I realise there are long term solutions to this (site and subnet synchronisation, the addition of network routes), but I am keen to understand the DNS interactions so I can determine whether this will work in the short term.   Tony     This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.   This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.