novell securelogin installation, deployment, lifecycle management and troubleshooting

Novell® SecureLoginInstallation, Deployment Life-Cycle Management and Troubleshooting

Don Swain, SecureLogin Product Lead, Global Technical [email protected]

Greg Morris, Technical Support Engineer [email protected]

Rajasekar PandiyanSoftware [email protected]

Planning the Installation

© Novell, Inc. All rights reserved.3


• The beauty of SecureLogin is that it can be configured so many different ways to do so many different things in so many environments.

• The challenge of SecureLogin is that it can be configured so many different ways to do so many different things in so many environments.



• So many installation options...

– For example:

> Novell® eDirectory™ mode

> AD mode

> LDAP mode

» GINA Mode

» Credential Manager Mode

» Application mode

• So many choices can be confusing



To plan your NSL installation, consider the following in sequence

• Determine where SecureLogin will store data

• Determine how SecureLogin will access stored data

• Prepare the destination directory for use with SecureLogin

• Prepare the workstation, add any NSL workstation prerequisites

• Install the SecureLogin client

• Configure directory settings

• Enable applications for Single Sign-On




• The DATA store (i.e. the directory)

– Options:

> Novell® eDirectory™

> Active Directory

> ADAM (Active Directory Application Mode)

> Other LDAP-compliant directory

– Typically the same directory to which users authenticate

> Not a requirement, just easier




• Determine how SecureLogin will access stored data

• How will NSL attach to the directory?

– Options:

> Novell Client™ (connecting to Novell® eDirectory™)

> LDAP (connecting to Novell eDirectory, Active Directory, or any LDAP v3-compliant directory)

> Microsoft Windows Client (connecting to Active Directory)



• LDAP Choices– GINA mode – (Replaces Windows GINA)

> “When logging into Windows” install option> Most features, manages Directory and Windows logins

– Credential Manager mode – (Uses Windows credentials)> “After successfully logging into Windows” install option> Seamless, transparent to users

– Application mode – (Launch manually, enter directory creds)> “When SecureLogin starts” install option> Best for Kiosk workstations

» Autoadmin logon to Windows, Login and and out of directory through SecureLogin

– Modify with Reg settings > see tid 3790292, Registry Settings for SecureLogin in LDAP mode



• Determine where SecureLogin will store data• Determine how SecureLogin will access stored data• Prepare the destination for use with SecureLogin

– Extend schema in the directory and assign rights to directory attributes

> Run appropriate tools from ...\SecureLogin\Tools\Schema\» AdamConfig.exe

» ADSchema.exe

» NDSSchema.exe

» LDAPSchema.exe

» Note: Both NDSSchema and LDAPSchema must be run in a Novell® eDirectory™ environment (LDAP schema mappings needed for iManager)



• Determine where SecureLogin will store data• Determine how SecureLogin will access stored data• Prepare the destination for use with SecureLogin • Prepare the workstation, add any prerequisites

– Consider how the SecureLogin client will access data> Novell Client™, LDAP MSClient

– Install any workstation prerequisites(the following all are optional)

> Java > Firefox > Novell Client, NMAS™, Novell SecretStore®

> Citrix program neighborhood



• Determine where SecureLogin will store data• Determine how SecureLogin will access stored data• Prepare the destination for use with SecureLogin • Prepare the workstation with any NSL workstation

prerequisites• Install the SecureLogin client

– Launch MSI from ...\SecureLogin\Client\x64\ or ...\x86– Choose install options as appropriate

> Data store> Novell Client™ vs LDAP> Citrix> etc



• Determine where SecureLogin will store data• Determine how SecureLogin will access stored data• Prepare the destination for use with SecureLogin • Prepare the workstation with any NSL workstation prerequisites• Install the SecureLogin client• Configure NSL settings using appropriate tool

– SLManager MMC iManager> Hide or password protect desktop icon (blue hand)

> Allow / disallow user to add applications

> Change cache refresh interval

> Change passphrase/ security settings

> Etc etc etc



• Determine where SecureLogin will store data• Determine how SecureLogin will access stored data• Prepare the destination for use with SecureLogin • Prepare the workstation with any NSL workstation prerequisites• Install the SecureLogin client• Configure NSL settings using appropriate tool• Script for applications

– Let the Wizard do its magic – Manually script as needed

> Scripting guide located at: http://www.novell.com/documentation/securelogin70/nsl70_application_definition_guide/?page=/documentation/securelogin70/nsl70_application_definition_guide/data/bookinfo.html

Deployment


Deploying SecureLogin

Schemaextension

iManager plug in

(eDirectory)

NMAS ServerMethod

(Optional)Server/ Directory

MMC Plug in(Active Directory)

InstallingNSL in single

workstation Adding new Applications

Distributing NSL data

to the containers

Optional registry values

Single ClickInstallation

Distributing custom

installation

Workstation



• Server- / Directory-Side Deployment – extend schema – <Installation Directory>\SecureLogin\Tools

> ADSSchema.exe> NSDSchema.exe> LDAPSchema.exe

– Install plugin, configure settings> iManager> MMC > NMAS™ Server methods> For example, configure passphrase questions



• Workstation Deployment

• Begin with one user on a single workstation

– Install manually

– Make sure all is as expected

– Configure applications using the Application Wizard

> Wizard demo – configure yahoo



• Copy applications to container

– Using “distribution” tab In iManager

> Demo – copy Yahoo script from user to container



• Automate for mass distribution– Response file

> How it is used

– Also single click NSL installationhttp://www.novell.com/communities/node/8987/single-click-customized-novell-securelogin-installation

– MSIExec switches and commands> Also shown in above> Links to On Line Docs

» http://www.novell.com/documentation/securelogin70/nsl70_installation_guide/?page=/documentation/securelogin70/nsl70_installation_guide/data/

– How to extract from an msi file» http://www.novell.com/support/php/search.do?

cmd=displayKC&docType=kc&externalId=tip-16584html&sliceId=&docTypeID=DT_ARTICLES_TIPS_1_1&dialogID=67012716&stateId=0%200%20124945726



• OPTIONAL Registry Entries change default behavior– Note: default behavior works about 99% of the time

• Complete list of reg entries available at http://www.novell.com/documentation/securelogin70/pdfdoc/nsl70_registry_settings/nsl70_registry_settings.pdf

• Commonly used entries from the list of reg settings– Tryregcredinoffline - Seamless login

– DisableCADUserSelection - LDAP GINA force AD and eDir pwd sync

– ForceHKLMandNoDPAPI - Roaming profile corruption

Lifecycle Management



• The MSI MSP model

– MSI for major releases and support packs

– MSP for Hot Fixes



• Hotfixes vs Support Packs– MSI vs MSP

• HotFixes– Bundled bug fixes – Some testing– Download from download.novell.com

• Support Packs – Bundled updates – bug fixes and some enhancements– Thorough testing– Download from customer care portal



• Schedule for patch releases

– Support packs approximately every 6 months

– Hot fixes generally every 6 – 8 weeks as needed

> Sometimes more frequently if needed

> Sometimes less frequently

» No hot fix releases while working on a support pack



• Installing a Support Pack

– Upgrade on top of existing installation

> Launch msi manually or from command line

– New install – no previous version required



• Installing a HotFix

– Adding patches to existing installation

> Requires the most recent full release

» Original release or SP

– Deploying hotfix and full release together

> Can be done in one msiexec operation, for example:

msiexec /i "C:\path\Client\Novell SecureLogin.msi" /qb PATHTOISS="C:\path\responsefile.ini" /update “C:\path\NSLFIXSP10911003.msp”



Gotchas:

• Combined one- step MSI / MSP installation requires NSL6.1sp1 or later MSI

• Administrative rights to the workstation required

– Use ZENworks® to install without administrative rights

> tid 10100347 - “Installing the NSL Client without local Administrative Rights”



• TEST with each update

– at least basic sanity check after patching

> Make sure single sign on to all applications still works

Troubleshooting


Troubleshooting SecureLoginSecureLogin Operational Overview

Novell® SecureLogin is a workstation-based application. It does not run on a server although management and distribution of SecureLogin information can be performed at the directory level. The SecureLogin client running on the workstation will communicate with the configured network infrastructure during initialization and then periodically during scheduled synchronization times.

So, based upon this design we could safely say that SecureLogin troubleshooting will fall into one of 3 categories

• Workstation

• Network

• Server

WorkstationNSL client

ServerData store



On the workstation itself, SecureLogin comprises both system- and user-based modules. The system modules are executed during login prior to the user actually having access to the local workstation. The module actually captures the users login credentials and then subsequently stores the information into the registry of the workstation. After completing this process the module then terminates.

After the user gains access to the local workstation, the SecureLogin client is launched as a user process. It will open the registry and read the information stored by the configured login module.

GINA login

Login module

NSL Client

Write Registry

Read Registry

Initialize



The SecureLogin client module slproto.exe provides the user interface. Slproto really does nothing by itself. It just waits for notifications from the module slbroker that work needs to be performed.

The module slbroker is the interface mechanism for all other SecureLogin modules to communicate with the SecureLogin client. Modules send notifications to slbroker when they detect that work needs to be performed.

There are many different interface modules that monitor specific Windows components. When they detect that an application or event has occurred they in turn notify slbroker. Slbroker will then notify slproto to take whatever action is necessary.

slbroker slproto

slwinsso

sljava

iesso



The SecureLogin interface modules monitor the many different types of applications that run on a Windows operating system. When the interface module detects that an application has been executed it sends a notification to slbroker. Slbroker then notifies slproto that work needs to done with this application.

Slproto will then parse the data store to determine if the application has been configured for SecureLogin interaction. If configured, slproto will execute the script and interact with the application via slbroker and the applicable interface module.

Additional modules communicate with slbroker to provide interface to the configured data store location.

slbroker slprotoslwinsso

Data store Local cache



Based upon the previous slides, we could break down the SecureLogin client into the following categories.

• Login modules

• SecureLogin client

• Slbroker

• Windows application interface modules

• Local cache file

• Data Store interface modules

• Scripting engine

See Appendix A and the online documentation for a more concise description of the SecureLogin processes in it's many different configurations.


Troubleshooting SecureLoginProblem Isolation

When troubleshooting SecureLogin we must determine where the issue is occurring. There are many different steps that can be used to help in this isolation process.

The first step in this isolation process is to eliminate as many of the components as possible. By simplifying the configuration we can narrow down the problem to one specific area.

For example, since we know that SecureLogin is a workstation-based application, we might first try to isolate the issue down to the workstation itself. We could try duplicating the issue without network interaction. This might include

• Setting SecureLogin to offline mode

• Enabling or disabling the local cache

• Trying different users

• Trying the same user on a different workstation

TroubleshootingInformation and Problem Gathering Steps


Troubleshooting SecureLogin

Information and problem gathering steps

• Validate configuration and version

• Document the exact error / problem

• Search for a solution

• Replicate the problem

• Consider debug options


Troubleshooting SecureLoginGathering Version and Installation Mode

The first step in the troubleshooting process should be to validate the version of the SecureLogin client that is installed on the workstation exhibiting the problem. See TID 7001335 - How to tell which version of SecureLogin is installed

Next we need to validate how the SecureLogin client was installed.

When the SecureLogin client is installed, we create a directory off of the root of the boot drive called nslfiles. The file nslinstalllog.txt will tell you what options where selected when the SecureLogin client was installed.

http://www.novell.com/support/php/search.do?cmd=displayKC&docType=kc&externalId=7001335&sliceId=1&docTypeID=DT_TID_1_1&dialogID=125433198&stateId=0%200%20125431234



In addition to the installation log you should also right click on the SecureLogin icon in the Windows systray and select the option “About”...



There is one additional piece of configuration information you should gather to confirm the installation settings and mode. The SecureLogin client will utilize a number of registry settings to customize operation in different environments. These registry keys are important to document. Open regedit and export the following registry key information.

Export the registry hive HKLM\Software\Protocom



In Novell® eDirectory™, LDAP, or any combination of these modes, exportHKLM/Software/Novell/Login


Troubleshooting SecureLoginDocumenting the Exact Error/Problem

Getting the problem description: Once we know how the client is installed and what version is being used, we now need to understand the problem the user is describing. Get a complete problem description including the exact steps the user is using to duplicate the problem. If an error code or message is being encountered then get the complete error code and any associated text that might be displayed with the error code. For example if the user was receiving a -426 error we would want the exact message that followed as well: “-426 BROKER_SYS_VARIABLE_NOT_AVAILABLE”.

New or existing problem: Next we need to ask the user if this is a new issue or an existing one. If this is an existing implementation, then what changed in the users environment just prior to the problem being seen. Changes could be (service packs, hotfixes, hardware changes, hardware updates, facility changes, etc...)

How often does the issue occur: You need to determine how often the issue is encountered by the user. The more often an issue is seen by the user the more likely you will be in replicating and isolating the problem. If the issue is very random and occurs infrequently then it might be easier to turn on debug logging and wait for the issue to reoccur.


Troubleshooting SecureLoginDocumenting the Exact Error/Problem

User actions: What actions has the user taken in his efforts to resolve or recover from the problem. This is important because the user might have made things worse during his attempts to fix the issue. Also, this troubleshooting information could be valuable in our problem analysis and isolation process.

The real problem: Another important aspect of this step is to ensure we are working on the correct issue. When errors occur, many times multiple errors can be observed. Only the first error is really applicable. The subsequent errors or behaviors are generally the result of the condition that existed due to the first error. By fully investigating the problem description you should be able to determine if the error being reported is the issue or just a subsequent message that was displayed due to some other previous error condition.

Already fixed: If the user is not running with the latest patch level for the version of the installed SecureLogin client, then please test on one workstation with the latest updates applied. Many issues are resolved in each patch release and a differently reported symptom might result in the same fix. So just because the symptom the user is reporting isn't explicitly stated, this doesn't mean that the patch would not resolve the issue.


Troubleshooting SecureLoginSearching for a Solution

Using the users defined problem description start researching by searching the Novell knowledgebase, Google, etc... for any documents that might help to identify if the problem has already been seen and/or suggestions on correcting the issue.

This is also the time for you to analyze and actually think about the users issue, formulate ideas as to what type of conditions might cause the product to behave in this manner. It really isn't important in the problem isolation to know why the issue is occurring but what factors are required to make it break. If the reported issue is an actual product defect then the likelihood of getting a quick solution solely lies in the ability to easily replicate the issue.

This is also a very good step to ensure that you completely understand the users communications. End users many times do not understand or know the correct terminology to properly describe the problem being seen. It is very important to discuss the issue fully with the end user to help completely understand the issue.


Troubleshooting SecureLoginSearching for a Solution

It is also important to understand how SecureLogin will report errors back to the end user. Internal SecureLogin client errors are in the range of 100 through 430. Other errors displayed that do not fall inside this range have originated from an underlying service. For example, if SecureLogin is configured for LDAP authentication, if the user enters the wrong LDAP credentials then an LDAP error message would be displayed to the user (not an NSL client error). For this reason it is imperative that you understand the error being reported and how to locate information for that specific error code. Other types of errors that can be seen could include.• LDAP error codes single digit error codes (0 through 255) • Novell Error codes

– NMAS (-16xx)

– SecureLogin client (-1xx through -4xx)

– eDirectory (-6xx)

– NICI (-14xx)

– Secret Store (-8xx)

• Microsoft Error codes (Many different types and formats)

http://support.microsoft.com/kb/218185

http://www.novell.com/documentation/nwec/nwec/data/al29t28.html

http://www.novell.com/documentation/nwec/nwec/data/al3r5be.html

http://www.novell.com/documentation/nwec/nwec/data/akx0p3p.html

http://www.novell.com/documentation/nwec/nwec/data/alwxsrr.html

http://www.novell.com/documentation/nwec/nwec/data/al2oa6u.html

http://www.novell.com/documentation/nwec/nwec/data/al4uac0.html

http://www.microsoft.com/technet/support/ee/ee_advanced.aspx


Troubleshooting SecureLoginProblem Replication

Before you can resolve the issue you must be able to replicate the problem. Without problem replication there is no mechanism to validate if the fix actually resolves the issue or not. Also it is important to understand that if the issue being encountered by the user is a product defect, then Novell® engineering will not be able to come to a quick resolution to the issue unless the issue can be replicated and the fix can be validated.

Attempt the duplication with the same versions of software and user configuration. For example if the user is running in Novell eDirectory™ with LDAP mode we wouldn't want to attempt the duplication in Novell eDirectory Novell Client™ mode.

Based upon the duplication results you should take different actions. It is very important to write down each step you take in your duplication effort. Documenting each step in as much detail as possible will help regardless of whether the issue is a product defect or not.



If the duplication is successful. (Meaning that you can replicate what the user is seeing)• Analyze the duplication steps to see if you can identify any missing

steps, settings, and/or configuration items. See Appendix A for details.

• Try the same duplication with the latest version of the software. Novell® SecureLogin updates are released periodically (about every other month). These updates contain fixes for customer reported issues so there is a strong possibility that the latest update could potentially resolve the issue.

• Eliminate SecureLogin by disabling or removing from the workstation. Then retest to see if the issue still occurs. If the problem occurs when SecureLogin is not active then SecureLogin is most likely not at fault.



If the duplication is not successful.

• Walk through your duplication steps with the user. Find out if they are doing the exact same steps when they are encountering the issue.

• Try the duplication again on the users computer, if the condition still exists, then try isolating the issue down to the user or the computer. See Appendix A for details.

If after performing the steps above the issue is still occurring then you might consider opening a new service request with Novell Technical Support.


Troubleshooting SecureLoginSecureLogin Debugging Options

SecureLogin has the ability to generate a debug log to help in the isolation of issues. Please note that in some cases we may need to acquire a debug log but in other cases we may not. This is all dependent on the actual problem being reported. Do not get debug logs unless the log will be beneficial in the troubleshooting process or requested by NTS. Most generally issues can be resolved without the use of logs.

TID 7001124 documents how to acquire a debug log by setting the correct registry keys on the workstation.

It is not necessary to edit the registry manually. Instead it is recommended that the appropriate SecureLogin tool be utilized for the purpose of enabling debug logging.

There are currently two tools that allow for the enabling of debug logging.

• slloggingmanager

• nsllogmanager

Note that debug logs are not very informative to a non-developer. So trying to analyze debug logs should be one of the last steps in the troubleshooting process.




Novell® SecureLogin client debug logging manager (slloggingmanager)

This utility provides the ability to enable debug logging in one or more of the SecureLogin client modules.

To enable logging for a specific module, change the Logging Level to the desired value. Most generally you would want to set the logging level to the value of "Debug" to log all debug messages, errors, warnings, etc.



The following describes what each of the debug options log information for• Active Directory datastore (madman) – AD environments• Advanced Windows Scripting (aws) – Windows Script• Credential Manager (slcredman) – AD environments• Internet Explorer (iesso) – Internet Explorer interface in NSL 6 and higher• Internet Explorer – Old (websso) – Internet Explorer interface in NSL 3.51 and

lower• Internet Explorer Java (javassobho) – Java BHO for NSL 6 and higher• Java (javasso) – Java application module for NSL 6 and higher• Lotus Notes – Pronotes.dll (lotussso) – Older interface for Notes in NSL 3.51• Netscape (netscapesso) – Old Netscape interface. Enable debugging in Mozilla• Script Parser (parser) – Checks the script syntax on all applications prior to

execution.• Novell SecretStore® datastore (ssman) – Novell SecretStore environments



• SLBroker.dll (brokerint) – Broker functions• SLBroker.exe (broker) – Broker interaction with other modules• Terminal Launcher (tlaunch) – Mainframe / Midrange interface• Terminal Launcher – DDE interfaces (launcher) – Debug DDE communications with

a DDE emulator• Windows (winsso) – Windows applications• Windows Library Functions (winlib) – Internal Microsoft functions (ie. 3DES)• Wizard – Windows (wizard) – Wizard for Windows applications

These are all of the current debug options provided by SecureLogin engineering. These options only apply to the SecureLogin client. For debugging NMAS™, Novell SecretStore®, Novell Client™, Microsoft client, etc. then please consult the online support knowledgebase or vendors documentation.

It is possible to enable debug logging for all of the SecureLogin client modules, but this causes a very large debug log. It is better to just enable those options that pertain to the issue being investigated. Also, when debug logging is enabled, performance will decrease.



Debug logs will be located in the user profile directory (as is the SecureLogin cache file).



SecureLogin Log manager for LDAP, pcprox, and secure workstation components

This tool ships on the NSL CD. The tool can be found in the following path.<CD>\SecureLogin\Tools\Unsupported\NSLLogManager.exe

This tool allows for the debugging of the LDAP GINA nldapaut.dll, the PCProx NMAS™ methods, and the Secure Workstation NMAS methods.



After setting the desired debug options then close the log manager and restart the workstation and/or logout and log back in. The reason why you must restart is because the LDAP GINA and the NMAS™ methods are invoked outside of the NSL client, so just a restart of the SecureLogin client is not enough. For example, the LDAP GINA is only called when doing a login so to debug the LDAP GINA you must logout and log back in so that the LDAP GINA would be invoked.

TroubleshootingProblem Scenarios


Troubleshooting SecureLoginProblem Scenarios

Error “You are not logged into the directory and SecureLogin was unable to find any cached user data”

Steps to replicate issue:

1. Newly created user2. Fresh installation of SecureLogin on workstation in Novell Client™ mode3. On bootup user logs into the network and gets an active desktop, when the SecureLogin client attempts to load it displays this error message.

The first step in isolating this issue is to eliminate the new user. On another workstation where SecureLogin is working correctly we could attempt to login as this new user. If this fails then we know that we have an issue with the user. We could then look at the datastore to see what conditions exist that could be causing the user access to the SecureLogin attributes to fail.

Possible solutions might be...• User rights not setup correctly because user was created with a management tool not running

the SecureLogin plugin.

• Server unable to satisfy the Novell client's request for specific SecureLogin information.

• Communications failures





1. Newly created user2. Fresh installation of SecureLogin on workstation in Novell Client™ mode3. On bootup user logs into the network and gets an active desktop, when the SecureLogin client attempts to load it displays this error message.4. User can login on another workstation and launch SecureLogin successfully

Since the user can login to a different workstation then we could assume that the issue is isolated to the workstation. But to be certain we should test this by attempting to login and launch SecureLogin with a user that is currently using SecureLogin successfully on another workstation. If another user is successful then we need to analyze the initialization process of the SecureLogin client.

Possible solutions might be...• Unable to acquire user identity from the network login

• User has limited or no rights to profile or program paths





1. Newly created user2. Fresh installation of SecureLogin on workstation in Novell Client™ mode3. On bootup user logs into the network and gets an active desktop, when the SecureLogin client attempts to load it displays this error message.4. User can login on another workstation and launch SecureLogin successfully5. Working user also fails on this workstation

Step 5 isolates this issue to the workstation itself. This indicates that there is either something wrong in the configuration, installation, or communications.

Possible solutions might be...• Unable to acquire user identity from the network login

• User has limited or no rights to profile or program paths

• SecureLogin was not installed by an administrative account

• SecureLogin installed in the wrong mode

• Can't contact/communicate with server



iManager SecureLogin plugin not working


1. Open iManager2. There are no options for SecureLogin

The first step in this analysis is to quickly ensure that the SecureLogin LDAP mappings have been performed. Even though SecureLogin installed in Novell Client™ mode does not use LDAP communications, iManager does. So it is important that the LDAP schema tool is ran on all Novell® eDirectory™ installations.

Possible solutions might be...• LDAP mappings not present – run ldapschema.exe

• NSL plugin not installed in iManager – install plugin

• NSL eDirectory schema not applied – run ndschema.exe

• Schema synchronization / Novell eDirectory problems



During login user is prompted for their passphrase answer


1. Login to workstation2. When SecureLogin loads it prompts the user for their passphrase answer

This is normal if an administrative password change had occurred. For example, the user had locked their account for one reason or another. They called the help desk and they reset the users password and account. When SecureLogin loads it detects that an administrative password change had occurred. At this point we must validate that the user attempting to load SecureLogin is actually the user and not the admin. SecureLogin prompts for the passphrase answer since only the real user should know the answer.

Possible solutions might be...• Enter the passphrase answer. On the next load SecureLogin should no longer prompt.

• If an administrative password change did not occur then perhaps the login modules were unable to determine/capture the user credentials. Try validating the process.

• If a user password change occurred then how was this implemented? Did they initiate the change by pressing <Alt><Ctl><Del> or some other process?



SecureLogin client crashes


1. Login to workstation2. When SecureLogin attempts to load it crashes

This should be a very rare occurrence but if a crash of the client is encountered then most likely the source of the issue would be due to some interaction with another application running on the system. It would be recommended that a user dump of the slproto (or whatever process is actually crashing) be acquired.

Possible solutions might be...• Apply latest updates to SecureLogin client.

• Try installing on a clean workstation with only the OS and SecureLogin installed. If the problem no longer occurs then start adding back all the other normal applications to determine when the problem starts. At that point we could investigate why SecureLogin is having an issue with a specific application or service.

• Try a different user, rename the current users cache, etc... It is possible that the SecureLogin clients cache has some type of corruption that is causing the issue. Even corruption at the data store could potentially cause this type of condition.



SecureLogin doesn't detect or fails to interact with a specific Windows application


1. Login to workstation2. SecureLogin loads OK3. When launching application X, NSL does not perform single sign-on

These types of issues can be a poorly written script, NSL client settings, application doesn't utilize the normal WM_CREATE event, etc.

Possible solutions might be...• First eliminate any existing script. It is important to understand that an application definition

without a script will cause SecureLogin to ignore the application.

• Do other Windows applications work? If so then the SecureLogin client settings shouldn't be a factor.

• It is possible that the application is using different Windows events instead of WM_CREATE. Some applications generate windows and then just hide them from the users view. When the user needs to access the window then the application makes the window visible. The Novell iFolder client acts in this manner.



SecureLogin doesn't detect or fails to interact with a specific web application


1. Login to workstation2. SecureLogin loads OK3. When launching browser for URL X, NSL does not perform single signon

These types of issues can be a poorly written script, SecureLogin client settings, BHO not installed, browser settings, etc.

Possible solutions might be...• First eliminate any existing script. It is important to understand that an application definition

without a script will cause SecureLogin to ignore the application.

• Do other web applications work? If so then the SecureLogin client settings shouldn't be a factor.

• Is the Browser Helper Object (BHO) installed and enabled?

• Check the browser settings. For example in IE you must have the setting “Enable third party browser extensions” enabled.

• Eliminate any browser application script. For example iexplore.exe script. This is a windows script since the IE browser itself is a Windows application.



Roaming or mandatory profiles no longer work after installing SecureLogin


1. Login to workstation2. SecureLogin loads OK3. User works for a period of time, then shuts down their workstation4. On the next logon the profile is corrupt

This issue is caused by the Microsoft encryption libraries being used by SecureLogin. The calls being made to the libraries cause the registry of the workstation to remain open. When shutting down the OS is unable to copy the registry back to the network profile.

Possible solutions might be...• [HKEY_LOCAL_MACHINE\SOFTWARE\Protocom\SecureLogin]

"ForceHKLMAndNoDPAPI"=dword:00000001

• Description - This registry key instructs SecureLogin to not use the Microsoft encryption API's and to use the built-in encryption libraries.

• Note that this registry key also causes the SecureLogin volatile information (user credentials) to be stored in HKLM instead of HKCU.

Appendix ASecureLogin Processes


Troubleshooting SecureLogin

The following slides document how SecureLogin works in its many different configurations.We can logically separate the environment into the following categories

1. SecureLogin and the Windows operating system2. SecureLogin and the Network3. SecureLogin and the data store

Appendix A.1 SecureLogin and the

Windows Operating System


Troubleshooting SecureLoginSecureLogin and the Windows Operating System

• How is SecureLogin launched on Windows• SecureLogin Login modules• SecureLogin client modules and initialization• How SecureLogin detects Windows applications • How SecureLogin detects web applications • How SecureLogin detects Java applications • How SecureLogin interacts with terminal emulators• How SecureLogin interacts with Citrix and terminal servers• Seamless login• Password expiration• Password changes and synchronization



How the SecureLogin client is launched by the operating systemWhen Novell® SecureLogin is configured to be launched when Windows starts, the Windows registry Run key is modified to launch the SecureLogin client. The operating system processes the entries in the run key immediately following the user seeing an active desktop and prior to running any applications defined in the start/programs/startup folder.



It is important to understand that there are several different modules that run at specific times to provide functionality needed by the SecureLogin client.

System login modulesThese modules run as the local system account to acquire information (users login credentials) needed by the SecureLogin client during its initialization process. These modules run prior to the launching of the SecureLogin client.

SecureLogin clientThe SecureLogin client runs as the local user account and is limited to the rights and resources that are assigned to the local user. The client (slproto.exe) doesn't load until after the user has performed a login to the network and has authenticated to the local workstation. The client depends on other modules to actually interact with configured data stores, applications, and the local cache file. For example ssman.dll is the module that interfaces with the Secret Store client. These additional runtime modules are automatically loaded by the SecureLogin client during it's initialization process.



Login processes run with system account access

The SecureLogin client runs as the local user



Acquiring user credentials

The process of acquiring the users credentials from the initial login of the workstation is the responsibility of the login process. Each process differs depending on the mode in which the SecureLogin client was installed.

➢ Novell® eDirectory™ with the Novell Client™ for Windows➢ LDAP➢ AD


Troubleshooting SecureLoginSecureLogin and the Windows operating system

Acquiring the user credentials in Novell® eDirectory™ with the Novell Client™ modeThe Novell client for Windows provides an interface to allow additional network services and/or resources to participate in the login process. This mechanism is termed a Novell Client login extension.

So what is a Novell Client login extension? This is a module that provides or extends the login functionality of the Novell Client for Windows. By default the Novell Client for Windows implements several different login extensions to provide LDAP contextless/treeless login, NMAS™ authentication, and the remote update service. When the Novell client for Windows successfully logs into Novell eDirectory, it will immediately call the registered login extensions and pass a credential structure (which includes the tree, context, username, password, etc) for processing. The login extension then takes this information and performs it's required tasks against Novell eDirectory.

The Novell SecureLogin installation will install a login extension to the Novell client when installing in Novell eDirectory Novell Client mode. The login extension is called slinac.dll.



SecureLogin Novell Client™ login extensionNote that the login extension description indicates that this module is for SecureLogin Terminal service. But this module is used anytime the client is installed in Novell® eDirectory™ Novell Client™ mode.



When slinac.dll is registered with the Novell Client™ as a login extension, we are passed the users credential structure during the login process. The login extension takes the provided credentials, encrypts the information, and then stores the data to the users hive (HKCU) in the registry. Also see reg key ForceHKLMandNoDPAPI.

After storing the passed credential information to the registry the module slinac.dll terminates.

Now when the SecureLogin client (slproto.exe) loads it reads the credential values from the users hive in the registry, validates that the user has a connection to the configured data store, then it performs its normal initialization process.



Acquiring the user credentials in LDAP modeSecureLogin supports three different LDAP modes. These modes are selected during the installation of NSL to the workstation.➢ LDAP GINA mode➢ LDAP credential manager mode➢ LDAP application mode

In any of the supported LDAP modes there are different configurations that effect how the credentials are obtained.


Troubleshooting SecureLoginSecureLogin and the Windows operating system

LDAP GINA modeIn GINA mode, we register with the operating system as the primary GINA. Notice that the GINA registered by SecureLogin has the same name as the GINA installed by the Novell client for Windows. The Securelogin client implements a modified version of the Novel Client™ for Windows' GINA module. This module will in turn call nldapaut.dll to perform the LDAP login.



LDAP Credential Manager modeIn credential manager mode, the client just registers the Novell® LDAP Auth Client as a credential manager with the operating system. Credential managers are called during the network initialization process of the workstation. They are passed credentials by the operating system during login. In this configuration, nldapaut.dll will utilize slnmas.dll for the credential manager functionality.



LDAP Application modeIn application mode there is no attempt made to acquire the users credentials during the bootup process. When the SecureLogin client loads it will prompt the user for their credentials.

It might be possible to have SecureLogin startup using cached information by setting the registry key ShowPassCacheOption.

See Novell® Cool solution “A Shortcut into SecureLogin in Standalone Mode” for more details. Also note that this registry key is defined within HKCU and not HKLM.

http://www.novell.com/support/php/search.do?cmd=displayKC&docType=kc&externalId=trench-8861html&sliceId=&docTypeID=DT_ARTICLES_TIPS_1_1&dialogID=67152628&stateId=0%200%20125389824



Acquiring user credentials in AD modeAD mode is implemented in a similar manner as LDAP credential manager mode. But a different module is utilized as the credential manager registered with the operating system. The module slcredman is the credential manager module for AD environments.

You can see the credential manager listed under the network provider order of the network advanced settings window.



Validating the NSL user credentialsSo how would we validate that SecureLogin successfully captured the user login credentials?

Based on the information seen in the previous slides we could conclude that a simple check of the registry would either confirm or deny if the process was successful. But it should be noted that once the SecureLogin client loads, it consumes the information from the registry. What is meant by consumes is that the SecureLogin client will read and then delete the entries. So trying to validate the user login credentials after the SecureLogin client has loaded will not exhibit the desired information.

First use msconfig and disable slproto from loading at startup. Then logout of the workstation and log back in to have the login modules repopulate the registry.



Symptoms encountered if SecureLogin is unable to acquire the users credentialsIf the login module is unable to acquire the users login credentials then the user will experience one or more of the following symptoms.➢ User prompted by SecureLogin during load time for their login credentials. When

the SecureLogin client loads and initializes, it must validate the users identity as well as the users access to the configured data store. If we were unable to obtain the users credentials during login, then the SecureLogin client will fail to validate the user. When the client encounters this condition it assumes that the failure was due to wrong user credentials. It then prompts the user to re-enter their credentials.

➢ -426 errors when running any script that has system variables defined. Once the NSL client has access to the data store, it generates/defines in memory a number of system runtime variables. These variables reflect information from the directory, like your context, tree, etc... The user credentials are also stored in system variables but are populated with the information acquired by the login process. Typically this error is displayed when one or more application scripts contain the SecureLogin ?sysuser or ?syspassword definitions. If the login module was unable to acquire the user credentials then the ?sysuser and ?syspassword variables are empty.



SecureLogin Client Initialization ProcessWhen the SecureLogin client (slproto.exe) initializes it performs several different activities.

1. Load required modules (required client support modules)

· slbroker - This module provides the interface to all of the other modules

· slnrmonitorserver - If remote access is enabled then this service is loaded

· slwinsso - Provides single signon to Windows executables. This module monitors the windows system event messages.



In addition to the standard modules used by the SecureLogin client a number of DLL's are loaded to provide access to the configured data store or to add support for additional features. ➢ ssman - Enables interaction with the Secret Store client running on the workstation ➢ madman - Enables interaction with an AD data store

Note that the modules listed above are not all the modules used by the SecureLogin client. For example slwinsso loads winsso.dll which contains one or more functions necessary for slwinsso to work properly.

Each module will then communicate with slbroker when they encounter an event that needs to be acted upon by the NSL client.

slbroker slproto

slwinsso

sljava

iesso



Validating step 1 of the initialization processThe simplest method of validating this step is to open the Windows task manager and ensuring that the following services are running.➢ slproto.exe➢ slbroker.exe➢ slwinsso.exe



2. Examine the current runtime environmentDuring initialization the SecureLogin client will attempt to identify the currently installed Java components. It parses the Java registry key to determine the version and installation path of the installed JRE. Note that in older versions this feature was not available and if you installed NSL with one JRE version and then later upgraded to a newer version of the JRE then NSL would fail to locate the JRE when attempting to interact with Java websites and applications.

This same check also applies to the Oracle JAVA client (jinitiator)



Validating step 2 of the initialization processThe simplest method of validating this step is to check the registry for the JRE or jinitiator path. SecureLogin will update the registry key on each load with the path of the JAVA modules found. If multiple versions are found then the key will contain each path separated by a comma.



3. Check user connectionOnce all the required modules have been loaded the SecureLogin client now validates the users connection to the configured data store. It takes the users local credentials (that it received from the appropriate login module or the registry) and attempts to connect to the configured data store. This process is necessary for several reasons.➢ Validates the users identity➢ Provides access to passphrase answer for decryption of local cache data

We utilize different mechanisms depending on the configured data store.

Novell® eDirectory™ - In Novell eDirectory we make a call to the Xplat libraries (Novell Client™ libraries) to acquire our login status. The Novell Client performs the work of validating the users connection and returns the information back to SecureLogin.

LDAP - We take the provided credentials and attempt to perform an LDAP bind to the server. If this is successful then we process the users data store.

AD – The SecureLogin client will query the local OS and it provides us with the information. Similar to the process used in Novell eDirectory environments.



Validating step 3 of the initialization processTo verify if the SecureLogin client was able to connect to the configured datastore is most easily done by right clicking on the SecureLogin client icon in the systray and then select the menu option “About”.



4. Accessing the local resources (cache file)Once we have validated the users connection and we have access to the configured data store, we can now start processing our cache. The local cache will be used in all configurations. We cache the users complete data set from the data store so that we do not have to query the network every time we detect a new login.

Because the cache is located in the user profile directory then the user should have adequate file system/user rights by default. If access to the cache seems to be failing then validate the local user rights to the users profile directory path.

Typical profile path example:

C:\Documents and Settings\Administrator\Application Data\SecureLogin\Cache



5. Open the cacheUpon boot up the client must first open the cache. The cache is encrypted by the SecureLogin client with the users' passphrase answer. Note that this is still true even if the passphrase system is disabled. In the case of the passphrase system being disabled, the client will utilize the GUID of the users' directory object as it's seed for the encryption process.

It is important to understand that the users' directory password can also be used to access the cache. The reason for this is that the password is used to access the stored and encrypted security values in the directory which ultimately contains the passphrase answer. Once we acquire the passphrase information then the process of decrypting the cache is the same. Note in most cases SecureLogin already has the users' name and password, so it should be able to determine the passphrase answer, but if you are not connected to the network then there is a mechanism called seamless login that can be configured so that the user is not prompted to enter the passphrase answer.



Validating step 4/5 of the initialization processIf it is uncertain if the cache file is being located, you can simply rename the cache file and restart the SecureLogin client. This should recreate the cache file with the contents from the datastore. This action would validate steps 4-6.



6. Synchronize the cacheOnce the cache has been successfully opened, SecureLogin will start processing the entries found. The SecureLogin client in version 6 and higher utilizes a checksum value to monitor any changes to the currently defined data. Each credential set, application, etc. will have it's own checksum value. The SecureLogin client will read each entry in the cache, generate a checksum and then read the checksum value stored in the data store. If the checksum value matches then the client moves on to the next value. If the checksum does not match then the client will refresh that entry.

The SecureLogin client only performs the checksum validation if the database mode (set in the data store) is set to version 6 or higher. If this setting is off then all entries will be read from the store regardless if they have changed or not.



Validating step 6 of the initialization processOne additional way of validating that the cache is being opened and updated with credential data from the datastore is to update the users credential in the datastore, then login with the SecureLogin client and check the modification date of the cache file.



7. Enable support for defined applications and settingsOnce the cache has been validated and updated with the latest information, the client moves on to the next step of activating SSO processing for the configured applications. For example if Java is enabled, then the SecureLogin client will load the appropriate Java modules for interaction with Java programs and websites.

The client also reads and applies the SecureLogin settings as defined in the cache or data store. As each setting is read SecureLogin loads or initializes the necessary components to implement the environment as specified by that setting. For example, perhaps the system administrator desires to not allow users to access the SecureLogin icon running in the systray. Once the value has been read and processed the SecureLogin client would no longer place a visable icon in the systray for the user to access.

It should be noted here that some settings are only available within the configured data store. It is required that a management tool like iManager, MMC, or slmanager be used to access all available settings.



Validating step 7 of the initialization process

This step is easily validated by modifying one of the SecureLogin client settings in the directory for a test user. Then login as that user and see if the setting is passed down to the client. For example you could try password protecting the SecureLogin icon running in the systray.

It is important to understand that making a change at the directory isn't reflected immediately at the client. SecureLogin uses a setting called “refresh interval” which defines how often the SecureLogin client will attempt to synchronize with the configured datastore.

So, after making a change in the directory you must initiate a synchronization. SecureLogin can be forced to resync with the directory by performing one of the following actions.➢ Right click the SecureLogin icon in the systray and select “Advanced / Refresh cache”➢ Double click the SecureLogin icon in the systray➢ Stop and restart slproto. This can be done several different ways but it is not

recommended to kill slproto from the Windows task manager. “Start/Run/slproto /shutdown” will force NSL to shutdown. Then just relaunch slproto.

➢ Logout and log back in to the workstation



8. Check current running modules for SSO interactionThe next step in the initialization sequence is to process all the currently running applications and check to see if we are configured to interact with any. In older versions of SecureLogin it was very important to ensure that the SecureLogin client was loaded before launching any application that you wanted to provide SSO interaction with. So programs from the Windows startup folder would be deleted and SecureLogin startup scripts would be defined to launch and interact with the desired application. Later consulting services developed a tool called DetectExisting which was an application you could run from a startup script to force the SecureLogin client to parse all the running applications to determine if it should interact or not. Starting in SecureLogin 6, the functionality of DetectExisting is now included as part of the SecureLogin client.

The SecureLogin client now has access to the data store, the cache, and will interact with any currently running applications. This should complete the initialization process of the SecureLogin client. It should now just go idle until notified by one of the running support modules that an application has been launched or needs interaction with.



Validating step 8 of the initialization processThe only real mechanism of determining if all the necessary modules were loaded and initialized is to test the clients ability to perform single signon. If you already have a SecureLogin environment in place then simply going through all the different application types will validate if SecureLogin is running and able to interact with each type.

As mentioned previously SecureLogin loads many different modules that communicate via slbroker to slproto. Typically an error message similar to “Unable to instantiate script broker” will be displayed if the client attempts to interact with a specific application type but one or more the required modules has crashed or isn't loaded.

There are a number of TID's that walk you through the use of regsvr32 to manually register the SecureLogin modules.

Also since this is the last step in the initialization process it would be recommended to check the about box to ensure that SecureLogin is online.



How SecureLogin detects Windows applicationsNovell SecureLogin monitors the Windows system event messages for running applications. If the running application is defined and enabled within the users configuration, SecureLogin will execute the script commands for the application window definition.

The WM_CREATE system message is the default Windows event message monitored by SecureLogin to detect newly created application dialogs. But by using the event script command, you can instruct SecureLogin to act upon a specific application when a different Windows message is encountered.

In theory SecureLogin should be able to handle any defined Windows system event message. Included in the older 3.51 product documentation there is a listing of the event specifiers tested with that product version. The listing of supported Windows system events are no longer included in the online documentation for SecureLogin 6.1 or higher. These are Windows system events and are managed and maintained by Microsoft. For a complete listing of all Windows system events see the Microsoft online documentation at:

http://msdn.microsoft.com/en-us/library/ms674887(VS.85).aspx

http://msdn.microsoft.com/en-us/library/ms674887(VS.85).aspx



How SecureLogin detects web pagesThe SecureLogin module IESSO (for Internet Explorer) or slomoz (Firefox) will monitor the running browser application. When a URL is entered into the browser location bar and a website is displayed, the SecureLogin client will scan the defined list of web applications to determine if that specific URL or domain is currently defined.

If found then the SecureLogin client will interact with either IESSO or slomoz to read/write to the browser window.



How SecureLogin detects JAVA applicationsJava scripting is new to the 6.x version of the SecureLogin client. Prior to version 6.x Java based applications were treated as Windows applications. Java websites were treated as purely a web site.

To utilize Java applications the SUN Java Runtime Environment (JRE) must be present on the workstation prior to the installation of the SecureLogin client. SLJava will monitor the system for JAVA based applications and websites. When the SecureLogin client detects a Java based application or website, it will then utilize the JRE to analyze the Java code and identify the defined Java components.

When Java applications and websites are detected we prompt the user to create a script definition for the identified Java application. But it should be noted that in version 6.x the script just defines the components found, it does not actually script for anything. With SecureLogin 7 the new JAVA wizard will define a proper script. For complex JAVA applications (IE Oracle Forms) then NSL 7 SP1 should be considered when available.



How SecureLogin interacts with terminal emulatorsA terminal emulator is a program that allows a personal computer to emulate a mainframe (3270) or mid-range (5250) system terminal.

SecureLogin utilizes a standalone executable called tlaunch.exe to provide the interface between the emulator program and the SecureLogin client.



How SecureLogin interacts with Citrix and terminal serversThere are several different components used depending on the installed configuration of the SecureLogin client. See Novell TID 3149664 for details.




Seamless LoginSeamless login is the term we use for the configuration of the SecureLogin client to startup automatically in disconnected mode. Meaning that when the workstation is booted in offline mode (network is unavailable), the SecureLogin client doesn't prompt the user for any information but instead automatically opens the cache and starts in offline mode. Once a network connection is established to the directory that houses the configured data store, then the SecureLogin client will automatically switch to online mode. The difficulty in starting up automatically in offline mode is the ability to validate the users identity and subsequently opening the local cache file. For this solution to work there are a couple of requirements.➢ The Novell® eDirectory™ user and the NT user (local or domain) must have the same

credentials. Meaning that they must have the same user name and password. ➢ Novell SecureLogin installed in Novell eDirectory LDAP Credential manager,

Novell eDirectory Client32, or AD mode. ➢ If installed in Novell eDirectory Client32 mode, you must ensure that the 4.91 SP5

client is used. If using the 4.91 SP4 client then ensure that the post SP4 client login update is applied. For example "post login updates for 4.91 SP4 client"



Seamless Login – Registry keysModify the registry and add the registry key.HKLM/software/novell/login/ldapDoNTAssoc REG_DWORD 1

Modfiy the registry and ensure that the following is either set to 0 or not present in the registry.HKLM/software/novell/login/ldapDoClient32Assoc REG_DWORD 0

Modify the registry and add the following registry key if not present.HKLM/software/Protocom/SecureLoginTryRegCredInOffline REG_DWORD 1

Note: The registry key TryRegCredInOffline was incorrectly spelled as TryRegCerdInOffline in the SecureLogin 6.1 initial release. When a later Hotfix is installed, it should create the key with the correct name. The misspelled key will remain in the registry but should not cause any problems.



Seamless Login - SecureLogin in eDirectory LDAP credential manager mode without the Novell Client™

➢ During bootup the user initially sees the Microsoft GINA (MSGina). They login to either the local workstation account or the locally cached domain account.

➢ SecureLogin's registered credential manager (nldapaut -> slnmas) receives the user credentials passed by the operating system during the login process.

➢ Slnmas takes the NT provided credentials and then encrypts and stores the credential data to the registry.

➢ When slproto (the NSL client) loads it first reads the value of the registry key TryRegCredInOffline. If this registry key is set to a value of 1, the SecureLogin client will attempt to startup in offline mode without prompting the user.

➢ The client now reads the stored credential structure from the registry and then deletes the items. (consumes the information)

➢ The SecureLogin client now takes the provided NT credential information and unlocks/decrypts the local cache file and starts up in offline mode.



Seamless Login - SecureLogin in Novell® eDirectory™ LDAP credential manager mode with the Novell Client™

➢ The user initially sees the Novell GINA (NWGina). They login workstation only.➢ (nldapaut -> slnmas) receives the user credentials passed by the OS.➢ Slnmas first checks for the registry key DoClient32Assoc to see if it should attempt to read the

Novell eDirectory credentials from the Novell Client for Windows. Set this to value to 0.➢ Slnmas now checks for the registry key DoNTAssoc to see if it should attempt to read the NT

credentials. Set this value to 1.➢ Slnmas takes the NT provided credentials and then encrypts and stores the credential data to

the registry. ➢ When slproto loads it first reads the value of the registry key TryRegCredInOffline. If this

registry key is set to a value of 1, the SecureLogin client will attempt to startup in offline mode. ➢ The client now reads the stored credential structure from the registry and then deletes the

items. (consumes the information) ➢ The SecureLogin client now takes the provided NT credential information and unlocks/decrypts

the local cache file and starts up in offline mode.



Seamless Login – SecureLogin in Novell® eDirectory™ Client32 mode➢ User initially sees the Novell GINA (NWGina). They login workstation only. ➢ The Novell Client™ calls the registered login extension slinc.dll and passes the NT

credential structure. With version 4.91 SP4 plus the post SP4 login updates or the Novell Client version SP5, the client will call slinac if a workstation only login is initiated. Previous versions of the Novell Client will not call slinac if logging in workstation only.

➢ Slinac receives the user credentials passed by the Novell client during the login process.➢ Slinac now takes the provided NT credentials, encrypts the values and stores the

information to the volatile registry key of HKCU ➢ When slproto loads it first reads the value of the registry key TryRegCredInOffline. If this

registry key is set to a value of 1, the SecureLogin client will attempt to startup in offline mode.

➢ The SecureLogin client now reads the stored credential structure from the registry and then deletes the items. (consumes the information)




Seamless Login - SecureLogin in AD mode➢ The user initially sees the Microsoft GINA (MSGina). They login to either the local

workstation account or the locally cached domain account. ➢ SecureLogin's registered credential manager (slcredman) receives the user

credentials passed by the operating system during the login process ➢ Slcredman takes the passed credential structure, encrypts and then stores the

information to the registry. ➢ When slproto loads it first reads the value of the registry key TryRegCredInOffline. If

this registry key is set to a value of 1, the SecureLogin client will attempt to startup in offline mode.

➢ The client now reads the stored credential structure from the registry and then deletes the items. (consumes the information)




Password expirationPassword expiration is really a Novell® eDirectory™ process of forcing password changes. Administrators in an Novell eDirectory environment will set an expiration date for the users password.



Password expiration – Novell Client™ for Windows

In Novell® eDirectory™ the user is not notified when they are approaching the expiration date. They are only notified when the password expiration date is hit and the password is expired. At that point, Novell eDirectory grants a grace login to the user. Note that Grace logins are valid logins. They allow a user to continue to login with an old password even though it has expired. Typically customers will limit the number of grace logins allowed. This value defaults to 3 grace logins. After the grace logins have been exhausted then the account will be locked.

The Novell Client detects that the password is expired due to information that is returned by eDirectory during our NDS connection attempt. With Novell eDirectory the NDS connection is setup through a two stage process. We first login to Novell eDirectory (this gets us attached to the directory), we then perform an authentication to Novell eDirectory (this validates our user identity). During the authentication request, the server will reply if the user has an expired password. The Novell Client will immediately make a request to Novell eDirectory to read the value of grace logins. The client then takes the grace login information and presents the user with a message like "Your password is expired, you have X grace logins available. Do you want to change your password now?" If the user answers positively then the user is presented with a change password dialog and the user changes their password. If they click no then the password is not changed. In either case, the password value that was used successfully will be passed on to the registered login extensions.



Password expiration – Active DirectoryAD environments differ in the way that they present this type of information to the user. In AD environments the user will see a message like "Your password will expire in X number of days". In this type of configuration the registered credential manager is passed any new credentials immediately following the password change. AD also does not implement grace logins so once the password expiration date has been hit then the account will automatically be disabled. At this point an administrative password change would be required.



Password expiration – LDAP

LDAP GINA modeIn LDAP GINA mode, ldapaut handles the password expiration and will update the password values if the password is changed during the login or afterwards through a password change event. There has been a lot of work in this area in regards to the handling of grace logins. Once you have 1 or less grace logins available, the user will be forced to change their password and they will not be able to proceed any further until this has been completed. The reason for this is that SecureLogin implements a two stage login process, the LDAP GINA performs the first LDAP login and then terminates. Then when the SecureLogin client loads it performs another LDAP Login. If the grace logins is not at least 2 then the SecureLogin client would fail to login via one of the remaining grace logins.

LDAP credential manager modeIf the Novell Client™ is installed then the Novell Client will handle the expiration. Once the password is changed then slinac would be passed the new credential structure.

In any other configuration, slnmas will evaluate the number of grace logins available. If there are less then 2 grace logins available, slnmas will force the user to change their password as noted in LDAP GINA mode.



Password changesPassword changes are an integral part of most customer environments. Most customers (just as Novell® internally) require users to periodically change their network passwords after a specific period of time has elapsed. Depending on who initiates the password change effects what processes are used by the SecureLogin client to update the local system variables to the newly changed password value. Password changes are also handled differently depending on the configuration and installation mode of the SecureLogin client.

There are two types of password changes that can occur– User initiated password change– Administrative password change



Password changes - User initiated password changesDepending on the environment different modules interplay here. If the Novell Client™ for Windows is installed on the workstation then the Novell Client will replace the normally seen Microsoft Windows components in the Alt-Ctl-Del security window. The purpose of replacing these components is to allow the Novell Client to control and interact with the lock workstation and change password events. So we will need to look at these two different environments separately.

➢ Without the Novell Client for Windows➢ With the Novell Client for Windows



Password changes - User initiated password changes without Novell Client™

When the user changes their password, the registered SecureLogin credential manager will be called by the operating system with the new credential structure. The credential manager will then call the SecureLogin client to reinitialize/update the sys credentials of the current logged in user. ➢ LDAP environments – nldapaut → slnmas➢ AD environments – slcredman

This information is then replicated to the SecureLogin client, and the configured data store for future access.



Password changes - User initiated password changes with Novell Client™

The Novell Client for Windows will display all currently connected resources to which a password change can occur. Note that these are the "currently" connected resources. If some resources are not listed here then cancel the password change window and connect to the desired resources. For example mapping a drive, logging in, etc...



Password changes - User initiated password changes with Novell Client™

For a long time SecureLogin was unable to provide password change support when configured in Novell® eDirectory™ with the Novell Client for Windows mode. We only supported the password expiration processing in this configuration.

The reason for this was that the interface provided by the Novell Client for Windows in the form of login extensions had certain limitations. One major limitation was that login extensions are only called during a login event. Since the change password event is not a login event then no login extensions are called when a password change occurs. Starting in the Novell Client version 4.91 SP3 the client was modified to call a login extension that also acts as a credential manager. This is a registry hack to enable this support but the newer product installations should create this key if it doesn't exist.



Password changes - Administrative password changes

There is one major security concern with administrative password changes. What would prevent an administrator from changing a users password, then logging in as that user and gaining access to their credential data? This is what we term as a rogue administrator. Great care has been taken in the development strategy to eliminate this potential security breach. Basically, a rouge administrator is an administrator who maliciously attempts to acquire another users credentials for access to restricted data within a customers environment. Since SecureLogin will store all credentials, then it is possible that logging in as another user might give access to personal bank accounts, websites, etc.. Perhaps even access to the customers payroll system. This type of access needs to be prohibited to maintain the security of customer data and resources.

To protect against this type of access SecureLogin implements a control mechanism in the case of an administrative password change. When an administrative password change occurs, the users data is locked. On the next synch or login the user is prompted for their passphrase to validate their identity and unlock their SecureLogin data. This forces the user to not only know their directory password but to also know their passphrase answer. Only the original user should know both of these pieces of information. A rouge administrator can not gain access to another users information by simply changing the directory password. They would also need to have knowledge of the users configured passphrase answer.



Password changes - Administrative password changesThe processes used here are basically the same for all modes with the exception of Secret Store implementations. The only real difference is the module that is responsible for the updating of the credential information.➢ AD – slcredman➢ eDirectory client32 mode – slinac➢ LDAP – nldapaut → slnmas

Note that if the passphrase system has been disabled then this control mechanism will not be in place. In other words, it would be possible to change a users password and then to login as that user. This is why we do not recommend that customers disable the passphrase system. It is an added security mechanism for a reason and by disabling this feature you are opening the system up to a potential security breach. So, if the passphrase system is disabled, then the administrator is considered a trusted user.



Password changes - Administrative password changesWhen the password change occurs in the directory the following occurs.➢ Administrator changes users password ➢ User attempts to access and login to directory ➢ Since the cached credentials (locally cached by the workstations client) will fail to

connect to the desired resource, the client will prompt the user for their credentials. ➢ The user enters their credential data which includes their new password ➢ The credential manager is updated by the OS with the newly provided information. ➢ The credential manager notifies the SecureLogin client of a password change event ➢ The NSL client takes the new credential data and updates the sys variables.



Password changes - Password changes with Secret StoreWhen Novell SecretStore® is in the configuration the process is different. With Novell SecretStore Services an additional level of security is implemented by the Novell SecretStore Services module loaded on the server. When it detects an administrative password change event, it locks the users data store. The data store can only be unlocked by the user or a Novell SecretStore administrator.

How Novell SecretStore detects an administrative password changeSecret Store detects that the password change event was an administrative change by monitoring specific information in Novell® eDirectory™.

When a user changes his own password (initiated from the Novell Client™) then Novell eDirectory will update the users password hash and the public key of the user object (public key is used to decrypt RSA encrypted data. IE the users password).

When an administrator changes a users password in one of the management utilities the password hash is updated but both the RSA private and public keys are changed as well. The Novell SecretStore Services module looks to see if only the public key has changed or if both the private and public key pair have changed. If both keys changed then Novell SecretStore Services will lock the users secret store.



Password changes - Unlocking the users Novell SecretStore®

Novell SecretStore also implements a passphrase system to ensure user identity for unlocking a locked users store. An additional management function "Novell SecretStore Administrator" allows for a secondary administrator to have specific rights to unlock user stores via a master passphrase answer. This gives the secret store administrator the ability to unlock any users secret store. For this reason it is important that the secret store administrator be a separate entity then the normal administrator who would be responsible for the changing of the user password in the directory. To change a users password administratively customers can implement the following.➢ User calls help desk to change password (forgotten password, password expired,

intruder lockout, etc) ➢ Help desk administrator changes the users password in Novell® eDirectory™ ➢ Novell SecretStore administrator is then contacted by the directory administrator to

unlock the users secrets ➢ Novell SecretStore administrator unlocks the users secrets.

Now the user has a new password that was set by the administrator and their secret store has been unlocked by the Novell SecretStore administrator. No user interaction is now required.



Password changes - Unlocking the users Novell SecretStore®

Most customers don't want to implement the two stage administrative process. To eliminate this need, the SecureLogin client does two things...

When logging in the first time to SecureLogin configured with Novell SecretStore Services, the NSL client will automatically assign the users SecureLogin passphrase as the Novell SecretStore passphrase.

When the SecureLogin client attempts to access the secrets of a SecureLogin user configured with Secret Store Services, Secret Store on the server will return an error back to SecureLogin indicating that the users secrets are locked. (result of the administrative password change) The SecureLogin client then takes the stored passphrase answer and submits a user request to unlock the secrets from the server.

But what if the customer has disabled the passphrase system in a Novell SecretStore configuration? Then the customer will need to implement the Novell SecretStore administrator function to manually unlock stores that are locked by an administrative password change event.



Password synchronization

Password synchronization is the process of keeping user directory credentials in a matched state. As noted previously for seamless login to work correctly then both the NT and Novell® eDirectory™ credentials must match. It can be challenge in mixed environments (containing both AD and Novell eDirectory) to ensure that user credentials stay synchronized between the directory platforms.

Many customers implement Novell Identity Manager (IDM) to synchronize passwords against the other platforms within their environment. For example, users utilize an internal website to change their password in Novell eDirectory, on a successful change the new password is then synchronized to AD or other systems.

This is a valid solution in many environments. But there is one exception. Mobile users who are using SecureLogin who are members of a domain and login to Novell eDirectory.

In this scenario, when a workstation is part of a domain the domain login credentials are cached to the local workstation. When the mobile user attempts to login to their laptop without network access, they login to the NT cached account on the workstation.

The problem with this method is that the cached NT account is not updated until the user performs a logout and login to AD. If the user changes their password, then attempts to work offline, they will need to enter their old password to access the workstation.



Password synchronization – SecureLogin directory password synchronization

SecureLogin incorporates a new method of password synchronization starting in SecureLogin 6.1 SP1. This new method only applies to installations of SecureLogin in Novell® eDirectory™ LDAP GINA mode.

Normally with the SecureLogin LDAP GINA when a user initiates a password change, the user must select the resource where they want to change their password. For example, if they need to change both their Novell eDirectory and AD passwords they would need to change one and then change the other. This differs from the functionality seen in the Novell Client™ where all connected resources can be changed at once. By making the following registry key change the SecureLogin LDAP GINA will mimic the functionality seen in the Novell Client configuration.

[HKEY_LOCAL_MACHINE\Software\Novell\Login\LDAP]“DisableCADUserSelection”=dword:00000001

Description - This registry key is implemented for the enhancement to force the users to change their password in both Novell eDirectory and AD. The LDAP GINA uses this key when you press alt-ctl-del to change the password. The SecureLogin client uses this key to force a password change in both AD and Novell eDirectory.

When a user changes their password, both Novell eDirectory and the AD credentials are changed at the same time, keeping the credentials in sync. Also during this process the locally cached AD account is updated as well.

Appendix A.2 SecureLogin and the Network


Troubleshooting SecureLoginSecureLogin and the Network

Novell® SecureLogin will communicate on the network with several different protocols depending on the installed configuration.➢ Novell eDirectory™ with Novell Client™ for Windows – In this case SecureLogin will

make calls internally to the Novell Client for Windows. The Novell Client will communicate with the Novell server via the NCP protocol. If Novell SecretStore® is also used then all Novell SecretStore packets are encrypted by NICI prior to transmission.

➢ LDAP – In all modes the SecureLogin LDAP components will communicate with the server via SSL encrypted LDAP packets.

➢ AD – In AD mode the SecureLogin client will make calls into the Microsoft client for Microsoft networks. This generates Kerberos, SMB, and CIFS communication packets.

It should be noted that all SecureLogin information is 3DES encrypted. So even if the primary protocol being used (IE NCP or CIFS) is not encrypted the payload data (information stored in the datastore) will be encrypted.

Since SecureLogin information is encrypted then most generally packet traces will show communication failures of the primary protocol only. The actual SecureLogin data will not be of any use. (Note that even if you have access to the private key and can decrypt SSL communications you will not be able to decrypt the NSL data)


Troubleshooting SecureLoginSecureLogin and the Network

The impact of SecureLogin on network communications should be minimal. But there are a few settings that should be reviewed to ensure that network communications and server resources are not effected by SecureLogin.➢ Database mode – Defined at the data store, this setting ensures that the SecureLogin

client utilizes checksum values to determine if a cached entry is synchronized with the directory. Set this value to 6.0 or higher to take advantage of the checksum validation process.

➢ Stop walking here – Defined at the data store, this setting instructs the SecureLogin client to not walk the directory tree any higher then the container/object where this setting is defined. The SecureLogin client (by default) will walk to the root of your tree trying to find configuration information. By setting this value at a container (most generally WAN link boundaries) then SecureLogin will stop searching for information any higher in the tree.

➢ Refresh interval – Defined at the data store, this setting instructs the SecureLogin client how often to attempt to synchronize the local cache with the directory. The default value is every 5 minutes. This does generate a number of communications packets and should be adjusted to meet your requirements. Just remember that by increasing this value you are extending the amount of time that a user must wait for any changes in the directory to be synchronized down to the workstation.

Appendix A.3 SecureLogin and the Data Store


Troubleshooting SecureLoginSecureLogin and the Datastore

SecureLogin at the server (datastore) is nothing more then a few additional attributes and LDAP mappings. There is really no additional services to load on the datastore location beyond extending the directory to include these components. There is one exception to this statement. If you install SecureLogin with Novell SecretStore® or NMAS™ support then you must ensure that Novell SecretStore and/or NMAS is available at the server.

Located on the SecureLogin CD are a number of tools for extending the schema for each of the supported directory platforms. The schema tools contain 2 features.➢ Extend the schema and add support for the SecureLogin attributes➢ Setup user rights to the newly added SecureLogin attributes

It is important that after performing these actions that all future user administration be performed with a management console that includes SecureLogin support. For example, iManager with the SecureLogin plugin installed. Failure to follow this requirement will result in SecureLogin errors for any newly created users. The plugin is responsible for setting the necessary rights to the SecureLogin attributes during creation and management activities. If management has been performed or a bulk load of users has occurred then a simple rerunning of the schema tool can correct the issue.

Always run ldapschema on Novell® eDirectory™ regardless of installation mode.

Questions?


For More Information

• Visit table A5 in IT Central• Attend the following complementary sessions:

– BOF106: SecureLogin in the Real World Panel Discussion– IAM205: Novell SecureLogin Installation, Deployment and Lifecycle

Management– IAM207: SecureLogin and Your Active Directory Setup– IAM302: Using Hard Disk Encryption and SecureLogin– IAM303: Enhancing SecureLogin with Multi-factor Authentication– IAM304: Securing Shared Workstation with SecureLogin

• Walk through the SecureLogin demo in the Installation and Migration Depot

• Visit www.novell.com/securelogin

Try SecureLogin for Yourself

We'll install SecureLogin on your machine (for free).

Unpublished Work of Novell, Inc. All Rights Reserved.This work is an unpublished work and contains confidential, proprietary, and trade secret information of Novell, Inc. Access to this work is restricted to Novell employees who have a need to know to perform tasks within the scope of their assignments. No part of this work may be practiced, performed, copied, distributed, revised, modified, translated, abridged, condensed, expanded, collected, or adapted without the prior written consent of Novell, Inc. Any use or exploitation of this work without authorization could subject the perpetrator to criminal and civil liability.

General DisclaimerThis document is not to be construed as a promise by any participating company to develop, deliver, or market a product. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. Novell, Inc. makes no representations or warranties with respect to the contents of this document, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. The development, release, and timing of features or functionality described for Novell products remains at the sole discretion of Novell. Further, Novell, Inc. reserves the right to revise this document and to make changes to its content, at any time, without obligation to notify any person or entity of such revisions or changes. All Novell marks referenced in this presentation are trademarks or registered trademarks of Novell, Inc. in the United States and other countries. All third-party trademarks are the property of their respective owners.