Outlook Web Access Security Features

[patris1]

http://www.msexchange.org/articles_tutorials/exchange-server-2007/security-message-hygiene/outlook-web-access-security-features-part1.html

PART-1

Introduction

In this multi-part article I want to cover the security features that are available in Outlook Web Access (OWA) in Exchange 2007. With OWA 2007, there are many security enhancements over previous versions of Exchange and therefore these security considerations should be addressed during the design phase of your Exchange 2007 deployment. Let us get going straight away and see what is on offer.
Client Access Server Location


Let us start this article by covering a fundamental part of Exchange 2007 OWA security, namely the security of the server responsible for providing OWA, the Client Access Server. With Exchange 2000 and Exchange 2003, the front-end server role is loosely similar to the Client Access Server role in Exchange 2007. It was sometimes the case that organizations deployed the front-end server role into a perimeter network based on the notion that this particular role was suited to that location, with the front-end server then performing a connection to the back-end mailbox server. However, such a configuration often proved controversial as there were also those who argued that locating the front-end server into a perimeter network required that many additional ports were opened on the firewall separating the perimeter network with the internal network housing the back-end mailbox server. With Exchange 2007, it should be noted that Microsoft does not support locating the Client Access Server in a perimeter network so this factor should be taken into account when planning the location of Client Access Servers.
With that covered, let us now move onto the other key areas of OWA security starting with Secure Sockets Layer (SSL) encryption and the certificates used for this purpose.
Secure Sockets Layer


One of the big changes in security for OWA in Exchange 2007 has been the fact that SSL encryption is enabled by default and to achieve encryption via SSL, Exchange 2007 makes use of digital certificates. You might ordinarily associate the term digital certificate with 3rd party certificate authorities such as Verisign, or perhaps with an internal certificate authority that is integrated with the Active Directory environment. Whilst this is correct, the default SSL certificate that is generated by Exchange 2007 during installation is actually a self-signed certificate. This means that, whilst 3rd party certificate authorities will sign certificates that it issues, the self-signed certificates issued by Exchange 2007 are, as the name implies, signed by Exchange 2007 itself.
Figure 1 shows a self-signed certificate that has been issued by an Exchange 2007 server with a NetBIOS name of CCR-SRV1. Figure 2 shows the same certificate but this time the focus is on the Subject Alternative Name field of the certificate.

Figure 1: General Tab of a Self-Signed Exchange 2007 Certificate

Figure 2: Subject Alternative Name Field of a Self-Signed Exchange 2007 Certificate
You can see from Figure 2 that the certificate has a Subject Alternative Name field set with not only the NetBIOS name of the server, but also the Fully Qualified Domain Name (FQDN). Also, you can see from Figure 1 that the self-signed certificate is not trusted by default in the same way that 3rd party certificates would be. In other words, you would need to copy this certificate to the Trusted Root Certificate Store on each computer from where you planned to connect to the Client Access Server, such as when using Outlook Web Access from the browser on a PC. If you do not do this, you will receive the certificate warning prompt that you can see in Figure 3.

Figure 3: Browser Certificate Trust Warning Prompt
If you do not mind the fact that you will receive the aforementioned certificate prompt, it is actually possible to use the self-signed certificate when using OWA to access your mailbox. However, you should note that other client access methods, such as Outlook Anywhere, do not work with the self-signed certificate so you may be better off deploying a certificate from a 3rd party certificate authority from the beginning, or possibly from an internal certificate authority. We will discuss the certificate authority options in greater detail later in this article. The other main issue with the self-signed certificate is the fact that they are more difficult to manage in general. For example, self-signed certificates are only valid for 1 year with Exchange 2007 Service Pack 1, after which time you must renew them via the New-ExchangeCertificate cmdlet. It can sometimes be problematic for an administrator to remember when these certificates are going to expire although monitoring technologies such as System Center Operations Manager (SCOM) can help address this issue. Certificates supplied by either 3rd party or Active Directory certificate authorities can have longer expiration timescales, such as 3 years for example.
The fact that an SSL certificate is installed by default on the Client Access Server role allows the use of SSL encryption between the client and the Client Access Server when using the protocols that the Client Access Server supports, such as HTTP, POP3 and so on. This is achieved by the various virtual directories created in Internet Information Services (IIS) on the Client Access Server requiring SSL encryption. You can see this if you examine the properties of the various virtual directories. For example, Figure 4 shows the properties of the /owa virtual directory running in IIS6 on a Windows 2003 server.

Figure 4: SSL Requirements For /owa Virtual Directory
Certificate Authorities


Although this is an article series covering OWA security in Exchange 2007, I feel that it is important to break out for a short while and discuss certificate authorities. As mentioned earlier in this article, it is possible to use the self-signed certificates that are supplied by default in Exchange 2007 or use certificates from another source. These other sources include an internal Microsoft certificate authority, an internal certificate authority based on non-Microsoft technology, or a 3rd party certificate authority such as Verisign, GoDaddy and so on. Of course, the use of 3rd party certificates depends largely on the server role that is being protected. For example, assume that an organization has a URL of https://webmail.neilhobson.com that provides external access to OWA from remote locations and that the Client Access Server responsible for external OWA access is protected by ISA Server 2006. It will likely be most appropriate to deploy a certificate on the ISA Server for the external OWA URL from a 3rd party certificate authority in order to ensure that, no matter which client PCs and browsers are being used for OWA access, there are no certificate trust issues involved. However, the certificate for the Client Access Server need not be purchased from the same 3rd party certificate authority as it is the ISA Server that will be communicating with the Client Access Server directly and not external client PCs. Therefore, it is sometimes the case that organizations deploy certificates issued from an internal certificate authority onto the actual Client Access Server.
Clearly there is a cost involved with purchasing 3rd party certificates whereas those issued by an internal certificate authority are free once the cost of designing and installing the internal certificate authority have been recovered. Additionally, it is much easier to create and assign certificates from an internal certificate authority and have them re-issued if there are any problems. For example, a Client Access Server certificate requires many additional names listed in the Subject Alternate Name field and it is quite possible that you may forgot to include one of these names in the initial certificate request.
There are many organizations out there, particularly smaller organizations, which have not installed an internal Microsoft certificate authority that integrates into the Active Directory environment. Therefore, when installing Exchange 2007 for the first time, these organizations must decide whether they are going to continue using the Exchange 2007 self-signed certificates, or whether they are going to obtain their digital certificates from a 3rd party certificate authority. The other option is, of course, to deploy an internal certificate authority and the most obvious option is to deploy one using Microsoft Certificate Services.
Deploying an Exchange 2007 infrastructure is not the only reason to consider the deployment of an internal certificate authority based on Microsoft technology. Other Microsoft products, such as Office Communications Server, System Center Operations Manager and System Center Configuration Manager also make use of certificates. Therefore, if you don’t currently have an internal certificate authority it might be worth taking the time to consider the advantages of having one deployed and operational.
Summary


This completes part one of this article series on OWA security in Exchange 2007. We have spent most of this article covering SSL certificates which is justified as these are vital to OWA 2007 security. In the next part of this article series, we will be taking a look at OWA authentication methods, such as forms-based authentication as well as the ‘standard’ authentication methods such as Integrated Windows authentication.

---

موضوعات مشابه:

• SolutionBase: Outlook 2007's new features and how they work with Exchange Server 2007
• Top 11 Hidden Features in Outlook Web Access for Exchange 2003
• Creating themes in Outlook Web Access 2007
• راه اندازي outlook web access

---

[patris1]

http://www.msexchange.org/articles_tutorials/exchange-server-2007/security-message-hygiene/outlook-web-access-security-features-part2.html

PART-2

Introduction

In part one of this article series on OWA security features we looked at the network location of the Client Access Server itself, followed by a general discussion on how Exchange 2007 uses certificates for securing OWA. Here in the second part of this article series we are going to concentrate on the different OWA authentication methods and considerations in choosing between them.
OWA Authentication – Forms-based Authentication


In Exchange 2007, you are able to choose between forms-based authentication and another group of authentication methods that come under the heading of standard authentication methods. Another security change seen in Exchange 2007 is the fact that the forms-based authentication method is used by default for OWA so we will cover this method first and come back to the standard authentication methods later. To view the authentication methods bring up the properties of the /owa virtual directory in the Exchange Management Console and then click the Authentication tab. You will then see a screen similar to that shown in Figure 5.

Figure 5: Authentication Methods
Forms-based authentication was first introduced in Exchange 2003 and allows a logon page to be displayed rather than the typical basic authentication prompt that simply asks for a username and password. This logon page increases security since the user’s logon name and password details are stored as a cookie rather than inside the browser. There are two main advantages to the cookie authentication approach. First, the cookie is cleared when the OWA session is ended and second, the cookie is also cleared after a pre-defined period of inactivity, such as when the user temporarily walks away from the computer running the browser session. Furthermore, this inactivity timeout can be configured to apply to both public and private computers. In other words, a different timeout can apply to client computers owned by the organization as opposed to those client computers that are not. It is likely that many organizations will desire a much lower timeout period for client computers that are external to their security boundary. This inactivity timeout period offers increased security because it means that the OWA session cannot be returned to once the cookie has timed out. Figure 6 shows the two options that are presented to the user, via the forms-based authentication screen, to control whether the client computer being used is either a public or a private computer.

Figure 6: Forms-Based Authentication Security Options
By default, selecting the public computer option means that a period of 15 minutes of inactivity is allowed before the session is timed out although it is possible to change this value. To change this value, either add or modify the following registry key on the Client Access Server where forms-based authentication has been enabled:
Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\MSExchangeOWA
Name: PublicTimeout
Type: DWORD
Value: {number of minutes}
You can see this registry key shown in Figure 7. Note that it is a requirement to restart Internet Information Services (IIS) on the Client Access Server. To do this quickly, just run a command prompt and then run the iisreset /noforce command.

Figure 7: Public Computer Timeout Registry Key
Selecting the private computer option means that, by default, a period of 8 hours of inactivity is allowed before the session is timed out, obviously a much longer period than the public computer option. A similar registry key exists to alter the private computer timeout value:
Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\MSExchangeOWA
Name: PrivateTimeout
Type: DWORD
Value: {number of minutes}
One thing to bear in mind with these timeout values is that they are not an exact figure and there will be a tolerance on the values used. Officially, Microsoft states that the actual timeout value will be between 1 and 1.5 times the value of the timeout figure due to the way that the Client Access Server cycles through the encryption keys. In my experience, the timeout does occur fairly close to the specified value but as I have already said it is not an exact figure, so please bear this in mind when you are testing the timeout values within OWA. Also, if you are using ISA Server for external OWA connectivity, note that you can set these same timeout values within ISA Server thereby giving your users a consistent experience.
Back in Figure 6 you saw the opening OWA forms-based authentication logon screen. You may also note from this screen that the user must provide their logon details in the domain\username format which is the default setting. It is possible to change the logon prompt to ask for just the username, or the User Principal Name (UPN). Although it may be tempting to make life easier for the users by changing the logon details to just require the username, consider the security impact of your organization before you do this. For example, it may be argued that the default setting of requiring both the domain name and the username means that there are two pieces of required information before a logon is possible, as opposed to just a single piece of information if just the username is required.
If you do decide to change the logon prompt to just require the username, this can be changed either via the Exchange Management Console or the Exchange Management Shell. In the Exchange Management Console, bring up the properties of the /owa virtual directory and go to the Authentication tab as you saw earlier in Figure 5. Here you can see that you have the ability to alter the forms-based authentication logon format to suit your requirements. In the Exchange Management Shell, you can use the Set-OwaVirtualDirectory cmdlet with the LogonFormat parameter. Valid options for the LogonFormat parameter are:

• FullName: This matches with the domain\username option that you can see in Figure 5 and therefore requires that users enter both their domain name and username when authenticating to OWA.
• PrincipalName: The PrincipalName parameter obviously matches with the user principal name option in Figure 5 and requires that users enter their UPN for authentication.
• UserName: This matches with the ‘user name only’ option in Figure 5. Note that if you use the Exchange Management Shell to set this option, don’t forget to set the default domain option via the DefaultDomain parameter of the Set-OwaVirtualDirectory cmdlet.

As with the public and private timeout registry key entries that we discussed earlier, making changes to the authentication methods requires that you restart IIS for the changes to take effect. You can therefore again use the iisreset /noforce command to achieve this.
OWA Authentication – Standard Authentication


If you have managed or are managing an Exchange 2000 or Exchange 2003 environment, you are likely to be familiar with the standard authentication models of basic authentication, digest authentication and integrated Windows authentication.
With basic authentication configured on the /owa virtual directory on a Client Access Server, users will see the familiar authentication pop-up box that you can see in Figure 8. By default, basic authentication is not secure unless SSL is added.

Figure 8: Basic Authentication Prompt
Integrated Windows authentication is extremely useful in that the users’ currently logged on credentials are used by the server to authenticate the users. With this method, the users are not prompted to enter their credentials again. For example, a user might log into their normal work computer using their Active Directory account information and then proceed to load Internet Explorer. Then, that user may choose to access a Client Access Server that has been configured to use Integrated Windows authentication. In this case, the user will be granted access to OWA immediately without being prompted for credentials. However, if ISA Server is used for external OWA access and has been configured with forms-based authentication, having different authentication procedures depending on whether the user is accessing OWA internally or externally could be confusing for the users. Therefore, sometimes, some organizations deploy forms-based authentication on separate Client Access Servers that have been deployed purely to service internal-only OWA sessions.
Finally, there is digest authentication that is also used by users who have an Active Directory domain account. With digest authentication, extra security is obtained via the fact that the passwords entered by the users are sent as a hash value as they are sent across the network to the authenticating server. However, note that with digest authentication the user’s authentication credentials do actually remain in the browser cache and so could be retrieved if it is not possible to close the browser. Therefore, you again need to consider forms-based authentication if this is likely to pose a security risk within your organization.
Summary


That completes part two of this article series on the security features of OWA in Exchange 2007. In this part we have covered the authentication methods that are available and paid particular attention to the configuration options available with forms-based authentication. I’ll conclude the look at authentication in part three and then move on to OWA segmentation.

[patris1]

http://www.msexchange.org/articles_tutorials/exchange-server-2007/security-message-hygiene/outlook-web-access-security-features-part3.html

PART-3

Introduction

Part two of this article series focused entirely on the authentication methods available in OWA 2007. I want to start part three of this article series by completing the topic of authentication by covering a few key points on which authentication method should be used. Once we’ve done that, we will then take a look at the OWA segmentation feature.
OWA Authentication – Which Method?


The question of whether to use forms-based authentication or standard authentication depends largely on your infrastructure and requirements. For example, ISA Server 2006 also comes equipped with forms-based authentication which can be enabled if required. If your internal Exchange 2007 organization is protected by ISA Server 2006, you may want to implement Integrated Windows authentication on the Client Access Server rather than forms-based authentication otherwise users will be presented with two forms, one for the ISA Server and one for the Client Access Server. With forms-based authentication configured on the ISA Server and Integrated Windows authentication configured on the Client Access Server, the user is only presented with the form once. When the user has entered their user account details into the form and been authenticated by ISA Server, the connection to the Client Access Server, and thus OWA, is made automatically via Integrated Windows authentication.
Having said this, the subject of different user experiences does sometimes need to be addressed. For example, users connecting externally to OWA will be presented with the ISA Server forms-based authentication screen whereas internally the same user will be logged on automatically via Integrated Windows authentication. Some organizations choose to combat this issue by deploying additional internal Client Access Servers, or even additional internal ISA Servers, and configure these with forms-based authentication to ensure that a consistent user experience is seen no matter whether the user is connecting to OWA internally or externally.
Also, you have to consider the requirements of other important Client Access Server technologies, such as CAS-to-CAS proxying. Take the example scenario where a user connects via OWA to a Client Access Server that is in a different Active Directory site to that of the mailbox server hosting that user’s mailbox. In this case, the Client Access Server that the user connects to is able to locate a Client Access Server that is in the same Active Directory site as the user’s mailbox server and can proxy the user request to that Client Access Server. This proxy request is known as CAS-to-CAS proxying. However, in order for this process to work, the Client Access Server in the same Active Directory site as the user’s mailbox must have Integrated Windows authentication set on the virtual directory that is being accessed.
When considering the choice between the different standard authentication methods, one of the primary considerations is the fact that cached credentials can pose a security risk for the organization if OWA is used from public locations. This is mainly a concern if the user is unable to close the browser after accessing OWA; if the browser cannot be fully closed, there is the risk that other users will be able to access the OWA session as credentials are cached within the browser.
Take the time to research your authentication requirements before choosing one, particularly when complimentary security products such as ISA Server 2006 are being used.
OWA Segmentation


OWA segmentation is another feature that has been present in some legacy versions of Exchange and is therefore not a feature that’s new to Exchange 2007. Essentially OWA segmentation is a feature that allows you to block access to specific features of OWA for either some or all users. For example, suppose that you transition your Exchange 2003 environment to Exchange 2007 and at the same time decide to migrate your public folder information to Microsoft SharePoint. If you have also deployed the Outlook 2007 client, there is now no need to use public folders within your environment and so you may choose to block access to public folders from within OWA. Figures 9 and 10 show you the difference between an OWA client with public folders enabled, and one where public folders have been disabled via OWA segmentation. As you can see from Figure 10, the public folder button is entirely missing.

Figure 9: Public Folders Available in OWA

Figure 10: Public Folders Disabled in OWA Via OWA Segmentation
Or, perhaps you have not deployed Exchange ActiveSync devices or the Unified Messaging server role within your organization. Again, it may be worth considering disabling these features so that the options do not appear in Outlook Web Access. Any configuration item that simplifies the user experience and possibly prevents a helpdesk call can only be a good thing.
It is possible to configure OWA segmentation for quite a range of features. The list includes ActiveSync integration, address lists, calendar, contacts, journal, junk email, reminders and notifications, notes, premium client, search folders, email signature, spelling checker, tasks, theme selection, unified messaging integration, change password, rules, public folders, S/MIME and deleted item recovery.
You can control OWA segmentation for an entire virtual directory on a Client Access Server or on a per-user basis. Let’s look at the controls for an entire virtual directory first, starting with the Exchange Management Console. To access the segmentation controls, bring up the properties of the /owa virtual directory and click the Segmentation tab. Figure 11 shows the contents of this tab.

Figure 11: OWA Segmentation Tab
As you can see from Figure 11, it is very straightforward to understand how to enable or disable a specific feature for OWA segmentation; you simply have to select the relevant feature and click the enable or disable button as required.
Note:
You can only configure segmentation on the /owa virtual directory, so do not go looking for the segmentation tab on the other virtual directories, such as /exchange, that you may have on your Client Access Server.
To use the Exchange Management Shell to configure segmentation, use the Set-OwaVirtualDirectory cmdlet. For example, if you wanted to obtain the properties of the /owa virtual directory on a server called CCR-SRV1, the following cmdlet would be used:
Get-OwaVirtualDirectory ‘CCR-SRV1\owa (Default Web Site)’
This cmdlet will return many parameters. Figure 12 shows some of the output of this cmdlet, where you can see the status of each of the segmentation values. You can see towards the top of Figure 12 that the Tasks feature has been disabled in OWA.

Figure 12: Output of Get-OwaVirtualDirectory Cmdlet
As briefly mentioned earlier in this section, it’s also possible to configure OWA segmentation on a per-user basis and to do this the Set-CASMailbox cmdlet can be used. For example, let’s assume that we wish to disable the Tasks feature for one specific user that has a mailbox alias of neil. We can use the following cmdlet to achieve our goal:
Set-CASMailbox –Identity neil –OWATasksEnabled:$false
You’d then obviously need to use the Get-CASMailbox cmdlet to verify that the setting was in place. Also, note that the per-user settings override those made on the virtual directory.
Summary


That concludes part three of this article series on OWA security features found in Exchange 2007. This part of the article series has covered a few important areas to consider when choosing between the various authentication methods and then moved on to the OWA segmentation feature. OWA segmentation can often be overlooked when configuring Exchange 2007 but it’s worth remembering that configuring it can help to give the users a consistent look and feel when using Outlook compared to OWA.

[patris1]

http://www.msexchange.org/articles_tutorials/exchange-server-2007/security-message-hygiene/outlook-web-access-security-features-part4.html

PART-4

Introduction

If you have been reading the other three parts of this article series, you will know that so far we have covered an array of different security features related to OWA; such as the network location of the Client Access Server, authentication methods and OWA segmentation. Here in part four we are going to discuss another important area regarding OWA security, namely controlling how your users access attachments when using OWA.
OWA File and Data Access

By its very nature an email system makes it extremely easy for users to send and receive files of all different types and over the years the control of dangerous file types such as .exe, .com and so on has been controlled by many different methods. Historically, it was all too easy for an unsuspecting user to double-click an executable attachment containing malicious code and hence changes had to be made.
For Exchange 2007 OWA, it is possible for an administrator to centrally control not only the different file types that can be accessed, but also how these file types can be accessed. Furthermore, this can be controlled separately depending on whether the user is accessing OWA on a public or a private computer, as indicated by the user’s security option selection at login; this was shown in Figure 6 in part two of this article series. To see how file access is controlled for OWA 2007 you can examine the configuration in the Exchange Management Console or use the Exchange Management Shell. In the Exchange Management Console, bring up the properties of the /owa virtual directory on a Client Access Server and click either the Public Computer File Access or Private Computer File Access tab. From here, you will see options for controlling direct file access, WebReady document viewing and accessing files from either file shares or Windows SharePoint Services. The screen controlling public computer file access is shown in Figure 13. I’m going to focus on the public computer file access settings for now but note that the same options exist for private computers on that specific tab.

Figure 13: Public Computer File Access Configuration
First, let us look at the direct file access option. If you click the Customize… button, you are presented with the screen shown in Figure 14. Here you can see that you can control how your users can deal with both known and unknown file types. For the known file types, there are three lists avalable: Allow, Block and Force Save.

Figure 14: Direct File Access Settings
The Allow list is a list of file extensions that the user is able to open in OWA. Conversely, the Block list is a list of file extensions that the user is unable to open in OWA. Finally, the Force Save list is a list of file extensions that the user is forced to save to the local computer hard disk before that file can be run. There is a specific order of preference of the three levels, namely Allow, Block and then Force Save. This means that the Allow list overrides the Block and Force Save lists and the Block list overrides the Force Save list. For example, if a file extension is added to the Allow list and that extension also appears in the Block list, a user attempting to access that file extension will be granted access. At the bottom of Figure 14 you’ll also see the option for handling unknown file types which do not appear in any of the aforementioned lists. This option has a default setting of forcing the users to save the attachment first which is arguably the most appropriate default option, although high security environments could consider changing this setting to ‘block’ to block unknown file types.
When a user attempts to access a file that is configured in the Block list, the user sees the message shown in Figure 15, whereas if the file is configured in the Force Save list the user sees the message shown in Figure 16.

Figure 15: Blocked Attachment Message

Figure 16: Force-Save Attachment Message
The Allow, Block and Force Save lists are pre-populated with many different file extension types as well as MIME types. You will therefore need time to review each of these file and MIME types for suitability within your organization. Microsoft has done a good job of ensuring that the most dangerous file types are handled accordingly and many organizations may well choose to leave the default configuration as it is. Of course, each organization that runs Microsoft Exchange likely has different security requirements and so it is recommended to review the default configuration for suitability within your organization. There are so many file and MIME types configured that you may find it easier to use the Exchange Management Shell to get the default list. You can use the Get-OWAVirtualDirectory cmdlet and examine the values of the AllowedFileTypes, AllowedMimeTypes, ForceSaveFileTypes, ForceSaveMimeTypes, BlockedFileTypes and BlockedMimeTypes parameters.
For example, to obtain a list of allowed file types for the \owa virtual directory held in the default web site, you could run the following cmdlet:
Get-OwaVirtualDirectory ‘owa (default web site)’ | fl *allowedfile*
This cmdlet filters the output to show the parameters whose names contain the string allowedfile. The result is shown in Figure 17.

Figure 17: AllowedFileTypes Output
WebReady Document Viewing


WebReady Document Viewing is another excellent feature available in OWA 2007. This feature simply allows supported document types to be converted to HTML and displayed in a browser window rather than launching the relevant application. For example, this feature can be used to render Microsoft Word documents in a browser window rather than launching Microsoft Word itself. This means that the users do not necessarily need to have the application installed on their local computer in order to view the document. However, you should be aware that WebReady Document Viewing should be considered as a basic way to view documents and that documents can sometimes look slightly different when viewed this way. WebReady Document Viewing does not have all the features that would be expected of the full application. As a result, there are some limitations that should be considered such as the fact that some Excel chart types are not supported.
You will notice back in Figure 13 that it is not only possible to enable or disable this feature entirely, but it’s also possible to force the document to be converted to HTML when a converter is available. Also, don’t forget that Figure 13 shows the options for computers classified as public computers and that separate WebReady Document Viewing options are available for computers classified as private computers. In case you have forgotten, we discussed public and private computers in part two of this article series.
Let us look at what setting the option Force WebReady Document Viewing… actually means for the users. In Figure 18, you can see that the attachment is able to be opened directly as the attachment name itself is a link. Also, the attachment can be opened as a web page by clicking the [Open as Web Page] link. Conversely, Figure 19 shows the same attachment after the Force WebReady Document Viewing option has been enabled. In Figure 19, you can see that the attachment name itself is no longer a link, therefore forcing the user to click the [Open as Web Page] link.

Figure 18: Optional WebReady Document Viewing

Figure 19: Forced WebReady Document Viewing
Summary


This completes part four of this five-part article series on OWA security features. Controlling attachment access is a vital part of any Exchange deployment as it is obviously very desirable to limit the dangerous file types that can host viruses and other unwanted software. I would recommend that you take the time to evaluate the default attachment types that are allowed, blocked or configured in the force-save list. We will continue our look at WebReady Document Viewing, and also move on to cover web beacons, in the final part of this article series.