• 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

    Flexible Single Master Operations

    In a multiple-master replication environment, any domain controller can theoretically change any object in Active Directory. As we saw in the last chapter, Active Directory has special features to handle conflicting updates performed during the same replication interval.

    Certain Active Directory functions just cannot be shared without causing potential data consistency problems. These special functions are called Flexible Single Master Operations, or FSMOs (pronounced FizzMohs). The domain controller assigned a particular FSMO is called a role master. Here are the five FSMOs and the MMC console you would use to view and set the role master:

    • PDC Emulator AD Users and Computers

    • RID Master AD Users and Computers

    • Infrastructure Master AD Users and Computers

    • Domain Naming Master AD Domains and Trusts

    • Schema Master Custom console containing the Schema snap-in

    Identifying FSMOs

    You can find the identity of a FSMO by right-clicking the top icon in the associated MMC console and selecting OPERATIONS MASTER from the flyout menu. This opens an Operations Master window with tabbed entries for each FSMO controlled by that MMC console.

    The FSMO role masters are flagged in Active Directory by an attribute called FSMORoleOwner. This attribute is assigned to the object that controls the function requiring single-master operation. The FSMORoleOwner attribute is linked to the following objects:

    • PDC Emulator Domain container

    • RID Master RID Manager$ object in cn=System,dc=<domain>,dc=<root>

    • Infrastructure Master Infrastructure container under dc=<domain>,dc=<root>

    • Schema Master Schema container

    • Domain Naming Master Partitions container under cn=Configuration,dc=<domain>,dc=<root>

    You can use a batch file in Resource Kit called Dumpfsmos.cmd to list the FSMOs. This batch file uses the NTDSUTIL utility to enumerate the FSMO roles. The syntax is dumpfsmos <dc_name>.

    PDC Emulator

    Active Directory supports the presence of downlevel NTbackup Domain Controllers (BDCs). To make this trick work, Active Directory fools the BDCs into thinking that a Windows Server 2003 domain controller is an NT Primary Domain Controller (PDC). This is necessary because BDCs will only replicate from a PDC. This special domain controller is the PDC Emulator role master.

    The PDC Emulator packages up Active Directory updates that affect objects shared by the classic SAM and replicates those updates to the downlevel BDCs using LanMan Replication. While in Mixed, objects representing security principals (users, computers, and groups) can only be created by the PDC Emulator.

    After all domain controllers have been removed from operation, the domain can be shifted to Native. When this is done, the LanMan Replication service is stopped and the downlevel BDCs no longer get updates. They remain active, however, getting older and older and further and further out of date, a little like 1960s rock bands.

    You cannot promote a classic NT BDC to PDC after you have begun upgrading your domain to Active Directory. You can, however, transfer the PDC Emulator role to another Windows Server 2003 domain controller (or a Windows 2000 domain controller if you are still running in Functionality Level 0). From the perspective of the downlevel BDCs, this looks as if a BDC has been promoted. They shift their allegiances to the new PDC Emulator and begin replicating from that server.

    Windows 9x and NT clients that are members of a domain know that the only domain controller with write permissions on the domain SAM is the PDC. Therefore, when these clients need to change a password, they communicate directly to the PDC. In modern Windows, any domain controller can update a user's password but the downlevel clients don't know this. The PDC Emulator gives the downlevel clients a place to go when they want to change passwords or make any other change involving the classic SAM.

    Updating Logon Processes for Downlevel Clients

    The DSCLIENT patch on the Windows Server 2003 CD modifies the behavior of a downlevel Windows 9x client so that it can change a password on any domain controller, not just the PDC Emulator. The Active Directory update for NT4, available as a download from the Microsoft web site, does the same for NT4 clients.

    This patch also changes the authentication mechanism for Windows 9x/ME clients to use NLTM Challenge-Response version 2 rather than LanMan Challenge-Response. Classic NT clients running SP3 or later already use NTLM v2. The AD client patch does not permit any downlevel client to use Kerberos.

    In addition to its duties as housemaid to the downlevel BDCs, Microsoft decided to throw additional single master operations onto the PDC Emulator. For example, as we saw in Chapter 7, "Managing Active Directory Replication," the PDC Emulator is also the primary time standard for other domain controllers in a domain. There are three additional duties assigned to the PDC Emulator.

    Final Validation for Password Changes

    When a user changes a password, or an administrator resets a password for a user, the update is replicated to the PDC Emulator on a "best effort" basis. This means that schedules on intervening inter-site links are ignored.

    The domain controllers in a domain use the PDC Emulator as a "last court of appeals" for invalid passwords. If a user enters an incorrect password, the local DC checks with the PDC emulator to see if the password has been changed and the user's password is actually valid. If so, the user is given access. This feature prevents calls to the Help Desk following a password change.

    Preferred Group Policy Location

    Group policies consist of two components: a Group Policy Container (GPC) in Active Directory and a Group Policy Template (GPT) in \Windows\Sysvol\Sysvol\<domain_name>. If these two components get out of sync, a user will either try to get a policy when the GPT is not yet in Sysvol or will miss a policy in Sysvol because the GPC hasn't yet replicated to the logon server.

    To avoid this problem and other inconsistencies that might arise from multi-master replication, when you open the Group Policy Editor, the focus of the tool is set to the PDC Emulator. This ensures that all administrators in the domain make their group policy modifications on the same machine, reducing the likelihood of synchronization problems.

    Disabling Invalid Password Checking

    The double-check of invalid passwords puts a strain on the PDC Emulator and the WAN links leading to it. You may want to disable invalid password checks when the local domain controller is in a different site than the PDC Emulator. You can do this with a Registry update on the local domain controller:

    Key:    HKLM\CurrentControlSet\Services\Netlogon\Parameters
    Value:  AvoidPDConWAN
    Data:   1
    

    If the PDC Emulator is not available (either because it is down or the WAN link is cut), you'll be prompted to pick another domain controller or to wait until the PDC Emulator is available again. If you are fairly confident that your modification won't conflict with changes made by other administrators, you can select another domain controller.

    Keep this behavior in mind as you update your group policies. If you are several slow hops away from the PDC Emulator, it may take you a while to get your screen refreshed.

    Domain Master Browser

    Windows is a little like the Beverly Hillbillies in some respects. You can dress it up and put it in a fancy setting, but at some point or another you're going to end up with lye soap cookin' out by the cement pond.

    An example of this unsophisticated behavior is browsing. I don't know of a single Windows feature that has caused more administrative headaches than browsing.

    Modern Windows does not need browsing. You can publish your printer resources in Active Directory. You can use the Distributed File System (Dfs) to abstract your share points away from their home servers. But for some reason, users find it comforting to open My Network Places and scratch around looking for resources.

    Windows Server 2003 provides backward compatibility for browsing. Windows Server 2003 and XP desktops participate in browse elections on an equal footing with NT4 servers and workstations. If they win the election, they become the Subnet Master Browsers.

    In a routed enterprise, browsing depends on a single server, a Domain Master Browser, to aggregate the subnet browser databases and distribute a comprehensive server list. In a classic NT domain, the PDC acts as the Domain Master Browser. In an Active Directory domain, the PDC Emulator takes on this chore.

    WINS plays an important role in browsing by publishing the IP address of the Domain Master Browser and any Subnet Master Browsers. It's important that the PDC Emulator be a WINS client so it will register the appropriate browser records.

    RID Master

    All security objects have a SID. The SID is a combination of the SID of the domain and a sequential number called the Relative ID, or RID. In a classic NT domain, security principals added after initial installation get RIDs starting with 1000. Here is an example of a few SIDs from a domain:

    PhxUser1:   S-1-5-21-515967899-764733703-1708537768-1000
    XP-WKS-01$: S-1-5-21-515967899-764733703-1708537768-1001
    PhxAdmins:  S-1-5-21-515967899-764733703-1708537768-1002
    PhxUser2:   S-1-5-21-515967899-764733703-1708537768-1003
    

    Notice that the last four digits, the RID for each SID, are in sequence. In a native-mode domain where any domain controller can create a security principal, the RIDs may not be in sequence, but they must be unique. For this reason, only one domain controller can hold the RID pool. This is the RID Master. The available RIDs are stored in an attribute called RIDAllocationPool.

    While in Mixed, the RID Master and PDC Emulator stay in constant touch because only the PDC Emulator can create security principals. In Native, the RID Master slices hunks from the RID list and passes them out to the domain controllers when they request it.

    There is one RID Master per domain. By default, the RID Master and the PDC Emulator roles are held by the same domain controller. You can transfer the RID Master role to another domain controller, but it is important that it remain available as long as you are in Mixed. Continuous service is not as critical in Native because each domain controller has a big slice of the RID pie, but you would not be able to promote new domain controllers without the RID Master.

    Infrastructure Master

    When you add a user to a group, the user's distinguished name (DN) is added to the Member attribute for the group. The User object has a corresponding MemberOf attribute that contains the distinguished names of the groups to which the user belongs.

    This pair of attributes, Member and MemberOf, are examples of linked attributes. In a pair of linked attributes, the primary attribute is termed a forward link and the other attribute is a back-link. In the example, the Member attribute is the forward link and the MemberOf attribute is a back-link. Only the forward link can be modified directly. The back-link is calculated.

    There are many instances of linked attributes in Active Directory. Another example is the Manager attribute, a forward link that identifies a user's manager, and the Reports attribute, a back-link that lists the users who report to a single manager.

    When a forward link is changed, for example, when a new user is added to a group, the user DN is replicated to all domain controllers hosting a replica of the affected naming context. When a domain controller applies the update, it recalculates the back-link attribute for the affected user object.

    If you think this process has the potential to get a little messy and complicated, you're right. Maintaining referential integrity between linked attributes is one of the more complex processes in a directory service.

    The linked Member and MemberOf attributes play an important role in Active Directory security because groups, as security principals, are used to protect objects. Users who are members of a group get the access permissions assigned to the object. When a user logs on, the system does a search for any groups that have the user's DN in their Member attribute. It resolves these group names into SIDs and adds them to the Privilege Access Certificate (PAC) for the user. The security subsystem on a member server uses the PAC to construct a local access token for the user.

    If the user's distinguished name changes, the system must update all the group objects that have the user as a member. This must be done as quickly as possible so the user doesn't "fly under the radar" and get inappropriate access permissions.

    Updates to the Member attribute for group objects in the same domain as the user with the changed name happen immediately because the domain controller holds both the user object and the group object. But when a user is a member of a group in another domain, the update can take a while. A domain controller in the remote domain must be informed about the name change so it can change the Member attribute for any affected groups in that domain.

    The job of quickly disseminating these name changes falls to the Infrastructure Master.

    Domain Naming Master

    When you create a new domain in an existing forest, the other domain controllers need to know that the new domain exists because the domain represents a separate naming context. The Directory Service Agent's (DSA's) shared knowledge about each other's naming contexts is one of the principal foundations of LDAP.

    Active Directory stores pointers to other domains in a special CrossRef object located in a Partitions container in the Configuration naming context. This object contains attributes that describe the distinguished name, DNS name, the flat name, and the name of the Domain naming context along with the kind of trust relationship that binds the domain to the forest.

    If two administrators were to create new domains with identical names during the same replication interval, the standard collision management algorithms would fail to prevent a snarl of incorrect links, references, and replication connections. For this reason, only one computer in a forest can make changes to the Partitions container, and that is the Domain Naming Master.

    By default, the Domain Naming Master is the first domain controller promoted in a forest. You can transfer this role to any domain controller in any domain, although it's best to put it on a domain controller in the root domain so there is no question about which group of administrators can have access to the server.

    Schema Master

    The objects in the Schema naming context define the very structure and identity of Active Directory for a forest. Objects can only be added, modified, or removed from the schema under strictly controlled circumstances. Only one domain controller in a forest can update the schema, and that is the Schema Master.

    Chapter 6, "Understanding Active Directory Services," discussed the requirements to modify the schema manually. This permits you to add attributes and object classes to support in-house applications for departments such as Human Resources or Facilities. Client/server applications such as Exchange 2000 also make changes to the schema. Newer network management applications can take advantage of features in Active Directory and they often make schema changes.

    When you install an application that modifies the schema, you do not need to be at the console of the Schema Master, but the Schema Master must be online and available before the schema updates can be applied. Also, you must be a member of the Schema Admins group.

    The role master for a FSMO can be transferred to another domain controller or seized if the original domain controller has crashed and cannot be revived. The procedures for these actions are in Chapter 10, "Active Directory Maintenance."

    Role Master Location

    If you take no actions to transfer FSMO roles, the first domain controller you promote will have all the roles, making it a significant risk as a single point of failure. Here is a set of recommendations for placing FSMO role masters:

    • PDC Emulator and RID Master. Keep these two FSMOs on the same domain controller. Use a fast, reliable machine that is well connected to your WAN. Remember that all other domain controllers in the domain check invalid passwords by querying the PDC Emulator for a second opinion.

    • Infrastructure Master. Move this FSMO to a domain controller that is not a Global Catalog server. Make sure the server is well connected because it is responsible for updating the other domain controllers with name cross-reference changes.

    • Domain Naming Master. Move this FSMO to a domain controller that is also a Global Catalog server. This server does not need to be fast but it must be available when you create a new domain.

    • Schema Master. Microsoft recommends putting the FSMO on the same domain controller assigned as Domain Naming Master, but this is not an absolute requirement. The schema rarely needs updating, but you want to maintain tight security on the Schema Master. All servers share a copy of the schema, so the Schema Master does not need to be a GC.

      Previous Section Next Section