I'm not sure that there are additional DNS related pieces of the equation, not documented by Gil.
The process is more of a referral than a DNS lookup per se, as per the steps below. i.e. the client always talks to a DC in its own domain, which then talks to a DC in the other forest. [I believe the DC will talk to any DC in the other forest, unless sites/subnets are synced. If the other DC is down, then the first DC will re-home to another DC.] Further detail is contained in the doc below, IIRC. I'll let someone who knows more about this fill in any gaps or correct me :) neil -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony Murray Sent: 14 December 2005 09:12 To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Cross forest trust and DNS Thanks Jorge I was aware of these. The provide good detail, but both of them assume that the DCs in the second forest to which referrals are made are available. For example, 5. Workstation1 contacts a domain controller in ForestRootDC1 (its parent domain) for a referral to a domain controller (ForestRootDC2) in the forest root domain of the msn.com forest. 6. Workstation1 contacts ForestRootDC2 in the msn.com forest for a service ticket to the requested service. Gil Kirkpatrick once wrote an excellent article on Authentication Topology (http://www.netpro.com/forum/files/authentication_topology.pdf), which showed (among other things) the sequence of DNS interactions for client location of DC and authentication. I was hoping to find something similar for the cross forest DNS interactions. Cheers Tony ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, Jorge de Sent: Wednesday, 14 December 2005 8:25 p.m. To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Cross forest trust and DNS Tony, Found the following documents. I think this is what you were looking for Planning and Implementing Federated Forests in Windows Server2003 http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technolog ies/ directory/activedirectory/fedffin2.mspx Look for the section called "Routing of Kerberos Authentication" Accessing resources across forests http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/S erve rHelp/517b4fa4-5266-419c-9791-6fb56fabb85e.mspx Cheers, Jorge ________________________________ From: [EMAIL PROTECTED] on behalf of Tony Murray Sent: Wed 12/14/2005 3:46 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Cross forest trust and DNS 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): 1. Forest A client queries DNS for ResourceServer.ForestB.com 2. Client receives response for resource server. 3. Client queries for _kerberos._tcp.ClientSiteName._sites.dc._msdcs.ForestB.com. 4. 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). 5. Client queries for _kerberos._tcp.dc._msdcs.ForestB.com. This is equal to a request for "any" KDC in ForestB. 6. Client will receive a response for all KDCs registered in _kerberos._tcp.dc._msdcs.ForestB.com for ForestB. 7. Client attempts to contact KDC based on the ordered response were returned from DNS. 8. 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. List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ PLEASE READ: The information contained in this email is confidential and intended for the named recipient(s) only. If you are not an intended recipient of this email please notify the sender immediately and delete your copy from your system. You must not copy, distribute or take any further action in reliance on it. Email is not a secure method of communication and Nomura International plc ('NIplc') will not, to the extent permitted by law, accept responsibility or liability for (a) the accuracy or completeness of, or (b) the presence of any virus, worm or similar malicious or disabling code in, this message or any attachment(s) to it. If verification of this email is sought then please request a hard copy. Unless otherwise stated this email: (1) is not, and should not be treated or relied upon as, investment research; (2) contains views or opinions that are solely those of the author and do not necessarily represent those of NIplc; (3) is intended for informational purposes only and is not a recommendation, solicitation or offer to buy or sell securities or related financial instruments. NIplc does not provide investment services to private customers. Authorised and regulated by the Financial Services Authority. Registered in England no. 1550505 VAT No. 447 2492 35. Registered Office: 1 St Martin's-le-Grand, London, EC1A 4NP. A member of the Nomura group of companies. List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
