If you would like to read the other parts in this article series please go to:
- Outlook Web Access Security Features (Part 1)
- Outlook Web Access Security Features (Part 3)
- Outlook Web Access Security Features (Part 4)
- Outlook Web Access Security Features (Part 5)
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\Services\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\Services\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.
If you would like to read the other parts in this article series please go to:
