ShowTable of Contents
This article explains how to implement the Microsoft® Windows® Integrated Log-in (aka Graphical Identification and Authentication, or GINA) with IBM® Lotus® Mobile Connect version 6.x. We begin with an explanation of the Connection Manager configuration, and then move to the Mobility Client configuration.
Introduction
These days, enterprises are looking for a way to implement single sign-on (SSO) solutions in their environments. Deployments that are heavily Microsoft-based often use Active Directory for management of their users and passwords.
The Windows Integrated Log-in Graphical Identification and Authentication (GINA) feature offered by the Lotus Mobile Connect client allows enterprises to achieve SSO functionality. This article explains how to implement GINA in your enterprise, so that when users log in to their Windows XP machines, they are simultaneously logged into the Connection Manager, establishing a VPN connection.
Before you begin
By considering the following items before beginning, you can determine how Lotus Mobile Connect must be configured for your given set of requirements:
· “Will my users authenticate with their Windows credentials before or after the Windows desktop is presented?” If the answer is after, then you won’t need to configure the Mobility Client to “Start Connection When Windows Starts”. If the answer is before, then you must remember to configure the Mobility Client connection properties on the Attributes tab to “Start Connection When Windows Starts”.
· “Will my users need to be able to change their Windows Domain Password while logged in with Lotus Mobile Connect?” If the answer is Yes, then be sure to complete the configuration of the Connection Manager to set up a restricted VPN session when appropriate (this is covered in the Connection Manager section of this article). If the answer is No, then be sure the user population is educated on how to properly remediate an expired password outside of Lotus Mobile Connect.
· NOTE: Windows GINA is supported only on Windows XP devices.
Configuring the Connection Manager
Configuring the Connection Manager for Windows GINA can be summarized by the following general steps:
1. Select the Mobile Network Connection(s) (MNC) that will use Windows GINA to authenticate users.
2. Create or modify an Authentication Profile (LDAP-Bind or RADIUS) to be used for the Mobility Clients using GINA for authentication.
a. Decide whether Windows Domain passwords need to be changed using LMC, and if so, configure the Authentication Profile for a restricted VPN session.
3. Associate the Authentication Profile with the Connection Profile on the appropriate MNC. Check the Security tab of the Connection Profile to ensure the Authentication Profile used to perform Windows Integrated Login is being used.
4. Test to ensure that Windows credentials are used and that users can change their passwords on the domain controller.
Create Directory Services Server Object
The first step is to create the Directory Server object, as follows:
1. Launch the Gatekeeper and log in. The default Gatekeeper user ID is gkadmin, and the password is gk4admin.
2. Add a Directory Server by right-clicking Default Resources and selecting Add Resource > Directory server (see figure 1).
Figure 1. Gatekeeper navigation
3. The dialog box in figure 2 displays. Fill in the fields as follows:
· Common name. How this Directory Server is displayed by the Gatekeeper.
· Host name or IP address of service. Enter the IP Address of the Microsoft Active Directory Server.
· Base distinguished name (DN). Used to tell the Active Directory server where to begin its search for user accounts.
Figure 2. Add a Directory Server wizard
If the Lotus Mobile Connect administrator does not know the Base DN value, then either ask the Active Directory administrator for this value, or alternatively (with proper permissions) use the adfind command to discover the Base DN.
NOTE: This command is not a Microsoft Server command, but a utility available from the Internet. Use it at your own risk.
An example of the adfind command to discover the Base DN would be:
adfind.exe (e.g., adfind.exe -default -f "&(objectcategory=person)(samaccountname=username)" –dn)
4. Click Next; the dialog box in figure 3 displays.
Figure 3. Add a Directory Server wizard (cont’d)
The Port number of service field is 389 by default.
The administrator’s account and password are critical to allowing Lotus Mobile Connect to perform the LDAP-Bind operation to the DSS.
In one case, the following command was used to derive the fully qualified name of the administrator account for use with Active Directory:
dsquery user –samid administrator
Sample Output: “CN=Administrator,CN=Users,DC=winsrv2003,DC=ibm,DC=com”
Entering this output text (without the quotes) is one way to enter the Administrator’s ID for the Directory Services Server (DSS) object.
Optionally you may secure the connection from Lotus Mobile Connect Access Manager to the Directory Services Server. For more detailed instructions on securing this connection, refer to the Lotus Mobile Connect 6.1.3 Administrator’s Guide, Chapter 5, “Configuring Resources” subsection ‘Enabling Secure Communication’.
5. Click Next; the dialog box in figure 4 displays. Choose the Organizational Unit where the DSS Object will be stored, and click Finish to complete this step.
Figure 4. Primary OU dialog
Create LDAP bind Authentication profile with Windows GINA
Add a new LDAP-Bind authentication profile as follows:
1. In Gatekeeper, right-click Default Resources and select Add Resource > Authentication Profile > LDAP-bind Authentication (see figure 5).
Figure 5. Navigate to LDAP-bind Authentication
2. The Add a New Authentication Profile wizard displays (see figure 6). Fill in the fields as follows:
· Check the box to Request Windows Credentials from GINA.
· Common name. Choose something that will make sense to you when you see it, such as “Active Directory Auth Profile”.
· Password policy. Leave set to None.
· There is an option to choose a Backup Authentication Profile should this one not be available, perhaps as the Active Directory server could be down.
Figure 6. Add a New Authentication Profile wizard
3. Click Next. The wizard dialog box in figure 7 displays. Fill in the fields as follows:
· Directory Server. Select the Directory server you had previously created by checking the appropriate box.
· When using LDAP-bind Authentication with Active Directory, set User key field to samaccountname, and set LDAP attribute used for lock status to UserAccountControl.
· Additional search criteria. There are other fields available to create additional search criteria when authenticating users, but to ensure this authentication profile works, leave this field blank initially.
· Restricted session filters. If you had previously defined a filter that allows users with expired passwords to access your Active Directory server in order to change it, then you may select that filter in this field. Otherwise, this can be done later (the next section discusses the restricted VPN session).
Figure 7. Add a New Authentication Profile wizard (cont’d)
4. Click Next; the dialog box in figure 8 displays.
· LTPA and SSO are additional features of Lotus Mobile Connect and are outside the scope of this article. Consult the Lotus Mobile Connect 6.1.3 Administrator’s Guide for details. For our purposes here, leave this page blank.
Figure 8. Add a New Authentication Profile wizard (cont’d)
5. Click Next; the screen in figure 9 displays. Decide which Organization Unit in which to store this Authentication Profile; click Finish.
Figure 9. Select primary OU 
Configuring the Connection Manager for a restricted VPN session
This section presumes that users will use Lotus Mobile Connect to remediate an expired domain password. The restricted shell, or restricted VPN session, allows a user to log in using the VPN, but the only destination host reachable by that user will be the domain controller (Active Directory) where they can change their password.
Once the password has been changed on the domain controller, the user must disconnect from the restricted session, and the log in again with the new password. This time, the session will not be restricted and would allow normal access to network resources.
NOTE: A restricted session is available only for secondary authentication using an LDAP-bind authentication profile connected to a Microsoft Windows Server 2003 or a 2008 Active Directory service server (DSS).
Here are the general steps to configure a restricted session:
1. First, make sure you have a connection profile to which you want to assign the LDAP-bind authentication profile. The connection profile must use the Diffie-Hellman key exchange algorithm.
2. Verify that you are using Active Directory for LDAP-bind operations, and then define the LDAP-bind DSS as a Directory server using Gatekeeper.
3. Determine how you want to allow Mobility Client traffic to pass after connecting with an expired password. The Connection Manager will receive a return code from Active Directory that the password is expired and then prompt it to turn on the restricted session for this user.
By default all traffic for this session is blocked. By setting up a filter(s), the administrator defines where the user may go in a restricted session. Normally an administrator would only wish to allow the user to reach the Domain Controller to change their password.
Positive-mode filters allow traffic to pass, while negative-mode filters deny traffic from passing. A bidirectional filter is applied to both incoming and outgoing traffic. Use a positive-mode bidirectional filter to the LDAP-bind DSS.
4. After reviewing the positive filters that were previously defined, determine if you need additional filters and, if so, create them in Gatekeeper:
a. Click the Resources tab and right-click the OU in which you want to create the filters.
b. Select Add Resource > Filter, and then select the type of filter to create.
c. Provide a descriptive label that will make it easy for you to recognize the profile later.
d. Select Direction > Bidirectional.
e. Select Mode > Positive.
f. Specify the LDAP-bind DSS IP address as the Destination IP address and do not specify a source IP address (see figure 10).
g. Specify the LDAP-bind DSS port as the destination port and do not specify a source port.
h. Follow the instructions in the Add wizard; click Finish.
Figure 10. Example filter
Figure 11 shows the continuation of the sample filter.
Figure 11. Sample Filter (cont’d) - Mode
5. Create or modify an LDAP-bind authentication profile that will offer restricted access (see figure 12).
IMPORTANT: If you are using Active Directory for LDAP-bind operations and you do not specify any filters to pass traffic, then all traffic is blocked by default.
Figure 12. LDAP-bind authentication profile
6. Click the Resources tab and expand the OU that contains the connection profile to which you want to assign the LDAP-bind authentication profile.
7. Double-click Connection profile, select the connection profile from the list in the right-hand pane, and then click Properties.
8. Click the Security tab and make sure that the key-exchange algorithm is set to Diffie-Hellman (see figure 13).
9. Select the authentication profile that you created in step 5 as the Secondary authentication profile; click OK.
Figure 13. Security tab
10. Make sure that the connection profile is assigned to the MNC through which the Mobility Clients connect (see figure 14).
Figure 14. Connection profile
Configuring the Mobility Client
Let’s now discuss the steps to configure the Mobility Client:
1. Make sure the Mobility Client is enabled to use the Windows user ID and password. On the Mobility Client for Windows systems:
· First, make sure that the custom program component, Windows Integrated Login, which supports using the Windows user ID and password, is installed along with the Mobility Client. If the “Use Windows user ID and password” is NOT present on a Mobility Client connection, then the Windows Integrated Login feature is not installed.
· If Windows Integrated Login is not installed, use the Microsoft Add or Remove Programs utility to install this additional feature. If you already have the Windows Integrated Login installed, skip to the next step. Use the Change option to re-launch the Mobility Client installation program (see figure 15).
Figure 15. Change option
· Choose the Modify option on the Install Program (see figure 16).
Figure 16. Modify option
· Scroll to the bottom of the list of features and make sure that Integrated Windows Logon is selected (see figure 17).
Figure 17. Select Features dialog
· Once this reinstallation process completes, you can continue with the process.
2. Create or modify a connection. Use the IBM Mobility Client Connections program from the Windows Start Programs list.
3. Right-click the icon representing that connection, and select Properties.
4. Click the Attributes tab and select the Use Windows user ID and password option. Decide now if this connection needs to be started when the Operating System starts or not; click OK (see figure 18).
Figure 18. Attributes tab
When you have the Mobility Client configured to start a connection when the operating system starts, and you have configured the Connection Manager to provide a restricted session for changing Windows domain passwords, users should be able to change their expired Windows domain password when prompted by the Windows logon operation.
If the change password operation consistently fails with a message that the domain is unreachable, you might need to modify the TCP/IP settings on the client system:
· On the Advanced TCP/IP settings for the Windows network connection, specify DNS suffixes to append, make sure the DNS domain representing the domain controller is present in this list; or, select the “Append primary and connection specific DNS suffixes” option. After modifying the TCP/IP settings, restart the system and retry the Windows logon.
Desktop Windows Mobility Clients offer the ability to authenticate to the Connection Manager, using their Windows Logon credentials either before or after the Windows Desktop is presented to the user. Refer to the Mobility Client for Windows: User’s Guide in the section “Using a Windows user ID and password to log into the Connection Manager” for details.
The Mobility Client’s Windows Integrated Login feature allows a user’s Windows login credentials to be used for authenticating to the Connection Manager, using an LDAP-bind or RADIUS Authentication Profile. The Mobility Client automatically uses the Windows credentials when connecting to a Connection Manager configured with an Authentication Profile specifying ″Request Windows credentials from GINA″.
Special consideration must be given when using the ″Start connection when Windows starts″ feature of the Mobility Client with regard to providing security credentials. The feature is incapable of prompting for credentials other than the Windows user name and password.
You may use either the Integrated Login feature to use the Windows credentials to authenticate the connection, or saved credentials, or use a combination of the two when using authentication chaining.
Examples
Example 1. Suppose the IP Connection Profile on the Connection Manager is configured on the Security Tab to use Diffie-Hellman Key exchange, and the Secondary authentication profile is an LDAP-bind Authentication Profile specifying ″Request Windows credentials from GINA″ on the General tab.
In this case the connection from the Mobility Client requires no saved credentials.
Example 2. Suppose the IP Connection Profile on the Connection Manager is configured on the Security tab to use Diffie-Hellman Key exchange, the Secondary authentication profile is Certificate based, and an Additional LDAP-bind Authentication Profile specifies ″Request Windows credentials from GINA″.
To use ″Start connection when Windows starts″ on the Mobility Client with this connection, you must configure it so it does not prompt for the user’s certificate. To do this, import the certificate into the Windows certificate store and then start the connection from the Mobility Client Connections folder. When prompted, select the certificate from the store, and select ″Remember my certificate and do not prompt″.
Future connection attempts will no longer prompt the user for the certificate. The connection can now safely be configured to ″Start connection when Windows starts″.
Conclusion
Today’s complex network environments beg to reduce complexity for the end user. Implementing the Windows Integrated Login feature of Lotus Mobile Connect supplies a partial single sign-on experience for users, thereby eliminating the need to issue log-in credentials numerous times.
This feature also streamlines overhead required by network administrators by utilizing existing corporate infrastructure. Using Lotus Mobile Connect for secure remote access provides customers with a feature- and security-rich solution for meeting this critical business need.
Resources
· Lotus Mobile Connect 6.1.3 information center:
http://publib.boulder.ibm.com/infocenter/lmc/v6r1/index.jsp?topic=/com.ibm.lmc_6.1.3.doc
· developerWorks Lotus Mobile Connect product page:
http://www.ibm.com/developerworks/lotus/products/mobileconnect/?S_TACT=105AGX13&S_CMP=LP
· Lotus Mobile Connect documentation page:
https://www.ibm.com/developerworks/lotus/documentation/mobileconnect/?S_TACT=105AGX13&S_CMP=LP
· Lotus Mobile Connect Support Web site:
http://www-01.ibm.com/software/lotus/mobileconnect/support/
About the author
Brian Erle is a Staff IT Specialist for IBM in Endicott, NY. He has more than 20 years of experience and is currently the primary Lotus Mobile Connect Support Specialist. He has extensive customer interface experience, from both a pre- and post-sales perspective. Brian is also heavy contributor to the Lotus Mobile Connect Support site, and contributes formal published content as well.