AnyConnect integrates support for RSA SecurID client software
versions 1.1 and later running on Windows 7 x86 (32-bit) and x64 (64-bit).
RSA SecurID software authenticators reduce the number of items a
user has to manage for safe and secure access to corporate assets. RSA SecurID
Software Tokens residing on a remote device generate a random one-time-use
passcode that changes every 60 seconds. The term SDI stands for Security
Dynamics, Inc. technology, which refers to this one-time password generation
technology that uses hardware and software tokens.
Typically, users make an AnyConnect connection by clicking the
AnyConnect icon in the tools tray, selecting the connection profile with which
they wish to connect, and then entering the appropriate credentials in the
authentication dialog box. The login (challenge) dialog box matches the type of
authentication configured for the tunnel group to which the user belongs. The
input fields of the login dialog box clearly indicate what kind of input is
required for authentication.
For SDI authentication, the remote user enters a PIN (Personal
Identification Number) into the AnyConnect software interface and receives an
RSA SecurID passcode. After the user enters the passcode into the secured
application, the RSA Authentication Manager validates the passcode and allows
the user to gain access.
Users who use RSA SecurID hardware or software tokens see input
fields indicating whether the user should enter a passcode or a PIN, a PIN, or
a passcode and the status line at the bottom of the dialog box provides further
information about the requirements. The user enters a software token PIN or
passcode directly into the AnyConnect user interface.
The appearance of the initial login dialog box depends on the
secure gateway settings: the user can access the secure gateway either through
the main login page, the main index URL, a tunnel-group login page, or a tunnel
group URL (URL/tunnel-group). To access the secure gateway via the main login
page, the “Allow user to select connection” check box must be set in the
Network (Client) Access AnyConnect Connection Profiles page. In either case,
the secure gateway sends the client a login page. The main login page contains
a drop-down list in which the user selects a tunnel group; the tunnel-group
login page does not, since the tunnel-group is specified in the URL.
In the case of a main login page (with a drop-down list of
connection profiles or tunnel groups), the authentication type of the default
tunnel group determines the initial setting for the password input field label.
For example, if the default tunnel group uses SDI authentication, the field
label is “Passcode;” but if the default tunnel group uses NTLM authentication,
the field label is “Password.” In Release 2.1 and later, the field label is not
dynamically updated with the user selection of a different tunnel group. For a
tunnel-group login page, the field label matches the tunnel-group requirements.
The client supports input of RSA SecurID Software Token PINs in
the password input field. If the RSA SecurID Software Token software is
installed and the tunnel-group authentication type is SDI, the field label is
“Passcode” and the status bar states “Enter a username and passcode or software
token PIN.” If a PIN is used, subsequent consecutive logins for the same tunnel
group and username have the field label “PIN.” The client retrieves the
passcode from the RSA SecurID Software Token DLL using the entered PIN. With
each successful authentication, the client saves the tunnel group, the
username, and authentication type, and the saved tunnel group becomes the new
default tunnel group.
AnyConnect accepts passcodes for any SDI authentication. Even
when the password input label is “PIN,” the user may still enter a passcode as
instructed by the status bar. The client sends the passcode to the secure
gateway as is. If a passcode is used, subsequent consecutive logins for the
same tunnel group and username have the field label “Passcode.”
The RSASecureIDIntegration profile setting has three possible
Automatic—The client first attempts one method, and if it fails,
the other method is tried. The default is to treat the user input as a token
passcode (HardwareToken), and if that fails, treat it as a software token pin
(SoftwareToken). When authentication is successful, the successful method is
set as the new SDI Token Type and cached in the user preferences file. For the
next authentication attempt, the SDI Token Type defines which method is
attempted first. Generally, the token used for the current authentication
attempt is the same token used in the last successful authentication attempt.
However, when the username or group selection is changed, it reverts to
attempting the default method first, as shown in the input field label.
The SDI Token Type only has meaning for the automatic setting.
You can ignore logs of the SKI Token Type when the authentication mode is not
automatic. HardwareToken as the default avoids triggering next token mode.
SoftwareToken—The client always interprets the user input as a
software token PIN, and the input field label is “PIN:”.
HardwareToken—The client always interprets the user input as a
token passcode, and the input field label is “Passcode:”.
AnyConnect does not support token selection from multiple tokens
imported into the RSA Software Token client software. Instead, the client uses
the default selected via the RSA SecurID Software Token GUI.
Compare Native SDI with RADIUS SDI
The network administrator can configure the secure
gateway to allow SDI authentication in either of the following modes:
Native SDI refers to the native ability in the
secure gateway to communicate directly with the SDI server for handling SDI
RADIUS SDI refers to the process of the secure
gateway performing SDI authentication using a RADIUS SDI proxy, which
communicates with the SDI server.
Native SDI and RADIUS SDI appear identical to the
remote user. Because the SDI messages are configurable on the SDI server, the
message text on the ASA must match the message text on the SDI server.
Otherwise, the prompts displayed to the remote client user might not be
appropriate for the action required during authentication. AnyConnect might
fail to respond and authentication might fail.
RADIUS SDI challenges, with minor exceptions,
essentially mirror native SDI exchanges. Since both ultimately communicate with
the SDI server, the information needed from the client and the order in which
that information is requested is the same.
During authentication, the RADIUS server presents
access challenge messages to the ASA. Within these challenge messages are reply
messages containing text from the SDI server. The message text is different
when the ASA is communicating directly with an SDI server from when
communicating through the RADIUS proxy. Therefore, in order to appear as a
native SDI server to AnyConnect, the ASA must interpret the messages from the
Also, because the SDI messages are configurable on
the SDI server, the message text on the ASA must match (in whole or in part)
the message text on the SDI server. Otherwise, the prompts displayed to the
remote client user may not be appropriate for the action required during
authentication. AnyConnect might fail to respond and authentication might fail.