UserLock Documentation
UserLock Documentation
You are here: Use cases > Advanced use cases > Secure Remote Access to an Exchange Mailbox

How to Secure Remote Access to an Exchange Mailbox with UserLock

Unauthorized access to users’ Exchange mailbox is a key security concern for many organizations.

In this article we will outline how UserLock protects access to Exchange 2013 mailbox and offers the control and visibility to Internet Information (IIS) sessions to help stop security breaches.

This procedure also applies to Exchange 2010 and Exchange 2016 or higher. For Exchange 2016 or higher, you will find a specificity at the end of this article.

Video Tutorial

A walk through on how to protect OWA with UserLock

Deploy the IIS Agent to monitor & audit mailbox access

As before, we will perform our demonstration on a small Active Directory environment: The server VES1 is the domain controller where UserLock is installed. The server VES2 has Exchange 2013 installed with the Client Access role. We will also use a workstation VEW1 to access a mailbox with Outlook 2013 and OWA.

  1. From the ‘Agent distribution’ view we can install the IIS agent on the server VES2.

    install UserLock IIS session agent

  2. You will notice that we need to finish the installation by registering the HttpModule.

    registering HttpModule

  3. Next, switch to the IIS management console on the server VES2. At the root of the server we open the Modules.

    IIS Manager modules

  4. Click on Configure Native Modules.

    Configure native modules

  5. Next click on Register.

    configure native modules register

  6. Specify the path to the UserLock HttpModule located at the following path: c:\Windows\System32\UlHttpModule.dll.

    configure native modules select path

  7. Once we click OK the module is selected in the native module list. If we leave the module selected it will be active server wide for all IIS applications. We recommend unselecting it and enabling it only on selected applications.

    configure native modules selected applications

  8. Once it is deselected in the root, enable it only for applications that you would like to protect,. For example you can enable it for OWA as shown below.

    viewing many different IIS sessions mailbox access

  9. Now that the agent is active, you can verify by connecting as user Bob to OWA, and in the UserLock console, under the "User Sessions" view, you should see Bob's OWA session.

    remove UserLock agent modules list IIS

  10. Next, logoff Bob from OWA and refresh the "User Sessions" page in the UserLock console. You should see that Bob's session is no longer visible.

    enable UserLock agent OWA ActiveSync

Detect when a user signs out from OWA

Next, let’s make Bob sign out from OWA.

owa sign out

If we look at the session view in the UserLock console we can see that the session is gone and Bob has only its workstation session on VEW1 still open. UserLock can detect when a user signs out from OWA.

Mailbox access Exchange 2013 logged off UserLock

Detect unauthorized mailbox access & close IIS sessions

Now, if we let Bob open a session on OWA with Alice’s credentials you can see clearly in the UserLock console that the OWA session from Alice is generated from the IP address of the workstation VEW1 where Bob is logged on.

monitor-suspicious-mailbox-access-exchange-2013-userlock

If we are the UserLock administrator, we would now be legitimately suspicious by seeing Bob accessing Alice’s mailbox. In this scenario the administrator can simply select the identified suspicious session and click logoff to close the suspicious access.

logoff-react-suspicious-mailbox-access-exchange-2013-userlock

Restricting mailbox access by IP address

As a precautionary measure the administrator could create a protected account rule for Alice to deny IIS sessions from the address 10.2.2.11.

restrict logon by IP address for IIS Sessions with UserLock

What’s the result? When Bob tries to do something in OWA he will be automatically redirected to the logon page:

outlook web access logon page

And if Bob tries to logon again with Alice credentials on OWA, he will receive the following deny message.

deny logon workstation restriction message with UserLock

As you can see, with UserLock an administrator can quickly react and sign out a user from a mailbox thanks to the new IIS session logoff feature.

About Exchange 2016 or higher

The same procedure will work on Exchange 2016 or higher too. There is only one point that you should take note about Exchange 2016 or higher:

If you do this procedure till the end, the IIS Agent will be configured only for “OWA” and “Microsoft-Server-ActiveSync” applications.

With Exchange 2016 or higher, the problem is that, after any update, all HTTP modules (including the IIS Agent) configured in applications only (not at the root level of IIS) will be automatically disabled.

Workaround

  1. Configure the HTTP Module IIS UserLock Agent at the root level of IIS (as documented at the beginning of the article).

  2. Specify IIS Application Pools to monitor:

    • By default, when you configure the IIS agent on an IIS website, all applications from this site are monitored independently of the application pool they run on.

    • If needed, you can choose to monitor only Web applications running on specific application pools by creating the following registry value (REG_MULTI_SZ type) on the IIS server:

      HKEY_LOCAL_MACHINE\SOFTWARE\ISDecisions\UserLock\IIS\ProtectedApplicationPools
    • Then enter the list of all application pools you want to supervise (one per line).

    • On an Exchange server for example, many Web applications are created on the 'IIS Default' website. If you configure the UserLock 'IIS agent' for this site, UserLock will display a lot of IIS sessions.

    • In most cases, you only want to control sessions from 'Outlook Web Access' and ignore the other Web applications. You can do this by specifying only “MSExchangeOWAAppPool” as application pool to monitor.

    • If you are interested in Active Sync, add “MSExchangeSyncAppPool”.

    • Example with both “MSExchangeOWAAppPool” and “MSExchangeSyncAppPool” application pools:

      protected application pools

Advanced settings
As explained in "Known limitations and additional settings" , if you want to exclude the sessions generated by Health Mailbox accounts, please configure advanced settings "IgnoredLocalUsers" and / or "IgnoredUsers".