To ensure that every Exchange client access mail securely from anywhere (internally and externally) Exchange deployment published through Forefront TMG 2010. you need to plan and deploy the different roles of Exchange Server which includes Exchange HT, CAS, ET and Mailbox and publish in Forefront TMG 2010. The main purpose of these deployment is to improve performance for client access, secure client access and encourage utilization of best practices of Exchange, TMG, and the Exchange clients (Microsoft Outlook) involved. There are few consideration you must take into account such as placing of server in different network segments. Create proper policies in TMG to allow https, POP3, IMAP, SMTP traffic securely to Microsoft Mail clients. In the following figure, I have illustrated a typical Exchange 2010 design that include Forefront TMG 2010.
Client Access
Allowing client access, you need to understand and plan what client access methods you need to make available on the Internet for your end users. Users with laptops can either use Outlook Web Access (OWA), which is lightweight and available via a Web browser to access
their mailboxes, or they can use RPC over HTTP over the Internet to check e-mail via Microsoft Outlook. Of course users with mobile devices capable of ActiveSync can access their mailboxes using Exchange Active Sync (EAS). When the administrator has decided which client access methods need to be made available, access to certain folders needs to be allowed through TMG. This is done via the Exchange Publishing Wizard, which is discussed in the next section. the default paths configured after running the New Exchange Publishing Wizard.
their mailboxes, or they can use RPC over HTTP over the Internet to check e-mail via Microsoft Outlook. Of course users with mobile devices capable of ActiveSync can access their mailboxes using Exchange Active Sync (EAS). When the administrator has decided which client access methods need to be made available, access to certain folders needs to be allowed through TMG. This is done via the Exchange Publishing Wizard, which is discussed in the next section. the default paths configured after running the New Exchange Publishing Wizard.
Outlook Web Access
|
/owa/*
/public/*
/exchange/*
/exchweb/*
|
RPC over http
|
/rpc/*
|
Outlook Mobile Access
|
Not Supported
|
Exchange Active Sync
|
/Microsoft-Server-ActiveSync/*
|
Outlook Anywhere
|
/rpc/*
/OAB/*
/ews/*
/AutoDiscover/*
|
Enterprise Root CA
When you publish Exchange client access with TMG, communications from external clients and from TMG itself to the published server can be encrypted using Secure Sockets Layer (SSL). Certain authentication mechanisms, such as Basic Authentication, allow user credentials
to be sent in clear text over the wire. This can be potentially unsafe if anyone runs a network sniffer over the wire and can therefore see user names and passwords. Hence it is essential to ensure that traffic is encrypted using SSL. By using certificates, we can analyze the session at
TMG before we forward it to the published Exchange Server by terminating the connection at the TMG. This is known as SSL bridging. SSL bridging protects against attacks that are hidden in SSL-encrypted connections. For SSL-enabled Web applications, TMG decrypts the client’s request, inspects it, and terminates the SSL connection with the client computer. The Web Publishing rules determine how TMG communicates the request for the object to the published Exchange server. If the secure Exchange publishing rule is configured to
forward the request using Secure HTTP (HTTPS), TMG initiates a new SSL connection with the published server. Because TMG is now an SSL client, it requires the published Web server to respond with a server-side certificate.
to be sent in clear text over the wire. This can be potentially unsafe if anyone runs a network sniffer over the wire and can therefore see user names and passwords. Hence it is essential to ensure that traffic is encrypted using SSL. By using certificates, we can analyze the session at
TMG before we forward it to the published Exchange Server by terminating the connection at the TMG. This is known as SSL bridging. SSL bridging protects against attacks that are hidden in SSL-encrypted connections. For SSL-enabled Web applications, TMG decrypts the client’s request, inspects it, and terminates the SSL connection with the client computer. The Web Publishing rules determine how TMG communicates the request for the object to the published Exchange server. If the secure Exchange publishing rule is configured to
forward the request using Secure HTTP (HTTPS), TMG initiates a new SSL connection with the published server. Because TMG is now an SSL client, it requires the published Web server to respond with a server-side certificate.
Authentication
TMG has a custom form for the Outlook Web Access client that is preconfigured when you use the Exchange publishing wizard. Using forms-based authentication, you can enforce required authentication methods, enable two-factor authentication, and provide centralized logging. After a user is authenticated, TMG can then delegate the credentials as per the configuration on the rule to the Exchange Server. It is important to ensure that the credentials being delegated should be in the same form as expected by the Exchange Server. In the event
of an authentication mismatch, client access fails and a credential delegation alert is logged by TMG.
of an authentication mismatch, client access fails and a credential delegation alert is logged by TMG.
| Authentication Method | Access Method |
| Microsoft Active Directory 2008 LDAP (Active Directory) |
Outlook Web Access
Outlook Anywhere Microsoft ActiveSync (only basic Authentication) |
| RSA SecurID |
Outlook Web Access
Microsoft ActiveSync (requires RSA SecurID component installed on Exchange servers) |
Outlook Web Access
When a Web client connects to an Outlook Web Access
Exchange Server front-end server, it loads the Outlook Web page that contains the user- interface icons and headers of messages currently in the mailbox. Subsequently, any operation that the user performs (such as Open, Send, or Move To Folder) generates a new HTTP connection that transfers an average of 10 to 20 KB. When accumulating the behaviour of Outlook Web Access over many users, the Web client
typically creates relatively low bits per connection value (such as 100 kilobits per connection). This traffic profile is relatively light and is distinguished by only two TCP connections, with a request rate corresponding to the user’s e-mail activity. Because this client is browser-based, it’s much less likely to produce error states as a normal course of events as does the Outlook
Exchange Server front-end server, it loads the Outlook Web page that contains the user- interface icons and headers of messages currently in the mailbox. Subsequently, any operation that the user performs (such as Open, Send, or Move To Folder) generates a new HTTP connection that transfers an average of 10 to 20 KB. When accumulating the behaviour of Outlook Web Access over many users, the Web client
typically creates relatively low bits per connection value (such as 100 kilobits per connection). This traffic profile is relatively light and is distinguished by only two TCP connections, with a request rate corresponding to the user’s e-mail activity. Because this client is browser-based, it’s much less likely to produce error states as a normal course of events as does the Outlook
RPC over HTTP or Outlook Anywhere
RPC over HTTP enables Outlook clients to access an Exchange
server in the internal corporate network from the Internet. When connecting to Exchange Server, an Outlook client working in Cached Exchange Mode typically starts with a synchronization of mailbox content with a local cache file by opening up anywhere between 10 to 15 connections to TMG. This behaviour is by default. After the
synchronization is complete, intermittent connections occur, in which new messages are transferred. The Outlook client would, however, maintain about 10 connections with TMG after it is connected. For a user utilizing Outlook heavily, the synchronization operation transfers many bytes of data over a small number of connections, so the overall characteristic bits per connection value is rather high (such as 500 kilobits per connection). Also known as RPC over HTTP, this traffic profile is the noisiest of all Exchange clients. It imposes a combination of high connection count (can be 20 or more separate TCP connections) with a higher data rate also coincident with the user activity.
server in the internal corporate network from the Internet. When connecting to Exchange Server, an Outlook client working in Cached Exchange Mode typically starts with a synchronization of mailbox content with a local cache file by opening up anywhere between 10 to 15 connections to TMG. This behaviour is by default. After the
synchronization is complete, intermittent connections occur, in which new messages are transferred. The Outlook client would, however, maintain about 10 connections with TMG after it is connected. For a user utilizing Outlook heavily, the synchronization operation transfers many bytes of data over a small number of connections, so the overall characteristic bits per connection value is rather high (such as 500 kilobits per connection). Also known as RPC over HTTP, this traffic profile is the noisiest of all Exchange clients. It imposes a combination of high connection count (can be 20 or more separate TCP connections) with a higher data rate also coincident with the user activity.
Exchange Active Sync or Outlook Mobile Access
This traffic profile is the lightest client of all, with only one TCP connection and very light traffic flow. A new HTTP connection is only made when a user performs an operation such as Open, Send, or Move To Folder.
0 comments:
Post a Comment