$Id: domain.txt,v 1.1.1.1 2003/02/25 19:35:05 wcw Exp $ --------- ChangeLog --------- 0.1 - 03/20/02 - Initial version 0.2 - 03/22/02 - revisions for WINDOWS-FOREST -> WIN 0.3 - 04/02/02 - split out Andrew and other higher level domain issues specific information to separate documents. 0.4 - 04/29/02 - rjy requests we change the registration process. ------------ 1.0 Overview ------------ This document describes the naming of the Windows Active Directory forests in the existing DNS domain naming system. Described below are a) How domains are named b) How machines are registered c) How to set up a new domain Please keep in mind that a Windows forest is composed of one or more Windows domains. Active Directory uses DNS to specify domains and implicit forest boundaries. See Appendix A for examples. ------------------------- 2.0 Windows Forest Naming ------------------------- Computing Services will provide a "empty root" top level for Windows Active Directory forests. All Windows Active Directory Forests (and thereby all Windows 2000 and newer domains) will be created under this root. The name of the toplevel is WIN.CMU.EDU. For example, the forest supported by Computing Services is named ANDREW and so the full name of the forest is ANDREW.WIN.CMU.EDU. This empty domain is hosted by Computing Services' production BIND9 servers. Servers exist in both Wean and Cyert Hall. ---------------------------- 2.0 Registering your machine ---------------------------- Registering your machine is basically the same process. The only difference is that you will select the full name of the forest as the DNS domain name. For example, if your machine's short name is "DELLPC" and your forest name is "ANDREW.WIN.CMU.EDU", you would enter in "DELLPC" in the short name box in Netreg and then select ANDREW.WIN.CMU.EDU as the DNS domain name. NOTE: Computers within an OU do not have a different DNS domain name. The DNS domain name only changes if you are in a different Windows domain/forest. All machines in a Windows forest should have the correct domain name as its suffix. If you do not, there may be interoperability problems. Additional functionality is provided for machines that join the ANDREW Windows forest. This functionality is described in xxxANDREW FEATURESxxx. -------------------------------- 4.0 Creating a Standalone Forest -------------------------------- Please refer to xxxFOREST DOCUMENTxxx to help decide whether or not you need to create your own forest. If you do need to create your own standalone forest, you will need to perform the following steps: 1. Email advisor+@andrew.cmu.edu with a request for the name forest. e.g. EXAMPLE.WIN.CMU.EDU. You may also specify a list of people or groups that should have the ability to register a machine in it. 2. Wait until you get confirmation that the forest is created. 3. Register the domain controller(s) in Netreg and set the DNS domain name of the domain controllers to the newly created DNS domain. e.g. EXAMPLE.WIN.CMU.EDU 4. Email advisor+@andrew.cmu.edu with the names of the domain controllers so that the Network Group can set the appropriate ACLs on the DDNS zone. 5. After getting confirmation that step 4 is complete, You can promote the machines to be domain controllers. When prompted for the domain name, use the full name of the forest, e.g. EXAMPLE.WIN.CMU.EDU ** If the domain controller's IP address changes or you need to add or remove machines that are domain controllers, you must notify advisor@andrew.cmu.edu beforehand or problems may arise with your domain. ** All client machines should also have the DNS domain name of the forest, e.g. EXAMPLE.WIN.CMU.EDU. ------------------------------- 5.0 Background on Naming Issues ------------------------------- The domain naming issue is complicated by a few factors. The initial approach was to create WINDOWS-FOREST.CMU.EDU as a top level DDNS zone. Domains would be created in WINDOWS-FOREST.CMU.EDU as in WIN.CMU.EDU; however, machines would not advertise or normally use the WINDOWS-FOREST.CMU.EDU name. Only domain controllers for internal Windows functions would use the WINDOWS-FOREST.CMU.EDU name. The name was intentionally chosen to be long to discourage its use. All machines in the domain would then have the "domain" name (e.g. M1.EXAMPLE.WINDOWS-FOREST.CMU.EDU) and a "netreg" name (e.g. M1.EXAMPLE.CMU.EDU). The problem with this comes in with Unix interoperability. Given the vagueness in the Kerberos/GSSAPI specifications , there were problems with choosing the correct name for the service principal. In particular, one implementation would take the IP address of the host it was trying to connect to and do a reverse DNS lookup. The reverse DNS look up provided the "netreg" name. However, the servers had the "domain" name and so no service principal was found. A way to work around some of these problems is by creating a specific service pricipal name (SPN) with the "netreg" name. Stanford takes this approach (see http://windows.stanford.edu/docs/CompJoin.htm#SPN for details). However, there are still problems with using just the "netreg" name and adding the SPN. Kerberos implementations use DNS suffixes to determine Kerberos realms. So using the "netreg" name could then result in two machines with the same DNS suffix but be in two different Kerberos realms. Thus, clients connecting to these machines would have difficulty determining which was the correct Kerberos realm to use. Another naming question is why have the 'WIN' part of the name instead of just having machines register in the current DNS third level zone. In the case of Andrew, we already have a Kerberos realm of the name of ANDREW.CMU.EDU and we are currently unwilling to switch our Kerberos infrastructure to be hosted on Windows. Other reasons for having the WIN third level domain include: a) We would need to provide DDNS for all domains under CMU.EDU and we are not ready for that yet. b) There is still the DNS suffix conflict if you have Andrew machines in your domain. c) This provides us more flexibility in case new information requires us to change yet again. --------------- 6.0 Dynamic DNS --------------- 6.1 Overview ------------ Windows Active Directory forests extensively use DNS as a mechanism for locating resources. Some of the information encoded in the DNS is very specific to a domain and so it would be extremely difficult for Computing Services to pre-populate the information in the central DNS for any arbitrary domain. Given the difficulty in prepopulating and maintaining this information, Microsoft uses Dynamic DNS to automatically populate and maintain the necessary information for running a forest. Microsoft also provides a means where the DNS data is automatically stored to a file and can then be manually loaded into a DNS server at a later date. Our evaluation of using this file is that it would likely be very difficult to keep this file in sync with Netreg and debugging problems could also be problematic. 6.2 Security ------------ Microsoft has a mechanism for doing secure DDNS updates. We are guessing it is using the host key of the machine doing the updates but need to investigate this more. The protocol on the wire is defined in draft-ietf-dns-gss-tsig-05 and the draft has been submitted to IESG last call. Unfortunately, it not seem to be clear enough to actually implement to. Larry posted a follow-up question. Kevin is looking at the BIND9 code. The current method of security would be to create a zone for the domain and only allow the domain controllers to make dynamic updates. This isn't great security given that IP addresses can be forged but until BIND9 supports the draft described above, we either do this or run Microsoft DNS servers. I also can't think of any attack that is made worse with the ability to change the dynamic DNS registration information. Clearly there are DoS attacks and man in the middle but it is unclear this makes it worse or significantly easier. ----------------------------------- Appendix A: Windows Forests and DNS ----------------------------------- Windows Active Directory takes advantage of the DNS naming conventions to indicate domains and forests. Let's take the following DNS names as examples: FOO.BAR.EXAMPLE.COM BAZ.BAR.EXAMPLE.COM OOK.ACK.EXAMPLE.COM ICK.ACK.EXAMPLE.COM The DNS name by itself is not enough of an indicator of domain and forest boundaries lie. So if all we are given is the following list of names, ANY of the following are valid assumptions: 1) There is one forest named EXAMPLE.COM and all the other names are domains within EXAMPLE.COM 2) All domains specified above are independent forests. 3) FOO and BAZ are sub domains of BAR in the forest BAR.EXAMPLE.COM. Ditto with OOK and ICK. The DNS name DOES define the domain boundaries. Thus there can not be two domains using the same DNS zone name. Forests can have explicit mappings between different DNS names as well. However, OUs in any of these domains are NOT exposed in the DNS name.