Prerequisites

  1. Right-click the Novell Client icon on the status bar (system tray), then click Novell Client Properties > Location Profiles.

  2. In the Location Profiles window, double-click Default, then click Properties.

  3. On the Credentials tabbed page, select Enable Password Field and then click OK.


How SecureLogin Performs Passthrough Authentication

Several components are utilized by SecureLogin to perform passthrough authentication. The modules differ depending on the passthrough configuration. The SecureLogin installation program detects the configuration and installs the correct modules to each device. For example, if the Citrix client is installed on the server and client, SecureLogin detects the corresponding components and installs them.

NOTE:  Prior to NSL 3.51 SP1, this was a manual process.

The following illustration details how passthrough authentication works:


Passthrough Authentication

Passthrough authentication features the following:


Workstation Components

The workstation must be configured to capture the user credentials on login to the server. This might be login to a Novell network, Microsoft network, or some other LDAP-compliant network. SecureLogin uses different modules to interface with the correct GINA in each environment. This allows the capture of the username, password, or any other variable during the normal boot/login of the client.

Different information is captured depending on the configured workstation environment. For a list of the runtime variables that are captured (for example, ?syspassword or ?sysuser), refer to "Using Symbols and Variables" in the Nsure SecureLogin 3.51.2 Scripting Guide.

The following table shows the environments and the corresponding module used.


Table 1. Workstation Components

Environment Module

Novell Client32TM (with/without NMAS)

slinac.dll

LDAP

slnmas.dll

Microsoft Client

sl_tscgina.dll

Each module captures credentials from the corresponding login dialog box and stores them in encrypted form in the registry for SecureLogin to access. When SecureLogin loads, it reads the encrypted values from the registry, deletes the registry values, and stores them in the ?sys variables as explained below:

  • The username gets stored in the ?sysuser variable.
  • The password gets stored in the ?syspassword variable.

NOTE:  The variables can be used in scripts for all applications that utilize the same credentials.

If, for some reason, Secure Login uses the wrong module, or if the module is missing, then when SecureLogin loads, it cannot copy the values to the corresponding ?sys variable. In such a scenario, if an application script utilizes the ?sys variables, the result is an error -426. Also, if passthrough authentication is configured, no credentials are supplied to the Citrix session and a second login is required.

Proper validation should be done to ensure that the credentials are captured correctly so that SecureLogin can provide them to either application scripts or passthrough authentication.


Validation of the Workstation Components

To ensure that SecureLogin client is able to read the workstation login credentials and store them in the ?sys variables, create a notepad.exe script to echo the values to a new notepad document.

  1. Right-click the SecureLogin icon on the status bar (system tray), then click Manage Logins > Applications > New.

  2. In the Create a New Application dialog box, select New Application.

  3. In the Name edit box, type notepad.exe.

  4. Leave the default (Windows) as the Type, then click Create.

  5. Click Script, then copy and paste the following script:

    ## BeginSection: "Test Notepad Script to display sys variable"Dialog   Class "Notepad"   Title "Untitled - Notepad"EndDialogType \NType ?SYSUSERType \NType ?SYSPASSWORDType \N## EndSection:

  6. To save the script and close all SecureLogin windows, click OK twice.

  7. On the Windows task bar, click Start > Run.

  8. Type notepad.exe in the Open field.

  9. Launch notepad.exe and validate that the login credentials are written to the application.

    If you receive a -426 error or if the wrong values are written to the document, it means proper modules are either not loaded or configured correctly.


Some Workstation Tips

  • After registration of components, reboot the system.
  • If SecureLogin captures only the username whereas the ?syspassword value is blank, make sure that you are not in the Workstation Only mode.

    The Novell client does not pass a password if you are logged into the Workstation Only mode. Also, in this mode, you cannot execute a login again and expect the ?sys variables to update. This process occurs only during the initial login process.

  • When the SecureLogin client acquires credentials on the workstation, it not only populates the ?sys variables but also stores the credential set within the SecureLogin data.

    If, for some reason, while SecureLogin is working, a configuration change prevents the credentials from passing, SecureLogin might still appear to work and passthrough authentication might succeed as well until the user changes the network password. But then, instead of new password, the stored credentials are used for passthrough authentication.

  • To ensure that correct username and password combination are captured from the initial workstation login, do a validation using a notepad script. For details, refer to .
  • Other tests can be performed to further troubleshoot this issue:
    • Create a new user and login
    • Expire the password and try an initial login again

    NOTE:  Make sure that you reboot the system and log in as a new user.

When prompted to change your password, click Yes and then change the user password. If the credentials get updated, this part of passthrough authentication is working properly.

IMPORTANT:  SecureLogin supports password expiration through the Novell Client login. The option to change the Novell Client password after the completion of the boot-up process is not supported. If you change the directory password anytime after SecureLogin client loads, you must log out from the workstation and log in again for SecureLogin to pick up the new password.


Server Components

Depending on the environment, SecureLogin utilizes the server module (corresponding to the client module) to perform passthrough authentication. The environment and the module details are given in the table below.


Table 2. Server Component Environments

Environment Module

Novell Client32 (without NMAS)

slinas.dll

Novell Client32 (with NMAS)

slnmas.dll

LDAP

slaa_sso.dll

Microsoft Client

sl_tsgina.dll

On the workstation, the concern is capturing credentials from the users' initial login, while on the server side, the focus is on taking those captured credentials and passing them through to the configured GINA.


Virtual Channel

In addition to the components on the workstation and server, SecureLogin requires a method of communicating the captured information between the workstation environment and the actual Citrix session. SecureLogin performs this using a virtual channel. The server modules rely on the virtual channel to get the credentials from SecureLogin.

A virtual channel is a session-oriented, bidirectional, error-free transmission connection that can be used by Application Layer code for exchanging custom data packets between a Terminal Server and a Terminal Client.


Virtual Channel Components

There are three major Virtual Channel components in the Terminal Server:

  • Client Login Extension: Collects user login credentials from the login GINA.

  • Virtual Channel Driver (VCD): The heart of SecureLogin Terminal Server single sign-on; it liaises between server login extensions and SecureLogin single sign-on to perform all Terminal session single sign-on procedures.

  • Server Login Extension: Requests user login credentials from the VCD and initiates the login. After authentication, the login extension sends credentials back to the VCD to update the SecureLogin single sign-on data store.


Types of Virtual Channels

SecureLogin uses two types of virtual channels in the Citrix environment named ICA and RDP. Two modules installed on the workstation and server allow the SecureLogin client to communicate with the specific virtual channel.

The following table provides the details:


Table 3. Details of Virtual Channel

Virtual Channel Session Client Interface Module Server Interface Module

ICA

Citrix ICA session

vdslssoN.dll

sl_ica.dll

RDP

Terminal server session

tsslsso.dll

sl_rdp.dll

On the server, there is yet another module, named sl_vc.dll. This is the main interface module on the server and provides the interface to the VCDs. It determines which of the two different virtual channels to query for the passthrough credentials.


Published Applications

An additional component is used while you launch remote applications outside of an ICA/RDP desktop session. This is typically referred to as a published application.

Here, the user clicks a shortcut to launch a remote server application without opening a full desktop session. The module SLLauncher.exe is used to interface between SecureLogin and the remote application server. SLLauncher is used to start the required SecureLogin components on the server for an application to single sign-on.

For information on SLLauncher and its configuration, refer to the SLLauncher Switches.

NOTE:  SLLauncher is not used in the actual passthrough authentication. SecureLogin uses slinas.dll, slnmas.dll, slaa_sso.dll, or the sltsgina.dll to set up the virtual channel.


Passthrough Process
  1. The user enters the username, password and, optionally, his/her Domain, NDS® context, and NDS tree. This information is encrypted and stored in the registry.
  2. SSO SLBroker reads the registry data, then destroys it. The login credentials are saved under a generic and hidden application platform in the SecureLogin SSO data store.
  3. When the user starts the Citrix ICA client or published application through an ICA file, the VCD is loaded. This driver retrieves the domain or preferred tree name of the server and then reads the platform name from SLBroker in order to retrieve the username, password, and other optional login information.
    • If the application platform does not exist, the VCD reverts to the generic platform name.
    • If the application platform name does not match the requested platform (Domain or Tree), the VCD displays a dialog box to prompt the user to enter his/her NT or NDS credentials, whichever is appropriate. The collected credentials are then sent to the server for verification.
    • When the user enters and accepts the credential dialog box, a hidden application platform is created for the next authentication request.
    • If the user chooses to abort entering his/her credentials, then the server login box is prompted as per normal.
  4. The server login extensions always send a user's login credentials back to the workstation after a successful authentication. This creates a new application platform in SLBroker, if it does not already exist, or updates the new password to SLBroker if there is a recent password change and the platform already exists.

Auto-Detection of the Client Protocol

The server detects whether the ICA protocol is present or not. If the ICA protocol is present, the server loads the ICA protocol. If the client is trying to establish a session using the RDP protocol, the server loads the RDP protocol and the session begins. By default, the server automatically responds to either the RDP or ICA protocol.The auto-detection feature is on by default. Because Windows NT 4.0 Terminal Server Edition (RDP 4.0) does not support the Virtual Channel operation, it does not respond to the client trying to establish a session using the RDP protocol.


Disabling Auto-Detection

You can do this by making the registry changes detailed below.

WARNING:  Editing the Registry can cause irreparable damage to the system. If you are not sure of the process for adding these registry values, seek assistance from someone suitably experienced.

  1. On the Windows task bar, click Start > Run.

  2. Type regedit in the Open field.

    The Registry Editor is displayed.

  3. In the left panel, select HKEY_LOCAL MACHINE > SOFTWARE > Protocom > SecureLogin > VirtualChannel.

  4. In the right panel, click Title.

    The Edit String dialog box is displayed.

    NOTE:  All Registry values specified are of string type [REG_SZ]

  5. Add the following entry:

    "AutoDetect" = "0"

HINT:  Make the following entry in the same key if needed during troubleshooting, to bypass the auto-detection feature and specify the protocol the server should use."Protocol" = "RDP" or "ICA"


User Scenario: What Happens When Susan Initiates a Citrix Session

  1. Susan logs in to the workstation. At the prompt, she specifies the login credentials.

    The appropriate SecureLogin client interface module captures these credentials, encrypts, and stores them in the registry of the workstation.

  2. SecureLogin loads the workstation, reads the encrypted credentials from the registry, then stores the values to the ?sys variables.
  3. Susan initiates a Citrix session via the ICA client, RDP client, or SLlauncher.
  4. SecureLogin detects the Citrix session and establishes the virtual channel.
  5. When login is necessary within the Citrix session, the SecureLogin client interface modules on the server query the virtual channel for the passthrough credentials.
  6. When the virtual channel provides the credentials, SecureLogin passes them through to the configured authentication service.