Configuring mobile logon

Updated: February 1, 2011

Applies To: Unified Access Gateway

When end users log on to Forefront Unified Access Gateway (UAG), the logon experience from mobile devices is different depending on the version of the portal being used. When using the premium mobile portal, end users go to the Forefront UAG portal web site and log on with their user name and password (or other credentials, depending on the authentication server).

When using the non-premium mobile portal, you can configure Forefront UAG to allow end users to enter their password once and to configure a personal identification number (PIN). When you configure Forefront UAG in this way, when end users go to the Forefront UAG portal on subsequent occasions, they are required to enter only their PIN. To enable this feature, Forefront UAG sets an encrypted cookie on the mobile device containing the user name, password, PIN, server secret, and ‘salt’. When the user makes subsequent logon attempts the mobile device sends only the cookie and PIN. Forefront UAG decrypts the cookie and authenticates the user. Depending on the configuration, end users are required to enter their password every few days, after which they can again log on using their original PIN.

Note

If the cookie is stolen from the device, it cannot be used without the end user’s PIN.

The configuration settings are stored in the .../Microsoft Forefront Unified Access Gateway/von/InternalSite/Mobile/config.xml file.

To configure PIN logon

1. On the Forefront UAG server, open the .../Microsoft Forefront Unified Access Gateway/von/InternalSite/Mobile/config.xml file.

   The file contains the following parameters:

   IsPINEnabled="true"
   IsSaveUserDetailsEnabled="true"
   RevalidatePasswordDays="7"
   CookieExpirationDays="90"
   PINLength="5"
   StringLengthMin="1"
   StringLengthMax="20">
   <SameRepositories>
   </SameRepositories>
   

2. Configure the settings as follows:

   • IsPINEnabled—Use this parameter together with the IsSaveUserDetailsEnabled parameter to define how users log on. Set this parameter to true to allow users to log on with their user name and a PIN of their choosing. Set this parameter to false if you want to force users to always log on with their user name and password.

   • IsSaveUserDetailsEnabled—Use this parameter together with the IsPINEnabled parameter to define how users log on. Set this parameter to true to save user details between logon attempts; users need to enter only their password or PIN. Set this parameter to false to force users to enter their details at every logon attempt; users must enter their password or PIN at every logon attempt.

   • RevalidatePasswordDays—After setting a PIN, users can log on with their user name and PIN. After a set number of days, set by this parameter, users must enter their password, after which they can continue to log on with their original PIN.

   • CookieExpirationDays—Set the cookie expiration length in days. After this number of days, the cookie is deleted. The next time users log on they must choose whether to log on using their user name and password or with a PIN, after which a new cookie is created. The cookie expiration length is reset every time the cookie is changed, for example, when revalidating the password. When the cookie expires, it is deleted and a new cookie must be created.

   • PINLength—Use this parameter to define the PIN length that users must enter. If you change this value, you must also change the relevant text strings in the resources.xml file.

   • StringLengthMin—Defines the minimum length of the username and password parameters.

   • StringLengthMax—Defines the maximum length of the username and password parameters.

   • SameRepositories—Use this section to define groups of repositories when you are using smartcards for authentication. This section is relevant only for non-premium mobile devices and is necessary when you use two authentication repositories that perform authentication against the same authentication server. In this situation, you should create a repository group to allow single sign-on (SSO) between the repositories so that the end user is not required to enter the same credentials twice for the authentication server. The following code sample shows how to configure the SameRepositories section.

     <SameRepositories>
         <RepositoryGroup>
             <Repository>AD_auth</Repository>
             <Repository>ACE_auth</Repository>
         </RepositoryGroup>
         <RepositoryGroup>
             <Repository>AD_auth</Repository>
             <Repository>Novell_auth</Repository>
         </RepositoryGroup>
     </SameRepositories>