Novell SecureLogin Installation, Deployment, Lifecycle Management and Troubleshooting

Novell SecureLogin ®

Installation, Deployment Life-Cycle
Management and Troubleshooting

Don Swain, Rajasekar Pandiyan
SecureLogin Product Lead, Global Technical Software Consultant
Support PRajasekar@novell.com
DSwain@novell.com

Greg Morris,
Technical Support Engineer IV
GMorris@novell.com

Planning the Installation

• 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.

3 © Novell, Inc. All rights reserved.


• 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





• 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



• Prepare the destination for use with SecureLogin
– Extend schema in the directory and assign rights to
directory attributes
> Run appropriate tools from ...SecureLoginToolsSchema
» 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)



• 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



• Prepare the workstation with any NSL workstation
prerequisites
– Launch MSI from ...SecureLoginClientx64 or ...x86
– Choose install options as appropriate
> Data store
> Novell Client vs LDAP ™

> Citrix
> etc



• Prepare the workstation with any NSL workstation prerequisites
• 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



• Prepare the workstation with any NSL workstation prerequisites
• 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


Deploying SecureLogin

Installing
NSL in single
workstation Adding new
Applications
MMC Plug in
(Active Directory)

Schema
extension

Distributing
NSL data
to the
containers
NMAS Server Workstation
Method Server/ Directory
(Optional)

iManager
plug in
(eDirectory) Distributing Single Click Optional
custom Installation registry
installation values


• Server- / Directory-Side Deployment
– extend schema
– <Installation Directory>SecureLoginTools
> 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 installation
http://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&st
ateId=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:pathClientNovell SecureLogin.msi" /qb
PATHTOISS="C:pathresponsefile.ini" /update “C:pathNSLFIXSP10911003.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 SecureLogin
SecureLogin 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 Workstation Server
NSL client Data store
• Server



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 NSL Client

Login module Read Registry

Write 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.

slwinsso

sljava slbroker slproto

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.

slwinsso slbroker slproto

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.


Problem 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


Troubleshooting
Information and Problem Gathering Steps


Information and problem gathering steps

• Validate configuration and version

• Document the exact error / problem

• Search for a solution

• Replicate the problem

• Consider debug options


Gathering 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.



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 HKLMSoftwareProtocom



In Novell eDirectory , LDAP, or any combination of these modes, export
®
™

HKLM/Software/Novell/Login


Documenting 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.


Documenting 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.


Searching 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.


Searching 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)


Problem 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.


Problem Replication

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.


Problem Replication

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.


SecureLogin 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>SecureLoginToolsUnsupportedNSLLogManager.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.


Troubleshooting
Problem Scenarios

Problem 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 user
2. Fresh installation of SecureLogin on workstation in Novell Client mode ™

3. 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


Problem Scenarios

cached user data”
2. Fresh installation of SecureLogin on workstation in Novell Client mode
™

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.
• Unable to acquire user identity from the network login
• User has limited or no rights to profile or program paths


Problem Scenarios

cached user data”
2. Fresh installation of SecureLogin on workstation in Novell Client mode
™

4. User can login on another workstation and launch SecureLogin successfully
5. 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.
• 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

Problem Scenarios

iManager SecureLogin plugin not working
1. Open iManager
2. 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.
®
™

• 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


Problem Scenarios

During login user is prompted for their passphrase answer
1. Login to workstation
2. 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.
• 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?


Problem Scenarios

SecureLogin client crashes
2. 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.
• 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.


Problem Scenarios

SecureLogin doesn't detect or fails to interact with a specific Windows application
2. SecureLogin loads OK
3. 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.
• 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.


Problem Scenarios

SecureLogin doesn't detect or fails to interact with a specific web application
3. 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.
• 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.

Problem Scenarios

Roaming or mandatory profiles no longer work after installing SecureLogin
3. User works for a period of time, then shuts down their workstation
4. 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.
• [HKEY_LOCAL_MACHINESOFTWAREProtocomSecureLogin]
"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 A
SecureLogin Processes


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 system
2. SecureLogin and the Network
3. SecureLogin and the data store


Appendix A.1
SecureLogin and the
Windows Operating System

SecureLogin 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 system
When 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 modules
These 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 client
The 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


SecureLogin and the Windows operating system

Acquiring the user credentials in Novell eDirectory with the Novell Client
®
™ ™

mode
The 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 extension
™

Note 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 mode
SecureLogin 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.


SecureLogin and the Windows operating system

LDAP GINA mode
In 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 mode
In 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 mode
In 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.



Acquiring user credentials in AD mode
AD 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 credentials
So 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
credentials
If 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
Process
When 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.

slwinsso

sljava slbroker slproto

iesso



Validating step 1 of the initialization process
The 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 environment
During 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)



The 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 connection
Once 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.



To 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 SettingsAdministratorApplication DataSecureLoginCache



5. Open the cache
Upon 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 process
If 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 cache
Once 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.



One 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 settings
Once 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.



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 interaction
The 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.



The 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 applications
Novell 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



How SecureLogin detects web pages
The 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 applications
Java 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 emulators
A 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 servers
There are several different components used depending on the installed configuration
of the SecureLogin client. See Novell TID 3149664 for details.



Seamless Login
Seamless 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 keys
Modify the registry and add the registry key.
HKLM/software/novell/login/ldap
DoNTAssoc 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/ldap
DoClient32Assoc REG_DWORD 0
Modify the registry and add the following registry key if not present.
HKLM/software/Protocom/SecureLogin
TryRegCredInOffline 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 expiration
Password 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 Directory
AD 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 mode
In 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 mode
If 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 changes
Password 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 changes
Depending 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.



The 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.



When 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 Store
When 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 change
Secret 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_MACHINESoftwareNovellLoginLDAP]
“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


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)



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

SecureLogin 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.
®
™


For More Information
Try SecureLogin for
Yourself
We'll install SecureLogin on
• Visit table A5 in IT Central your machine (for free).

• 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

Novell SecureLogin Installation, Deployment, Lifecycle Management and Troubleshooting

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 Disclaimer
This 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.

Novell SecureLogin Installation, Deployment, Lifecycle Management and Troubleshooting

More Related Content

What's hot (20)

Similar to Novell SecureLogin Installation, Deployment, Lifecycle Management and Troubleshooting (20)

More from Novell (20)

Novell SecureLogin Installation, Deployment, Lifecycle Management and Troubleshooting