Technical White Paper

Published: March 18, 2004

Executive Summary

Enhancing the security of corporate assets worldwide is a top priority for the Microsoft Information Technology (Microsoft IT) organization. A major concern is remote access: the services and connections that allow approved employees to connect to a corporation's network from a remote location. More than 92,000 Microsoft and contract employees worldwide gain access to corporate computer and network resources through remote access, establishing more than 1 million connections monthly. With the ever-increasing sophistication, availability, and ease of use of computer and network hacking tools, remote access pathways into the enterprise network must be protected.

In addition to mitigating the risk of malicious, unauthorized, or inadvertent threats to the corporate network and computer assets at Microsoft, the Microsoft IT remote access solution seeks to add value to the Microsoft business strategy by creating a positive and productive experience for users. Achieving these objectives cost-effectively is an ongoing focus and challenge for Microsoft IT. The solution currently deployed requires users to adhere to an internally developed Secure Remote User (SRU) framework, with mandatory requirements for server and computer operating systems, automated client computer and connection management software enforcing specific configurations, smart cards for two-factor authentication, and disciplined operations management and administration processes. Client computers are required to pass certain security checks while in a quarantine network before being granted full network access. The solution design also provides for alternate access points globally for business continuance and disaster recovery scenarios.

The purpose of this white paper is to share architecture, design, and deployment considerations and experiences of the Microsoft remote access solution, demonstrating the value of current Microsoft products in the security hardening and management of remote access. This paper briefly discusses the evolution of remote access and business scenarios at Microsoft; the current Microsoft IT security strategy and framework; the remote access infrastructure and client software functions currently in place; and the operational processes developed to standardize, optimize, and help secure remote access.

This paper assumes that readers are technical decision makers and are already familiar with Microsoft® Windows Server™ 2003 remote access technologies, such as Connection Manager (CM), Remote Authentication Dial-In User Service (RADIUS), virtual private network (VPN), and Internet Security Accelerator (ISA) Server 2004, as well as with associated technologies, such as Public Key Infrastructure (PKI) security, smart cards, and Microsoft Operations Manager (MOM) 2005. Many of the principles and techniques described in this paper can be employed to manage risk within any organization, and the design considerations for remote access infrastructure can likewise be applied to most any enterprise-scale IT environment through Microsoft products. However, this paper is based on Microsoft IT's experience and recommendations as an early adopter. It is not intended to serve as a procedural guide. Each enterprise environment has unique circumstances; therefore, each organization should adapt the plans and lessons learned described in this paper to meet its specific needs.

Note   For security reasons, the sample names of forests, domains, internal resources, organizations, and internally developed security file names used in this paper do not represent real resource names used within Microsoft and are for illustration purposes only.

Introduction

Today's information systems increasingly integrate the Internet and private networks, connecting businesses with their employees, customers, and partners. With this growth has come a corresponding increase in the growth of network intrusion attempts and other compromises of network security. Security is a worldwide issue that affects not just Microsoft customers, but anyone connected to the Internet. Systems that administrators judge as "not important enough to update" can host zombie and denial of service attacks that can affect everyone on the Internet, or can enable a hacker to attack the administrators' own networks. The increased frequency of malicious attacks against corporate remote access infrastructures has affected businesses on a global scale, forcing organizations to continuously strengthen their security measures.

The large size of the Microsoft computer network creates significant security challenges. At the time of this writing, the network includes:

• A user base of approximately 60,000 Microsoft employees and approximately 32,000 additional contract employees worldwide.
• Three enterprise data centers, and a total of 8 regional data centers worldwide.
• More than 300 sites in approximately 230 cities in 77 countries/regions.
• The largest wireless local area network (LAN) in the world, employing 802.1X and Extensible Authentication Protocol (EAP)-Transport Layer Security (TLS).
• More than 24,000 wireless devices.
• More than 4,000 wireless access points.
• More than 250 wide area network (WAN) circuits.
• More than 160 WAN sites in more than 70 countries/regions.
• More than 3,300 Internet Protocol (IP) subnets.
• More than 2,000 routers.
• More than 2,600 network layer 2 switches.
• More than 275 asynchronous transfer mode (ATM) switches.
• More than 10,000 worldwide servers.
• More than 150,000 managed desktop computers.
• More than 350,000 LAN ports.

Until recently, Microsoft IT's deployed remote access solution required only a user name and a password and allowed untrustworthy devices to access the corporate network. This authentication and these devices represented a significant threat to Microsoft assets.

To address the growing security challenges related to remote access, Microsoft IT studied a number of technologies to help secure remote access connections on the corporate network, and decided to combine several new and existing technologies as part of the SRU framework. By February 2003—in conjunction with the prerelease deployment of Windows Server 2003—Microsoft IT had completed deployment of an end-to-end remote access solution that requires the use of Microsoft Windows® XP Professional and smart cards for two-factor user authentication, and that enforces computer configurations that enhance security. Computer configuration management is achieved through CM, internally developed SRU scripts integrated into CM, and implementation of a quarantine network in which clients are placed when users log on to the network remotely. In October 2004, Microsoft IT deployed ISA Server 2004 to all VPN servers to provide the quarantine mechanism for these remote connections. Clients that match the Remote Access Quarantine Service (RQS) policy from RADIUS are immediately placed in a quarantine network and remain in quarantine until the VPN server receives a shared key from the client. There was an equally important focus to standardize the global Microsoft IT remote access infrastructure on Windows Server 2003, update operational support processes and documentation, and implement broad user education and communication.

The key considerations that drove the design of the solution were as follows:

• Mitigate the threat of stolen, shared, duplicated, or otherwise unauthorized use of user credentials by ensuring that the identities of all persons connecting to the corporate network by means of remote access are authenticated by using two-factor authentication to certify their identities.
• Mitigate the threats posed by untrustworthy devices by ensuring that all devices requesting a remote access connection to the corporate network meet security requirements for trustworthy devices. Trustworthy devices are those that Microsoft IT can be assured meet the minimum security requirements for the Microsoft IT trustworthy assets they access. More specifically, to be considered trustworthy, a device must:
  • Comply with all Microsoft IT security policies, standards, configurations, and software requirements, which evolve as new threats emerge.
  • Permit centralized management and control of Microsoft IT security policies, configurations, and software.
  • Use an operating system that meets Microsoft IT security requirements.
  • Grant security management rights to Microsoft IT.
• Improve the stability and reliability of remote access end to end, setting clear expectations for individual users and business units that have growing dependencies on the service. Provide an "always on" service, making it easy for users to confidently work anywhere, anytime.

In addition, Microsoft IT must do the following so that devices can be considered trustworthy:

• Ensure that all of the remote access security requirements are met while the user is in a quarantine network state prior to allowing an unrestricted remote access connection from the device to the corporate network.
• Ensure that all devices requesting a remote access connection to the corporate network are not vulnerable to access from other devices during the time they are connected to the corporate network.

Increasing the security of the network perimeter by integrating the Windows XP–based client, smart cards, CM with SRU scripts, a quarantine network with ISA Server 2004 and RQS, and Windows Server 2003 has resulted in the following business benefits beyond security improvements:

• Simplified administration and maintenance of services. Standardization on the latest technologies and removing hardware and operating system variables from the server infrastructure allows simplification of supporting tools, documentation, and processes. This simplification has improved day-to-day operational support of the remote access service, improving resolution times of tickets for service requests and reducing remote access infrastructure tickets overall. Comparing support metrics in February 2003 with the same month in 2004, infrastructure ticket resolution times on average were reduced more than 65 percent, and the number of highest-priority tickets were reduced 76 percent in the network operation center.
• Improved predictability and usability of remote access. Confidence in the service translates directly into flexible user productivity with fewer disruptions, reliable business continuance capabilities, and knowledge that important work and critical corporate resources are protected.
• Reduced total cost of ownership (TCO). With the continued optimization of the remote access solution, TCO continues to fall. Helpdesk is one of the largest cost generators for remote access, and its tickets have been reduced more than 35 percent in the past 10 months as of this writing. The remote access server infrastructure, in large part due to the increased capabilities and stability of Windows Server 2003, has been reduced by 18 percent for VPN servers and 37 percent for RADIUS servers.
• Increased user productivity. Shortly after implementation, user sessions increased by 27 percent. As the end-to-end implementation continues to be tuned and optimized, lessons learned continue to be applied, and user education continues, Microsoft IT expects to see continued growth in the number and duration of remote access sessions in 2005.
  In January 2004, a weather event prevented the majority of employees at the Microsoft headquarters from working at their offices for two days. Many employees decided to work remotely, creating an unplanned test of the stability, robustness, and flexibility of the deployed remote access solution. The solution supported more than 8,300 concurrent remote users for the majority of the first day and much of the second day with no performance issues. There were some access attempts rejected due to no available resources on the servers, but this was the only issue encountered. Remote access at Microsoft is not designed for 100 percent support of the user community attempting to connect simultaneously. In this case, the service supported 25–30 percent of the total regional Microsoft community, including the Microsoft IT 24×7 operations teams, software developer groups, finance and human resources organizations, managers, and executives, with the service performing as designed under 98 percent of total capacity load.
• Improvements in core products. All Microsoft IT organizations have a charter to be "Microsoft's first and best customer." A large responsibility for the majority of the various Microsoft IT organizations is to test and validate Microsoft products, and provide feedback to the internal product development organizations that will help improve these products for customers and partners. Microsoft also works closely with many third-party product engineers to continuously strive to ensure that Microsoft products function well with a broad range of industry technologies. The Microsoft products deployed in the remote access solution have been improved over the last 36 months, first through testing by Microsoft IT, and then through deployment to the Microsoft global enterprise. Testing and deployment have also improved the compatibility between Microsoft products and third-party products.

Past Challenges with Remote Access Technology and Support

This section briefly reviews the Microsoft IT remote access solution prior to the deployment of Windows Server 2003. This section is relevant to understanding enterprise scenarios that may be suffering from the same challenges and demands that led Microsoft IT to rebuild its remote access solution.

The products and tools deployed from 1995 through 2001 specifically for remote access lacked a cohesive vision to generate necessary improvements for reliable, seamless function for the user, and security at the global enterprise level. Remote access was not designed to play a major role in key business functions across the company and was not seen as a core IT service. Disparate technologies and gaps in the design, deployment, and support of the installation base were common, especially region to region. However, this approach to remote access technologies and service support worked sufficiently for many years and was cost-effective when considering all factors, including relevance to enterprise business strategies and revenue.

The early solution consisted of Microsoft IT–managed remote access devices and infrastructure, in addition to devices that users implemented themselves and that were not managed by Microsoft IT. In many cases, Microsoft IT was not aware that the unmanaged systems existed. These unknown systems became known as "rogue" systems by Microsoft IT's operations and security groups.

Individual users, as members of business units, routinely had their business unit IT (BUIT) support teams set up remote access solutions at local regional offices, within labs, and even under desks for their groups. Typically, a server was configured for remote access, a standard modem or NT-1 Integrated Services Digital Network (ISDN) modem was attached, and the access phone number was provided to those who would be using the particular access point and resources. The access phone numbers and circuits for these private systems were not centrally managed. Often, access numbers were provided to Microsoft employees to use for remote connections while traveling within a region. Microsoft IT may or may not have been consulted on these installations, and as such, these deployments followed no proven or consistent design, the service quality and reliability were often unpredictable, and there was no official Microsoft IT operational support.

Early solutions were also not as heavily dependent on the Internet as they are today, with the majority of connections completed through direct dial devices rather than Internet or VPN connections. The Microsoft IT–managed and unmanaged remote access solutions were primarily based on Microsoft Windows NT® version 4.0 technology and servers with dial connectivity provided by the internal Private Branch Exchange (PBX) and/or the local telecommunications service provider, with separate physical analog and ISDN infrastructures, circuits, and access numbers. The circuits were connected to the servers by means of separate individual modems or rack-mounted modem banks with multiplexer components. Client management software managed only the global phone numbers known to Microsoft IT at that time, and the software was not required to make any remote connections; a user only had to know a valid phone number for a remote access system. Windows NT authentication (user name and domain password) was used with the Microsoft Challenge Handshake Authentication Protocol (MS-CHAP) authentication protocol.

Challenges during this period can be summarized as follows:

• Inability to manage remote clients. The lack of established and enforced client computer standards, and no means to enforce management of the remote client software configurations as a part of the logon process, presented a significant gap in the security fabric of the remote access solution and also contributed to many of the usability problems related to client computers.
• Lack of consistency across Microsoft IT organizations. To develop and deploy a more secure, predictable service for the enterprise, key organizations needed to have a unified vision with a clear and consistent security framework as the underlying driver.
• Lack of detailed monitoring, alerting, or metrics gathering. To effectively manage the security, quality, and cost containment of a service end to end—as well as improve the overall user experience—the Microsoft IT support teams needed to adequately measure that service. Microsoft IT was able to monitor the basic aspects of server health, but not end-to-end service health and compliance.
• Compatibility challenges within Microsoft products and third-party products. There were no true end-to-end solutions from 1995 through 2001 for remote access. Solutions in place were built from many product parts, which lacked built-in feature integration capability in the client operating system, the server operating system, and third-party platforms.
• No cohesive strategy to effectively manage external dependencies. Microsoft IT had little contractual framework in place to reliably manage global Internet service providers (ISPs) and telecommunications service providers and their infrastructures and/or access phone numbers. Also, users had independently procured many of the access numbers in use. Effectively managing these global services and the hundreds of phone numbers would significantly increase the reliability of the initial access to the service for users.
• Unclear roles and responsibilities. Various groups within Microsoft IT struggled with unclear roles and responsibilities in the delivery of a more secure service. This was a key area of focus as the security strategy began to emerge. The technology and process discussions to help secure and manage the service led to the evaluation of organizational responsibilities and how they would need to be aligned for the approach to succeed. This alignment was a significant challenge because remote access consists of many unique dependencies supported by various groups in Microsoft IT.

Remote access was being increasingly woven into the fabric of how Microsoft conducted business efficiently and effectively in multiple scenarios. As of January 2001, remote access was routinely used to support:

• Day-to-day flexibility for individual needs, such as work-from-home days, to help employees balance work and personal lives while still being as productive as they would be in the office.
• Stay-at-home Call Center support scenarios to reduce overhead costs associated with providing physical office space.
• Fully functional field sales forces and consultants whose team members rarely used Microsoft office space for weeks at a time.
• Major Microsoft technical or sales conferences globally to enable Microsoft attendees, often numbering in the many thousands, to access material quickly and reliably to support critical presentations or question-and-answer sessions with customers or industry peers.
• Business continuance and/or disaster recovery tools that many business units had come to rely on, including Microsoft IT operations, in the event that weather, natural disasters, or travel advisories kept users from the office.
• Day-to-day Microsoft IT and BUIT operations support tools to improve incident response and resolution times, reduce response costs for vendors, and ultimately enable quicker restoration of IT services for users.
• Microsoft executives who needed to conduct critical day-to-day business while engaged in extended regional or global business travel.

As the business needs grew, the service became unable to meet the security and usability needs of the enterprise.

Responding to the growing employee reliance on remote access, Microsoft IT began to change its view of the service from a non-critical, value-added service to a top-priority, business-critical resource. As a result, the security and the reliability of the service had to be improved. The first key steps that Microsoft IT took in the effort to better manage and secure remote access as a viable business service were:

• Begin a broad communication campaign with end users, business units, and product development groups, clearly explaining the short-term and long-term objectives of a more secure remote access solution.
• Deploy an initial solution that was robust and superior to the unmanaged devices that users had deployed privately. In terms of easy access, management, and performance, Microsoft IT had to first beat the competition internally and win users' confidence in a Microsoft IT–managed solution.
• Identify all "rogue" devices or access points globally and set firm dates to remove these devices, bringing all remote access under Microsoft IT management and control.
• Begin to enforce the use of connection management software as part of the management of the service. Initially, the software would manage only the global phone numbers and establishing connections, but this application would set the stage for future requirements and enable users to become familiar with the technology.

Windows Server 2003–Based Remote Access Infrastructure

Remote access services at Microsoft are, as of this writing, a set of technologies built on the foundation of Windows Server 2003 and Windows XP Professional that transparently connect an authorized client computer, located at off-site or remote locations worldwide, to Microsoft network resources. These technologies are supported by tightly woven Microsoft IT operational processes and tools within a service management structure aligned with the Microsoft Operations Framework (MOF) to deliver a dependable, more secure service to internal clients. The Microsoft IT solution seeks to make the user experience on a remote access session virtually indistinguishable from a corporate connected LAN experience in accessibility, security, and performance.

Users are required to use a smart card and run client-based, remote access management software—CM—to initiate a connection to a VPN remote access server across the Internet or by means of a Microsoft IT–managed dial-up network router. The VPN server requests an authentication through the Internet Authentication Service (IAS) server by using RADIUS, and supports the session until disconnected by the user, by a network administrator, or by a network irregularity. ISA Server 2004 now runs on the VPN server to provide a quarantine network based on the RADIUS policy applied. If RQS is set in the RADIUS policy, the client is placed in a quarantine network until the VPN server receives the shared key. The Microsoft IT solution takes advantage of the flexibility of the Internet as a key part of the design and as a means of providing a direct dial-up component to connect users to the corporate network, all from hundreds of locations worldwide. The solution is fully integrated with the global Microsoft corporate network.

As of November 2004, an average of 46,000 Microsoft workers worldwide use remote access each month. In a typical month, there are:

• 1,303,796 total remote access connections.
• 90,776 remote access connections through direct dial.
• 1,213,020 remote access connections through VPN over the Internet.

An adequate remote access infrastructure is essential for supporting the highly mobile Microsoft workforce. On a global scale, this infrastructure includes:

• Approximately 150 managed direct dial numbers.
• Approximately 545 managed Remote access Over the Internet (ROI) phone numbers.
• 74 managed VPN edge servers running ISA Server 2004.
• 38 managed IAS authentication servers using RADIUS.
• 12 stand-alone Cisco direct dial devices.
• 40 direct dial modules on shared Cisco network devices.

Figure 1 depicts the integrated technologies as they are currently deployed in the Microsoft IT remote access infrastructure. This solution assumes core Microsoft IT infrastructure components are in place, such as proxy servers, domain controllers, the Active Directory® directory service, core network elements, and Internet egress.

Figure 1   Remote access infrastructure at Microsoft

Remote access clients running Windows XP Professional can use standard tools to access resources from a remote connection. All services typically available to a LAN-connected client are enabled by means of the remote access connection. As an example, clients can use Windows Explorer to make drive connections, to access e-mail, and to access and run business-related applications. The connections are persistent, so users do not need to reconnect to network resources during their remote sessions.

The sections that follow provide details about the technologies of the security enhancements for the Microsoft IT remote access solution and how those technologies are integrated to deliver an end-to-end service. These elements are required to deploy the Microsoft IT solution.

Server Requirements

The solution that Microsoft IT deployed uses Windows Server 2003 for all server components. At Microsoft, the physical or logical connection between the remote access client and the remote access server is facilitated by dial-up facilities and equipment installed at the remote access client location (such as a modem and an analog or ISDN phone line); the VPN server; the Public Switched Telephone Network (PSTN); and the Internet. The Microsoft IT solution supports both analog and ISDN dial-up connectivity.

VPN Servers

The overwhelming majority of remote access connections to the Microsoft corporate network resources are established through VPN connections over the Internet. With VPN remote access, a client uses an IP network to create a virtual point-to-point connection to a port on a Microsoft IT remote access router, which establishes a connection to the Microsoft VPN server. The rest of the connection parameters can then be negotiated. This connection is made through the PSTN to the ISP or through a persistent Internet connection, such as broadband cable.

After the VPN server accepts the incoming connection, the VPN server routes packets between the remote access client and the Microsoft corporate network. VPN server groups are deployed, two or more, for redundancy and/or to handle known typical traffic loads. The connection requests for VPN servers in a group are managed by a round-robin Domain Name System (DNS) load distribution. If one VPN server fails, another server or servers within the group will absorb the traffic. If all VPN servers in a group fail, or the network connectivity is lost for a particular group of servers in one location, the users can select the nearest regional VPN access locations from within CM as an alternative access point.

For remote access connections through VPN, the Windows Server 2003–based remote access server and client in the Microsoft IT solution support Point-to-Point Tunneling Protocol (PPTP) and Layer 2 Tunneling Protocol (L2TP). PPTP encapsulates Point-to-Point Protocol (PPP) and uses the authentication, compression, and encryption mechanisms of PPP. PPTP is automatically installed with Transmission Control Protocol/Internet Protocol (TCP/IP) in Windows. PPTP with EAP-TLS provides the primary VPN services of encapsulation and encryption of private data.

A PPP frame (an IP datagram) is wrapped with a Generic Routing Encapsulation (GRE) header and an IP header. In the IP header is the source and destination IP address that correspond to the VPN client and VPN server.

The PPP frame is encrypted with Microsoft Point-to-Point Encryption (MPPE) through encryption keys generated from the MS-CHAP, MS-CHAP v2, or EAP-TLS authentication process. For the payloads of PPP frames to be encrypted, PPTP clients must use the MS-CHAP, MS-CHAP v2, or EAP-TLS authentication protocol.

The VPN servers deployed in the Microsoft remote access infrastructure are equipped with two Intel Xeon processors running at 3.06 gigahertz (GHz), 2 gigabytes (GB) of random access memory (RAM), 17.2 GB of total hard disk capacity, redundant power supplies, and redundant fans.

As of October 2004, ISA Server 2004 is also deployed on all VPN servers to provide additional functionality for quarantining clients as they connect by means of remote access.

IAS and RADIUS Servers

For user authentication, the Microsoft IT–deployed solution for the Routing and Remote Access service in Windows Server 2003 uses IAS, an optional networking component, as its implementation of a RADIUS. RADIUS is a lightweight, User Datagram Protocol (UDP)–based protocol. It provides centralized authentication through passwords (CHAP, MS-CHAP, MS-CHAP v2), certificates (EAP-TLS), smart cards (EAP-TLS), or other EAP-based authentication methods and authorization for dial-up network access server (NAS) devices, 802.1X wireless access points, and VPN servers. Microsoft IT employs IAS so that the VPN server acts as a RADIUS client and sends the users' credentials and other connection settings to a regional IAS server. The IAS server validates the credentials of the remote access client, authorizes or rejects the connection attempt, and stores accounting information for the remote access connection.

RADIUS servers can also provide a proxy service to forward authentication requests to distant RADIUS proxy servers. For example, many ISPs have agreements to allow roaming subscribers to use local services from the nearest ISP for dial-up access to the Internet. These roaming alliances take advantage of the RADIUS proxy service. If an ISP recognizes a user name as being a subscriber to a remote network, the ISP uses a RADIUS proxy to forward the access request to the appropriate network proxy servers. This component is used heavily in the Microsoft IT remote access solution with managed ISPs globally.

Each IAS server accepts authentication requests from specific VPN servers connected to the Microsoft network or from ISP RADIUS servers, and then accepts or rejects requests based on preconfigured Remote Access Policy (RAP) in IAS. At this time, the IAS server also initiates a timer on the VPN session to start the preconfigured Network Access Quarantine Control timer. The Microsoft IT remote access solution uses several VPN servers for each single IAS server deployed regionally. Each IAS server, by design, provides primary and secondary support for designated VPN servers within the regions.

There are many benefits with using IAS for RADIUS authentication in a remote access scenario. The use of IAS:

• Enables centralized user authorization and authentication.
• Creates a seamless experience for users.
• Works with Active Directory.
• Provides a wide range of authorization and authentication options.

The IAS servers deployed in the Microsoft remote access infrastructure are equipped with two Intel Xeon processors running at 3.06 GHz, 2 GB of RAM, 34.4 GB of total hard disk capacity, redundant power supplies, and redundant fans.

SQL Server–Based Servers

Each IAS RADIUS server also acts as a collection point for client session data, running a lightweight, local Microsoft SQL Server™ 2000 application. SQL Server is used in the collection of infrastructure server performance data and client-specific data. The Microsoft SQL Server 2000 Desktop Engine (MSDE 2000), available as a free download with each copy of Windows Server 2003, runs on each of the IAS servers that are collecting client session data. IAS servers log the data to a local MSDE database. The data is transferred from MSDE to a central SQL Server database store in near real time.

There are also SQL Server–based data collection servers deployed regionally in the Microsoft remote access infrastructure to collect specific client session data. These servers are equipped with two Intel Xeon processors running at 3.06 GHz, 2 GB of RAM, 68.8 GB of total hard disk capacity, redundant power supplies, and redundant fans.

A high-end SQL Server–based server deployed for centralized data storage from all the collection servers in the Microsoft remote access infrastructure is equipped with four Intel Xeon MP processors running at 2.0 GHz, 2 GB of RAM, 430 GB of total hard disk capacity, redundant power supplies, and redundant fans. Automated reporting is then generated from this central store, posted, and used for analysis. The data is compiled and posted by means of a process that uses SQL Server 2000 Analysis Services, the Microsoft version of the Online Analytical Processing (OLAP) cube technology.

Network Requirements

The Microsoft IT solution for enhancing the security of remote access incorporates the following technologies to enable all remote access scenarios offered.

Cisco Routers

Cisco edge devices answer direct dial calls that arrive from the PSTN and that originate from the remote access client location. The routers accept either analog or ISDN calls. The router negotiates the remote client modem, negotiates the PPP connection, authenticates to the IAS server, assigns a client IP address, and handles DNS default gateway tasks (identifying and handing off to the appropriate VPN server address). After the physical or virtual circuit is created, the rest of the connection parameters can be negotiated.

Cisco routers are used in this direct dial role for Microsoft because they are readily available within the Microsoft network globally. The routers are convenient for supporting some of the regional Microsoft locations where the Internet is not readily available or is not reliable. However, Microsoft expects to eliminate virtually all direct dial devices as use of the Internet continues to grow. Microsoft IT observed a 27 percent reduction in direct dial usage from June 2004 through November 2004, and subsequently reduced the total direct dial devices used in the remote access infrastructure by 33 percent in the same timeframe.

Callback

With callback, the remote access server calls the remote access client after the user credentials have been verified. Callback can be configured on the server to call back the remote access client at a number specified by the user of the remote access client during the time of the call. A traveling user can thus dial in and have the remote access server call back at his or her current location, saving phone charges. Callback can also be configured to always call back the remote access client at a specific location, which is the most secure form of callback.

Note   The use of callback in the Microsoft IT remote access solution pertains only to the direct dial Cisco solution that is a part of the remote access service and is used as a cost containment strategy in the regions outside North America. Callback is not used with the ISP or VPN dial scenarios because these numbers are either Microsoft IT–managed local numbers or local client ISP numbers with no need for callback.

CHAP

CHAP is an encrypted authentication mechanism that avoids transmission of the actual password on the connection. The NAS sends a challenge, which consists of a session identifier (ID) and an arbitrary challenge string, to the remote client. The remote client must use the Message Digest 5 (MD5) one-way hashing algorithm to return the user name and a hash of the challenge, the session ID, and the client's password. The user name is sent as plaintext.

MS-CHAP

Microsoft created MS-CHAP to authenticate remote Windows workstations, providing the functionality to which LAN-based users are accustomed while integrating the hashing algorithms used on Windows-based networks.

MS-CHAP is an encrypted authentication mechanism very similar to CHAP. As in CHAP, the NAS sends a challenge, which consists of a session ID and an arbitrary challenge string, to the remote client. The remote client must return the user name and an encrypted form of the challenge string, the session ID, and the Message Digest 4 (MD4)–hashed password. This design provides an additional level of security because it allows the server to store hashed passwords instead of clear-text passwords. MS-CHAP also provides additional error codes, including a password expired code, and additional encrypted client/server messages that permit users to change their passwords during the authentication process. In MS-CHAP, both the access client and the NAS independently generate an initial encryption key for subsequent data encryption by MPPE. Therefore, MS-CHAP authentication is required to enable MPPE-based data encryption.

MS-CHAP v2

MS-CHAP v2 is an updated encrypted authentication mechanism that provides stronger security for the exchange of user name and password credentials and determination of encryption keys. With MS-CHAP v2, the NAS sends to the access client a challenge that consists of a session identifier and an arbitrary challenge string. The remote access client sends a response that contains the user name, an arbitrary peer challenge string, an encrypted form of the received challenge string, the session identifier, and the user's password. The NAS checks the response from the client and sends back a response containing an indication of the success or failure of the connection attempt and an authenticated response based on the sent challenge string, the peer challenge string, the encrypted response of the client, and the user's password. The remote access client verifies the authentication response and, if correct, uses the connection. If the authentication response is not correct, the remote access client ends the connection. MS-CHAP v2 also uses the MD4 hashing algorithm.

Using this process, MS-CHAP v2 provides mutual authentication—the NAS verifies that the access client has knowledge of the user's password and the access client verifies that the NAS has knowledge of the user's password. MS-CHAP v2 also determines two encryption keys, one for data sent and one for data received.

MPPE

MPPE encrypts only the data sent between the remote access client and the VPN server. Data encryption on a remote access connection is based on a secret encryption key known to the remote access server and remote access client. This secret key is generated during the connection authentication process. The VPN server can be configured to require data encryption. If the remote access client cannot perform the required encryption, the connection attempt is rejected.

MPPE uses the Rivest-Shamir-Adleman (RSA) RC4 stream cipher with 40-bit, 56-bit, or 128-bit encryption keys and is supported by Windows Server 2003, Windows XP, Microsoft Windows 2000, Windows NT 4.0, and PPTP-based VPN clients and servers. MPPE keys are generated from the MS-CHAP, MS-CHAP v2, or EAP-TLS user authentication process.

EAP

EAP is a PPP authentication protocol that allows for an arbitrary authentication method. EAP differs from the other authentication protocols in that it does not actually perform authentication during the authentication phase. Phase 2 for EAP only negotiates the use of a common EAP authentication method (known as an EAP type). The actual authentication for the negotiated EAP type is performed after Phase 2. EAP is a required protocol to support two-factor authentication in the Microsoft IT remote access solution.

Network Access Quarantine Control

Network Access Quarantine Control is a Windows Server 2003 feature that delays normal remote access to a private network until the configuration of the remote access computer has been examined and validated by an administrator-provided script. When a remote access computer initiates a connection to a VPN server, the user is authenticated and the remote access computer is assigned an IP address. However, the connection is placed in quarantine mode, with which network access is limited to specific resources. The administrator-provided script is run on the remote access computer. When the script is completed successfully, it runs a notifier component that notifies the remote access server that the remote access computer complies with current network policies. The remote access server removes quarantine mode and the remote access computer is granted normal remote access.

Network Access Quarantine Control is a combination of the following:

• A remote access server running Windows Server 2003 and a quarantine notification listener service. The solution also uses ISA Server 2004.
• A RADIUS server running Windows Server 2003 and IAS, configured with a quarantine remote access policy that specifies quarantine settings.
• A CM profile created with the Connection Manager Administration Kit (CMAK) provided in the Windows Server 2003 Resource Kit. The profile contains a network policy compliance script and a notify component.
• A remote access client that is running Windows XP or Windows Server 2003.

For more information about quarantine, see Network Access Quarantine Control in Windows Server 2003 on TechNet and ISA Server 2004 Technical Overview on TechNet.

Active Directory

In distributed computing environments, networked computers and other devices communicate over remote connections to accomplish tasks through client/server applications. Distributed environments require a central repository of information and integrated services that provide the means to manage network users, services, devices, and additional information that administrators want to store.

Microsoft IT, operating a distributed environment, needs an efficient way to manage all network resources and services. As the company grows, the need for a more secure and centralized management system becomes more critical. Active Directory fills this need.

Clients accessing Microsoft network resources by means of a remote access connection use Active Directory as they would on the corporate LAN. The Microsoft IT remote access solution uses Active Directory as an integrated function when a user is establishing the remote access connection and accessing resources after a connection is established.

Server Management Requirements

In the centralized management of the servers that compose the Microsoft IT remote access infrastructure, the operations support teams heavily use automated monitoring and alerting for real-time server health management. The teams also use remote management capabilities provided in the Windows Server 2003 family to support the Microsoft IT centralized management strategy.

Microsoft Operations Manager

MOM 2005 is an enterprise systems management application that uses a client agent to collect predefined events in a central database from event logs on monitored servers. It also creates, in response to predefined events or performance thresholds, alerts that are routed to central consoles monitored by the Microsoft IT 24×7 Data Center Operations staff.

The key Windows Server 2003 management data monitored includes server state, performance metrics, and service status. In addition to the out-of-the-box capabilities, MOM provides specific instrumentation for the remote access servers. MOM provides customizable knowledge scripts (KS) that enable system administrators to create specific management objects for the operating system or applications. Microsoft IT uses the MOM KS functionality extensively to create custom scripts for managing the services related to remote access. These scripts provide Microsoft IT with automated logging and alerting for specific events in the remote access scenarios.

Table 1 provides a sampling of MOM KS that Microsoft IT uses to manage remote access for all servers.

Table 1   MOM KS Used by Microsoft IT for All Data-Center Servers

Table 2 provides a sampling of KS specific to VPN and the IAS server.

Table 2   Examples of MOM Alert Functions Used by Microsoft IT Specifically for Remote Access Management

Microsoft IT uses a custom MOM management pack to manage specific events that are unique to the remote access environment. Microsoft IT provides tuning, consolidation, and feature feedback to the product development groups for inclusion in future MOM product versions.

For more information about deploying MOM within Microsoft IT, see the IT Showcase white paper titled Deploying Microsoft Operations Manager 2005 at Microsoft.

Remote Desktop Protocol and Remote Desktop for Administration

Microsoft IT uses the Remote Desktop Protocol (RDP) and Remote Desktop for Administration features of Windows Server 2003 and Windows XP Professional to manage remote access servers. These features also enable quick remote access to servers in a local region by the local operations teams.

RDP is used for communication between the Terminal server and the Remote Desktop Connection. RDP is encapsulated and encrypted within TCP/IP.

Enabled by Terminal Services technology, Remote Desktop for Administration is specifically designed for server management. As a result, Remote Desktop for Administration can be used on an already busy server without noticeably affecting processor performance. This capability makes it a convenient and efficient service for remote management. In essence, Remote Desktop for Administration is used to log on to the server remotely as though it were a local logon. This technology provides for more effective centralized management of the global infrastructure.

Client Requirements

The Microsoft IT remote access solution requires users to run Windows XP Professional or Windows Server 2003 on their client computers. Every remote access client is also required to use a customized CM application to manage each remote access session and to run the required security checks as part of the connection process. A personal smart card is used for authorization and authentication.

Windows XP Professional

Windows XP Professional, integrated with a Windows Server 2003 infrastructure, provides significant improvements from previous versions of Windows client and server products in the management and performance features for end-to-end security. The security enhancements enabled by Windows XP Professional are as follows:

• Smart cards.
• Kerberos.
• Network Access Quarantine Control.
• Windows Firewall (ICF).
• Windows Firewall (provided with Windows XP Service Pack 2).
• Internet Protocol Security (IPsec).
• Blank password restrictions.
• Personal privacy.
• Credential management.
• PKI and Certificate Services.
• Delta certificate revocation lists (CRLs).
• Bridge certification authority (CA) configurations.
• Unified user management through Active Directory.

The most significant Windows enhancements used in the enhanced-security Microsoft IT remote access solution will be discussed throughout this paper.

To run Windows XP Professional, client computers must meet or exceed the following specifications:

• A 233-megahertz (MHz) clock-speed microprocessor (single-processor or dual-processor system). A 300-MHz or higher clock-speed microprocessor was recommended. Recommendations also included the Intel Pentium/Celeron family, the AMD K6/Athlon/Duron family, or other compatible microprocessors.
• 128 MB of RAM.
• 1.5 GB of available hard disk space.
• Super VGA (800 × 600) or higher-resolution video adapter and monitor.
• CD-ROM or DVD drive.
• Keyboard and mouse or compatible pointing device.
• 14.4–kilobits per second (Kbps) modem or a network connection.

Authentication and Authorization Technologies

The distinction between authentication and authorization is important in understanding why connection attempts are either accepted or denied:

• Authentication is the verification of the credentials of the connection attempt. This process consists of sending the credentials from the remote access client to the remote access server by using an authentication protocol.
• Authorization is the verification that the connection attempt is allowed. Authorization occurs after successful authentication.

For a connection attempt to be accepted, it must be both authenticated and authorized. In the Microsoft IT solution, the remote access server is configured for RADIUS authentication, so the credentials of the connection attempt are passed to the RADIUS server for authentication and authorization. If the connection attempt is both authenticated and authorized, the RADIUS server sends an accept message back to the remote access server and the connection attempt is accepted. If the connection attempt is either not authenticated or not authorized, the RADIUS server sends a reject message back to the remote access server and the connection process is denied.

Microsoft IT applies the following specific technologies to the authentication and authorization functions in its remote access solution.

Challenge Handshake Authentication Protocols

In the Microsoft IT solution, the encrypted exchange of user credentials for authentication is performed by means of CHAP, MS-CHAP, or MS-CHAP v2 authentication protocols when connecting to a Microsoft IT direct dial router or by means of a dial-up connection through an ISP. For details about which protocol is used in which scenario, refer to Figure 1 earlier in the paper.

The remote access server is configured to require specific secure authentication methods. If the remote access client cannot perform the required secure authentication methods, the connection is denied.

Kerberos

Kerberos provides industry-standard and high-strength authentication with a fast, single logon to Windows Server 2003–based enterprise resources. Kerberos is an Internet standard, which makes it especially effective for networks that include different operating systems. Windows XP Professional offers the single logon for end users for resources and supported applications hosted on Windows Server 2003.

EAP

EAP allows for arbitrary authentication mechanisms to be employed for the validation of a PPP connection. With PPP authentication protocols such as MS-CHAP, a specific authentication mechanism is chosen during the link establishment phase. Then, during the connection authentication phase, the negotiated authentication protocol is used to validate the connection. The authentication protocol itself is a fixed series of messages sent in a specific order.

With EAP, the specific authentication mechanism is not chosen during the link establishment phase. Instead, each PPP peer negotiates to perform EAP during the connection authentication phase. When the connection authentication phase is reached, the PPP peers must first negotiate the use of a specific EAP authentication scheme known as an EAP type. After the EAP type is agreed upon, EAP allows for an open-ended conversation between the remote access client and the remote access server. The conversation consists of requests for authentication information and the responses and can vary based on the parameters of the connection. The length and detail of the authentication conversation depend on the EAP type.

For example, when EAP is used with smart cards and certificates, the remote access server can separately query the remote access client for a name, personal identification number (PIN), and card certificate value. As each query is asked and answered, the user passes through another level of authentication. When all questions have been answered satisfactorily, the user is authenticated and permitted access to the network.

Architecturally, EAP is designed to allow authentication plug-in modules at both the client and server ends of a connection. By installing an EAP type library file on both the remote access client and the remote access server, a new EAP type can be supported. This opportunity enables vendors to supply a new authentication scheme at any time. EAP provides the highest flexibility in authentication uniqueness and variations.

EAP-TLS

EAP-TLS is a type of EAP based on Secure Sockets Layer (SSL) and public key certificates and is used in certificate-based security environments. Using smart cards for remote access authentication (as Microsoft IT has deployed) requires the use of the EAP-TLS authentication method. The EAP-TLS exchange of messages provides mutual authentication, negotiation of the encryption method, and encrypted key determination between the remote access client and the authenticator. With EAP-TLS, a client presents a user certificate to the dial-in server, and the server presents a server certificate to the client. The first exchange provides strong user authentication to the server; the second exchange provides assurance that the user has reached the server that he or she expected. Both systems rely on a chain of trusted authorities to verify the validity of the offered certificate.

EAP-TLS is supported only on servers that are running Routing and Remote Access, that are configured to use Windows authentication, and that are members of a domain. A remote access server running as a stand-alone server or as a member of a workgroup does not support EAP-TLS.

In the Microsoft IT remote access solution, the user's certificate is stored on a smart card. The certificate can be accessed only with some form of PIN or name-and-password exchange between the user and the client computer.

Note   The user's certificate can also be stored on the VPN client computer.

EAP-TLS is the most secure form of user authentication and is supported in Windows Server 2003 and Windows XP. Like MS-CHAP and MS-CHAP v2, EAP-TLS returns an encryption key to enable subsequent data encryption by MPPE.

EAP over RADIUS

EAP over RADIUS is not an EAP type, but refers to the passing of EAP messages of any EAP type by the remote access server to a RADIUS server for authentication. The EAP messages sent between the remote access client and VPN server are encapsulated and formatted as RADIUS messages between the VPN server and the RADIUS server. The VPN server becomes a pass-through device, passing EAP messages between the remote access client and the RADIUS server. All processing of EAP messages occurs at the remote access client and the RADIUS server.

EAP over RADIUS is used in environments where RADIUS is the authentication provider. An advantage of using EAP over RADIUS is that EAP types need to be installed only at the RADIUS server, instead of at each remote access server.

In a typical use of EAP over RADIUS, the remote access server is configured to use EAP and to use RADIUS as its authentication provider. When a connection attempt is made, the remote access client negotiates the use of EAP with the remote access server. When the client sends an EAP message to the remote access server, the remote access server encapsulates the EAP message as a RADIUS message and sends it to its configured RADIUS server. The RADIUS server processes the EAP message and sends back a RADIUS-encapsulated EAP message to the remote access server. The remote access server then forwards the EAP message to the remote access client.

Mutual Authentication

Mutual authentication is obtained by authenticating both ends of the connection through the encrypted exchange of user credentials. This authentication is possible through either the EAP-TLS or MS-CHAP v2 authentication protocol. During mutual authentication, the remote access client authenticates itself to the remote access server, and then the remote access server authenticates itself to the remote access client.

It is possible for a remote access server to not request authentication from the remote access client. However, in the case of a remote access client running Windows XP or Windows 2000 and configured for only MS-CHAP v2 or only EAP-TLS, the remote access client enforces the authentication of the server. If the remote access server does not respond to the authentication request, the client ends the connection.

Caller ID

Caller ID can be used to verify that the incoming call is coming from a specified phone number. Caller ID is configured as part of the dial-in properties of the user account. If the Caller ID number of the incoming connection for that user does not match the configured Caller ID, the connection attempt is rejected.

Caller ID requires that the caller's phone line, the phone system, the remote access server's phone line, and the Windows driver for the dial-up equipment all support Caller ID. If a Caller ID is configured for a user account and the Caller ID is not being passed from the caller to the Routing and Remote Access service, the connection is denied.

Caller ID is a feature designed to provide a higher degree of security for networks that support telecommuters as part of the business model. The disadvantage of configuring Caller ID is that the user can dial in only from a single phone line.

In the Microsoft IT solution, Caller ID is used only in the callback scenario for those dialing directly to a Microsoft IT–managed router by means of a phone number in CM.

Packet Filtering for VPN Remote Access

For VPN-based remote access at Microsoft, the VPN remote access server is either directly connected to the Internet or connected to a network segment between the Microsoft corporate network and the perimeter network (also known as DMZ, demilitarized zone, and screened subnet). In either configuration, the VPN remote access server is vulnerable to attacks from malicious Internet users. To prevent the VPN remote access server from receiving or sending any traffic that is not PPTP based, IP packet filters for PPTP traffic are configured on the interface of the VPN remote access server that is connected to either the Internet or the perimeter network.

CM and Managed Remote Access Connections

CM is an application provided in the Windows Server 2003 Resource Kit that runs on the client computer and, as part of the Microsoft IT–based remote access solution, provides any authorized Microsoft end user a single vehicle for quick and reliable access to corporate resources globally. The primary purpose of CM is to centralize and automate the establishment and management of various kinds of network connections. Key areas managed by CM are global phone books for access points worldwide through established service providers, security checks to automatically and interactively manage client computer configurations, and various system security checks and validations at logon. CM consists of various modules, many of which are internally customized for the specific Microsoft remote access implementation. CM plays a central role in the management of remote access security for Microsoft in addition to managing the overall user logon experience.

One key feature of CM is the client dialer software that is installed on each remote access client. The client dialer software includes advanced features that make it a superset of basic dial-up networking. At the same time, CM presents a simplified dialing experience to the Microsoft user. It limits the number of configuration options that a user can change to help ensure that the user can always connect successfully. The following are examples of Microsoft IT custom actions regarding the CM client dialer:

• Users select from a list of phone numbers to use, based on physical location.
• Users see customized graphics, icons, messages, and Help.
• Users automatically create a dial-up connection before the VPN connection is made.
• Users run custom actions during various parts of the connection process, such as pre-connect and post-connect actions (run before or after the dial-up or VPN connection is completed).

A customized CM client dialer package, also known as a profile, is a self-extracting executable file that is created by a network administrator through the CMAK. Microsoft IT distributes the CM profile to VPN users by means of CD-ROM, e-mail, Web site, or file share. When a user runs the CM profile, it automatically configures the appropriate dial-up and VPN connections. The CM profile does not require a specific version of Windows—it will configure connections for computers running Windows Server 2003, Windows XP, Windows 2000, Windows NT 4.0, Microsoft Windows Millennium Edition, and Microsoft Windows 98.

Connection Point Services (CPS), another feature of CM, enables Microsoft IT to create, distribute, and update custom phone books. Phone books contain one or more point of presence (POP) entries. Each POP has a telephone number used to access a dial-up network or the Internet. This phone book provides Microsoft users complete POP information, so when they travel, they can connect to different corporate or Internet access points based on location, rather than having to use a toll-free or long-distance number.

Without the ability to update phone books, users would not only have to contact Microsoft IT's technical support staff to obtain changes in POP information, they would also have to reconfigure their client dialer software each time they attempted to make a remote access connection.

CPS is a combination of:

• Phone Book Administrator. A tool used to create and maintain phone book files, and to publish new or updated phone book files on the phone book server.
• A phone book server. A computer running Windows Server 2003 and Internet Information Services (IIS) (including the File Transfer Protocol [FTP] Publishing Service) and an Internet Server Application Programming Interface (ISAPI) extension that processes phone book update requests from CM clients.

After the phone book is configured and published, the CM profile is created through CMAK and configured.

Microsoft IT elected to outsource VPN access to a third-party service provider as part of the business strategy for global remote access by means of the Internet. With more than 400 sites worldwide, there are multiple local phone numbers that employees can use within each country or region—depending on the physical location of an office—to reach the corporate network over the Internet. Microsoft IT uses the client dialer and CPS components of the CM application as an effective means of centrally managing global phone numbers for initial Internet access as an element of the remote connection to the corporate network.

CM is designed to be independent of the actual types of connections that it establishes. Therefore, as long as CM enumerates the connection properly by using CPS, CM can handle most types of connections, including PPP, VPN, and proxy server connections. The automatic actions and optimizations that CM enables are supported by a detailed knowledge of the available connection options and their properties. Microsoft IT preconfigured this information in CM. In a vast majority of cases, users do not have to enter, understand, or be aware of any of this information.

To use a custom configuration of CM to establish remote connections, each client must be preconfigured to provide the management to make a connection with many globally deployed servers. For a small business with a limited number of clients, each client can be configured manually. However, Microsoft IT needed to configure the dial-up and VPN connections for tens of thousands of clients and hundreds of access phone numbers globally. This task required the CM configuration to incorporate the following considerations:

• The exact procedure used to configure a dial-up or VPN connection varies, depending on many factors.
• To prevent configuration errors, the decision was made to have Microsoft IT staff—not end users—configure the dial-up or VPN connection.
• To manage configurations for enhanced security on remote connections, it was necessary to have some functions be dynamic and managed by the Microsoft IT staff to ensure security compliance when any user attempts to establish a remote connection to the Microsoft network.
• To best utilize Microsoft IT staff resources, the configuration method developed had to be able to scale to a global enterprise.
• Some dialed VPN connections require a double-dial configuration, in which users access the corporate network through one of the private dial-up routers before creating a VPN tunnel.

CM is designed to be flexible so that IT administrators can write and insert modules based on an organization's specific requirements for management or security. The Connection Manager Administration Kit wizard guides you through a variety of options when you are configuring a CM profile and creates the profile to distribute to your dial-up and VPN users. For more information, please refer to CMAK information on TechNet.

CM supports a variety of features that both simplify and enhance implementation of connection support for users. These features, shown in Table 3, were incorporated into the Microsoft IT solution by means of the CMAK wizard.

Table 3   Examples of CM Capabilities for Local and Remote Connections Used by Microsoft IT

CM VPN Connection Capabilities

In addition to the support for basic dial-up connections, Microsoft IT used the CMAK wizard to incorporate support for VPN connections by means of a tunneling protocol to tunnel through a public network (such as when dialing in to an ISP to access a corporate server). CM can create a VPN connection through a pre-existing dial-up session, a local area network (LAN), a digital subscriber line (DSL), or a persistent connection (such as broadband cable). Table 4 shows some of the CM capabilities used by Microsoft IT.

Table 4   Examples of CM Capabilities for VPN Connections Used by Microsoft IT

CM Custom Actions

Microsoft IT enhances the connection experience for its users by providing additional programs that start seamlessly during the connection to the remote access service. Microsoft IT uses the CMAK wizard to include custom actions in CM profiles to automatically start programs when users connect to the service.

Using the CMAK wizard, Microsoft IT specified custom actions in CM to run at five points during the connection process:

• Pre-init actions. As soon as users start CM, it runs the pre-init actions specified in the CM service profile. These actions are run before the CM logon screen appears. Note that CM pre-init actions are run when the Properties dialog box is selected for the service profile.
• Pre-connect actions. As soon as users click Connect, CM runs the pre-connect actions specified in the service profile. These are run before CM establishes a connection to the remote access service. For actions that relate specifically to tunneling, CM uses pre-tunnel actions.
• Pre-tunnel actions (for VPN). CM runs pre-tunnel actions after establishing a connection with the Internet server (if one is used) but before establishing a tunnel to the VPN server. This type of action is available only if VPN is set up in a CM service profile, and it will run only when users are using the VPN connection option.
• Post-connect actions. CM runs post-connect actions after establishing a tunnel. Each post-connect action specified in the CMAK wizard runs every time the user connects to Microsoft IT's remote access service. SRU is the only post-connect action specified to run under CM control.
• Disconnect actions. CM runs disconnect actions immediately before disconnecting from the service. Microsoft IT uses the disconnect actions for routine administration. For example, a custom action might be set up to collect status information from the service, such as total minutes online (if this information is tracked). This information can then be displayed for the user or used by the operations team to analyze the user experience.

Note   Disconnect actions will run even if CM did not cause the disconnection. For example, if a disruption in telephone service ends the user's connection, CM will attempt to run the disconnect actions specified in the service profile after the unexpected disconnection.

SRU Components and Processes

The SRU application and scripts help secure remote connections made to the Microsoft corporate network by mobile users (with corporate computers) and home users (with personal computers) by enforcing various security policies and processes. Additionally, SRU is designed to enable various capabilities—for example, installing an update or installing various certificates—that enhance the remote access experience for the user. The core piece to this process is an internally developed application called Sremotac.exe. This self-updating application starts various security processes that check the local computer and alters configuration settings to help secure a connection to the corporate network.

Microsoft IT developed SRU scripts to integrate closely with CM. The scripts are essentially a set of predetermined custom actions to meet the specific requirements of Microsoft IT security efforts for remote access. CM is the application vehicle that calls the dynamic-link library (DLL) called Sremotac.dll to start the specific SRU scripts.

The following are examples of required scripts that are currently being run within the SRU environment:

• Credential Harvester. Stores NTLM credentials.
• Windows Firewall check. Checks to ensure that the Windows Firewall is enabled correctly on the LAN/WAN interface. If it is not, the option is given to enable it. If a client does not have Windows Firewall enabled, the user is disconnected.
• Hotfix installation. Checks for the existence of a specified hotfix. If the hotfix is not on a computer, the user is prompted to install it.
• Antivirus check and signature update. Checks to make sure an antivirus tool is installed and running on a computer; updates signature file as necessary.
• IPsec policy deployment. Loads local IPsec policy on the computer that is used for IPsec communication if the client computer is not joined to a domain. Also checks for a valid machine certificate and installs the certificate if it is not present or if it is expired.
• Installation of security updates. Scans for security updates and installs missing updates.
• Password expiration. Checks the password age for the domain account and notifies the user if the password needs to be changed.
• Smart card certificate expiration. Checks the smart card certificate and notifies the user if certificate renewal needs to occur.
• Export of client connection data to regional collection servers. Uploads client connection data to a data collection server.

New checks can be added in the future or existing checks can be removed. Additionally, the order of processing can be changed based on security, user experience, or other business criteria. An initialization file called Sremotac.ini is used to configure the checks to be performed. This initialization file also includes any parameters that will be passed to the executable files that are being started to do these checks.

Sremotac.exe is started by Sremotac.dll, which is called by CM on pre-init, pre-connect, pre-tunnel, post-connect, and disconnect actions. After starting the Sremotac.exe executable file, this DLL checks for the return value. If the return value is NEW_FILE_COPIED, the DLL swaps the old Sremotac.exe with a newly copied Sremotac.exe and restarts the newly copied file.

All message boxes displayed during post-connect have a 30-second timer built in. If a user fails to respond to a prompt within the 30-second timer, the support script will send a "Process Fail" signal to the calling executable file, Sremotac.exe. Sremotac.exe, depending on whether the Mandatory flag is set in the Sremotac.ini file for each support script, will initiate a disconnect action or just ignore the result and continue processing.

The SRU environment also applies time stamps for remote access metrics. The time-stamp functionality is implemented internally within Sremotac.exe. However, the gathering and posting of the data is implemented through a separate, custom component of CM.

Sremotac.exe and Sremotac.dll have been revised to support Unicode strings for logging and configuration settings. Sremotac.exe also uses a separate resource DLL for icons and all graphical user interface (GUI)–related text items, such as a Help pop-up window.

Figure 2 shows the computer management function in the Microsoft IT implementation of CM with custom SRU scripts.

Figure 2   CM and SRU script functions

Sample VPN scripts similar to those that Microsoft IT uses for verifying client health configurations in a quarantine network are available for download and customization.

Smart Cards

With the steadily increasing security threats to corporate and government network assets, especially with regard to remote access, Microsoft sought to implement two-factor authentication as a key element of the enhanced-security remote access solution. As opposed to the simple user name and password method of helping to secure network assets, two-factor authentication consists of something the user has—the smart card—and something the user knows—the smart card's access PIN, an encrypted alphanumeric code set by the individual card owner and stored on the card. The requirement that a user must have a smart card for remote access authentication significantly reduces the likelihood that an intruder will gain access to the corporate network.

Microsoft IT considered several alternative technology solutions before selecting the smart card, including biometrics, such as thumbprint and handprint scanners; hardware tokens, such as Secure ID, a keychain-sized device that automatically calculates new passwords on predefined intervals to match the similar password-changing device on the authentication server; and universal serial bus (USB) token reader devices that are somewhat similar to smart cards. However, some of the alternative solutions were less robust and very expensive per employee when compared with smart cards. In addition, smart cards are not overly burdensome for remote users to employ, take advantage of technologies found in the existing Windows 2000 Server and Windows Server 2003 infrastructure (including Certificate Services, PKI security, cryptographic service provider [CSP], and EAP-TLS) at Microsoft, and present Microsoft IT with an extensible platform for the future development of internal applications.

Smart cards are essentially tamper resistant. The smart card operating system used in the Microsoft IT solution, Microsoft Windows for smart cards, will render a card useless if anyone tampers with it. Without a smart card reader, the data that the card contains—including the logon certificate's private key, the e-mail signing certificate, and the user's personal information—cannot be accessed and the card is not usable. Even with a smart card reader, the user must know the PIN associated with the card to access the card's contents. The cardholder can be authorized to access only a particular range of data on the card or to carry out a particular range of activities with the card. If an employee loses a smart card, it is a simple administrative process to revoke the validity of the lost network logon certificate, thereby rendering the lost smart card unusable for remote access. These measures help ensure the security of the data stored on the smart card.

Certificates issued on smart cards may differ from certificates stored on disk, and they can be distinguished by the smart card logon Extended Key Usage (EKU) within each certificate. During the authentication process, the RADIUS server validates the certificate and the smart card logon EKU to ensure that the certificate used was from the smart card.

The open Windows for smart cards operating system allows both third-party and in-house development and can hold information for additional applications, such as specialized digital certificates. Because smart cards are portable, users can carry personal security certificates and their corresponding key pairs with them wherever they go. Smart cards also enhance software-based solutions, including strengthened authentication processes such as local logon, WAN logon, and application authentication.

With smart cards, the remote access logon process is as follows:

1. The employee inserts a smart card into the smart card reader device connected to the client computer. The connection sequence, managed through the customized installation of Windows XP Professional CM, starts by activating the smart card reader. A dialog box requesting the card's PIN is displayed.
2. Successfully entering the PIN unlocks the card and allows the remainder of the remote access logon process to continue. CM initiates the connection to the dial-up or VPN server. Card management software on the client retrieves information from the logon certificate from the card. The private key for the certificate never leaves the card.
3. The EAP-TLS security protocols verify that the client has the certificate and the private key and send the certificate information to the IAS server on the corporate network.
4. By using RAP, the IAS server manages the authentication policy for processing, sending the authentication accept packet to the corporate Active Directory database and the RQS timeout to the VPN server.
5. ISA Server places the connection in quarantine while the certificate is validated to Active Directory, where the certificate is checked for authenticity and verified against the CRL to ensure that it is not revoked.
6. If the certificate is valid, the user is authenticated.
7. The user is able to access all of his or her network data and resources.

Figure 3 illustrates this process.

Figure 3   Smart card logon process

The smart card selected by Microsoft IT is essentially a 32-bit microprocessor and memory chip embedded on a card. Most smart cards available today contain between 4 kilobytes (KB) and 128 KB of RAM for data storage. The expected life span of a typical smart card is 18 to 24 months.

The smart card solution implemented by Microsoft IT has five main components: the smart card, the required client hardware, client-side software, server-side software, and network requirements. Table 5 summarizes the components that make up each element.

Table 5   Elements of the Smart Card Technology in the Microsoft Remote Access Solution

Deploying Smart Cards

Microsoft IT had to investigate and resolve bugs or incompatibilities with Microsoft products and third-party products used in the solution, such as Cisco routers and smart card readers. Compatibility had to be validated as a part of the development cycle, before the final design was deployed.

To avoid giving employees an additional card or device to carry (and possibly lose), a 32-KB cryptographic processor smart card chip was embedded into the standard RFID cardkeys issued to employees for access to Microsoft buildings. Thus, employees need only one card to access Microsoft physical assets and network assets.

After the smart cards were manufactured, Microsoft IT took great care in getting the correct cards into the hands of the correct users. The smart card deployment operation strictly limited the number of people authorized to distribute the new smart cards. Microsoft IT created a centralized card management team with responsibility for card issuance, card administration, and Tier 2 user support (that is, user support beyond Helpdesk, Tier 1 in the Microsoft support organization). Because Microsoft is a global enterprise with clients across the world, replacing broken or lost smart cards is an operational challenge. Using custom-developed tools and Windows Server 2003, Microsoft IT was able to create a process by which trusted delegates in regional offices could request replacement certificates on behalf of their clients.

Security officers distributed the smart cards to employees after verifying their identities. After a recipient's identity was confirmed, the security officer exchanged the old RFID building access badge for the new smart card RFID badge, along with a CD-ROM containing the necessary software for card use. Users were required to use the CD-ROM software to set their PINs prior to logging on to the network remotely for the first time.

Microsoft made the smart card reader hardware available as corporate standard equipment. The readers cost between $12 and $25 U.S., depending on the interface type (PC Card, USB, or serial) and manufacturer. The solution also required the deployment of RAP on the VPN/RADIUS infrastructure servers. RAP requires the use of the native mode of Active Directory in either Windows 2000 Server or Windows Server 2003.

Installing a Cryptographic Service Provider

Every client computer needed to install a CSP to enable access to the contents of the smart card's chip. A CSP:

• Performs all smart card cryptographic operations, such as digital signing.
• Manages private keys.
• Facilitates more secure communication between the client computer's smart card reader and the smart card.

A CSP is specifically designed to work with a particular smart card operating system so that it can read the certificate stored on the smart card. As a result, the smart card CSP can instruct the smart card to complete specific cryptographic operations.

Although each smart card solution vendor provides a CSP to be used for reading the card information from the operating system on its smart cards, not all CSPs are the same. The card management team at Microsoft tested several CSPs built for use with Windows for smart cards and discovered that the level of performance and card security provided by those CSPs varied greatly. Additionally, many CSP solutions were not designed to scale up to the enterprise-level solution that the card management team needed. After determining that none of the commercially available CSPs built to work with Windows for smart cards met its specific security and performance needs, the card management team worked with the Windows product development team to create a new Microsoft CSP that fully met its requirements. This new CSP was based on a new smart card framework that Microsoft was already developing.

The CSP developed by Microsoft is small, efficient, fast, and reliable; offers a high degree of security; and offers clear error messaging for users. In short, the CSP's performance met all Microsoft IT requirements for its clients. Currently, the Microsoft CSP is available only for internal use. However, in the near future, the Windows product development group is planning to make its smart card framework available to allow vendors to add support for their smart card solutions.

Public Key Infrastructure and Certificates

Many of the techniques and products available to help provide security for an enterprise employ some form of cryptography. A PKI, whether self-hosted or third party, is required to provide the certificates to verify and authenticate the validity of each party involved in a cryptographically secured electronic transaction. A PKI has to be in place to take advantage of the security measures that build upon it.

A PKI is a set of services provided by a collection of interconnected components that work together to provide public key–based security services, such as privacy, authentication, and non-repudiation. A PKI offers a strong form of authentication because private identification keys are stored locally, eliminating the need for databases that contain valuable confidential information. Using external credentials, with a minimal number of trust relationships, reduces the need to verify that multiple third parties follow their prescribed policies and procedures. Microsoft uses certificates for several PKI-enabled services in its remote access infrastructure, requiring certificate issuance both within the organization and for external partners.

PKI provides the ability to:

• Manage keys. A PKI makes it easy to issue new keys, renew or revoke existing keys, and manage the trust level attached to keys from different issuers.
• Publish keys. A PKI offers a well-defined way for clients to locate and retrieve public keys and information-specific key validity. Without the ability to retrieve keys and know that those keys are valid, users cannot use public key services.
• Use keys. A PKI provides an efficient way to use keys—not just by moving keys to where they are needed, but also by providing easy-to-use applications that perform public key cryptographic operations to help provide increased security for e-mail, e-commerce, and networks.

Because the number of applications using certificates at Microsoft continued to grow, Microsoft IT deployed Windows 2000 Certificate Services to provide a CA. A CA acts as a guarantor of the relationship between the subject's public key and the subject's identity information that the certificates contain.

For the smart card deployment, Microsoft used its existing PKI (one of the largest in the world), delivered through Windows 2000 Server and Windows Server 2003 Certificate Services. Because Microsoft uses Windows 2000 Server and Windows Server 2003 across the enterprise, Microsoft IT did not need to use external, third-party PKI CA services to deploy smart cards. Using the existing, self-hosted PKI infrastructure has yielded significant savings in per-certificate fees, has enabled Microsoft IT to share the PKI services across many different implementations, and has enabled Microsoft IT to maintain control of the security of its network environment.

The Microsoft IT PKI hierarchy does not have a persistent connection to the external public root; rather, the external public root CA signs the certificates used within the Microsoft IT additional certificate hierarchy only once. This intermediate CA issues a certificate for issuing CAs, which then issue certificates to the publicly available Microsoft Web sites. This PKI hierarchy allows Microsoft IT to issue SSL certificates to the publicly available Web servers so that Microsoft does not need to purchase these SSL certificates from a third party. All of the CAs, as shown in Figure 4, are housed in a secure vault controlled by Microsoft IT.

Figure 4   Microsoft PKI hierarchy

All of the features of the Microsoft PKI are implemented on industry standards such as X.509, Lightweight Directory Access Protocol (LDAP), SSL/TLS, Secure/Multipurpose Internet Mail Extensions (S/MIME), IPsec, and the public key extensions of Kerberos version 5.0. Using industry-standard technologies enables interoperability with third-party applications and PKIs.

By designing, implementing, and supporting a PKI that uses a self-signed root authority certificate and a separate hybrid PKI for enabling Web-facing SSL, Microsoft IT accomplished the following goals for the PKI implementation at Microsoft:

• Increased security, increased application compatibility, and reduced infrastructure costs.
• Deployment of a self-hosted PKI solution that is easy to manage, conforms to industry standards, and is scalable to meet the demands of a growing infrastructure.

User Education

Microsoft IT embarked on a broad user education campaign as another key element in the deployment of the remote access solution with new security management and enforcement technologies. It was important for users to become familiar with the new requirements and implications prior to full security enforcement. Examples of education methods used include:

• Internal and external Web sites
• Targeted and/or broad e-mail messages
• Focused communications to regional account managers
• Updated security information, including best practices, posted on the internal Microsoft IT security Web site for users to reference at any time
• Project status updates at the Microsoft IT internal site
• Printable information for quick reference
• Articles in the internal Microsoft newspaper
• Communication of the SRU initiative with end users at every opportunity

Over time, users became more familiar with how to handle various security risks for Internet and remote access users, such as how to better recognize suspicious, potentially damaging files or attachments before activating them or introducing them to the corporate network, or the importance of isolating the client computer when connected to corporate resources remotely. Through a coordinated communication strategy, Microsoft IT has been able to cultivate a user community that is knowledgeable and savvy about not only remote access security, but security overall.

Alignment with Microsoft Operations Framework

To develop, test, and deploy the SRU solution in the most advantageous way, Microsoft IT aligned its processes and procedures with MOF principles. MOF provides Microsoft IT and Microsoft customers a collection of best practices, principles, and models that provide guidance for achieving high availability, reliability, and security on production systems built on Microsoft products and technology.

The teams within Microsoft IT aligned with MOF in the areas discussed in the following sections. For more information about MOF, go to the MOF Web page on TechNet.

Change Management

A management steering committee was formed to oversee the budget, phased schedules, and development of solution components, and to provide final approval for each phase of the project. This committee served as the Change Advisory Board (CAB).

Microsoft IT completed rigorous testing and pilot deployments prior to implementing changes in the production environment. In addition, Microsoft IT adhered to a specific, defined process for scheduling changes and providing clear communication to management, users, and Helpdesk.

Virtual teams within Microsoft IT were established around the world. These teams worked closely to design, develop, and test the design and technologies in differing scenarios. These teams then worked to schedule, communicate, and manage the change in the remote access environment during the actual deployment of the new systems and technologies.

In addition, Microsoft IT worked with the operations support teams to schedule changes, in part based on the time of day that would have the smallest impact on users or business units. In most remote access scenarios, the best time to make major changes is during the business day, because remote access is most heavily used outside core business hours. However, with the increased use of remote access in supporting business strategy during core business hours at Microsoft, this is not always the case.

Operations

From the pilots, Microsoft IT developed and distributed technical support documentation to the Tier 1 and Tier 2 support teams in advance of deployment. Microsoft IT also provided training sessions to complement the documentation and incorporate productive feedback where possible.

Microsoft IT developed and implemented specific monitoring and alerting to be in place prior to, or parallel to, deployment. This work may not always be possible to complete prior to getting a solution into production, but effectively managing the systems and the service is a critical part of the operations support of any new technology deployment.

To pinpoint trouble areas during deployments, Microsoft IT used data collection and analysis. Microsoft IT created a key process element that is extremely useful in helping to manage service health: a remote access "dashboard" report to capture, trend, and break down single user incidents that indicate broad problems. A user incident is a singular event that results in a single ticket. A problem is derived from analyzing the ticket data, among other performance indicators, to isolate and identify a root cause and develop focused action plans. The dashboard measures multiple performance indicators and can contain whatever an IT support organization feels are important measurements to capture for a particular service.

Data collection and analysis are critical to the management of the service during any major changes and in the steady-state service management functions. Combining collected data and reports with ticket handling data, the overall health of the service can be determined with a high degree of confidence at any given time. Teams can also use this data to look back at any service-affecting event, correlate the effects to the service, and build proactive response plans and future predictability.

Granular data is extremely valuable, whether used daily or for trending over time. The Microsoft IT operations support teams use SQL Server and OLAP to generate reports to track, measure, and quickly analyze:

• Overall health of the service globally with the ability to focus on specific areas.
• Infrastructure data that reflects server health and performance.
• Client data that reflects specific user experiences, such as time to connect, first-time success, specific actions that may be failing, user location, and ISP access number used.
• Any broad service-affecting issues that also affect user productivity.
• Largest cost drivers, in detail, for service cost containment.
• Ticket resolution against service level agreement (SLA) to target improvements to processes or documentation.

Figure 5 shows a sample 90-day trend for remote access–related troubleshooting tickets handled by Helpdesk.

Figure 5   Ninety-day ticket totals by month

Figure 6 shows long-term and average ticket trends for remote access.

Figure 6   Long-term and average ticket trends

Figure 7 shows 90-day infrastructure tickets by priority for remote access.

Figure 7   Ninety-day infrastructure ticket trends by priority

Figure 8 shows 90-day proactive infrastructure tickets for remote access.

Figure 8   Ninety-day proactive infrastructure ticket trends

Figure 9 shows the correlation of ticket trends and changes to the service.

Figure 9   Ticket trend and service change correlation

Figure 10 shows a breakdown of the incidents related to Helpdesk tickets for one month.

Figure 10   Sample of monthly incident analysis

Support

The better an IT organization equips the service desk to support new technologies or processes, the better the incident management and feedback will be to correct negative trends quickly. Microsoft IT therefore engaged the Helpdesk organization early and often in the technical aspects and training for supporting the deployment. Microsoft IT also put a problem management plan in place during the implementation of the remote access SRU technologies to analyze incidents, identify and isolate broad problems, and quickly work to resolve problems.

Optimization

Near the end of the deployment, the Microsoft IT teams began to shift the focus of the service management efforts to tuning the new solution. Teams analyzed existing metrics and now had time to develop new metrics, searching for lingering areas of concern to improve, such as capacity, ISP performance, CM/SRU application streamlining, or system performance. Microsoft IT also surveyed users throughout the project to get candid input on impacts to service usability and the perception of service health overall.

Data gathering tools and detailed data analysis—for example, through the dashboard report—played an important role in maintaining client satisfaction during security upgrades and continues to support the day-to-day analysis of service health.

Lessons Learned and Best Practices

As part of the implementation of the broad SRU initiative and with the development and deployment of new technologies to meet the initiative's objectives, Microsoft IT learned a number of important lessons and developed or applied many best practices for upgrading and optimizing the remote access service at Microsoft.

Manage Risk

At Microsoft, risk is acknowledged as a fundamental part of operations that is neither good nor bad. A risk is the possibility of a future loss, and although the loss itself may be seen as bad, the risk as a whole is not. Risk is not something to fear; it is something to manage. Operations teams deal with risks by actively addressing each identified risk in advance. If a loss is one possible future outcome, other possible outcomes are gains, smaller losses, or larger losses. Risk management lets the team change the situation to favor one outcome over the others.

Manage the risk in the internal operational environment with rigid processes for:

• Receiving and acting on security bulletins.
• Scanning the environment.
• Configuration compliance, service pack compliance, and patch management.
• Detailed metrics analysis.
• Actively managing employee education and communication by partnering with the user community and clearly setting expectations throughout a major project.

Establishing disciplined, repetitive processes as part of the operational support model will maximize the security benefits of the remote access technology deployed. The goal is to know that your enterprise is as prepared as it can be, and that it has a plan for staying prepared.

To protect against viruses, Trojan attacks, and worm attacks, train users to identify virus behavior and to respond properly, prevent disabling of virus detection software, and force timely virus signature updates. Use only trusted software.

Stay informed by subscribing to the security bulletins.

Understand your remote access scenarios and security threats, and the trade-offs between them based on organizational needs. Prioritizing the assets most needing protection, and determining the appropriate balance between cost and risk, are strategic decisions best made by senior management.

Consider Network Bandwidth

Consider network bandwidth constraints before modifying core IT services such as remote access. It is likely that the network was designed with different assumptions, and the risk of business disruption must be carefully managed. For example, if your IT organization has chosen to deploy worldwide remote access by using your existing internal network and Internet access points, engineers will need to analyze Internet egress capacity and capability at the access points and across internal network segments between remote users and the corporate resources they need to access. Accessing resources that place high demands on shared network bandwidth is another area to study. Specific business-related applications and/or tools, or the routine transfer of large files and e-mail with attachments, may overrun certain segments of the existing network not designed for these traffic loads and usage patterns.

Reduce Variables

An important consideration in any IT environment is to remove as many variables as possible to improve end-to-end compatibility, create a more manageable solution, and reduce costs and cycles associated with supporting a highly mixed environment. By limiting the Microsoft IT remote access solution to Windows Server 2003 and Windows XP Professional, the entire solution has been much easier to manage and administer, and is highly stable and robust.

Manage Evolutionary Changes in Technology

Anticipate technical challenges, such as installation routines, distribution of CD-ROMs, integration with third-party products, and issues exposed under heavy loads. The development of smart card technology, as one example, was initiated when the available technology was relatively immature. As the Microsoft IT SRU projects progressed, there were advancements in smart card technology that had to be integrated into the solution. In another example, Microsoft IT worked closely with Cisco Systems to develop router code to support MS-CHAP v2 and EAP-TLS protocols as well as to resolve initial issues with network compression for direct dial access. Anticipate and manage evolutionary changes in the technology as part of any long-range project.

Upgrade to Windows Server 2003

For corporations with Windows NT 4.0 domains, the first step is to upgrade to Windows Server 2003 in order to maximize the latest and best technology, including RAP, CMAK, PKI, and smart card support. Windows XP Professional integrates easily with Windows Server 2003 in this remote access solution.

Choose a Practical PKI Solution

Carefully examine the self-hosted or third-party PKI decision. Consider two key factors in deciding whether you should self-host or purchase PKI services: the number of certificates your enterprise plans to use and the types of applications you want to enable with digital certificates. At Microsoft, Microsoft IT uses certificates for everything from remote access to code signing and enhancing e- mail security. Third-party hosting would be cost prohibitive. In addition, one of Microsoft IT's primary missions is the testing of Microsoft enterprise software in production before it is released. Self-hosting allows Microsoft IT to test products against Microsoft's PKI implementation for compatibility.

Provide Alternative Access

At the time of this writing, the following clients cannot gain remote access to the Microsoft corporate network:

• Users of mobile Personal Digital Assistant (PDA) devices, such as Pocket PCs and Smartphones, which do not yet support the required EAP-TLS protocol.
• Employees who are unable to install, or who do not want to install, the software and hardware solution required for smart card–enabled remote access on their home computers.
• Home users equipped with some Macintosh, UNIX, and Linux computers when those systems do not support the required version of the EAP-TLS protocol.

Remote access is a full-feature productivity service that enables users to access all data and applications necessary to work as they do on the corporate LAN. However, you can provide alternative, partial network access for users. For example, Outlook Web Access (OWA) and remote procedure call (RPC) over Hypertext Transfer Protocol (HTTP) provide a worldwide alternative for Microsoft employees by allowing HTTP Secure (HTTPS) access to their most frequently used data (e-mail, contacts, tasks, and calendar functions). Alternative access also enables users to stay connected if remote access services are not available.

Define ISDN Expectations with ISPs

ISDN channel bonding (that is, the combining of two 64-KB ISDN channels into a single 128-KB connection) is supported with the Microsoft IT solution. However, the function of channel bonding for ISDN relies on the capability and willingness of an ISP to allow the added on-demand bandwidth consumption through its facilities. The expectations should be clearly explained during service contract discussions.

Select Smart Cards Carefully

Smart card manufacturers are constantly adding new features to their products, including more memory space (128 KB cards are now available). Enterprise-wide standardizing on one model of card can be a challenge given the rapid pace of development of this technology.

During SRU implementation, Microsoft IT encountered a number of operational and management challenges that customers should address in their own planning:

• Immature smart card administrative tools increase management burden.
• Secure registration authority for certificate issuance and renewal must be managed. Microsoft IT chose to manually create and deliver smart cards to all users as the most secure method to validate recipients' identities.
• Remote client troubleshooting requires cooperation of different teams.

Table 6 provides some key considerations for selecting smart cards.

Table 6   Smart Card Selection Criteria

Assess Available Resources Carefully

Make a thorough assessment of available resources. Security in the digital environment is an ongoing and constantly changing entity. Focus on the highest-priority items to implement first, as defined by your risk assessment process. This focus is important, because not all work will be completed due to time, budget, or personnel constraints, and the changing landscape demands continuous reprioritization. Lower-risk exposures may not all be addressed based on cost and risk analysis. These decisions are best made by management-supported review boards or steering committees.

Conduct Pilot Tests

Monitor and manage potential performance issues and set user expectations before deploying a remote access solution. It is best to first run a controlled, non-production pilot to validate overall functionality of the design and technologies, addressing any major issues that surface. Next, move to a controlled production pilot on equipment that is in the production infrastructure. If there are no major issues at this point, deploy in a carefully phased roll-out, monitoring for user impacts.

Deploy in Phases

A phased approach with time between major deployments throughout the upgrade of the service is important. The Microsoft IT teams compressed the schedule, and with little or no time between major phases of work, issues that surfaced were much more difficult to isolate and user impacts were much more severe.

Use MOF

Taking advantage of a structured support framework—such as MOF—for the design, deployment, and operational support of a new or existing service facilitates delivering a high-quality, stable product for clients while reducing costs to manage the service.

Monitor Service Health

For any complex project with a broad scope, establish detailed tools and processes for data collection and reporting prior to implementing change to ensure that you capture service-affecting issues early. The combination of MOM 2000, SQL Server, and Windows Server 2003 enabled Microsoft IT to implement these tools and processes.

Set baselines for key performance indicators prior to deployment to use as a gauge for service-level impacts. If key indicators of service health show negative impacts, quickly work to identify the cause and develop a remedy. Service health metrics tracked during the enhanced-security remote access upgrade at Microsoft included:

• Total number of remote access Helpdesk tickets generated as technology was deployed.
• Top cost-driving or user-affecting categories of tickets from users—for example, CM installation, setup and configuration, smart cards, certificates, and network connectivity.
• Distribution of tickets resolved at the first tier and second tier.
• Tickets created proactively (monitoring and alerting) versus reactively (customer call).
• Percentage of tickets closed within SLA.
• Trending over time for top cost-driving or user-affecting issues.

Conclusion

Remote access, for many enterprise organizations such as Microsoft, has evolved into a valuable resource that individual users and business units take advantage of to help achieve business objectives. Whether it is encouraging work/life balance, supporting revenue-generating organizations and strategies, providing access for traveling executives and employees, or playing a critical role in business continuance or disaster recovery scenarios, remote access is a valuable business enabler for Microsoft. Tightening security for access to sensitive resources and intellectual property is imperative to protect these assets.

Although allowing remote access for employees presents a significant security threat, the risk can be managed actively with a security strategy that includes both strong authentication and computer configuration management. Microsoft has mitigated remote access security risks in its internal environment through the deployment of Windows Server 2003, Windows XP Professional, CM, smart cards, RAP, and Network Access Quarantine Control, combined with clearly defined, disciplined operational processes to monitor and manage the service.

Over the past three years, while developing SRU and implementing the broad security measures now deployed specifically for remote access, Microsoft IT has tracked client satisfaction for remote access. Internal user surveys showed an increase of 22 percent in satisfied or very satisfied scores from 2001 to 2004. This reflects an increase in overall user satisfaction in parallel with the implementation and enforcement of significant security requirements for the remote access service. Over the same three years, the dissatisfied or very dissatisfied scores held a relatively steady overall score of about 14 percent, although there was a significant decline of 20 percent from 2002 to 2003. These survey numbers show that when a complex project such as SRU is deployed across a business-critical service such as remote access, if people, processes, and technology are aggressively measured and managed within a defined framework such as MOF, the results can be very positive in achieving all objectives, including usability.

Microsoft IT continues to advance the company's multiyear Trustworthy Computing strategy. As of this writing, Microsoft IT has significantly reduced the external exposure posed by remote access connections, reduced day-to-day administrative cycles for managing remote access, improved system performance and service availability, and improved the ability to identify and quickly resolve service-affecting issues. Corporations can use these examples to get a head start on making their own systems more secure.

The knowledge that Microsoft IT has gained through the development, deployment, and management of the current end-to-end remote access solution at Microsoft will be woven into subsequent versions of the Windows server and client product releases. Future Microsoft products will continue to benefit from the efforts of the Microsoft IT operations and engineering teams whose mission is to be Microsoft's first and best customer.

For More Information

For information related to security and technologies deployed at Microsoft, see the following resources:

Remote access link

Windows Server 2003 links

Windows Server 2003

Technical Resources for Windows Server 2003

Windows Server 2003 on TechNet

Windows Server 2003 VPN link

Virtual Private Networks for Windows Server 2003 on TechNet

Windows XP Professional links

Windows XP Professional

Windows XP Professional on TechNet

"Securing Mobile Computers with Windows XP Professional"

CM link

Connection Manager Administration Kit

Security links

TechNet Security Resource Center

PKI Enhancements in Windows XP Professional and Windows Server 2003

Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure

Microsoft Operations Manager link

MOM Technical Resources on TechNet

Microsoft Operations Framework link

MOF on TechNet

For more information about Microsoft products or services, call the Microsoft Sales Information Center at (800) 426-9400. In Canada, call the Microsoft Canada information Centre at (800) 563-9048. Outside the 50 United States and Canada, please contact your local Microsoft subsidiary. To access information via the World Wide Web, go to:

http://www.microsoft.com

http://www.microsoft.com/services/microsoftservices/howmsdoesIT.mspx

For any questions, comments, or suggestions on this document, or to obtain additional information about Microsoft IT Showcase, please send e-mail to:

showcase@microsoft.com

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Microsoft grants you the right to reproduce this White Paper, in whole or in part, specifically and solely for the purpose of personal education.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place or event is intended or should be inferred.

© 2004 Microsoft Corporation. All rights reserved.

Microsoft, Active Directory, Windows, Windows NT, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.