To meet the demands of a remote and mobile workforce, today most companies offer employees access to their company mailbox from outside the office. This is most likely accomplished by either using Outlook Web Access (OWA) with a web browser or by using their phone with an ActiveSync mail client.

Because these two common ways to access an Exchange mailbox are both based on the Microsoft web server IIS (Internet information Services), organizations can use the IIS agent introduced with UserLock 6.0 to protect these IIS sessions and help control access to company email outside of the office.

This article presumes the reader has a basic understanding of using UserLock. If this is not the case, take a look at these short video tutorials.

We will perform our demonstration on a small Active Directory environment. The server VES1 is the domain controller and also has the UserLock server installed on it. The server VES2 has Exchange 2010 installed with the Client Access Server (CAS) role.

To deploy the IIS agent on the chosen server, go to the "Agent distribution" view and locate the server VES2. Click Install.

The agent is successfully deployed but a message informs us that the installation should be finished in IIS by installing the ISAPI filter.

After refreshing the view in the UserLock console, the IIS agent will also still be marked as "installing" on server VES2.

Next, switch to the Exchange server VES2.

Open the IIS management console and go in the ‘Default web site’ and open "ISAPI filters." Here we add the UserLock IIS agent located at the following path: c:\Windows\System32\IisSessions.dll

Once the ISAPI filter is registered, we make sure with the Ordered list view, that the UserLock agent is at the bottom.

(If the agent is not at the bottom, the protection will still work but if a user enters invalid credentials by mistake, their account may be immediately locked out even if the Active Directory is configured to lock accounts only after several failed attempts.)

Next, go onto a workstation and access a mail box with Outlook web access to force the ISAPI filter to be loaded by IIS.

If we go back to the UserLock console and refresh the "Agent distribution" view we now see that the agent status has switched to "Installed."

If we look at the "user sessions" view we see several IIS sessions; not all related to OWA. This is because other services are provided by Exchange through IIS: For example, ActiveSync for mobile access, RPC over http, Auto discovery, Offline Address book…

We’re not interested in all these other sessions because many of them are generated by the desktop version of Outlook and workstations are already controlled by the desktop agent of UserLock.

Keeping all these sessions would generate too much data, hiding the really interesting information from a security point of view. We’ll see in the next steps how to fix that.

If we check how these Exchange web applications are configured in IIS we see that they run in different IIS application pools.

The UserLock IIS Agent can take advantage of these different application pools to filter out the sessions we are not interested in and don’t want to manage.

To do this we create the following registry value and add all concerned application pools we are interested in.

HKEY_LOCAL_MACHINE\SOFTWARE\ISDecisions\UserLock\IIS\ProtectedApplicationPools (REG_MULTI_SZ)

• If we are interested in Outlook Web Access we add MSExchangeOWAAppPool

• If we are interested in Active Sync we add MSExchangeSyncAppPool

For this example we add both of them.

Once this is done, the ISAPI filter needs to be reloaded in all application pools. Either restart IIS immediately or wait until all application pools are recycled.

After generating some activity by accessing mailboxes with Outlook Web Access we can now see that only Outlook web Access and ActiveSync sessions are displayed.

Next, we’ll set and enforce some session access rules.

From the "Protected accounts" view we can create a new rule. For example, limit the protected account "everyone" to allow only one opened IIS session.

When we then try to access a mailbox that is already open with Outlook web access from somewhere else, we see the following.

A deny message is shown explaining that the maximum number of concurrent logon has been exceeded and mentioning from where the user is already logged on.

This access session control helps protect against unauthorized access to company email outside of the office. What’s more, once the agent is deployed, all IIS sessions for the chosen application pools will be logged in the UserLock database and displayed in real-time in the User Session view within the UserLock console.