Migrating from Novell SecureLogin 3.x to 6.0: A Case Study
Novell Cool Solutions: AppNote
By Girish Mutt
Digg This -
Posted: 9 Aug 2006
This AppNote helps you migrate from your present Novell SecureLogin 3.x client to a Novell SecureLogin 6.0 client. This article clearly describes the advantages and value addition of migrating your old clients to the new 6.0 client. It also clarifies the business needs and new features that are compelling arguments for migration, as well as the technical issues behind planning and executing your migration.
- Business needs to consider
- NSL 6.0 New Features
- Planning your migration
- Migration Considerations
- Technical considerations- An Approach on How to do it
- Example of a Migration
NSL is basically a Single-Sign On (SSO) technology that eliminates the need for Windows users to remember user names and passwords for the various applications they use, after initial network login. The user names and passwords are stored on the same machine in a standalone mode or into the directory server and automatically entered into the corresponding fields of an application when Windows, Java, Web, and other applications are launched. NSL can be used with most directories like Novell eDirectory, Active Directory or any other LDAP compliant directory.
Whenever we think of migration from an older version of software to a newer version of it, the first thing that comes to our mind is whether this migration will impact the existing functionality that is doing all we need from it. It's quite natural for anyone to think of the risk factor whenever adopting change. But if you look at the other side of it, you will see many advantages of migrating to the newer version, such as:
- New features that may satisfy your business needs that have changed over time
- Excellent technical support
- New enhancements requests that can be made to support your new business needs
- Reduced time spent on patching for minor enhancements
In today's fast-growing world, everything from small components to fully functional systems are dependent on one primary thing: business logic. This is what drives innovation in the engineering stream. Let's take a look at the business needs addressed by NSL 6.0:
- Easy integration with directories
- Easy maintenance
- NSL Scripting support
One of the important issues being faced by most enterprises today is increasing the level of IT security. NSL is a single sign-on solution that provides you with utmost security in the following areas:
- Authentication Services
- Data Security
- Passphrase Security System
NSL is client software that handles the Single Sign-On requirements of an user. Its security aspect includes authentication services that enable the user to be recognized by the directory or by a standalone machine. When you use eDirectory as your back-end directory, authentication is one thing you don't have to worry about. eDirectory has one of the best supports for both basic and advanced authentication mechanisms, in the form of Novell Modular Authentication Services (NMAS). NMAS has extensive support for both single-factor and multi-factor graded authentication mechanisms, including biometric authentication. This provides great flexibility in the way the users are handled, to meet the needs of organization.
The most difficult aspect of security is handling data transmission over the communication channel. NSL supports secure transaction of data over the communication channel, between the NSL client and any directory server. NSL also supports the following data encryption mechanisms for storing the data on server:
- Triple-Data Encryption Standard (3-DES)
- Advanced Encryption Standard (AES)
Passphrase Security System
The passphrase security system ensures one more level of security for the NSL user, beyond the initial authentication to the directory or standalone machine. Passphrases, an important security component in a SecureLogin implementation, are a unique question and response combination created to verify and authenticate the individual. In a directory environment, you can create passphrase questions for users to select and answer. You can also permit users to create their own question and response combination.
Passphrases protect user credentials from unauthorized use. For example, in a Directory environment, administrators can potentially log on to the network as the user by resetting the user's network password. With SecureLogin, if someone other than the user resets this network password, SecureLogin triggers the passphrase question. An administrator cannot access the user's SecureLogin SSO-enabled applications without knowing the user's passphrase response. This passphrase can also be used in a situation when you want to use NSL in offline mode or when back-end server is not available.
Easy integration with directories
Unless you want to deploy NSL as a standalone application, you need to have a directory server with which NSL can be integrated. Here, NSL has great flexibility: you can seamlessly integrate it into your existing corporate directory that may be used for other business needs. To deploy NSL, you need not add a separate directory service.
NSL supports for the following directories:
- Novell eDirectory
- Microsoft Active Directory and Active Directory Application Mode (MADAM)
- Sun One/iPlanet directory server
- Servers running LDAP-compliant directories
NSL is very easy to maintain, as it is tightly integrated with directory. A primary purpose of using a directory is to create users and have separate data stores for each user; all the policies impact the users as per the directory design, and NSL has no control over that. Directory maintenance has a direct impact on the NSL application.
NSL demonstrates ease of use in the following ways:
- Eliminates the requirement for users to remember multiple user names and passwords beyond their initial network logon.
- Enforces policies at different levels of directory will automatically get inherited.
- Provides a good fail-over scenario when a highly available backup server is provided for NSL data.
- Easy export/import of applications across containers.
- Reduces calls to the Help Desk about locked accounts and forgotten user name and password combinations.
- Avoids creation/deletion of separate users, as the directory user itself is used. Quickly retrieves and enters credentials, which results in faster login.
- Has wizards, directory console plug-ins, and tools that make it easy to centrally configure for use on the corporate network.
NSL Scripting Support
NSL gives you the capability to create proprietary Application Definitions, a powerful feature. The Application Definition command language facilitates using SecureLogin with all types of applications. SecureLogin implements Application Definition commands to provide a flexible single sign-on and monitoring environment. This enables you to define how to handle your legacy applications that may not have pre-built scripts - you can defining your own NSL scripts.
Before exploring the new features of NSL 6.0, we need to address this question: "Why should somebody migrate to the new version of NSL 6.0, when most needs are being satisfied by NSL 3.x itself?" This is an interesting question with an interesting answer. When a product is built, there is a particular focus on business needs that drive it, developed according to the requirements of that time ("yesterday"). But today the situation may be different, with many changes needed. NSL 3.x was built based on the requirements of yesterday; for the present-day scenario, the requirements have changed a bit. We need to bring those changes in our product to provide our customers with the latest advantages in the industry.
Now let's look at the new features of NSL 6.0 that differentiate it from NSL 3.x - and that may convince you to make a move towards migration:
- User interface re-design for greater ease in navigation. The NSL client user interface has been significantly improved to provide greater ease in navigation, and enhancements have been made for easy access to all options. The re-designed user interface has a two-panel display with left and right window panes. The left panes provides easy access to most options in tree structured manner and right provide details for option selected in the left pane.
- Improved web wizard functionality. The advanced web wizard makes it easier to single sign-on enable the websites and capture virtually any web-based login. This provides simple access to any web page, and the web wizard will automatically prompt you to capture the login details, handling all the error messages and password change requests.
- Secure distribution of SecureLogin SSO configurations via digitally signed files. his feature has been designed to keep in mind all the mobile users who frequently connect to the corporate network. NSL has significantly improved the configuration distribution through digitally signed and encrypted files.
- LDAP contextless login. This new feature allows any user to log into the LDAP datastore by entering partial distinguished names, without having to remember the full distinguished names. This helps users easily log in by providing the user name. Users don't need to provide the context or position of reference to the user object in the directory.
- SecureLogin administrative management utility. For administrators, a powerful LDAP browser is embedded in a management tool that automatically browses the network configuration in LDAP environments. This enables NSL to automatically locate and display the directory structure.
- Mozilla Firefox browser support. NSL now has built-in support for the Mozilla Firefox, so you can configure the web SSO functionality with this browser as well.
- Support for more pre-defined applications. Now NSL has extensive support for all the popular and most-used applications, including Novell product-specific applications. The support is in the form of pre-built scripts that automatically detect all the applications and configure them for SSO.
- Customization of the Passphrase security system. This new features allows the administrator to disable the passphrase security system if needed. By default, this feature will always be enabled.
- Smartcard integration. NSL now provides easy-to-do integration of Smartcard technology with support for Smartcard login.
- iManager administrative support on the eDirectory and NSL administration side. This is one more new feature integration with NSL 6.0. Now the user can use iManager to do NSL configuration changes instead of ConsoleOne, which was used in earlier versions of 3.x. To facilitate this support, new iManager-specific plug-ins have been developed.
- Microsoft Active Directory Application Mode (MADAM) support. In the older versions of NSL, the support was there for Active directory to be used as directory server. Now the new MADAM, which tries to separate the user datastore specific to NSL from the normal AD datastore, is also supported by NSL. This allows the NSL datastore to remain isolated from the normal AD datastore in a deployment scenario. The AD server will be contacted for all authentication services.
- Novell Auditing system support on the eDirectory side. NSL 6.0 offers new support for auditing NSL-related events as part of the Novell Auditing system integration with NSL. This enables NSL to handle the registry for most critical events, to know the application status of NSL. If you already have a Novell Audit system, it can be easily integrated with NSL.
- Extensive support for PCprox-card-based authentication. In the NSL 6.0 release, pcprox support has been enhanced to support different readers and cards. The changes have been made to the PCprox functionality in the following areas:
- New support for 8-byte PCprox cards
- Extensive support for new readers
- iManager plug-in support for easy configuration
Because migrations can be painful if not planned carefully, you will want to make sure your technical staff has the necessary skills to implement and maintain the whole NSL system environment. NSL has one of the best consulting communities in terms of technical expertise, which you can leverage when your migration strategy is ready.
The planning phase of the migration should be the critical aspect of the strategy. That is where you make key technical decisions that must be based on foresight. For this phase, it's always advisable to get in touch with the Novell Technical Services (NTS) people who have the expertise to help you plan and execute.
Novell Technical Services offers consulting engagements that range from Strategy and Discovery to Requirements Assessment, and from Planning and Design to Implementation. These offerings help you assess both current and future strategies and discover your readiness for moving to NSL 6.0. They also provide you information about how to best approach a migration and help you implement your migration plans without issues.
Below is an overview of the requirements for a successful migration:
1. As you know, NSL has a dependency on directories. So before you consider NSL migration, you need to see whether your existing directory services (if used) has the support for all the new features that NSL 6.0 will provide. This is true not only for the Novell eDirectory but also for other directory services like Active Directory, Sun One, iPlanet, or any LDAP-complaint directory.
For example, if you are using the Novell eDirectory 8.7.3.x with NSL 3.x and you plan to migrate only your NSL 3.x client, then you're OK - NSL 6.0 has been stated to support Novell eDirectory 8.7.3.x. In this case, if you want to migrate to the latest eDirectory as well, then you need to plan for the eDirectory migration separately.
2. Once you are sure of the directory server migration, then you can plan the NSL migration without any further complications. For further information on how you can migrate from older versions, refer to the link below:
To make the decision about migrating to NSL 6.0, here are some of the key things that you may want to consider:
- New support for the latest Novell eDirectory 8.8 and Microsoft Active Directory Application Mode (MADAM).
- A rich set of new features focused on present-day requirements.
- Novell Technical Support for NSL 6.0 in the coming years. For further information on the Novell Support Life cycle, see http://support.novell.com/lifecycle/
- Extensive support for Windows/Web/JAVA/Terminal Emulator applications.
- Support for pre-built scripts for all new Novell products.
- An excellent support community that answers your queries quickly.
- All the new NSL 6.0 features listed in Section 3 above.
Once you decide to migrate to NSL 6.0, the general approach that will be planned for your migration include the following phases:
When it comes to NSL migration, you just can't rip and replace with a new software version. A careful, systematic planning process is the key to success. This entire assessment phase completely involves this. Here you will be making an assessment based on security requirements, flexibility, ease of use, etc.
During the assessment phase, there are many things to take care to avoid issues during migration. The checklist you should have during the assessment covers the following things:
- Platforms Supported
- Upgrades Supported
- Backup strategy for SSO Credentials
NSL 6.0 supports the platforms given below. The latest support packs are recommended for all platforms.
- eDirectory on Netware - eDirectory 8.7.3 on OES-SP1, eDirectory 8.8 on OES-SP1 and Novell eDirectory on Netware 6.5 SP4
- eDirectory on Linux - eDirectory 8.7.3 on OES-SP1, eDirectory 8.8 on SLES 9.1 and up eDirectory on Windows, Sun Solaris, AIX, and HP-UX
- Microsoft* Windows 2000 Server, Terminal Server, or Advanced Server with Active Directory
- Microsoft Windows 2003 Server or Terminal Server with Active Directory Servers running LDAP-compliant directories
*Client Platforms Supported
- Windows XP
- Windows 2000 Professional
- Windows 2003
*Client Platforms Not Supported
- Windows 98 SE
- Windows NT workstation
*Browsers Supported for Web-SSO
When you think of the upgrades to NSL, you need to think of two things: the NSL upgrade on the client side, and the upgrade on the server side, which depends on your requirements. In this AppNote our focus is on explaining how to handle the upgrades on the NSL client side.
Note: All upgrades explained in this section assume that you are using eDirectory as a directory server without SecretStore.
The upgrades to NSL 6.0 are supported in the following scenarios:
- Upgrade from NSL 3.5
- Upgrade from NSL 3.0.x
- Upgrades in Mixed Mode Environment
Backup strategy for SSO Credentials
When you want to upgrade your NSL client from older versions to 6.0, you may want to take a backup of the data user credentials. This can be easily done by exporting the user credentials to an XML file (non-encrypted or encrypted) that can be used to restore the credentials if needed.
During this phase, Novell helps you design a Migration Plan that accounts for both current and future architectures and the process for moving between them.
Novell Consultants will help you with:
- eDirectory Server migration path
- NSL migration path. Here it will be verified that the server meets all the NSL requirements.
- NSL Administration migration path from ConsoleOne to iManager (in the case of an eDirectory server)
eDirectory Server Migration Path
This is one of the critical part of the migration if you are migrating both your directory server and the NSL client. During this phase you need to look into the following aspects:
- Backing up of your directory server to be able to restore back to a previous state if something goes wrong during the directory upgrade.
- Deciding on the version of directory to which you want to upgrade. Here you also need to ensure that the upgraded version of the directory is supported by NSL 6.0, as mentioned in the Platforms Supported for Servers section above.
NSL Migration Path
NSL can be migrated as an upgrade from NSL 3.5 or NSL 3.0.x. The other items that need be taken care of during NSL client migration are:
- If you are using a browser version of Internet Explorer older than version 5.5, you need to plan for its upgrade to version of 5.5 or later.
- If you are using a browser version of Netscape older than 4.7.x then you need to plan for it's upgrade to version of 4.7.x or later.
- From NSL 6.0 onwards, there is new support for Mozilla Firefox 1.0.x or later. This will be needed only if you want to use this browser in your clients.
NSL Administration Migration Path from ConsoleOne to iManager
This is one of the major changes incorporated with NSL 6.0. Because most eDirectory administration is done with iManager, a browser-based administration utility, NSL related administrative tasks have also been moved from the traditional ConsoleOne utility to iManager. A set of new iManager specific plug-ins has been developed to support this transition.
During this phase, Novell helps you implement the Migration Plan that has been designed and approved by the migration steering committee and executive staff. During the implementation phase, you put into action your plan and design. This can be done by using the steps below:
- Implement eDirectory Server Upgrades
- Implement NSL client Upgrades
- Implement NSL Administration migration from Console One to iManager
Implementing eDirectory Server Upgrades
The Implementation approach for the eDirectory server upgrades as mentioned in the Design involves the following activities:
*Backing Up and Restoring eDirectory
Backing up eDirectory is not an essential requirement for eDirectory upgrades, but it's always recommended for a production environment. The backup mechanism varies from one version to another version of eDirectory, but the basic procedure is same in most cases. For example, for eDirectory 8.7.3 you can find further information on Backing Up and Restoring Novell eDirectory in the Novell eDirectory 8.7.3 Administration Guide or at:
Note: Refer to the eDirectory version-specific Administration guides for more information backing up and restoring that particular version of eDirectory.
*Performing eDirectory Upgrades
Once you back up your eDirectory server, you have fewer things to worry about. You can easily start upgrading the older version of eDirectory to one supported by NSL 6.0.
For example, if you are using eDirectory 8.7.3 and want to upgrade to eDirectory 8.8, further information can be found in the Novell eDirectory 8.8 Installation Guide at:
Note: Refer to the eDirectory version-specific Installation guides to get more information on upgrading to that particular version of eDirectory.
Implementing NSL Client Upgrades
When you upgrade the NSL Client to version 6.0, there are several possibilities depending on which version of NSL you are currently using. The upgrades to NSL 6.0 are explained below, based on versions of NSL being currently used.
*Upgrade from NSL 3.5
- If SecureLogin 3.5 was deployed to work with eDirectory, a cache most likely exists on the workstation, unless the administrator turned that capability off. After you upgrade, the 6.0 version of SecureLogin recognizes the cache left by SecureLogin 3.5 and automatically works with it.
- When you upgrade SecureLogin in the standalone mode, you will be prompted whether to run SecureLogin in the seamless mode. If you select Yes, SecureLogin 6.0 will automatically take your Windows user name and password and log in.
*Upgrade from NSL 3.0.x
To upgrade from SecureLogin 3.0.x versions,
1. Un-install SecureLogin 3.0.x from your workstation.
2. Run setup.exe found in the \securelogin\client directory on the Novell SecureLogin 6.0 image or CD.
*Upgrades in Mixed Mode Environment
You can run SecureLogin 6.0 and SecureLogin 3.0.x in the same environment. When SecureLogin 6.0 runs in the same environment as SecureLogin 3.0.x, SecureLogin 6.0 does the following:
- Versions the SecureLogin data store.
- Saves SecureLogin 6.0 data in the SecureLogin 3.0 data format.
This mixed mode enables you to gradually deploy SecureLogin 6.0 in a SecureLogin 3.0 environment while still allowing you to perform most administration tasks during the transition.
Deploying NSL 6.0 in a mixed environment has the following limitations:
- Limited administrative functionality - When you run SecureLogin 6.0 in mixed mode, new features such as shadow variables will not work. Also, some SecureLogin 6.0 settings and changing script descriptions aren't supported in mixed mode.
- Warning messages - To inform you that you are running in mixed mode, a warning message is displayed when data is saved in the SecureLogin 3.0 format.
Implementing NSL Administration Migration from ConsoleOne to iManager
With NSL 6.0, all eDirectory-related administration has been moved from ConsoleOne to iManager. But you won't have to do too much in terms of installation and configurations. To administer NSL on eDirectory using iManager, you just need to install the new 6.0 plug-ins that are part of the Novell SecureLogin 6.0 image or CD under the iManager folder.
For further information on how to install, configure and use iManager plug-ins, visit:
In this phase, training will be provided to the supporting staff of the migrating organization to meet their needs.
For further information on NSL support, please refer to the SecureLogin Support page. Go to http://support.novell.com and from there select SecureLogin under Support by Product.
Let's start with an example that shows how to handle the entire migration process step by step. For this example, we assume the following deployment exists:
- Server Directory: eDirectory 8.7.3 running on OES-SP1
- SecretStore: 3.3.3
- NSL Client version: NSL 3.51 SP3
- Client OS version: Windows-98 SE
- Client IE Version: 5.5
From the above deployment, suppose you want to migrate to the below mentioned deployment:
- Server Directory: eDirectory 8.8 running on OES-SP1
- SecretStore: 3.4
- NSL Client Version: NSL 6.0
- Client OS version: Windows XP
- Client IE Version: 5.5 or later
Figure 1: Migration of eDirectory Server and NSL client
The procedure that you need to follow is described below.
From the above assessment the following points are clear:
- On the server side we are migrating to the latest version of eDirectory 8.8 with subsequent version of SecretStore 3.4.
- On the client side we are migrating the OS from Windows-98 SE to Windows -XP as NSL 6.0 doesn't support Windows-98 SE anymore. After this we need to move to the newer version of NSL 6.0.
- Once we upgrade to Windows XP, there won't be any issues migrating from NSL 3.51 SP3 to NSL 6.0, as this platform is supported.
DesignIn this phase you need to decide on the following things:-
eDirectory Server side Migrations Path
On the eDirectory server side, the following things have to be taken care of:
- Back up your eDirectory 8.7.3 directory server to be able to restore back to a previous state, if something goes wrong during the directory upgrade.
- Ensure that the upgraded version has support from the NSL 6.0 side. This should be fine, as eDirectory 8.8 with SecretStore 3.4 is supported by NSL 6.0 client.
- Extend the schema to support the new Datastore 6.0. This tool adds new attributes that will not be recognized by older versions of NSL.
NSL Migration Path
On the NSL client side the following things have to be taken care of:
- The first foremost thing that we have to plan is the OS upgrade from Windows-98 SE to Windows-XP as NSL 6.0 doesn't support Windows-98 SE.
- Backing up of the user's NSL credentials is optional.
- Next thing is the up gradation of NSL from 3.51 SP3 to NSL 6.0 which is supported.
- On the browser side which has direct impact on Web-SSO, the existing IE 5.5 is supported but if you still want to upgrade then you can go ahead and do it.
NSL Administration migration path from Console One to iManagerThis is needed as from NSL 6.0 onwards the administration of the NSL-related tasks with eDirectory can only be done using iManager. For this purpose NSL 6.0 comes with a set of plug-ins for managing all the administrative tasks.
During this phase all the things that were planned and designed are implemented as a set of tasks as mentioned below:
- Back up the entire eDirectory 8.7.3.
- Upgrade eDirectory from eDirectory 8.7.3 to eDirectory 8.8.
- Upgrade the SecretStore from 3.3.3 to 3.4.
- Extend the Directory schema to support new datastore mode.
- If you want to move to new datastore, do it by changing it to 6.0 datastore mode using the SecureLogin iManager plug-in.
- Upgrade to Windows-XP from Windows- 98 SE.
- Upgrade the browser from 5.5 to later (optional).
- Back up user credentials (optional).
- Upgrade the NSL from 3.51 SP3 to 6.0.
NSL Administration migration path from Console One to iManager
As mentioned in the above sections, you just need to install and configure all the NSL related iManager plug-ins to be able to administer the eDirectory from iManager.
By following all the above mentioned steps, you will complete a successful migration to new 6.0 version of NSL.
From this systematic approach to migration, it's clear that NSL 6.0 can meet all your current day-to-day needs. In addition, NSL is a versatile product that is feature-rich in every sense and meets your daily needs effectively and efficiently. Now it's up to you to decide whether you want to have the best of the NSL features.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com