RSA SecurID for Microsoft Windows
A well-conceived offline mode.
Server-side configuration can be complex if you only want a simple setup.
A very welcome addition to the RSA SecurID portfolio.
Replacing the weak security of passwords with two-factor authentication is a no-brainer for security today, but there are still situations where passwords remain.
One of these is the venerable Microsoft Windows login screen, dating back to Windows NT. Though that login screen has been strengthened over time, with ideas such as the Ctrl-Alt-Del requirement to avoid password interception, it is still just a password-entry element. And with integration into directory services, that single password can be the start of an enterprise-wide authentication.
So it was with interest that we received RSA's SecurID for Microsoft Windows, which replaces the Windows logon screen with an RSA version, using a SecurID token for strong, two-factor authentication. RSA is not the first to do such a thing, but the company had (we were told) been holding off on its release to iron out some complications. We are glad they did, because the end result was worth waiting for.
In its simplest configuration, the SecurID login client authenticates local logins against an RSA Authentication Manager (the service formerly known as ACE/Server), thereby granting access to the desktop. At the other end of the scale, the service can be integrated to authenticate the user to domain resources, with access managed across multiple domains by Active Directory.
Managing rights on a single machine (such as you might do in a shared environment, such as a point-of-sale terminal) is simplicity itself if you have any experience with ACE/Server.
With the server set up and configured, and token certificates imported, users are assigned to tokens in the usual way. Then the client side software needs to be installed on each client machine (or pushed out with a software provisioning tool), and at the next login the password screen is replaced with RSA's own password screen.
For domain authentication, a couple of further steps must be taken on the server – that of installing and configuring a certificate service and the domain authentication agent.
This can be finicky. There are several steps to take, and trying to shortcut the process sometimes means having to start over.
But the documentation provided was very good, and walked us through setting the services up without much fuss. Once configured, the service worked exactly as expected.
We are glossing over much of the detail of the server configuration in saying the above. There is an enormous amount of control given to domain access rights, logging, token and certificate management, but we will avoid most of that in this review (focusing as we are on the Windows login service).
One key point, however, is the facility to allow offline authentication, which is a major step and one of those complications RSA needed to iron out before shipping the product.
Offline authentication allows the server to generate a client-side mechanism which will authenticate a user if a connection to the server cannot be established. The most obvious use for this is laptop users, who frequently use their machines without a pre-existing network connection.
RSA enables users to be set up with several days of authentication, in which the client machine will effectively function as the server and check the supplied passcode and PIN in the usual fashion. The period can be set on a per-user basis.
Then, when the user reconnects, the client will synchronize its access logs with the server. Repeated failed logins can require an emergency code to be entered to unlock the system.
To make offline authentication work, the token must have previously been used on the system (to generate the cached credentials). When online again with a connection to the server, the number of available days is "topped up" back to the maximum set by the administrator. A taskbar icon also shows the status of this, and the software can fire up a sort of battery-low warning when the days are starting to run out.
On the client side, once the local software has been installed, users can still log in with their existing usernames and passwords at the new RSA prompt until an administrator uses the simple client configuration tool to enforce SecurID passcodes for specific users. The company recommends setting up a SecurID user group for this purpose.
The first time a user logs in with a token, a PIN needs to generated and sent back to the server. Entering just the SecurID code displayed on the token will bring up a prompt where the user can enter a new PIN, after which the user can log in normally (with the PIN code followed by the token code).
From the user's perspective, apart from a different password screen and the presence of the RSA token, the login process is as seamless as ever. From the administrator's point of view, all Windows local and domain logins can now be administered and monitored (in real time, even) from the RSA server console.
RSA's SecurID suite was already a powerful two-factor solution, but the introduction of SecurID for Microsoft Windows gives the firm a compelling product for desktop authentication, too.
With cross-domain integration and the existing breadth of the RSA Authentication Manager, we have no concerns about deploying the software across any size of enterprise. Only the possible overhead of managing large numbers of tokens (with replacements, revocations for lost tokens, and so on) detracts from a great addition to the RSA offering.