How SecureLogin performs passthrough authentication

  • 3149664
  • 29-Nov-2006
  • 16-Mar-2012


Novell SecureLogin
Novell SecureLogin version 3.5
Novell SecureLogin version 3.51
Novell SecureLogin version 3.51 SP1
Microsoft Terminal Server


How SecureLogin performs passthrough authentication


Several components are utilized by SecureLogin to perform passthrough authentication. Depending on the configuration, different modules are required. Starting with SecureLogin 3.51 SP1 the installation program attempts to detect the configuration and install the proper modules to each device. Prior to SP1 this was a manual process. The purpose of this document is to allow administrators to better understand which components are used and how the passthrough authentication is implemented.

Workstation components:

The workstation itself must be configured to capture the users credentials on login. This might be login to a Novell network, Microsoft network, or some other LDAP compliant network. In any case different modules are utilized to interface with the correct GINA (User Login Dialog) in each environment. This allows for the username, password, context, domain, etc. to be captured during the normal boot/login of the remote workstation. As seen in the chart below, this interface is supplied by the modules:

1. slinac.dll for Novell Client32
2. slinac.dll for Novell Client32 with NMAS
3. slnmas.dll for LDAP
4. sltscgina.dll for Microsoft client

Each of these modules will capture the credentials from the cooresponding login dialog and store them in memory for access by SecureLogin. When SecureLogin loads it reads the encrypted values from memory and stores them in the ?sys variables. For example the username would be stored in the ?sysuser variable whereas the password would be stored in the ?syspassword variable. Of course these variables can be used in scripts for applications that utilize the same credentials. If for some reason the wrong module is being used or is missing, then when SecureLogin loads it will not be able to copy the values to the corresponding ?sys variable, and a script utilizing the ?sys variables will return a -426 error. Also, if passthrough authentication is configured and the variables are incorrect, then no credentials will be supplied to the Citrix session and a second login will be required. This is one of the most critical steps for the passthrough to complete successfully. Testing should be made to ensure that the credentials are captured correctly so that SecureLogin can supply them to either application scripts or passthrough authentication.

A quick way to validate this mechanism is working, is to create a notepad.exe script to echo the values to the application. Use the application wizard to create a basic application for notepad.exe. Then copy and paste over the notepad.exe script with the one below.

## BeginSection: "Test Notepad Script to display sys variable"
Class "Notepad"
Title "Untitled - Notepad"

Type \N
Type \N
Type \N
## EndSection:

After entering this script into your test notepad appliication, then click OK to close out all of the SecureLogin windows. Then launch notepad.exe and validate that the login credentials are written to the application. If you receive a -426 error or the wrong values are written to the document then the proper modules have not been loaded or configured correctly.
One additional note should be made here. When the SecureLogin client does acquire credentials on the workstation it not only populates the sys variables but the credental set is also stored within the SecureLogin data. If for some reason it was working and then a configuration change was made that stopped the passing of the credentials, SecureLogin will still appear to work. To validate if the sys variables are actually being updated you should try either creating a new user and performing a login, or expire the password and attempt the login again. If the credentials get updated then this part of passthrough authentication is working properly.

In addition to the components necessary to capture the users credentials from the initial login, SecureLogin needs a method of communicating that information between the users workstation environment and the actual Citrix session. This is done through the use of a virtual channel. SecureLogin works with 2 types of virtual channels in the Citrix environment. This would be ICA for a Citrix ICA session or RDP for a terminal server session. Two modules installed on the workstation allow the SecureLogin client to communicate with the specific virtual channel.

1. vdslssoN.dll provides the virtual channel support within an ICA session
2. tsslsso.dll provides the virtual channel support within an RDP session

Server components:

Just like the client modules, different server modules are utilized depending on the environment. On the workstation we are concerned with the capturing of the credentials from the users initial login. But on the server side we are focused on taking those captured credentials and passing them through to the configured gina. The gina interface modules for the server are:

1. slinas.dll for Novell Client32
2. slinas.dll for Novell Client32 with NMAS
3. slaa_sso.dll for LDAP
4. sltsgina.dll for Microsoft client

These modules again rely on the virtual channel to get the credentials from SecureLogin. The main interface module is sl_vc.dll that provides the interface to the virtual channel drivers. This module determines which of the two different virtual channels to query for the passthrough credentials. The two modules that actually provide the virtual channel are:

1. sl_ica.dll provides the virtual channel support within an ICA session
2. sl_rdp.dll provides the virtual channel support within an RDP session

One additional component is utilized when launching of remote applications outside of a ICA/RDP desktop session. This is typically refered to as a published application. The user just clicks on a shortcut that launches the application from the remote server without having to open up a desktop session. The module"sllauncher.exe" is used to interface between SecureLogin and the remote application server. Sllauncher is used to start the necessary server side SecureLogin components for an application to Single Sign On. It is important to note that it is not used in the actual passthrough authentication. Either the slinas.dll, slaa_sso.dll, or the sltsgina.dll will start the virtual channel to get the necessary login information. For information on sllauncher and it's configuration please refer to the online SecureLogin documentation
So, what really happens when passthrough authentication is actually working?

1. User boots workstation. When prompted they enter their credentials to login. The appropriate SecureLogin client interface module captures these credentials, encrypts, and stores them in the registry of the workstation.
2. SecureLogin loads on the workstation and reads the encrypted credentials from the registry and then stores the values to the ?sys variables.
3. The user then 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 the login is necessary within the Citrix session, the SecureLogin client interface modules on the server query the virtual channel for the passthrough credentials
6. Once the credentials have been obtained via the virtual channel, then SecureLogin passes the credentials to the configured authentication service.

Additional Information

Formerly known as TID# 10094565