Before installing SecureLogin on workstations, review supported platforms, determine a type of installation, and complete pre-installation tasks.
Novell SecureLogin 3.0 supports the following platforms. Latest support packs are recommended for all platforms.
In the non-SecretStore mode, SecureLogin runs against eDirectory on any platform.
SecureLogin 3.0 only supports ConsoleOne® 1.3.2 or later.
Depending on workstation configurations, the browsers might behave differently.
Windows 95 and Windows 98 workstations should have Novell ClientTM 3.21 or later.
Windows 2000 workstations must have Novell Client 4.71 or later.
The SecureLogin snap-in to ConsoleOne requires ConsoleOne 1.3.2 or later. The installation program can install version 1.3.3.
When you install SecureLogin on a workstation, you must select one of the following installations:
Before installing on a workstation, complete necessary pre-installation tasks.
The Novell eDirectory with SecretStore option installs SecureLogin onto networks that are running one of the following:
This option uses Novell's patented SecretStore client/server system to provide the highest possible level of security for user login data. SecretStore requires server components on the eDirectory server and SecureLogin client software on workstations.
If you plan to use SecureLogin with SecretStore, complete the following tasks before installing SecureLogin on a workstation:
Install SecretStore on a server.
See Installing SecretStore in the Novell SecretStore Administration Guide.
Extend the NDS or eDirectory schema.
Prepare the workstation.
Migrate earlier versions of Novell Single Sign-On or Novell SecureLogin.
Ensure that the workstation's current primary tree and server connections are set to the tree in which the SecretStore service has been installed.
The Novell eDirectory option installs SecureLogin onto networks that are running NDS® (NetWare 4.2 or later) or eDirectory. This option provides secure, centralized storage of user login data by performing encryption once on the workstation before the data is saved to eDirectory. No server components are installed for this option. The first installation of client software must be done by an eDirectory administrator to extend the schema and assign user rights.
If you plan to use SecureLogin with eDirectory, complete the following tasks before installing SecureLogin on a workstation:
Extend the NDS or eDirectory schema.
Prepare the workstation.
Migrate earlier versions of Novell Single Sign-On or Novell SecureLogin.
Ensure that the workstation's current primary tree and server connections are set to the tree in which the SecretStore service has been installed.
The LDAP option installs SecureLogin into LDAP v3.0 directory environments (for example, Novell eDirectory 8.5 or later).
This option does not require the Novell Client for Windows.
If you plan to use SecureLogin with LDAP, complete the following tasks before installing SecureLogin on a workstation:
Extend the LDAP directory schema.
Grant rights.
See Granting Rights .
Set up LDAP mappings.
Before LDAP client support can be used, you must map NDS or eDirectory attribute names to LDAP names.
The LDAP v3.0 client option supports servers that have the following:
Establish a Novell Client connection to the NDS or eDirectory server where you want to run LDAP compatibility mode.
From that client connection, launch ConsoleOne.
Select the LDAP Group object for your server.
Display the Attribute Mappings tab by clicking Properties > Attribute Mappings.
If you can't locate this tab, you must install the LDAP snap-in to ConsoleOne. Download the snap-in from http://download.novell.com. Select ConsoleOne Snap-ins > On NetWare > NDS eDirectory 8.5 Snap-in.
Click Add.
From the NDS Attribute drop-down list, select the Prot:SSO Entry attribute.
If the Prot:SSO Entry attribute is unavailable, run NDSSchema.exe or LDAPSchema.exe. These files are in the securelogin\tools directory.
Map the Prot:SSO Entry attribute to protocom-SSO-Entries, as indicated in the following figure.
Similarly, map the Prot:SSO Auth attribute to protocom-SSO-Auth-Data.
Similarly, map the Public Key attribute to publicKey.
Click Apply and then click Close.
Refresh the LDAP server.
If you are using ConsoleOne, right-click the LDAP Server object, click Properties, and then click Refresh NLDAP Server Now.
If you are using Novell iManager, click LDAP Management, click LDAP Overview, click View LDAP Servers, select the LDAP server, and then click Refresh.
Install a Trusted Root certificate by copying RootCert.der from sys:\public to c:\Program Files\novell\securelogin.
After you select the LDAP option during a SecureLogin installation, the installation program copies the RootCert.der file to the c:\program files\novell\securelogin directory. This is a placeholder file. You must replace RootCert.der with an actual Trusted Root certificate file. Users must browse to this file and use it for an SSL LDP bind on their client workstations.
When eDirectory is installed on NetWare, RootCert.der is exported to the sys:\public directory. When eDirectory is installed on Windows NT or Windows 2000, RootCert.der is exported to the winnt\profiles\administrator\recent directory.
If sys:\public or winnt\profiles\administrator\ recent is unavailable, you can create, export, and copy a TrustedRootCert.der file:
Provide information for users.
When using the LDAP connectivity option, the user must provide LDAP server information during the first login. For subsequent logins, this information is automatically saved and entered into the login dialog box.
You must provide users with the following:
By default, this is port 636. When entered, it is saved in the workstation's registry for subsequent logins.
To simplify the initial LDAP login, you can preconfigure these registry values as part of an automated client deployment. To do this, modify the HKEY_CURRENT_USER registry key.
The following lines contain a sample registry entry:
HKEY_CURRENT_USER\Software\Protocom\SecureLogin\LDAP Settings
"PrimaryHost"="151.155.164.77"
"SecondaryHost"="151.155.165.88"
"PrimaryPort"=dword:0000027c
"SecondaryPort"=dword:0000027c
"SSL Cert File"="C:\\TrustedRootCert.der"
"Context1"="O=Novell"
The Other option enables you to install a standalone version, Microsoft Active Directory* Server Interface (ADSI), or Microsoft NT 2000 Domains.
The Standalone option installs SecureLogin on a workstation and runs without eDirectory synchronization. This option uses only local cache files.
Select this option to demonstrate or evaluate the product.
Before installing SecureLogin on a workstation for Active Directory, set up SecureLogin for an Active Directory server. See Installing SecureLogin on an Active Directory Server .
If you have a mixed Widows NT/2000 environment, follow instructions in Setting Up SecureLogin for NT 4 Domains . If all users are connecting to a Windows 2000 server running ADS, follow instructions in Installing SecureLogin on an Active Directory Server .
Then install SecureLogin on workstations.
For SecureLogin to be able to save user single sign-on information, the eDirectory schema must be extended. Therefore, for the first installation of SecureLogin into an eDirectory tree, run NDSSchema.exe. (You only extend the eDirectory tree schema once for SecureLogin.)
NDSschema.exe also grants existing users rights to the SecureLogin attributes on the User object. This file is in the securelogin\tools directory. You can run NDSSchema.exe multiple times to grant rights to users that you create after installing SecureLogin.
To extend the schema of a given tree, you must have sufficient rights over the [root] of the tree.
WARNING: Don't run NDSSchema.exe from a Windows 98 workstation. SecureLogin doesn't support using Windows 98 to run NDSSchema.exe.
At the securelogin\tools directory, run NDSSchema.exe.
The extension may take some time to filter throughout your network, depending on the size of your network and the speed of the links.
Enter an eDirectory context so that SecureLogin can assign rights to User objects.
You will be prompted to define a context where you want the User objects' rights to be updated, allowing users access to their own single sign-on credentials. The following figure illustrates this prompt:
If the installation program displays a message similar to -601 No Such Attribute, you have probably entered an incorrect context or included a leading dot in the context.
For Windows 95/98, Windows NT/2000, and Windows XP Pro workstations, install required software as listed in the following table:
To enable support for NMAS NDS Password disconnected login, set the registry key "NMAS required for disconnected mode" (a DWORD value) to 1. This key resides under HKEY_CURRENT_USER\Software\Protocom\SecureLogin.
To disable support, delete the DWORD value or set it to 0.