- Mapping the Design Components
- Evaluating Different Design Options
- Active Directory Design Details
- Defining Storage Groups and Multiple Databases
- Defining Administrative and Routing Groups
- Designing Remote Access to Exchange 2000
- Exchange 2000 Support and Maintenance Tasks
- Case Study for SmallCompany Inc.
- Case Study for MediumCompany Inc.
- Case Study for LargeCompany Inc.
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Designing Remote Access to Exchange 2000
As the concept of the "office" changes, businesses are realizing the value of creating a more mobile workforce. In order for an organization to maintain pace with this evolution, remote access has become a requirement. For that reason, Exchange 2000 has developed and, more importantly, refined the remote access component of Exchange 2000, Outlook Web Access (OWA).
Planning and Designing Outlook Web Access (OWA)
Outlook Web Access allows mail access using the Internet. The interface is consistent with the client installed on the desktop. However, it is a pared down version. That is not to say that the important core features are not available via the Internet. Users will be able to access all mail stored on the Exchange server in addition to their address lists, calendars, and Public Folders. The ability to offer the option of accessing mail regardless of the user's location makes this one of the major features of Exchange 2000.
Outlook Web Access Architecture
The focus of this section is the different architecture options available when designing Outlook Web Access. The OWA component is installed on the Exchange Server by default. There are three design options for Outlook Web Access. They are the single-server model, the multiserver model, and the multiserver model with Secured Socket Layer (SSL) enabled.
Single-server model. In the single-server model the Internet Information Server (IIS) directly delivers client HTTP requests to the mailbox store using a high-speed internal channel.
Multiserver model. In the multiserver model, client HTTP requests are passed to the Exchange server by a proxy using the HTTP protocol. The advantage gained with this model is the ability to use a single front-end server to service multiple back-end servers. Also, with the use of Network Load Balancing (NLB), multiple front-end servers can be clustered to accept and service client requests.
Multiserver model with Secured Socket Layer (SSL) enabled. This configuration is the same as the preceding configuration. However, the difference is that Secured Socket Layer (SSL) is enabled. Again, this adds an additional layer of security by encrypting the communications between the client and the front-end servers.
Now that the three architectural models have been described, the next step is to determine which model will work best based on needs of the organization. As you select the model best suited for your organization's requirements, there are important rules to consider that should be followed for both the single and the multiserver model.
Single-server rule. In a single server rule, the server setup to run Exchange 2000 can also be the system that'll host the Outlook Web Access server services. This minimizes the number of systems the organization needs to have, and provides full access for an organization that may have fewer than 50–100 total users.
Multiserver rule. In a multiple server rule, OWA servers should be dedicated to perform Web-based message access. For example, front-end servers are used only as the OWA server(s) and the back-end server(s) are the actual Exchange mail store servers. Servers should not serve mixed roles.
Multiserver rule. By default, front-end servers are configured to automatically service all back-end servers within the Exchange organization. In practice, this is not recommended. Instead, target the front-end server for specific back-end servers. This is important when SSL is enabled due to the amount of overhead required to process SSL connections.
NOTE
Exchange 2000 Server Enterprise Edition must be installed in order to take advantage of the front-end server feature. To configure this feature, use the Exchange System Manager.
Outlook Web Access Security
There are security considerations when planning for the deployment of Outlook Web Access to the enterprise. The current security implementation will impact the design of Outlook Web Access. In a multiserver configuration, the primary consideration is server placement. There are three available options: internal, perimeter, or demilitarized zone (DMZ). These three design options will be discussed in detail.
Internal Network
An internal network configuration is recommended only under certain circumstances; specifically, in scenarios where Outlook Web Access is deployed for users roaming or roving between locations within the organization. For example, these users will be accessing the Outlook Web Access server exclusively through the corporate intranet.
Perimeter Network
Users will access the front-end server from the Internet using a Web browser over HTTP or HTTPS (HTTP over SSL). It is important to remember that the front-end server should reside only on the perimeter network as shown in Figure 3.4 if there is a firewall and/or proxy server between the front-end and back-end servers.
){kind=link}
The front-end server is a dedicated Exchange 2000 Enterprise installation with the front-end feature enabled. It communicates with the back-end server within the private network via Lightweight Directory Access Protocol (LDAP) on port 389. Port 3268 needs to be opened on the firewall. This allows the front-end server to have access to the internal Global Catalog.
Port 80 for HTTP traffic also needs to be enabled to allow communication to the back-end server. The back-end server is a standard Exchange 2000 server that hosts mail or public folder stores. If security is an issue, the front-end and back-end servers should be configured to communicate using IP secure protocol to encrypt all communications.
Figure 3.4 Perimeter configuration.
Demilitarized Zone (DMZ)
The DMZ shown in Figure 3.5 is similar to the perimeter network scenario, with one exception. The front-end server is isolated from the public Internet. It provides an additional level of protection for the front-end because all communication with this machine is protected and controlled by the firewall. It is strongly suggested that this design configuration be used in all circumstances where external access is required.
){kind=link}
Figure 3.5 DMZ configuration.
Authenticating OWA Clients
Microsoft recommends that authentication should occur only on the back-end servers. The reason for this recommendation is security. It is more important that the back-end servers are secured than the front-end servers. By designating the back-end server as the authentication server, possible conflicts between the front-end and the back-end are minimized.
There are several authentication options available with Outlook Web Access. The option used by an organization is based on both the existing security policies and the installed Internet browser software used to access Outlook Web Access.
Basic—Challenge/response using clear text. Basic authentication where clear text is used for transmitting the password is not a secure method of authentication and is usually not advised as the method of logon authentication when security is of concern.
Integrated Windows. Integrated Windows authentication uses the security attributes of the remote client to validate the user's identity and logon authentication information to access the messaging system.
Digest. The Digest option provides secure authentication using cryptology.
Anonymous. The Anonymous option allows for general access to specifically designated Public Folders without logon authentication. This is usually a good solution for remote users to access completely unsecured public information that requires no user validation.
Secured Socket Layer (SSL). SSL makes available a secure communication channel that can be used with the Basic, Integrated Windows, Digest, and Anonymous methods of authentication.