Yes! RSA SecurID is now DirectPush friendly…

One of the questions I consistently get asked during conferences is: “Does ActiveSync support RSA SecurID?”.  This is a two-part answer.  The short answer is “Yes, Windows Mobile and Exchange ActiveSync support SecurID”.  The second part is: “But, the experience on the device is really not that good…especially if you have Scheduled Sync or DirectPush enabled”.

Let me briefly elaborate on that.  The key point is that if you have SecurID enabled when the device issues a request to the server it will be challenged to enter the SecurID.  From the user perspective this is a familiar form where you can just type in the SecurID, click OK and the device can sync.   This is a somewhat ok experience if you manually sync every once in a while.  But, if you have DirectPush you are pretty much challenged to enter the SecurID token every time you get an email…you get the point: it really becomes extremely annoying for users.  Who would want to enter the SecurID token for every email?

The GREAT news is that our friends at RSA have notified us that they have a fix to improve the end-user experience and still get the SecurID benefits.  In their latest RSA Web Agent update there is a new feature that allows ActiveSync sessions to be “cached” for an admin-chosen number of hours.  This is better explained by an extract from RSA:


“RSA Authentication Agent 5.3 for Web for IIS enables you to use Microsoft Outlook Web Access ActiveSync without having to reauthenticate every time ActiveSync is invoked. When you invoke ActiveSync by clicking Sync on the Pocket PC, the Agent provides a one-time authentication window for ActiveSync that is valid for a default of 15 minutes. This default time setting matches the default time setting of Cookies Always Expire After the Specified Time. If you extend the duration of the browser session cookie by changing the value in the Cookies Always Expire After the Specified Time field on the Agent tab of the IIS configuration panel, you extend the one-time authentication window for ActiveSync to the same number of minutes. You can further extend the ActiveSync time window to remain valid beyond the maximum time duration of the browser session cookie by adding an entry to the registry.

To extend the ActiveSync time window:

    1. On the protected web server, log on as Administrator.

    2. Click Start > Run and in the Run dialog box, enter regedit.

    3. In the Registry Editor, click HKEY_LOCAL_MACHINE\SOFTWARE\SDTI\RSAWebAgent.

    4. In the right pane of the Registry Editor window, right-click, and then click New > DWORD Value.

    5. For the new value name, enter ActiveSyncWindowExtension = <number of minutes>, where <number of minutes> is the number of minutes that you want the ActiveSync time window to remain open.
      The maximum number of minutes is 1440 (one day).


You can find more info on the RSA web site or if you are an RSA customer you can call their support line.

This is truly great news!

Max Ciccotosto

Comments (13)
  1. Rick says:

    We are using SecurID for OWA.  We are leveraging the SecurID feature built into ISA.  How can we leverage ISA’s SecurID feature for EAS?

  2. Anonymous says:

    Previously many customers had avoided using SecureID with Exchange Activeync because entering the credentials…

  3. Anonymous says:

    One of the questions that came up at least once in each of the cities was from someone who had an RSA…

  4. Max says:


    I would suggest you get in touch with the RSA Product Support.  Based on my understanding you need to have a Web Agent installed and the ISA plugin by itself does not do it.

  5. Anonymous says:

    I almost missed the weekend, but gladly I made it on time&amp;nbsp;;-)

    Rivals Take Aim at RIM


  6. Jason says:

    I beleive “Remote Wipe” uses Direct Push technology, so how would Remote Wipe work in the SecurID scenario; would sys admin be able to send a “remote wipe” command to a stolen device after the session cookies expire after the specified Time?

  7. Anonymous says:

    Last nights Brisbane Infrastructure Group last night rocked.&amp;nbsp; (Ok I&amp;nbsp; may be&amp;nbsp;biased – but…

  8. BrAtKo says:

    We have RSA, OWA and EAS working fine. But I have problem with OMA, I have all on front end, SSLed and RSAID protected. I get always error about Web Server Security Settings, error 500. I think I have to create another virtual web without SSL to work this. Am I right ? Thanks.

  9. Robert says:

    This is a little late but I was wondering how Microsoft deals with security and mobile devices.  


    New employee has treo 650.  Does this user go through a process to get setup or is he just allowed to connect without Microsoft IT knowing?

    We are faced with the mobile devices growing faster over the BB now and I am trying to go over the in’s and out’s of why to have a user come to IT to be setup on the EAS or just let them do it themselves.  

  10. ML49448 says:

    Is your question specific to RSA, or more general to allowing devices to sync with your Exchange server?

    For Secure ID implementations, the user will need to get the Secure ID FOB from IT, so there is some "touch" required.

    From a general perspective, the decision on how much "touch" IT will want to have in an EAS deployment is based on two main factors:

    – Support Costs

    – Security requirements

    Security Costs – EAS is implemneted through many mobile operating systems, and as a result the more devices allowed to sync to a company’s Exchange server the greater the support cost (due to the nuances of each device implementation).  There may be other support reasons as well…  

    Security Requirements – Some companies have strict corporate security policies and only a select number of devices in the market are able to satisfy.  A company may require that all devices be capable of a local wipe if the password was entered incorrectly for a specific number of times.  Another company may require the user of passwords of a certain length or specific characters used in the password.  

    It is for these two aforementioned reasons that some companies have choosen to control EAS access by blocking sync for all users (by default) and then individually enabling each user to sync once they have received the company supported device.  One thing to note about this type of approach is that once a user is enabled to sync, they can add other devices that may not be "company supported".  

  11. Robert says:

    Is there any way to stop the devices that may not be company supported?

  12. Anonymous says:



    Exchange 2003 introduced the Always Up To Date notification feature (AUTD) that kept…

  13. BrAtKo says:

    Hello, even I set up latest installation files and set up the registry the EAS still ask me for ID every sync. Any ideas ? Please email to bratko at gmail dot com, thanks

Comments are closed.