Return to home page
Decrease font size by 1 pointChange font to 8 pointChange font to 9 point (default)Change font to 10 pointIncrease font size by 1 point

Log in or log out
Tech Notes

Setting Up Mobility Authentication

Technical Note 2177

Last Reviewed 14-Jun-2007
Applies To

Mobility XE
 Printer-friendly version

Summary

This technote describes options for setting up user authorization for connections to a Mobility server.

Quick Start

Most NetMotion Mobility users will have authentication up and running by following this simple instruction:

  • To use Windows domain credentials for Mobility connections, simply configure the setting Authentication—NTLM Global Domain Group in the Mobility server console (Server Settings page). When you point this setting at a global domain group, the members of that group will be allowed to connect.

This is the recommended configuration for most Mobility installations. The information that follows provides a more thorough understanding of how Mobility authentication works, and alternatives for configuring authentication if you don't want to use domain accounts.

How to Set Up an Authentication Scheme

When a client connects to a Mobility server it must provide valid user credentials. There are several ways to set up an authentication scheme, depending on what your needs are. Here are the steps in the process, with more detail below:

  1. Select an authentication protocol

  2. Determine how to handle client desktop access

  3. Implement

1. Selecting an Authentication Protocol

Mobility XE supports three types of authentication:

  • NTLM (Windows users and groups, including Active Directory)
    When a Mobility server is configured to use NTLM, users' credentials are authenticated against either the Windows domain that the Mobility server is a member of, or against local Windows users defined on the Mobility server itself. Users from other domains are allowed to connect if there is a trust between the domain the user is in and the Mobility server's domain.

  • RADIUS
    When using RADIUS, users' credentials are sent to specified RADIUS servers for authentication. As of version 7.0, Mobility supports three authentication protocols: RADIUS - LEAP, RADIUS - PEAP, and RADIUS - MD5.


    Most Mobility customers use NTLM authentication. If you are already using RADIUS in your environment for other purposes you may want to also use RADIUS for Mobility authentication, but even if you're using RADIUS for network access (for example, LEAP) you can still use NTLM for Mobility authentication.


    RADIUS authentication is described in detail in the Mobility System Administrator Guide. For information on configuring RSA SecurID authentication using the RSA Authentication Manager’s RADIUS interface, see tech note 2150: Enabling RSA SecurID Connections for RADIUS.

  • RSA SecurID
    As of version 7.0, Mobility supports native SecurID authentication. Mobility XE Server 7.0 and higher communicates directly with the ACE/Server using ACE/Agent software installed on the Mobility server machine. (Previous versions of Mobility XE only supported RSA SecurID authentication using the RSA Authentication Manager’s RADIUS interface; see the RADIUS section above). Mobility XE 7.0 and higher interfaces directly with the RSA Authentication Manager.


    RSA SecurID two-factor authentication meets RSA certification criteria, including native authentication via the RSA Authentication Agent and support for new PIN Mode and Next Tokencode Mode. Key fobs, PINpads, USB tokens, smart card tokens and software tokens are supported, and the implementation has been certified as RSA SecurID Ready.


    RSA authentication is described in detail in the Mobility System Administrator Guide. For information on configuring native RSA SecurID authentication, see tech note 2214: Enabling Native RSA SecurID Connections for Mobility Clients.

The authentication method is selected in the Mobility server console with the server setting Authentication—Protocol.

2. Determining How to Handle Client Desktop Access

For your remote Windows clients there are two sets of user credentials to consider:

  • A user must be able to log into the client machine's desktop

  • To connect with Mobility, a user must provide valid Mobility credentials

By default, these two sets of credentials are tied together: the Mobility client will first attempt to authenticate to the Mobility server using the same credentials that Windows uses for the desktop login. This provides a "single sign-on" feature, requiring users to enter only one set of credentials for both their desktop login and remote access through Mobility. Below are options for setting up single sign-on, and alternatives if you want to use separate credentials.

Recommended setup for single sign-on

Single sign-on is most easily achieved if you use domain accounts for both the local desktop logins and Mobility authentication, and it's the easiest to administer because you don't need to manage local accounts on your devices. It requires that you have a Windows domain, that your clients and Mobility server are all part of that domain, and that your clients are connected to the network before the Windows authentication happens.

To configure Mobility to use domain accounts for single sign-on, point the setting Authentication—NTLM Global Domain Group in the Mobility server console (Server Settings page) at a global domain group. Users that are a member of this group will be allowed to connect.

Limitations of domain accounts for desktop logins

If your clients are not part of a domain, or if your network connection isn't established until after you reach the Windows desktop (this is common with WWAN connections), then you may not be able to use domain accounts for the local Windows desktop login.

WWAN connections are especially problematic for logging into the Windows desktop with domain credentials because the network connections typically aren't established until after you reach the Windows desktop, so unless you have cached credentials from a previous login you won't be able get into Windows. See these technotes, and below, for other options:

Single sign-on using separate desktop and Mobility credentials

If you can't use domain accounts for the desktop login there are still options for achieving single sign-on.

If you define a local user account on the client that matches an account defined on the Mobility server or in the server's domain (that is, it has the same user name and password), that user will be able to enter his or her credentials just once, logging into Windows and connecting with Mobility in one step. When the user enters credentials the domain is specified either as NONE or as the machine name of the client; when the Mobility server authenticates the user against the domain it will supply the domain name automatically (or it will use local accounts—see below).

3. Implementing your Authentication Scheme

First, specify the authentication method (NTLM, RADIUS, or RSA SecurID) in the Mobility server console with the server setting Authentication—Protocol.

Refer to the Mobility System Administrator Guide for information on configuring RADIUS or RSA SecurID authentication.

NTLM (Windows authentication)

With this type of authentication you use standard Windows users and groups to manage who is allowed to connect to the Mobility server. The Mobility server authenticates users against two different groups:

  • The Mobility server setting Authentication—NTLM Global Domain Group points at a domain group whose users are allowed to connect.

  • On the Mobility server, the local group "NetMotion Users" contains users who are allowed to connect.

Using domain accounts for Mobility authentication

If you're using domain accounts for Mobility authentication the easiest way to configure this is through the Authentication—NTLM Global Domain Group setting. This allows you to manage your users in Active Directory: as you add Mobility servers to your pool they'll all pick up this setting automatically.

Using local accounts for Mobility authentication

If your Mobility server isn't part of a domain you'll need to use local users and the local "NetMotion Users" group. You then authorize users to connect using the Windows Computer Mangement tool:

  1. On the Mobility Server, select Start —> Settings —> Control Panel —> Administrative Tools —> Computer Management.

  2. Under System Tools, expand Local Users and Groups.

  3. If you don't already have the local user accounts defined, right-click on Users and select New User... to create accounts.

  4. Select Groups, then right-click on NetMotion Users and select Properties. Add users to this group who should be allowed to connect.

Authentication FAQ

Q:

Can a user be logged in multiple times at once?

A:

Yes. Some Mobility deployments even choose to have all of their devices connect with the same user name and password, but be aware of the security implications of this approach.

Q:

Can I automate the logon so that users don't have to manually enter any credentials?

A:

Yes, using the standard Windows methods for autologon; see tech note 2117 for details.

Q:

What's the sequence of events when I boot up, connect with Mobility, and log into the desktop?

A:

After you reboot (Ctrl-Alt-Del) and enter your credentials, the Mobility client passes those credentials to the Mobility server to establish the VPN tunnel. Once the tunnel is up, the client hands the process over to Windows, which then authenticates as it normally would without Mobility in the picture. If you are using domain credentials, Windows contacts the domain controller through the Mobility tunnel.

Related Information

2214

Enabling Native RSA SecurID Connections for Mobility Clients

2172

WWAN Authentication Options

2173

WWAN Authentication—Speeding Up the Desktop Login

2174

WWAN Authentication—Reaching the Domain Controller Over a WWAN Connection

2117

How To Enable Automatic Logon

9979

NetMotion Mobility Technical Notes

Please comment on this technical note.