IS Decisions logo

IS Decisions Blog

Secure remote access to an Exchange 2013 mailbox

Learn how UserLock protects users access to Exchange 2013 mailbox and offers the control and visibility to IIS sessions to mitigate security breaches.

Updated November 1, 2023

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

In a previous article (if you haven't already, read that first), we explain how UserLock can control remote access to an Exchange 2010 mailbox through either Outlook Web Access (OWA) or ActiveSync.

In this article, we'll 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.

Deploy the IIS agent to monitor and 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.

From the "Agent distribution" view we can install the IIS agent on the server VES2.

Install UserLock IIS session agent

If you've been using a version of UserLock prior to version 8, the first difference you will notice is that we need to finish the installation either by registering the ISAPI filter (as we did in our previous article) or by registering the HttpModule.

Register Http module

The UserLock HttpModule is an agent to control IIS sessions (from UserLock version 8 onwards). The main goal of this agent is to improve the overall compatibility with most web applications. With Exchange 2013 we get a better result with the HttpModule so we will continue our demonstration with this.

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

IIS manager modules

Click on Configure Native Modules.

Configure native modules

Next click on Register.

Configure native modules register

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

Configure native modules select path

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

To illustrate this, if we had left it selected for the whole server, the result after opening a single instance of Outlook 2013 on the workstation VEW1 (10.2.2.11) would be as follows. Looking at the sessions in the UserLock console you can see a lot of different sessions for just one instance of Outlook.

Viewing many different IIS sessions mailbox access

Now remove the UserLock agent from the modules list at the root of IIS. The module will remain registered and available for selection in child applications.

Remove UserLock agent modules list IIS

Next enable it only in the OWA and Microsoft-Server-ActiveSync applications.

Enable UserLock agent OWA Active Sync

We can now see the result after all application pools have been recycled. The user Bob has an interactive session open on the workstation VEW1 (10.2.2.11) with Outlook and OWA open but we no longer see the IIS sessions generated by Outlook.

Mailbox access exchange 2013 UserLock

Detect when a user signs out from OWA

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

OWA sign out

If you're using a version of UserLock prior to UserLock 8, the session would still be open and would be considered as closed only after a timeout. Now, if we look at the session view in the UserLock console for versions 8 or after, we can now see that the session is gone. Bob has only the 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 and 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 on 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

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 IP address IIS session 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 UserLock

Easily secure remote access to your Exchange 2013 mailboxes with UserLock

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

Try UserLock for free

3400+ organizations like yours choose UserLock to secure access for Active Directory identities and meet compliance requirements.

Download a free trial