Product Documentation

Single Sign-on Plug-in Does Not Submit Credentials

Mar 24, 2011
Occasionally the Single Sign-on Plug-in does not submit a user’s credentials to a configured application. This problem can be caused by a number of reasons, such as:
  • Changes in the web application leading to an out-of-date application definition.
  • A setting unintentionally configured when creating the application definition.
Do the following initial activities to determine the cause of the submission failure:
  • Check all settings for potential conflicts.
  • Verify that the plug-in is configured to detect applications.
  • Compare the plug-in and Single Sign-on console definitions.
  • Remove matching criteria and submission fields one by one until the plug-in begins submitting credentials.
Important: Single Sign-on contains many settings to help you build application definitions, password policies, user configurations, and identification verification methods. It is possible to create contradictory settings where, for example, credentials are not submitted to an application.

If the Single Sign-on Plug-in still fails to submit the user’s credentials, try the following troubleshooting techniques for Web-based and terminal emulator-based applications.

Web-Based Applications

  • Verifying that StrictURL Is used correctly
    1. In the Single Sign-on component of AppCenter, select the Web-based application you want to view.
    2. From the Action menu, click Edit application definition.
    3. Click Application Forms, select an application form and then click Edit.
    4. Click Form Identity. From here, you can enable Strict URL matching as well as URL case- sensitivity.
    5. Make sure that pages use HTML-compliant field types. Web application definitions require HTML-compliant field types. Undefined and user-defined field types are not detected.
  • When using InPrivate Browsing in Internet Explorer 8, ensure Disable toolbars and extensions when InPrivate Browsing starts is not selected. See Microsoft's website for details of Internet Explorer privacy features.

Terminal Emulator-Based Applications

Create terminal emulator-based application definitions using the Application Definition Wizard and Form Definition Wizard. When adding the application definition to a user configuration, be sure to enable support for terminal emulators.
  • Verify that the terminal emulator is configured in the Mfrmlist.ini file

    The Ssomho.exe process that controls Single Sign-on interaction with terminal emulators recognizes only emulators defined in the Mfrmlist.ini file. If the terminal emulator is not defined in this file, the Ssomho.exe process does not attempt to communicate with the terminal emulator.

  • Verify that a session short name is specified

    The Ssomho.exe process uses the session short name to communicate with the HLLAPI dll. Without a session short name, Ssomho.exe loads, but cannot monitor the screen activity. Configure the session short name on the terminal emulator on your client device.

  • Verify that the Ssomho.exe process is running
    Follow these instructions to make sure Ssomho.exe is running:
    1. On the computer running the Single Sign-on Plug-in software, open Task Manager and select the Processes tab.
    2. Click the Image Name heading to sort the processes by image name.
    3. Verify that Ssomho.exe is listed.

    If the Ssomho.exe process is not listed, the process could be failing to locate any HLLAPI dlls, or it could be terminating prematurely because of third-party terminal emulator-related issues.

    Note: Even if the Ssomho.exe process is listed, it may not be communicating with the HLLAPI dll successfully. Verify the session short name is correct before pursuing further troubleshooting alternatives.
  • Test each terminal emulator individually

    If you installed multiple supported emulators on the same system, Ssomho.exe attempts to communicate with all of them. Occasionally, one of the HLLAPI dll implementations may cause Ssomho.exe to be unstable. Test each terminal emulator individually by removing the other host emulators or by commenting out and resequencing the entries in the Mfrmlist.ini file.

    This step helps verify that the ssomho process is not inadvertently connecting to an emulator other than the one you are attempting to troubleshoot.