Is it possible to do a SecureLogin proof of concept without extending the Directory Schema?

Question

Is it possible to do a SecureLogin proof of concept without extending the Directory (e.g. ADS, eDirectory) Schema?

Answer

Whilst organizations using Novell Directories are much more relaxed about extending the directory schema to accommodate SecureLogin data, those who have implemented ADS are typically extremely cautious. We have engaged an independent 3rd party to produce an extensive document outlining the Schema extension process. This document is readily available from your territory sales manager.

There are a number of options for setting up a POC environment. The following options are typically suitable for most organizations.

Option 1, which extends the Directory schema, is the best mode to prove the concept and see the full power of SecureLogin, while Option 2 allows you to prove you can SSO to applications but doesn’t show the administration and full functionality of the product.

Directory mode is the best mode to demonstrate the real power of SecureLogin’s centralized management, administration and configuration, including encrypting and storing the secrets in the Directory and using MMC.

Option 1

Install SecureLogin on a test network incorporating the organizations desktop and server environment. The following are typical requirements;

• A test Windows 2000/2003 server running ADS.
• A standard workstation logging on to a test ADS server.
• SecureLogin installed on the workstation in ADS mode.
• Production applications installed and configured on the workstation.
• A logon to ADS with Administrative rights to extend the Schema, install SecureLogin on the workstation etc.
• A test logon to ADS with standard user rights so you can test SecureLogin as a standard user.
• Test logons for all production applications.
• A member of staff who knows about the application (e.g. password policy rules, passwords expiry) and the ability to request / reset application passwords as required.

The member of staff who knows about the application does not necessarily need to be with the SSO consultant at all times, but must be available to assist when required, such as to reset a password for an application so the password expiry message appears (instead of waiting for 30 days) and the application connector (formerly called scripts) written accordingly. To fully SSO enable an application SecureLogin must be configured to handle error conditions such as invalid logon credentials, password expiry, account locked etc. It is much easier having a contact to arrange this for each application.

Option 2

If you don’t have an operational test facility and the Directory experts at your organization are reluctant to extend the production schema, installing SecureLogin in Standalone mode on a production workstation provides a simple solution.

With SecureLogin installed in Standalone mode on a workstation connected to the production network, all applications are readily available on the workstation without having to configure a separate test environment, and you don’t have to extend the Directory Schema for the POC. The consultant doing the POC simply logs on to the production network with a test user account and logs on to SecureLogin.

In Standalone mode, changes are only made on the local workstation (and can easily be removed - they don’t affect the production network whatsoever). You won’t have all the functionality and won’t be able to see the full power of the product, but applications can still be fully SSO enabled and show you enough to prove the concept before deciding to extend the Schema for full functionality.

• A standard workstation logging on to the production network.
• SecureLogin installed on the workstation in Standalone mode.
• A test logon to the network.
• Test logons for all production applications.
• A member of staff who knows about the application (e.g. password policy rules, passwords expiry) and the ability to request / reset application passwords as required.

Although backups of SecureLogin data occurs automatically in Directory mode, if you do install SecureLogin in Standalone mode, make sure you backup all application scripts (using a Word document for example). If you don’t keep a copy of the scripts and the hard disk crashes, you will have lost everything because SecureLogin data is encrypted in the file system on the workstation’s local hard disk when in Standalone mode. You can change the default cache location to a network drive for mobility and backup if you prefer (see the Knowledgebase item on changing the default cache file location).