Symptoms
Exchange ActiveSync (EAS) devices continue to synchronize after their
account has been disabled. Devices also connect using an old password,
after the password has been changed.
The main issue of concern is that if a user is terminated and just
their AD account is disabled, that once their AD account is disabled
it’s believed that the user is now stopped from being able to access
anything using Windows Authentication, such as Exchange). However, that
may not necessarily be true…especially with ActiveSync.
Why Does This Happen?
One of the main reasons is due to the way ActiveSync keeps a
connection open to the server to watch for new messages. That connection
has already authenticated and has been validated…so while the AD count
may be disabled, all Exchange knows is that the user HAD rights to the
mailbox and is continuing to use that connection. Eventually, the “life”
of that authentication expires and the user has to re-authenticate
(which is all done transparent to the user) and if the account was
disabled, the re-authentication will fail and the user will no longer be
able to sync. ActiveSync devices with their long heartbeat intervals
and token cache can still allow access up to 24 hours after an AD
account has been disabled.
We have two component involved which does the authentication viz F5 APM (Pre-authentication) and IIS authentication.
The main component/feature of IIS involved is User Token Caching
in IIS. Default is 15 mins, that means, if connection is made within 15
mins of last connection, the cached token information is reused instead
of checking with AD. It will take 8 to 24 hours for IIS to reset token
caching.
In F5 APM, expiration time for authenticated session is inactivity timeout which is 15 Minutes by default and maximum session timeout is 7 days by default which will force session to re-authenticate.
However, as DirectPush in ActiveSync maintains an open
connection to server, inactivity timeout on F5 never reaches and in IIS,
cached token will be re-used.
So even after AD account is disabled, user can still sync the emails
until maximum session timeout which is 7 days or when IIS
re-authenticates the request (after it resets cached token) which could
be around 8 to 24 hours.
Resolution
According to my study, there are two solutions that we can implement to resolve this scenarios.
1. Reduce Maximum Session timeout (F5 APM) to a less value like 15 min or 30 mins
2. Reduce token caching in IIS (Not recommended)
Reduce Maximum Session Timeout
We are using APM feature in F5 which pre-authenticates the session before traffic can be sent to Exchange servers.
In APM, two timeout settings are available
1. Inactivity Timeout
The Inactivity Timeout setting controls how long a client can
keep a live session without sending traffic. Timeout counter is updated
after session is updated or client sends traffic before timeout value is
reached. Once timeout value is reached, APM will terminate the session.
For example, if user sje1 is connected and authenticated at ,
session’s start time will be current time and session’s expiration time
will be timeout value after start time. (In our case, timeout value is
selected as 15 mins as default)
The expiration value keeps updating as timeout counter of inactivity
timeout keeps updating itself after session is updated with client
traffic.
For ActiveSync devices, it keeps connection open with long their
heartbeat, resulting inactivity timeout will keep extending every second
by 15 mins.
So in nominal scenario, APM session will not be terminated until activeSync device is connected.
2. Maximum Session Timeout
The Maximum Session Timeout setting configures a limit on the
maximum amount of time a user’s session is active without needing to
reauthenticate. Default value is 7 days.
With default value, user’s session can be active maximum upto 7 days.
After 7 days, user’s session will be forcefully reauthenticated.
During my testing, I have setup this value to 12 mins. The main
difference that this value would be resulting is, it will set expiration
time for this session to 12 mins after start time.
After I setup this value to 12 mins, after every 12 mins, APM
forcefully reauthenticates all sessions. And if during this time, AD
account is disabled or AD account password is changed, at the expiration
time, APM will reauthenticates the session. If user account is
disabled, APM will deny the request for session and if password is
changed, new password needs to be updated on Activesync device.
Although reauthentication process is transparent to all other users, this will put some load on domain controllers.
Reduce token caching time in IIS
In IIS, we can reduce token caching.
But this means for every request within that period, IIS will authenticate the session with
Domain controllers. This is will put lot of load on Server and Domain
controller. This option will impact performance. This option is not recommended by microsoft.
