Administrator SSO enabled a windows application using the Windows Wizard but it does not appear to work as expected.

  • 7940256
  • 19-Aug-2009
  • 16-Jan-2014

Archived Content: This information is no longer maintained and is provided 'as is' for your convenience.


SecureLogin SSO



The administrator SSO enabled a windows application using the SecureLogin Add Applications Wizard. It appeared to work but the next time they started the application nothing happened. SSO was not prompting for credentials or automatically logging on.

The administrator checked the SecureLogin icon in the system tray and it was definitely active and the application connector (formerly called scripts) appeared to be OK.



When troubleshooting the problem the administrator used the window finder to highlight the Username and Password fields on the logon prompt for the application to SSO enable and discovered they were changing every time the application started.

When SecureLogin enters credentials, it typically enters into a known Dialog ID. For example, the following command would type the Username into the field on the logon page with the Control’s Dialog ID #3.

Type $Username #3

If the wizard enabled the application but does not operate as expected from that point on, the issue is typically caused by;

  • changing Dialog IDs. Many applications have static Dialog IDs (programmed by the application developer) but some applications do not.
  • the Username and Password field are not a direct child control of the Window Title (the parent command is required)


Windows application developers typically assign windows Titles, Classes and Dialog IDs when developing their applications.

When the wizard is used to SSO enable an application, it interrogates the Title, Username and Password (and any other fields on the logon screen that a required e.g. database name, domain etc.) and the OK/Logon button at the time it is run and automatically creates an application definition.

In this case, the wizard identified the Title as “Logon”, Class as #32770, Dialog ID of the Username field as #12375, Dialog ID of the Password field as #54782, and the OK button as Dialog ID #1.

The windows wizard automatically creates an application definition using this information e.g. finance.exe similar to the following example;

Title “Logon” 
Class #32770 
Type $Username #12375 
Type $Password #54782 
Click #1

In addition to the pre built application definitions and the windows wizard, to SSO enable or customize applications, SecureLogin includes a Window Finder tool. The window finder allows you to determine what the application developer has assigned as the Title, Class, Dialog IDs etc. It also displays the executable name and command line. This information can be used to troubleshoot and/or help resolve any issues you may experience with in house developed applications.

The Window Finder is installed when you install the SecureLogin client and an icon is added to the SecureLogin program group. Wintool.exe runs the Window Finder.

To inspect an item on a message box, dialog box or other window, right click on the Protocom icon in the middle of the Window Finder and drag and drop it on the item in question (e.g. Title bar, Username field, OK button, Error Message etc.) The Window Finder will then display the details of the control.

Note: When you highlight the Username and Password fields, the Window Title should be the title of the application’s logon screen. If it isn’t, you may have to use the Parent command to enable the application as per this knowledge base article.

In this case, the Dialog IDs change for the customer’s application. To resolve this issue, simply enter the Username and Password and tab between fields (Type “T”) and press enter (Type “N”) as appropriate.

The customer edited the relevant application definition as per the following;

 Dialog Title “Logon” Class #32770 EndDialog Type $Username Type “T” Type $Password Type “N”

If you are still unable to SSO enable the application, contact