Novell SecureLogin runs on any platform that is running Novell eDirectory or previous versions of NDS®, including NetWare® 4.12 and later. SecureLogin functionality depends on whether you are running an NDS version earlier than 8.5 or NDS 8.5 or later.
SecureLogin is a suite of applications for authentication and single sign-on. As the following figure illustrates, it includes components for both client and server:
SecureLogin works by keeping a record of user authentication credentials and instructions for how to use those credentials. SecureLogin stores these credentials in the Directory, either directly or through Novell's patented SecretStore® technology. At run time, SecureLogin detects login opportunities, retrieves the appropriate authentication credentials, and then automatically supplies those credentials.
The SecureLogin script language is a key feature of SecureLogin single sign-on. This language enables the product to be compatible with almost all network environments and applications. The script language has the following advantages:
This feature is especially important when you upgrade your applications.
SecureLogin data (for example, user credentials and application scripts) is stored and protected in the Directory. When used with eDirectory, SecureLogin can use SecretStore technology to provide an additional level of security. On startup, SecureLogin performs the following tasks:
SecureLogin allows you to define which applications are to be enabled for single sign-on. This option gives you the following:
The corporate scripts are stored in a Container object rather than individual User objects. For users, the result is a less complex system. For you as the administrator, the improved login mechanisms provide the following:
At Digital Airlines, users start ICA sessions on Citrix servers with the NetWare client installed. Upon initiating a session a user must be authenticated to eDirectory (or to NDS). Authentication is achieved by the company's GINA components passing the user's credentials to the NetWare Client interface. After the interface receives the credentials, the normal user level eDirectory transaction occurs between the Citrix server and eDirectory.
Upon authentication in eDirectory, ProLauncher starts SecureLogin (Proto.exe launches which in turn starts Combroker.exe). A call is made to eDirectory to acquire/synchronize assigned scripts and stored credentials.
Control is then handed off to the specified ICA application and any SecureLogin requests are handled from local cache. As the session ages, periodic refreshes of the SecureLogin store are attempted. The timeframe is adjustable by the administrator. This is the same call to eDirectory to acquire/synchronize assigned scripts and stored credentials. (This is where the -601 occurs.)
When a user ends the ICA application, ProLauncher ends SecureLogin.
Why this could happen.
Our application could have an issue interfacing to eDirectory at refresh time.
If the replica that answers the call for SecureLogin information is busy, the request could timeout and the object would appear to be not available.
It is possible that the Citrix servers are using a different replica ring than a user might. This could explain the disproportionate number of instances with the Citrix client.
The workstation's or user's eDirectory rights could be inadequate for the requested item.
The SecureLogin scripting language enables SecureLogin to be compatible with almost all network environments and applications. SecureLogin uses a script language to provide a flexible single sign-on and monitoring environment. For example, the SecureLogin Windows Agent watches for application login boxes. When a login box is identified, the agent runs a script to enter the username, password, and background authentication information.
The script language is used in individual application scripts to retrieve and enter the correct login details. These scripts are stored and secured within eDirectory to ensure maximum security, support for single-point administration, and manageability.
The script language can be used to automate many login processes, such as multi-page logins and login panels requiring other information (such as surname and telephone number) that can be stored in eDirectory. The script language also contains the commands required to automate password changes on behalf of users and request user input when it is required.
The scripting language has the following advantages:
This feature is especially important when you upgrade your applications.
SecureLogin provides the SecureLogin application that runs on users' workstations and also provides a snap-in to ConsoleOne®.
SecureLogin leverages your existing Net directory so that you can administer single sign-on solutions for applications, users, and the entire organization. With the SecureLogin administration tools, you can centrally manage users and corporate single sign-on applications and configurations.
Novell SecureLogin runs on the desktop. Users can use this tool to manage logins. The following figure illustrates the main window for this application:
This tool enables users to do the following at their workstations:
Using the ConsoleOne snap-in to eDirectory, you can enable or disable all of these functions for individual users and the entire organization.
You access this application through the Start > Programs > Novell SecureLogin option or by double-clicking the SecureLogin icon on the workstation's task bar. The following figure illustrates this icon:
When SecureLogin is used with eDirectory, you can use SecretStore, a patented Novell technology, to store your application passwords and other authentication credentials. SecretStore is a repository located within your eDirectory User object.
SecretStore provides an added level of protection and security to SecureLogin. Only the SecretStore server can access secrets, and each secret is stored separately, so that access to data is very compartmentalized and controlled. SecretStore also provides additional capabilities to deter would-be intruders, whether internal or external to your organization.
SecretStore runs on all eDirectory platforms: NetWare 5, NetWare 6, Windows NT/2000, Linux, and Solaris.
Terminal Launcher enables you to log into any type of host that requires the user to log in using an emulator (for example, an ACF2 or RACF mainframe, a UNIX host, or a Cisco* router). Either you or the user configures Terminal Launcher to connect to the mainframe or host, wait for the login sequence, and then enter usernames and passwords.
Terminal Launcher enables you to easily launch terminal emulation sessions and to run a script within those sessions.
The script is stored within eDirectory, which makes it more secure than generic scripts that are written in a particular language for a particular emulator. These scripts are designed to be compatible with many different emulators.
With the use of corporate scripts, Terminal Launcher is very powerful. It can be used to provide shortcut icons to mainframe or UNIX applications, removing the need for user intervention.
The following figure illustrates Terminal Launcher:
You access Terminal Launcher from Start > Programs > Novell SecureLogin.
SecureLogin is designed for large networks. It supports the ability to use eDirectory to centralize the setup of the single sign-on applications. This feature is referred to as Corporate Login Scripts.
A corporate login script can be stored in either a file system or in a Container object located in eDirectory. This feature gives you the ability to write and define single sign-on scripts once for the whole organization, while still allowing for customized subordinate containers and User objects. This customization significantly reduces the effort and complexity of enterprise deployment.
If a subordinate object has a different script for the same application defined locally, the local copy will be used instead of the version that is on the higher object. If a script is defined on a User object with the same name as a script defined on a Container object, or if there are two scripts with the same name on different level Container objects, the script from the subordinate object will always be used instead of the script in the higher level object. This strategy allows for specialization in corporate scripts.
For more detail on scripting, see Administering Scripts .
Window Finder is a component for Windows applications. While you are creating a script, Window Finder enables you to find out information about the window that the login box is on. Window Finder shows you the name of a control button (for example, OK or Next) and reveals the control ID number.
This component works with
The following figure illustrates Window Finder:
You access Window Finder by clicking Start > Programs > Novell SecureLogin > Window Finder.
SecureLogin 3.0 provides a snap-in to ConsoleOne. Using ConsoleOne, you are able to do the following:
The following figure illustrates the ConsoleOne window for setting user preferences:
The Microsoft* Internet Explorer and Netscape* components enable applications that are accessed through these browsers to use single sign-on. Depending on a workstation's configuration, the browsers might behave differently.
These components also enable sites using http dialogue authentication to use single sign-on.
The SecureLogin Lotus Notes* component enables you to use single sign-on with Lotus Notes. This component is a more specialized version of the Windows applications single sign-on component and is designed so that you do not notice you have switched over to single sign-on (apart from the lack of login windows).
When you install SecureLogin on a workstation, the installation program looks for the HKEY_LOCAL_MACHINE\SOFTWARE\Lotus\Notes key in the Windows registry. If Lotus Notes is installed, a Lotus Notes SecureLogin file (pronotes.dll) is automatically installed. This file tightly integrates with the Lotus Notes authentication system.
The following figure illustrates the Lotus Notes option that is available during installation:
This option is only displayed if the installation program detects that Lotus Notes is installed on the workstation.
The installation program also updates the Lotus Notes notes.ini file by adding the following:
EXTMGR_ADDINS=pronotes.dll
After installation, the next time you authenticate to Lotus Notes you actually type your password into a SecureLogin panel designed to look like the Lotus Notes password box. This will be the last time you need to enter your password into Notes.
The next time you are required to authenticate, SecureLogin communicates with Lotus Notes in the background. The password box to log in never appears. At the end of the password expiration period, SecureLogin can prompt for a new password or automatically populate the password field.
SecureLogin supports password expiration in Notes and, as with all applications, can be set up to automatically generate a random password, based on a password policy. In addition to controlling single sign-on, this component supports
Taking advantage of eDirectory architecture, SecureLogin allows users to roam with their authentication details. Because there are no workstation dependencies, users can move freely from office to office. Their credentials follow them.
By using the local encrypted cache, SecureLogin also allows notebook users access to single sign-on.