programming4us
programming4us
DESKTOP

Windows Server : Branch Office Deployment - Branch Office Services (part 2)

- How To Install Windows Server 2012 On VirtualBox
- How To Bypass Torrent Connection Blocking By Your ISP
- How To Install Actual Facebook App On Kindle Fire
7/21/2011 11:35:20 AM
Windows Server 2008—Full Installation

The full installation of Windows Server 2008 is what most administrators are used to. It provides all of the desired features through a familiar GUI. Unfortunately, all the “make life easy for the administrator” gadgets, GUIs, tools, utilities, and applications create substantially more opportunities for hackers to break into and take over a server, as previously described.

Windows Server 2008—full installation is generally safe to use on the well-protected LAN or branch office environment where the threat of compromise is reduced and where the server is supporting less than highly sensitive data and processes.

Adding a Domain Controller

Access to the domain controller server is required for successful authentication of users and computers in the enterprise. Adding a DC to a branch office introduces increased risk, cost, and administrative overhead in human terms, and in terms of directory services, it involves the following:

  • The additional hardware (cost) at the branch office.

  • Enterprise Admins must create, configure, and maintain a site in Active Directory for the branch office.

  • There will be Active Directory replication traffic over the WAN link between HQ and the branch office.

  • There will be the need for additional infrastructure devices or services, or both.

  • The remote DC must be maintained (at the server level), requiring that Administrator Role Separation be configured.

  • There are security concerns about having a copy of the entire Active Directory database, complete with usernames and passwords, along with the additional infrastructure systems and services in this potentially unsecure facility.

On the other hand, having a DC in the branch office provides a notable improvement in performance and reliability for the branch office for the following reasons:

  • Branch office users can authenticate faster and can authenticate even if the WAN link is down.

  • All other local requests of Active Directory Domain Services respond faster and are successful even if the WAN link is down.

  • Not having a DC in the branch office means the branch office relies more heavily on the performance and reliability of the WAN link.

  • The DC provides an additional level of fault tolerance to the Active Directory database.

Microsoft recommends the addition of a DC in any site (like a branch office) in the following situations:

  • More than 100 users are in the site.

  • The site is using an application that relies on a custom Active Directory partition for replication.

  • Domain logons must be successful (typically expressed as the requirement to access domain resources) even if the WAN link is down.

Note: Active Directory Domain Services binaries

A new process that runs prior to initializing the Active Directory Installation Wizard is the installation of the DCPromo binaries (executables) onto the server. You can initiate this by adding the AD DS server role to the server. Then you can execute DCPromo. Alternatively, if you don’t first install the AD DS server role, you’ll see it automatically initiate by simply running DCPromo at a command prompt.


In the situations where the DC is required in the branch office, the next decision is “What type of DC shall be deployed in the branch office?” This question has new potential answers in Windows Server 2008. Windows Server 2008 can now provide the following types of DCs, engineered to help satisfy reliability, performance, and security concerns in the branch office.

Full Domain Controller

Based on a full installation of controller Windows Server 2008 (as opposed to a Server Core installation), the full domain contains all of the standard components of Active Directory, just as it did in Windows Server 2003. These DCs perform bidirectional replication with other DCs in the domain and forest, just as they did in earlier versions of the operating system.

The full domain controller is the least secure implementation of the DC. It has the full operating system, with many opportunities for the hacker to exploit. It has the full Active Directory database, complete with usernames and passwords. The Active Directory database is writable, providing the opportunity for inappropriate modification, which is a violation of the integrity of the data in the Active Directory database. These potential violations of integrity can be the result of either an authorized user’s accidental misconfiguration or willful misuse or of an unauthorized user (hacker) manipulating Active Directory.

Read-Only Domain Controller

The RODC is a more secured version of a DC. Based on a full installation of Windows Server 2008 (as opposed to a Server Core installation), the RODC contains all of the standard components of Active Directory, except for account passwords. Clients are not able to write any changes to the RODC, however. Lightweight Directory Access Protocol (LDAP) applications that perform write operations are referred to writable DCs that are located in the nearest site over an available WAN link. RODCs receive only inbound, one-way domain data replication from Windows Server 2008 DCs in the domain.

In addition to the read-only Active Directory database and the one-way replication, RODC features include the following:

  • Credential caching Limited contents are stored in the password database in case of compromise. Administrators must configure a Password Replication Policy to allow password replication of only specified accounts to occur to the RODC.

  • Administrator Role Separation Described earlier in this lesson.

  • RODC filtered attribute set To allow administrators to selectively filter attributes on Active Directory objects, typically for security purposes.

  • Read-only DNS All Active Directory–integrated zones get replicated to the read-only DNS server; however, the zones are nondynamic. When clients attempt to update their DNS information, the read-only DNS server returns a referral to the client with the address of a DNS server with a writable copy of the zone.

Note: Increased RODC security comes at a price

Although the RODC provides additional security against unauthorized changes to Active Directory and minimizes the number of passwords that might be compromised if the DC gets stolen from the branch office, the RODC cannot be used to make any changes to Active Directory data. If the WAN link is down, no changes can be made to Active Directory through the RODC.


The RODC was largely designed for the branch office implementation. It can be installed on the full installation or the Server Core installation of Windows Server 2008—Server Core, of course, being the more secure of the two. The option to install the DC as a RODC is a new setting in the DCPromo utility, as shown in Figure 3.

Figure 3. Selecting the read-only domain controller during DCPromo

Server Core Domain Controller

As stated previously, Server Core is the securest installation of Windows Server 2008. Server Core installs a minimal operating system, providing minimal services and applications, with no Windows shell and a limited GUI.

Server Core is not a DC by default, but AD DS can be added to the Server Core installation. When the more secure RODC role is added to the Server Core installation, you have the securest DC installation possible, optimized for the risky branch office implementation. You add the AD DS role to the Server Core server using the DCPromo /unattend <unattend.txt> command, along with a preconfigured answer file (Unattend.txt) for the DCPromo utility.

Windows Server 2008 Server Core in the branch office, whether configured as a standalone, member, DC, or read-only DC server, provides the securest Windows Server 2008 operating system platform due to its server hardening by design.

Global Catalog

The global catalog server is required for successful authentication of users and computers in the enterprise. The global catalog (GC) must reside on a DC. Microsoft recommends that you place a GC in a branch office in the following situations:

  • There is a DC in the branch office, and:

  • The WAN link is unreliable.

  • There are more than 100 users in the branch office.

  • Universal group membership caching is not enabled.

  • The branch office supports Active Directory–aware or Distributed Component Object Model (DCOM) applications.

Placing a GC in the branch office will improve the performance of LDAP queries, user logons, and Active Directory–aware and DCOM applications for users in the branch office.

Placing a GC in the branch office requires a DC in the branch office, raising the risk of the DC being compromised. Furthermore, it increases the risk of compromise of sensitive GC data, and it increases the amount of AD DS replication traffic to and from the branch office over the WAN links.

Operations Masters

Few situations would warrant placing one or more operations masters in a branch office. These are significant components that reside on DCs within the AD DS environment, and placing them in an isolated, and potentially disconnected, branch office could cause problems for the entire forest. About the only cases where it might be appropriate are:

  • There is a DC in the branch office, and:

  • The branch office is its own domain. A DC in the branch office would hold the relative ID (RID) master, the infrastructure master, and the PDC emulator operations master roles.

  • The branch office is its own forest. A DC in the branch office would hold the domain naming master, the schema master, the RID master, the infrastructure master, and the PDC emulator operations master roles.

  • The branch office has the bulk of down-level clients in the enterprise. A DC in the branch office would hold the PDC emulator operations master roles.

In almost every other case, the operations master roles should typically remain on the well-secured, stable, and well-connected HQ network.

Domain Name System

The Domain Name System (DNS) server is required for successful authentication of users and computers in the enterprise and for Internet access. Clients in the branch office will need to locate AD DS servers and other infrastructure services. It is useful, and can be a requirement, that a DNS server be placed in the branch office. This provides rapid registration and query responses, even if the WAN link to HQ is down or busy.

Providing a DNS server in the branch office is a requirement if the branch office is configured as its own domain in AD DS. Local clients will need local DNS to locate domain-related services. From the perspective of the user or a computer, the act of locating AD DS is accomplished through service location (SRV) records within the DNS zone for the domain. In addition, other AD DS DNS zones throughout the forest must:

  • Be configured as Active Directory–integrated DNS zones with proper replication partitions configured.

  • Have secondary DNS zones and zone transfers configured.

  • Have forwarders or stub zones configured.

  • If the branch office domain is a child domain, a delegation record in the parent DNS zone will need to be configured.

Dynamic Host Configuration Protocol (DHCP) Services

Another network infrastructure service that is often required is DHCP for the dynamic assignment of IP addresses and other configuration settings to clients. Again, for performance and reliability reasons, placing a DHCP server in the branch office is often desirable. This aids IP connectivity for branch office clients even if the WAN link is down for extended periods.

Multisite (Branch Office) Clustering with Microsoft Cluster Services

Failover clusters provide server fault tolerance for highly available applications and services, such as SQL Server, Exchange Server, Windows Server Virtualization (also known as Hyper-V or WSv) servers, DHCP servers, and file and print services. You can place cluster nodes in each branch office site to provide local access with increased availability to applications, services, and data.

Distributed File System Replication for Data Fault Tolerance

Another fault tolerant mechanism that can be used in the branch office is distributed file system (DFS) replication. DFS Replication is typically used to replicate data files to multiple and geographically dispersed DFS replica sets, which is ideal for the branch office deployment. DFS Replication has been overhauled in Windows Server 2008, with improvements in performance, data reliability, and replication on demand (called Replicate Now), and it can be used on the new Windows Server 2008 RODC server. DFS Replication is so much better than the earlier (Windows 2000 Server and Windows Server 2003) File Replication Service (FRS) that it replaces FRS for SYSVOL replication for domains configured to use the Windows Server 2008 domain functional level.

Routing and Remote Access Services

The Routing and Remote Access Services (RRAS) server hosts several useful but potentially risky services. It is now a component of the Network Policy and Access Services server role, but it can be installed independently of NAP. New in Windows Server 2008 is support for IPv6.

RRAS can be particularly useful in the branch office because it includes the following services:

  • VPN server

  • Demand-dial routing—for use with establishing on-demand VPNs

  • Network address translation (NAT) with:

    • IP routing (small scale, just perfect for satisfying the limited routing needs in the branch office)

    • DHCP relay agent

In addition, RRAS provides support for these typically lesser-used but sometimes helpful services:

  • Dial-in connections

  • IGMP—Multicast routing

  • Routing Information Protocol (RIP) v1 and v2

If you decide to place an RRAS server in the branch office, if it doesn’t exist in the branch office already, you’ll want to consider the potential placement of a DC in the branch office. If the RRAS server will be authenticating users and VPN connections, you might prefer to provide local authentication services.

The VPN server component of the RRAS server provides tremendous benefits in securing information in transit between the branch office and HQ, between two branch offices, and between the branch office and remote authorized users. It can provide core network infrastructure services with NAT, IP routing, and the DHCP relay agent.

However, remember that a dial-in server, like RRAS, allows remote users, both authorized users and hackers, to gain access to the internal network and its resources. This device is a gap in the security fortress and must be implemented with careful consideration and planning. It requires ongoing monitoring and analysis to maintain and maximize security on this portal into your network infrastructure.

Windows Server Update Services (WSUS)

Microsoft Windows Server Update Services (WSUS), currently v3.0 SP1, enables administrators to deploy the latest Microsoft product updates to computers running the Windows operating system. This server downloads, stores, and distributes approved Microsoft operating system and application updates to computers in the enterprise. Placing a WSUS server in a branch office reduces update traffic, either from the HQ or from the Internet. The WSUS server in the branch office can be managed from HQ, so no administrative privilege is required other than local administrator privilege  for underlying server support. HQ administration can, of course, grant update approval authority to the branch office administrator, if appropriate.

The down side, again, is the hardware cost, the slightly increased local administration overhead, and the increase of the attack surface of the server and the branch office network.

Virtualization in the Branch Office

Another new technology that can be a major benefit in the branch office is Microsoft’s Hyper-V technology. Hyper-V provides support for running multiple virtual machines on a single physical computer host. This is referred to as server consolidation. Because most computers operate using only 10 to 25 percent of a computer system’s available resources, such as RAM and CPU clock cycles, the hardware is severely underutilized. By running multiple virtual machines on a single physical server host, these server resources are much better utilized, requiring fewer physical servers and providing better return on investment. Having fewer physical devices in the branch office reduces the number and difficulty of physically securing those fewer devices.

Microsoft’s virtualization technology provides for rapid and easy deployment of virtual machines and simplifies the migration of virtual machines from one physical host to another. These features can be essential components of the enterprise’s business continuity and disaster recovery plans. Hyper-V can be implemented on Windows Server 2008 Server Core servers for increased security and can be clustered to provide server failover fault tolerance.

Hyper-V is included with Windows Server 2008 Standard, Windows Server 2008 Enterprise, and Windows Server 2008 Datacenter. Windows Server 2008 Standard includes one virtual instance per license. Windows Server 2008 Enterprise includes four virtual instances per license. With Windows Server 2008 Datacenter, customers receive unlimited virtual instances per license. You can buy these versions without Hyper-V, but the savings are negligible.

Branch Office Communications Considerations

Branch office networks need to connect to resources in the HQ network. This connection can be on dedicated lines, like a T1 or T3, or it can communicate over the public wires of the Internet. In either case, these channels of communication should be protected from the sniffer or eavesdropper. Furthermore, it is not uncommon for the WAN link between the branch office and HQ to go down, forcing the network administrator to view WAN links as unreliable. These unsecure and unreliable WAN links are required to carry sensitive corporate, medical, financial, and otherwise private data requiring protection by laws and regulations, as well as data to support AD DS. The types of data an enterprise must consider in its branch office deployment design are the following:

  • User data—accessed over the WAN links and for centralized backups at HQ

  • DFS replicated data

  • AD DS replication data—if the branch office holds a DC

  • Global catalog replication data—if the branch office holds a GC

  • DNS data—either within AD DS replication Active Directory Integrated zones or in zone transfers

  • Multisite clustering heartbeat data

Site Link Considerations for the Branch Office

Each defined site must connect to AD DS by means of a site link. A site link is the logical connection object between sites for AD DS replication. This logical connection, of course, requires physical connectivity to be in place and to be functioning properly for replication to succeed. Due to the security constraints on different types of data that must be replicated and to provide redundancy for failed replication servers, there are often replication paths for Active Directory replication data that would fail without the addition of site link bridges.

The good news is that from as early as Windows 2000 Server, site link bridging is enabled by default on all site links. If tighter control over replication paths is required, the Bridge All Site Links option can be disabled. The administrator must then manually construct any specific site link bridges required to provide the proper connectivity and redundancy on these logical connections.

Another aspect of AD DS replication, new to Windows Server 2008, is the need to ensure replication to the new RODC. Unfortunately, down-level domain controllers (Windows 2000 Server and Windows Server 2003) do not recognize an RODC because of its one-way replication processes and will not replicate data to it. This requires that any site with only RODCs (one or more) must have a site link directly to a site with at least one Windows Server 2008 DC. The Windows Server 2008 DC does recognize the RODC and will replicate AD DS data to it appropriately.

Confidentiality for Data in Transit

No matter what type of connection you use, you should employ VPNs to secure data in transit between the branch office and HQ and between remote clients and the branch office. Windows Server 2008 provides VPN support for the following VPN protocols:

  • Point-to-Point Tunneling Protocol (PPTP) The early and original Microsoft VPN protocol. This VPN is easy to set up and provides reasonable security based on the RC4 cipher for encryption. It uses TCP port 1723.

  • Layer 2 Tunneling Protocol (L2TP) Operates at layer 2 of the OSI model, so no IP network is required. L2TP provides strong authentication, nonrepudiation, and strong integrity validation by using X.509 digital certificates on the end point servers. It does not provide confidentiality (encryption). It uses TCP port 1701.

  • IP Security (IPsec) Operates at layer 3 of the OSI model, so an IP network is required. It has become the de facto VPN protocol of choice. With Windows Server 2008, it uses 3DES or AES for encryption and can provide weak authentication and integrity validation based on Kerberos. It can be strengthened to provide strong authentication, nonrepudiation, and integrity validation based on X.509 digital certificates. It uses UDP port 500.

  • Secure Sockets Transport Protocol (SSTP) This is a new feature in Windows Server 2008. This VPN protocol is based on the very popular Hypertext Transfer Protocol (HTTP) over Secure Sockets Layer (SSL) and Transport Layer Security (TLS), but it has been refined for use on the LAN (versus its original use for Web-based services and applications). It can provide only client-to-server functionality and provides strong authenticity, nonrepudiation, and integrity validation of the server (only), along with weak authentication and integrity validation of the client. SSTP has native support for IPv6. It is based on an X.509 digital certificate on the server, uses the popular RC4 and AES ciphers, and runs over TCP port 443.

Other  
  •  Windows Server : Planning Application Virtualization
  •  Windows 7 : Understanding TCP/IP (part 2)
  •  Windows 7 : Understanding TCP/IP (part 1) - Basics of IP Addressing and Configuration
  •  Windows Server 2008 : Planning Operating System Virtualization (part 2) - Planning for Server Consolidation
  •  Windows Server 2008 : Planning Operating System Virtualization (part 1)
  •  Windows Server 2003 : Troubleshooting Group Policy
  •  Windows Server 2003 : Working with Resultant Set of Policy (part 2)
  •  Windows Server 2003 : Working with Resultant Set of Policy (part 1) - Generating RSoP Queries with the Resultant Set Of Policy Wizard
  •  Configuring Windows 7 NIC Devices (part 2) - Configuring Wireless NIC Devices
  •  Configuring Windows 7 NIC Devices (part 1) - Configuring a Network Adapter & Troubleshooting a Network Adapter
  •  
    Top 10
    - Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
    - Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
    - Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
    - Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
    - Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
    - Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
    - Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
    - Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
    - Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
    - Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
    REVIEW
    - First look: Apple Watch

    - 3 Tips for Maintaining Your Cell Phone Battery (part 1)

    - 3 Tips for Maintaining Your Cell Phone Battery (part 2)
    programming4us programming4us
    programming4us
     
     
    programming4us