4.1 Types of Variables

Novell SecureLogin supports the use of four different types of variables:

NOTE:Specify variables without spaces, for example $Username_Alias. If you use spaces you must enclose the entire variable in quotation marks, for example, "$Username Alias".

4.1.1 Using a Variable to Change the Default Platform

Each variable defaults to the platform specified in the application definition or the predefined application name. You can use a variable to change the platform, for example you can have an application definition named www.website1.com, for example:

type $username
type $password password

An application definition named www.website2.com might use the variables from www.website1.com, for example:

type $username(www.website1.com)
type $password(www.website1.com) password
Directory attribute variables

4.1.2 Directory Attribute Variables

Novell SecureLogin reads directory attributes from the currently logged in user's object.

For example:


reads the CN attribute from the currently logged in user's object and specifies it.

You can only use the percentage symbol (%) variables when Novell SecureLogin is configured to use a directory, and only on single-valued text attributes.

Quotes are required around the variable if the attribute name contains a space.

For example:

Set ?text “%Login Time”

Messagebox "%Given Name"

4.1.3 Stored Variables

Stored variables are the most common style of variable used in application definitions and Predefined Applications. They are preceded with a dollar symbol ($). Use these variables to store the values used during the login process, such as usernames, passwords and any other details that are required.

This section contains the following information:

Storing the Variables

The values of these variables are stored in the directory under the user object. They are encrypted so that only the user can access them. You can store variables separately for each application definition and predefined application, so the username variable for one application can be different from the username variable for another application. It is, however, possible to set an application to read variables from another application's application definition and predefined application. This is useful for applications that share user accounts or passwords.

For details, see Section 5.2.73, SetPlat

Using Stored Variables

If a stored variable is referenced in an application definition and predefined application, and there is no value stored for that variable (for example, the first time the program is run), SecureLogin prompts the user to enter a value for the variable. This is an automatic process. It is also possible to manually trigger this process to prompt a user to enter new values for particular variables.

Class #32770
Title "Log on"
Type $Username #1001
Type $Password #1002
Click #1

NOTE:If you want to hide a variable from an administrator by displaying it as **** instead of clear text, begin the variable name with $Password.

For example, the $PasswordPIN variable is protected as described, however $PIN is not.

For more details, see Section 5.2.20, DisplayVariables and Section 5.2.9, ChangePassword.

4.1.4 Runtime Variables

Runtime variables are generally used for storage of calculations, processing data, and date information. You can also use them for temporary passwords and usernames.

Runtime variables are preceded by the question mark symbol (?). They have two modes:

  • Normal runtime variables are reset each time SecureLogin is started.

  • Local runtime variables are reset each time the application definition and predefined application is started.

Runtime variables are Normal by default. For details on how to switch a runtime variable to Local mode, see Section 5.2.43, Local.

Using Runtime Variables

Runtime variables are not stored in the directory or the Novell SecureLogin cache; they are used straight from the computer's memory. For this reason, it is important not to use runtime variables for the storage of usernames, passwords, or other details Novell SecureLogin will need to access in the future.

If runtime variables are used for such details, the user is prompted to enter them each time the application definition or predefined application is run, or each time Novell SecureLogin is restarted. Users are not prompted for ?variables that have no value. These variables are given the value <NOTSET>.

Example of a Runtime Variable

Class #32770
Title "ERROR"

Local ?ErrorCount
Increment ?ErrorCount

If ?ErrorCount Eq "2"
MessageBox "This is the second time you have received this
error. Would you like to reset the application?" -YesNo ?Result
If ?Result Eq "Yes"
KillApp "App.exe"
Run "C:\App\App.exe"
Set ?ErrorCount "0"

4.1.5 Passticket Variables

Passticket variables are preceded with the exclamation mark symbol (!). To use a passticket variable, you must create and define numerical values for stored variables with the names $DESKEY and $DESOFFSET. These numbers are then used by the Novell SecureLogin application definition or the predefined application parser to generate the one-time password.

Using a Passticket Variable to Generate a Password

Once you have defined the stored variables, use the following passticket variable to generate a password.

!<Name of application definition> 



For example, if you want to use a passticket variable for the Microsoft Outlook application, create two stored variables called $DESKEY and $DESOFFSET under the Outlook application definition. Then, set values for the two stored variables, which allows you to use the variable "!Outlook" whenever you need to generate a one time password.

You can also use "!Default", which automatically reads the values from the current application definition.

If the credentials used to generate one time passwords do not already exist in a secured area of the SecureLogin cache (that is, the $DESKEY and $DESOFFSET variables are not defined), then they are retrieved from the closest SecureLogin Advanced Authentication server. For more information on this, contact Novell Technical Support.

4.1.6 SecureLogin Supported Variables

SecureLogin is able to read details from the system and use them to create variables that you can incorporate into the application definition. These variables are automatically generated as Runtime Variables and used in the same manner within any application definition.




The local SecureLogin windows agent version.

You can use this variable to determine if specific support is built into the product running on the user's workstation. The version convention is to use two digits for each section read from right to left, and leading zeros are removed. For example, version would be returned as 03000400.


Contains Internet Explorer or Netscape and indicates in which browser the application definition or predefined application is running.

This variable is only set in a Web application definition or predefined application.


The name of the user currently using SecureLogin.


The directory password of the user currently using SecureLogin.

This variable is only available if the appropriate options are chosen when installing SecureLogin.


The context within which the current SecureLogin user's directory object exists.


The name of the directory tree that SecureLogin is currently using.

NOTE:The variable ?SysTree returns the Domain name when using the Microsoft GINA (MS-AD or ADAM) and the tree name or port number when using the Novell GINA or LDAP installation.


The name of the server or the IP address of the server that was entered in the Novell Client™ login panel.

NOTE:This variable is only available if the Novell client login extension is installed (NDS) and is not available if the MS Active Directory (MS-AD) or ADAM option has been installed.


Contains the condition state value when SLLauncher is run.

This variable is set to True when a script is being executed by SLLauncher. Otherwise it will be <NOTSET>.


The running time in seconds from January 1970 to the present. You can use this variable to force password changes every X days, and so on.

Do not use the application definition to force a password change if you want to continue having the application generate the change password event (recommended). Use this variable on applications where you cannot set a password expiry at the application back end.