• Chapter 1. Installing and Configuring Windows Server 2003
  • software development Company Server 2003
  • Chapter 1. Installing and Configuring Windows Server 2003
  • New Features in Windows Server 2003
  • Best Practices
  • Moving Forward
  • Version Comparisons
  • Hardware Recommendations
  • Installation Checklist
  • Functional Overview of Windows Server 2003 Setup
  • Installing Windows Server 2003
  • Post Setup Configurations
  • Functional Description of the Windows Server 2003 Boot Process
  • Correcting Common Setup Problems
  • Chapter 2. Performing Upgrades and Automated Installations
  • New Features in Windows Server 2003
  • NT4 Upgrade Functional Overview
  • Upgrading an NT4 or Windows 2000 Server
  • Automating Windows Server 2003 Deployments
  • Moving Forward
  • Chapter 3. Adding Hardware
  • New Features in Windows Server 2003
  • Functional Description of Windows Server 2003 Architecture
  • Overview of Windows Server 2003 Plug and Play
  • Installing and Configuring Devices
  • Troubleshooting New Devices
  • Moving Forward
  • Chapter 4. Managing NetBIOS Name Resolution
  • New Features in Windows Server 2003
  • Moving Forward
  • Overview of Windows Server 2003 Networking
  • Name Resolution and Network Services
  • Network Diagnostic Utilities
  • Resolving NetBIOS Names Using Broadcasts
  • Resolving NetBIOS Names Using Lmhosts
  • Resolving NetBIOS Names Using WINS
  • Managing WINS
  • Disabling NetBIOS-over-TCP/IP Name Resolution
  • Chapter 5. Managing DNS
  • New Features in Windows Server 2003
  • Configuring a Caching-Only Server
  • Configuring a DNS Server to Use a Forwarder
  • Managing Dynamic DNS
  • Configuring Advanced DNS Server Parameters
  • Examining Zones with Nslookup
  • Command-Line Management of DNS
  • Configuring DHCP to Support DNS
  • Moving Forward
  • Overview of DNS Domain Structure
  • Functional Description of DNS Query Handling
  • Designing DNS Domains
  • Active Directory Integration
  • Configuring DNS Clients
  • Installing and Configuring DNS Servers
  • Configuring Secondary DNS Servers
  • Integrating DNS Zones into Active Directory
  • Chapter 6. Understanding Active Directory Services
  • New Features in Windows Server 2003
  • Active Directory Support Files
  • Active Directory Utilities
  • Bulk Imports and Exports
  • Moving Forward
  • Limitations of Classic NT Security
  • Directory Service Components
  • Brief History of Directory Services
  • X.500 Overview
  • LDAP Information Model
  • LDAP Namespace Structure
  • Active Directory Namespace Structure
  • Active Directory Schema
  • Chapter 7. Managing Active Directory Replication
  • New Features in Windows Server 2003
  • Replication Overview
  • Detailed Replication Transaction Descriptions
  • Designing Site Architectures
  • Configuring Inter-site Replication
  • Controlling Replication Parameters
  • Special Replication Operations
  • Troubleshooting Replication Problems
  • Moving Forward
  • Chapter 8. Designing Windows Server 2003 Domains
  • New Features in Windows Server 2003
  • Design Objectives
  • DNS and Active Directory Namespaces
  • Domain Design Strategies
  • Strategies for OU Design
  • Flexible Single Master Operations
  • Domain Controller Placement
  • Moving Forward
  • Chapter 9. Deploying Windows Server 2003 Domains
  • New Features in Windows Server 2003
  • Preparing for an NT Domain Upgrade
  • In-Place Upgrade of an NT4 Domain
  • In-Place Upgrade of a Windows 2000 Forest
  • Migrating from NT and Windows 2000 Domains to Windows Server 2003
  • Additional Domain Operations
  • Moving Forward
  • Chapter 10. Active Directory Maintenance
  • New Features in Windows Server 2003
  • Loss of a DNS Server
  • Loss of a Domain Controller
  • Loss of Key Replication Components
  • Backing Up the Directory
  • Performing Directory Maintenance
  • Moving Forward
  • Chapter 11. Understanding Network Access Security and Kerberos
  • New Features in Windows Server 2003
  • Windows Server 2003 Security Architecture
  • Security Components
  • Password Security
  • Authentication
  • Analysis of Kerberos Transactions
  • MITv5 Kerberos Interoperability
  • Security Auditing
  • Moving Forward
  • Chapter 12. Managing Group Policies
  • New Features in Windows Server 2003
  • Group Policy Operational Overview
  • Managing Individual Group Policy Types
  • Moving Forward
  • Chapter 13. Managing Active Directory Security
  • New Features in Windows Server 2003
  • Overview of Active Directory Security
  • Using Groups to Manage Active Directory Objects
  • Service Accounts
  • Using the Secondary Logon Service and RunAs
  • Using WMI for Active Directory Event Notification
  • Moving Forward
  • Chapter 14. Configuring Data Storage
  • New Features in Windows Server 2003
  • Functional Description of Windows Server 2003 Data Storage
  • Performing Disk Operations on IA32 Systems
  • Recovering Failed Fault Tolerant Disks
  • Working with GPT Disks
  • Moving Forward
  • Chapter 15. Managing File Systems
  • New Features in Windows Server 2003
  • Overview of Windows Server 2003 File Systems
  • NTFS Attributes
  • Link Tracking Service
  • Reparse Points
  • File System Recovery and Fault Tolerance
  • Quotas
  • File System Operations
  • Moving Forward
  • Chapter 16. Managing Shared Resources
  • New Features in Windows Server 2003
  • Functional Description of Windows Resource Sharing
  • Configuring File Sharing
  • Connecting to Shared Folders
  • Resource Sharing Using the Distributed File System (Dfs)
  • Printer Sharing
  • Configuring Windows Server 2003 Clients to Print
  • Managing Print Services
  • Moving Forward
  • Chapter 17. Managing File Encryption
  • New Features in Windows Server 2003
  • File Encryption Functional Description
  • Certificate Management
  • Encrypted File Recovery
  • Encrypting Server-Based Files
  • EFS File Transactions and WebDAV
  • Special EFS Guidelines
  • EFS Procedures
  • Moving Forward
  • Chapter 18. Managing a Public Key Infrastructure
  • New Features in Windows Server 2003
  • Moving Forward
  • PKI Goals
  • Cryptographic Elements in Windows Server 2003
  • Public/Private Key Services
  • Certificates
  • Certification Authorities
  • Certificate Enrollment
  • Key Archival and Recovery
  • Command-Line PKI Tools
  • Chapter 19. Managing the User Operating Environment
  • New Features in Windows Server 2003
  • Side-by-Side Assemblies
  • User State Migration
  • Managing Folder Redirection
  • Creating and Managing Home Directories
  • Managing Offline Files
  • Managing Servers via Remote Desktop
  • Moving Forward
  • Chapter 20. Managing Remote Access and Internet Routing
  • New Features in Windows Server 2003
  • Configuring a Network Bridge
  • Configuring Virtual Private Network Connections
  • Configuring Internet Authentication Services (IAS)
  • Moving Forward
  • Functional Description of WAN Device Support
  • PPP Authentication
  • NT4 RAS Servers and Active Directory Domains
  • Deploying Smart Cards for Remote Access
  • Installing and Configuring Modems
  • Configuring a Remote Access Server
  • Configuring a Demand-Dial Router
  • Configuring an Internet Gateway Using NAT
  • Chapter 21. Recovering from System Failures
  • New Features in Windows Server 2003
  • Functional Description Ntbackup
  • Backup and Restore Operations
  • Recovering from Blue Screen Stops
  • Using Emergency Management Services (EMS)
  • Using Safe Mode
  • Restoring Functionality with the Last Known Good Configuration
  • Recovery Console
  • Moving Forward
  • Who Should Read This Book
  • Who This Book Is Not For
  • Conventions
  • Acknowledgments
  • About the Author
  • About the Technical Reviewers
  • Index
  • Index A
  • Index B
  • Index C
  • Index D
  • Index E
  • Index F
  • Index G
  • Index H
  • Index I
  • Index J
  • Index K
  • Index L
  • Index M
  • Index N
  • Index O
  • Index P
  • Index Q
  • Index R
  • Index S
  • Index SYMBOL
  • Index T
  • Index U
  • Index V
  • Index W
  • Index X
  • Index Z
  • Preface
  • Previous Section Next Section

    DNS and Active Directory Namespaces

    As we saw in Chapter 6, "Understanding Active Directory Services," an Active Directory domain must be rooted in a DNS domain name. Figure 8.1 shows a DNS domain namespace and a corresponding Active Directory tree.

    Figure 8.1. DNS Namespace and Active Directory tree.


    There's no question that deploying and managing Active Directory is simpler if you use Windows Server 2003 name servers. However, if you have an existing third-party DNS platform, it's not likely that you can shift to Windows Server 2003 overnight. You may not even want to shift at all. Because DNS is such a critical element in Active Directory design and operation, you must decide how you will integrate Windows Server 2003 into your current DNS infrastructure. Here are three popular configurations:

    • Forget about Windows DNS completely and use third-party name servers to host the zone for the Active Directory domain.

    • Create a separate DNS domain for Active Directory, host the zone on Windows Server 2003 name servers, and forward queries for records in other zones to a third-party name server.

    • Use your current public DNS domain to root the Active Directory domain and create a split public/private zone with the private zone hosted by Windows Server 2003 name servers.

    The next few sections examine these options in detail.

    Active Directory and Third-Party Name Servers

    You do not need to run Windows Server 2003 DNS to support Active Directory, but your DNS servers must run a version of DNS that supports the Service Locator (SRV) resource record type as defined in RFC 2782, "A DNS RR for Specifying the Location of Services (DNS SRV)."

    Active Directory domain controllers use SRV records to publish their Lightweight Directory Access Protocol (LDAP) and Kerberos services. The format for these records is specified in RFC 2052, "SRV Record Format and Use." Name servers running BIND 8.1.2 and later support SRV records—so do servers running the most current version of Lucent QIP or NetWare 5.x DNS.

    Because SRV records have a complex format, and Active Directory uses a lot of them, it is helpful to use a DNS platform that supports dynamic record registration as defined in RFC 2136, "Dynamic Updates in the Domain Name System (DNS UPDATE)."

    If your DNS platform uses only static zones, or you don't want to enable dynamic updates, you must manually enter the SRV records in their proper format. The Domain Controller Promotion Wizard creates a file called Netlogon.dns in the C:\Windows\System32\Config folder. This file contains the SRV records that Netlogon attempted to register with DNS. You can import this file into a third-party name server, but your job doesn't stop there. You must remember to manually update the zone for any subsequent changes such as promoting or demoting domain controllers, creating new site objects, or changing a domain controller's site affiliation.

    Separate Windows Domain and Windows-Based Zone

    You may decide that your current DNS name is unsuitable for Active Directory. Or you may be unable to convince management to host Active Directory resource records on your current name servers. If so, you can create a separate DNS domain and root Active Directory in that namespace. Host the zone for the new domain on a Windows name server and use the existing name server as a forwarder. This configuration is shown in Figure 8.2.

    Figure 8.2. Windows Server 2003 DNS running with third-party forwarder.


    In this configuration, your Windows clients point at the Windows name servers. When the clients request a record in an outside zone, the Windows name server forwards the request to the original name server. For Internet records, the Windows server can use root hints to sent iterative requests to the Verisign Top Level Domain (TLD) servers.

    Public Domain with Split Public/Private Zone

    This option is commonly used by organizations that want to retain their current, registered DNS domain name as their Active Directory domain name. For instance, the International Widget Company may prefer to use its registered Widget.com name rather than Widget.net or Widget.local or some other private namespace. Figure 8.3 shows this configuration.

    Figure 8.3. Public DNS domain name with split public/private zones.


    This configuration uses separate zones for the public namespace and the private namespace. The private zone is hosted on a name server inside the firewall. The public zone is hosted on a name server in the DMZ or on an ISP's name server. In either case, clients point at the name server inside the firewall. This name server uses the outside name server as a forwarder or uses root hints to resolve addresses outside its zone of authority. You get the most flexibility for Active Directory by hosting the private zone on a Windows name server.

    If you use this split configuration or one similar to it, keep in mind that Active Directory clients cannot access the private name server while they are outside the firewall. The client can only authenticate when connected through the firewall using a dial-up connection, a Virtual Private Network (VPN), or some other form of protected connection. Clients can use the Logon Using Dial-Up Connection option at the initial logon window to establish their credentials at logon. For Windows 2000/XP clients, this initiates a Kerberos-based logon that significantly speeds up subsequent access to member servers.

    Root Domain Name

    "What's in a name?" asked Juliet as she gazed at the heavens and dreamt of her Romeo. Names turn out to be critically important, in computing and love. Don't pay the price that Romeo and Juliet paid by ignoring names as you design your domains.

    Windows clients live in two worlds: a hierarchical world where the only name that really matters is the fully qualified DNS domain name and a flat world where the NetBIOS name has ultimate significance. Your domain design must support both these naming structures.

    When you promote the first domain controller in an Active Directory domain, the Domain Controller Promotion Wizard (Dcpromo) generates a flat NetBIOS name from the left-most element of the fully qualified DNS name. For example, the Company.com DNS name yields the flat name COMPANY. It's theoretically possible to designate a flat name during the domain controller promotion that does not match the leftmost element in the DNS name. This can cause confusion among users, who may wonder what name to use in any given circumstance.

    If you want to retain your current NT domain name as your Active Directory domain name, you must select a DNS domain name that uses the flat name as the lowest domain constituent. For example, the NT domain called COMPANY could have a DNS name of Company.com, Company.net, Company.local, or Company.Enterprise.ParentDomain.com.

    Domain Name Restrictions Caused by Flat Names

    To retain your current NT domain name as the flat name for your Active Directory domain, you must upgrade the existing PDC. You cannot create a parallel Active Directory domain with the same flat name because this causes a NetBIOS name conflict.

    For example, let's say you have an existing NT domain named COMPANY. If you try to promote a new Windows Server 2003 domain controller and root Active Directory in a DNS domain called Company.com, the Domain Controller Promotion Wizard attempts to register the flat name COMPANY it derived from Company.com. When it does this registration, it gets a notification from the PDC of COMPANY (or from WINS) declaring that the COMPANY domain name already exists. The promotion wizard will suggest COMPANY0. You should not accept this or any other alternative that results in a flat name that does not match the lowest DNS domain.

    If you don't like your current NT domain name and you want your Active Directory domain to have a different flat name, you must set up a new Active Directory domain and migrate objects into the that domain from the existing NT domain. The next chapter contains details on object migration.

    Suggestions for Resolving Name Disputes

    The pairing of Active Directory and DNS in many organizations is as star-crossed as Romeo and Juliet's relationship. Large organizations often have a multitude of highly competitive IT groups who may have fractured the DNS namespace into many zones that forward and delegate in ways that would give a chess champion a headache.

    The DNS namespace for a university, for example, might have separate domains for Academic Services, Administration, Alumni, Biology, Chemistry, Physics, Fine Arts, Physical Education, Facilities, Math-Physics, Humanities, Bookstore, Student Union, and Library with subdomains under each for Undergrads, Grads, Law, Medical, and Hospital, not to mention more branches for outlying campuses and extended campuses and minicampuses and walk-in learning centers and on and on and on.

    If you are an administrator in a department or office that exists in a DNS subdomain, you may be wondering how to handle your Active Directory design. To avoid the inevitable bureaucratic decision process, you may be tempted to root your Active Directory forest in your current DNS subdomain and proceed with your deployment. Here is why that would be a mistake.

    Let's say your DNS subdomain is Humanities.EastCampus.BigUniversity.edu. Your current NT domain name is PLATO. When you migrate to Active Directory, you want to change the domain's flat name because Plato has been exposed as an intellectual despot who wreaked carnage on centuries of western thought. You decide to create a Windows Server 2003 domain rooted in your DNS subdomain with the flat name HUMANITIES. This has two unfortunate consequences:

    • The domain's flat name must be unique in a forest to preserve backward compatibility. There are other Humanities departments at other campuses and they would not like you preempting the name.

    • By rooting your Active Directory domain at Humanities.EastCampus.BigUniversity.edu, you form a new forest. When the rest of the university eventually migrates to Active Directory, you'll be forced to migrate objects from your forest to their forest or to form a transitive Forest Trust. The second option limits your ability to share resources and makes comprehensive domain management much more difficult.

    Your best option is to meet with IT staff from the various campuses and decide how to move forward together with a DNS namespace that supports a unified Active Directory design and deployment. If you are absolutely stymied by bureaucracy and inertia, you can proceed with your own forest but be prepared to do lots of work in the future to heal the breach.

      Previous Section Next Section