SSLock for NDS

Version 6.20
(Jul 187, 2003)


 DISCLAIMER:
     THIS  PRODUCT  IS  SUPPLIED  "AS  IS".  DREAMLAN 
     DISCLAIMS ALL WARRANTIES,  EXPRESSED OR IMPLIED,
     INCLUDING, WITHOUT  LIMITATION,  THE  WARRANTIES
     OF  MERCHANTABILITY   AND  OF  FITNESS  FOR  ANY
     PURPOSE.  DREAMLAN  ASSUMES  NO  LIABILITY   FOR
     DAMAGES,  DIRECT  OR  CONSEQUENTIAL,  WHICH  MAY
     RESULT FROM THE USE OF THIS PRODUCT.

Introduction

Well, SSLock may be just the solution you've been waiting for!

Though not designed to be a true "screen saver" (as it does not draw fancy graphics), SSLock for NDS is an NDS-aware console-locker that has some screen-saver-like features. When SSLock is in the keyboard "locked" mode, it takes over as the current screen and displays some text in random locations on the screen so as not to burn the screen in. Its auto-lock feature will secure the console keyboard even if you forget to. For the security-concerned administrators, SSLock has built-in logging functions to keep track of who unlocked or unloaded the NLM and when. It even has a "intruder detection warning & lockout" feature!

The SCRSAVER NLM shipped with NetWare 5 and higher requires you to have Supervisor object rights to the server object in order to unlock the console. SSLock is much more flexible. You can define users to be member of a group in order to unlock the console (but not unload the NLM). To unload the NLM (i.e. to turn it off), the user needs to be a member of a different group. Users that have Supervisor object rights to the server object can unlock and unload SSLock.

SSLock for NDS works with NetWare 4.10 and higher. [We also have available SSLock3X, a bindery-based works with NetWare 3.12 and higher (but not with NetWare 4.0 and higher--this is by design). We are no longer adding features to it but it is still available upon special request.]

Included with v6.13 and higher is a GUI client module that can be used to control the locking, unlocking, and unloadng of SSLock from a workstation (over IP). This is also a handy feature in NetWare 6 environments where there is currently a bug in RCONJ (not fixed yet in SP2)--when a screen saver (SSLock or even Novell's own SCRSAVER NLM) is active, RCONJ will report "screen destoryed" upon connecting to the server. At this point, you have no further access to the server. However, using the GUI module (called SSUnLock), you can remotely unlock the console and RCONJ will then allow you full access to the console.


What's New


Notes

Since a single doc file is used for both the NDS-aware and bindery-only versions, you'll find some information not applicable to the version you have. Unless otherwise noted, SSLock will be used to refer to both SSLock for NDS and SSLock3X.

  1. The issue of not locking the console in a pure-IP environment when using RCONJ is addressed by v5.13 and higher. However, this requires the use of an undocumented API call that may cause interference with other NLMs. However, we have tested this, including on NetWare 6, and found it has no ill effect. Should you suspect this is a problem, we have included a INI setting (DisableForcedLock) that you can use to prevent the call from being made--of course, this allows RCONJ to access all screens remotely even if the console is 'locked'. Novell is working on a documented API to support this feature but it will only be available for NetWare 6 and not earlier versions of NetWare.

  2. To utilize the SMTP function and/or to enable the GUI module to communicate with the SSLock NLM, the server running SSLock must support Winsock. NetWare 5 and higher has Winsock support built-in; for NetWare 4.11/4.2, you need to apply the latest Winsock update. [Filename is NW4WSOCK.EXE at the time of this writing.] Unfortunately, there is no Winsock update available for NetWare 4.10 or below.

  3. The location (context) of the SS_UNLOCK and UNLOAD_SS group determines which server(s) their members will have access to. If the group is in the same context as the server object, then members of that group can access the server console. If the group is located at a higher context in the tree, its members can access the servers located at that context and below it. Consider the following tree structure: 
                                 [Root]
                               |
                           O=Company
                               |
                    +----------+----------+
                 OU=West                OU=East
                    |                     |
          SS_UNLOCK +                     + UNLOAD_SS
          UNLOAD_SS +                     |
            SERVER1 +                     +
                    |               +-----+-----+
                                  OU=A         OU=B
                                    |           |
                            SERVER2 +           + SERVER3

    Members of the SS_UNLOCK.West.Company group only has control over SERVER1's console. On the other hand, members of the UNLOAD_SS.East.Company group has control over both SERVER2 and SERVER3. Members of the SS_UNLOCK.West.Company have no access to SERVER2 and SERVER3 as these servers are not in the same "branch path"; same is the case for members of the UNLOAD_SS.East.Company group re SERVER1. (We made a concious decision during the design phase that we'll not make the group-server relationship "too granular" nor use Console Operators unless there is much demands and/or a good arguments for them.)

  4. Initially we were using SS_UNLOCK and SS_UNLOAD groups. But it was decided that it is easy to make a simply error and assign a user to the SS_UNLOAD group instead of the SS_UNLOCK (as the two group names are so similar). Therefore, UNLOAD_SS is now used instead.

  5. The NDS username can be given in fully distinguished name or typeless name. You do not need to specify the leading period to indicate absolute path. For example,

    CN=username.OU=org_unit_name.O=org_name
    username.org_unit_name.org_name
    .username.org_unit_name.org_name

    are treated as the same. User Alias is supported as well. If contextless authentication is enabled, you can simply enter the CN.

  6. This utility has not been fully tested with SFT III, High Availability Server nor SMP/MP servers. If you need to use it on a SFT III system, try it on the MSEngine. Initial testing on NetWare 4.11 SMP showed SSLock to function correctly. At this time, this NLM is not SMP/MP-aware, and will, therefore, load on and use CPU #0. Testing has only been done with NetWare 3.12 and higher.

  7. A free connection slot is needed on the server for the utility to work correctly.

  8. There should be a valid license (even if a 2-user) installed on the server for the NLM to function correctly. No licensed connections are used by SSLock during its normal operation. A brief authenticated (but not licensed) connection will be used, for no more than 2 seconds unless the server needs to cross a WAN link to locate and authenticate, when verifing the user's password and group membership. On NetWare 4 and higher, you'll notice a NOT-LOGGED-IN connection (but not licensed) taken by SSLock and this is normal..

  9. You may see SSLock report a high CPU utilization (10+%) from time to time. You need not worry as SSLock will yield the CPU when other processes need the CPU. The occassional spike in the CPU utilization is due to other (background) processes and not SSLock. It has been observed that SSLock takes no more than 1-2% CPU utilization.

  10. The CPU utilization displayed by SSLock for NDS is averaged over an approximate 1-second interval. You should not use it as an accurate measure of CPU utilization but use it as an indicator (or "just something to look at"!). It has been reported that on some NetWare 6 servers which seem to report abnormally high CPU utilization when there is not.

  11. Because SSLock does not "hook" into REMOTE.NLM or the O/S kernel in any way, you may still be able to bring up the "Options" menu in RCONSOLE using F1 (or "*" on the keypad in the NetWare 3.x version of RCOSNOLE) and perform some functions even when SSLock has locked the console keyboard. WARNING: if you exercise the DisableForcedLock option, someone can overwrite SSLOCK.NLM or any files on the server, even if the file is flagged Read-Only, via RCONSOLE or RCONJ.

  12. You may notice the console screen flicker when observing the SSLock screen using the server's monitor. This is due to the screen update rate and is not seen through RCONSOLE. This cosmetic issue may be addressed in a future version.

  13. When you're at the username/password screen, you'll see a countdown clock on the lower-right of the screen. When in this screen, you have 5 minutes (hardcoded in the NLM) to enter your username and password. The timeout clock is mainly used to re-lock the console in case you started to unlock it (say, you have entered your username) but got called away and forgot to lock the screen. Five minutes should be more than sufficient to enter a username/password, authenticate to NDS, and decide if SSLock should simply unlock the console or unload itself.

  14. Sometimes a countdown clock may be seen on the lower-left of the screen. This is the countdown timer for clearing of the intruder detection counter (and this timer is settable using the LockoutResetTimer option in the INI file).

  15. Sometimes you'll see a "<#>" (such as <2>) in front of the username prompt. This is to inform you on the number of intruder attempts recorded.

  16. SSLock3X (the bindery-based version) will not load on NDS servers (i.e. NetWare 4 and higher). Conversely, SSLock for NDS will not load on bindery servers.

  17. If you see [SSLock] messages at the server console but you didn't enter any SS console commands (especially right after you loaded the NLM), check the INI file. The messages may be caused by unknown or illegal settings in the INI file.

  18. Due to support for certain APIs available in NetWare 4 and higher but not for NetWare 3, not all features available in SSLock for NDS are available in SSLock3X. For example, CPU information and the ability to prevent a console UNLOAD command are not available in SSLock3X.

  19. SSLock records its events (such as who unlocked the console when) in the system error log file (SYS$LOG.ERR in SYS:SYSTEM).


Installation

SSLock NLM

No special installation steps or setup program need to be used. Simply copy the SSLOCK.NLM / SSLOCK3X.NLM to the server. The NLM may be located in any volume and directory. Generally, you would put it in SYS:SYSTEM.

The NDS schema is not extended in any way.

A sample SSLOCK.INI (or SSLOCK3X.INI) configuration file is supplied and is shown below. This file contains the license key and can be used to alter default SSLock settings. The INI file must be placed in the same directory as the NLM.

# SSLOCK.INI
#============
#     This is the configuration file for SSLock v3.94 and higher
#
#------ Please do not modify the following lines ------
# (License for xxx servers)
License_key = 0000 # Evaluation license key
Licensed_to = Evaluation Use
#------ Please do not modify the above lines ------

# Contexts for "contextless" logins. Max. 10 allowed.
# Do NOT add leading period to the context.
# Case of keyword does not matter.
;user_context = test
;USER_CONTEXT = systems

# Flag to disallow the use of emergency bypass on this server
# Case of keyword does not matter.
;NoByPassAllowed

# Flag to disable the use of forced screen locking.
# Case of keyword does not matter.
;DisableForcedLock

# Flag to disable the display of countdown timer on the
# console screen. This is useful on NetWare 6 where the
# logger screen interferes with the console screen.
# Case of keyword does not matter.
;DisableConsoleCountDownTimer

# Option to execute an NCF file should intruder is detected.
;NCF_FILE = [path:]filename

# -- new in v6.20 -- #
# Option to display some legal stuff.
;LEGALTEXT_FILE = [path:]filename

# PIN in order to access the emergency bypass prompt. Can be alpha
# numeric and embedded blanks are significant. Must first encrypt
# the PIN using the supplied ENCRYPT2.EXE (DOS application).
;ServerPIN = encrypted_pin

# Controls how soon (in minutes) the 'intruder lockout' will get
# reset. The default is 5 minutes; valid range is 3 minutes to
# 59 minutes.
# Case of keyword does not matter.
LockoutResetTimer = 5

#------- The following options are valid for v5.xx and higher -----
# Case of keywords does not matter.
#
# SMTP-related settings.
# Generally, you do not need to specify a smtpMailFrom address.
# This means a 'null' will be used for the Return-Path parameter
# in the e-mail header (meaning, if it bounces, do not care).
# However, if your SMTP host does not support that (which it
# should as its RFC), you can specify an e-mail id using the
# smtpMailFrom parameter. Up to 10 ids may be specified in the
# smtpSendTo parameter.
;smtpHost     = smtp.domain.com
;smtpSendTo   = "alert1@domain.com, alert2@domain.com"
;smtpMailFrom = SSLock.Alert@domain.com

# The following specifies the condition under which SMTP alerts
# will be generated.
;smtpOnUnload
;smtpOnUnlock
;smtpOnIntruder
;smtpOnLock
;smtpOnBypass
;smtpOnSettingChange

# Rarely needed, but if the server is heavily loaded (busy),
# sometimes the SMTP alert from smtpOnUnload does not get a
# chance to be sent before the NLM completely shuts down.
# This option adds a 5 second wait to the shutdown process to
# allow the smtpOnUnload email be sent.
;waitOnUnload

# The following enables communication with the SSUnLock GUI
# client module.
;enableWatcher

# The default IP (UDP) port is 2000. But you can change it.
;watcherPort  = 2002

#------- The above options are valid for v5.xx and higher ---------

#
# Supported keywords:
#     LOCK       To lock the console right away (as soon as
#                the NLM loads); same as ON.
#     ON         To lock the console right away (as soon as
#                the NLM loads); same as LOCK.
#     IDLE = xyz specifies the keyboard idle timeout to be "xyz"
#                seconds. Default is 120 (min is 0; max is 3600
#                [1 hour]).
#     WARN = x   specifies the number of "intruder attempts" is
#                permitted within a 5 minute period. Default is
#                3 (min is 1; max is 5).
#     MONO       Turns off the use of color (if you can not read
#                the text).
#     NONOTIFY   Turns off notification to network when the
#                emergency bypass option is used.
#
# They must be specified all on the same line, separated by a
# space, comma, or semi-colon. The line must be terminated by
# cr/lf. If there are multiple keyword lines, the last one will
# be used.

LOCK; idle = 120; warn = 3; on
; The above MUST be the last non-comment line in this file.

SSUnLock GUI Module

SSUnLock is a Win32 application and has been tested to work correctly on Windows 9x/NT/2K/XP. No special installation procedure is required. Simply copy SSUnlock.exe to a directory of your choice and, optionally, create a shortcut on your desktop for it. The workstation is required to have IP configured and Client32 installed. See SSUnLock GUI for more details. (SSUnLock uses UDP/IP to communicate with SSLock)

Module Requirements

SSKey

Included with the NLM is SSKEY.EXE and SSKEY.NLM. SSKEY.EXE is a DOS application ("lowest common denominator of most desktops") that generates a one-time authenication key for emergency SSLock access. See Emergency Bypass for more details (also see SSUnLock GUI). SSKEY.NLM provides the same function as SSKEY.EXE and is included in case you are in the server room and do not have handy access to a workstation. You should keep these files separate from the SSLOCK NLM file.

Encrypt2

ENCRYPT2.EXE is a DOS application that is used to encrypt your PIN that enables the emergency bypass option. You should keep it separate from the NLM. The size of the PIN can be anywhere from one to 50 characters and can consist of any alpha numeric characters (do not use any punctuations such as "!"); embedded blanks are significant. Although you can specify a longer PIN (100 chars.) but it is recommended that you should keep it to 50 characters or less. LETTER CASE IS IMPORTANT.


Usage

SSLock NLM

SSLock accepts a number of command-line parameters (or you can put them in the INI file, see Configuration), which you can use to alter the default settings. The LOAD syntax is:

LOAD [path]SSLOCK [LOCK | ON] [IDLE=xyz] [WARN=x] [NONOTIFY] [-MONO] [-HELP]

where

The options are not case-sensitive. Each should be separated by a space, comma, or semi-colon. For readability, a comma or semi-colon is suggested.

For example, if you have the following in your AUTOEXEC.NCF, the console will be locked immediately and will be re-locked after a 3-minute (180 seconds) keyboard inactivity:

LOAD SSLOCK ON; IDLE=180

Once the NLM is loaded, you can also modify some settings with the following SSLOCK console commands:

You can also use SS instead of SSLOCK.

Press ESC (or X) to bring up the username/password screen

Emergency Bypass

(This feature may be disabled by including the NoByPassAllowed keyword in the SSLOCK.INI file. You are also strongely encouraged to implement the ServerPIN option in the INI file. Refer to the Configuration section below.)

There will be times when the person in front of a SSLock'ed console is not a member of one of the SSLock groups but you need that person to perform some tasks but you are not able to add that user into the SSLock group (say, because you are not in the office). SSLock has an "emergency bypass" feature that allows you to generate a "one-time" authentication code that can unlock the console. This authentication code is only valid for the "enter username/password session" at that particular instance. Here's how it works:

  1. Have SSKEY.EXE or SSKEY.NLM handy, as you only have 5 minutes to get the server key, generate the corresponding authenitication key, and use it.

  2. Press ESC at the SSLock'ed console to bring up the username/password screen (this begins the "session").

  3. If you wish the user to just unlock the console, at the username prompt, type in "..//" (that is, two periods followed by two slashes; and without the quotes) and then press <Enter>. If you wish the user to be able tounload the console, enter "..//unlock//.." (two periods, two slashes, the word unlock, two slashes, then two periods; and without the quotes) and then press <Enter>.

  4. If the ServerPIN option is enabled, you will be prompted for the PIN. An invalid PIN will cause the bypass process to be cancelled and the intruder detection count will be incremented by one.

  5. A 9-byte "Server key" is displayed. This code is valid only for 5 minutes; if the screen is closed and then re-displayed, a new server key is generated.

  6. Enter this 9-byte key into SSKEY. A 4-digit authentication code is returned. This code is valid only for the server key displayed in the previous step. Since the username/password screen is displayed only for 5 minutes, that means this authentication code is only valid for this time period.

  7. Enter the 4-digit authentication code into SSLock. When done correctly, you now have the option to either unlock or unload the NLM.


SSUnLock GUI Client Module

SSUnLock is a Win32 application that communicates with the Watcher process of SSLock. The data exchange is over UDP and the requests (or commands) are encrypted before sending (so that your ServerPIN is not passed in cleartext over the wire).

The GUI supports four types of operations:

The server name used by SSUnLock is the DNS host name, not the actual NetWare server name. Should you not have DNS configured or not using a local hosts file, you can use IP address for the server name. SSUnLock can keep a history of 10 server names (using the SSUNLOCK.INI file located in your workstation's system directory). To add to the history list, click the button beside the server name edit box (which should have the '+' symbol). If the server name you entered (or selected) is already in the history list, the '+' symbol will be changed to a '-', meaning you can remove it from the history list.

You can clear the entire history list using the "Clear server name history list" option from the system menu, or simply delete the SSUNLOCK.INI file. The INI file will be recreated as needed.

By default, SSUnLock assumes the IP port is 2000. However, you can override that default value in one of two ways:

If the target server is configured to use a ServerPIN, you enter this in the GUI when issuing a unlock or unload request. However, unlike setting up for the server, you do not need to first encrypt it using ENCRYPT2.EXE before entering it in the GUI.

Although this is the first release of SSUnLock GUI, it is numbered v6 to match the version of SSLock NLM that it supports.


Configuration

SSLOCK.INI

The SSLock INI file must be placed in the same directory as the NLM. The following keywords and information are placed in the INI file (please ensure each line is terminated with a CR/LF):

The following are the new INI options introduced starting in v5.xx to enable SMTP e-mail alerts:
  • smtpHost = smtp_server_name specifies the name of the SMTP host. The current implementation of the SMTP client does not support authentication. Therefore, when specifying the smtpHost parameter, use a SMTP server that does not require authentication. Ensure you have correctly configured the RESOLV.CFG file located in SYS:ETC to point to the appropriate DNS server(s); a IP address may be used instead of a server name.

  • smtpSendTo = list_of_receipents specifies the e-mail addresses you wish the alerts to go to. You can specify up to 10 receipent names (however, if each name is long [say, more than 30 bytes], recommend you use no more than 5 names) in the smtpSendTo line; separate each name with a comma. For example: 
    smtpSendTo = alert1@domain.com, alert2@domain.com

  • smtpMailFrom = email_address. Generally, you do not need to specify a smtpMailFrom address. This means a 'null' will be used for the Return-Path parameter in the e-mail (meaning, if it bounces, do not care). However, if your SMTP host does not support that (which it should as its RFC), you can specify an e-mail id using this parameter.

    Note that you must specify both smtpHost and smtpSendTo (while smtpMailFrom is optional) in order to enable the SMTP alert option.

When the SMTP option is enabled, an e-mail will be sent upon successful loading and initializing of SSLock.


The following are the new INI option "flags" introduced starting in v5.xx that specifies the condition under which SMTP alerts will be generated:
  • smtpOnUnload. Send alert when the SSLock NLM is unloaded.

  • smtpOnUnlock. Send alert when the console is unlocked.

  • smtpOnIntruder. Send alert whenever the Intruder Counter is incremented.

  • smtpOnLock. Send alert when the console is locked (either on-deman by a user or auto-locked after idle timeout).

  • smtpOnBypass. Send alert when the emergency bypass option is being exercised.

  • smtpOnSettingChange. Send alert when operational settings (such as idle timeout) are changed after the NLM has been loaded.

  • waitOnUnload. Rarely needed, but if the server is heavily loaded (busy), sometimes the SMTP alert from smtpOnUnloaddoes not get a chance to be sent before the NLM completely shuts down. This option adds a 5 second wait to the shut down process to allow the smtpOnUnload email be sent.


The following are the new INI option "flags" introduced starting in v5.xx that enables communication with the SSUnLock GUI client module:
  • enableWatcher. Enables the "Watcher" thread in SSLock which allows communication over IP (using UDP datagram) with the SSUnLock GUI client module.
  • watcherPort = ip_port_number. The default IP (UDP) port used by Watcher is 2000 but you can change it using this parameter.

Refer to the comments included in the supplied SSLOCK.INI file for more information about the syntax for the following commands:

Any load-time option will cause the INI file settings to be ignored.


SSLock Groups

You will need to create a SS_UNLOCK group and a UNLOAD_SS group in the appropriate container(s) in your tree and assign users to them. (See the Notes section above on how the NDS context of these groups affect which users can work with SSLock on a particular server.)

Assign users that you allow to unlock the console (but not unload the NLM) to be a member of the SS_UNLOCK group; users that you allow to unlock and unload the NLM should be a member of the UNLOAD_SS group.

Users that have NDS Supervisor object rights to the server object can unlock and unload the NLM; they do not need to be a member of the UNLOAD_SS or SS_UNLOCK group. It does not need to be a direct trustee assignment as inheritence will work just fine.

If you apply Address Restriction to your users, ensure those users in the SS_UNLOCK and UNLOAD_SS groups can log in on the server's Internal (IPX) network. If you limit Concurrent Logins, ensure there is sufficient login allowed for the user to be logged in at a workstation and from the server.



Registration

You are granted a 30-day trial license to evaluate the unregistered version of SSLock. The evaluation (unregistered) version has the following limitations:

SSLock is licensed on a per-server basis. For multiple servers, a tree/site-license is available (so that you only need one license key for all servers). The licensing cost, effective September 1, 2002, is as follows:

     1  - 49 servers     $25 US or $37.50 CDN+GST per server
     50 - 99 servers     $20 US or $30.00 CDN+GST per server
     100+ servers        $15 US or $22.50 CDN+GST per server

Sites with 10 or more servers will receive tree/site-based site licenses. At the time of this writing, SSLock can be registered using the enclosed order form (ORDER3.FRM), via a Company Purchase Order, or from the following Websites:

Upgrade SSLock3X to SSLock for NDS

You can upgrade SSLock3X licenses to SSLock for NDS licenses (a one-to-one upgrade). A credit of $5 US ($7.50 CND) per SSLock3X license will be applied towards the new SSLock for NDS license cost. Upgrades must be made directly through DreamLAN and is not available through the normal reseller channels.


Other Information

SSLock is written in C using WatCOM 32-bit C optimizing compiler and Novell Developer Kit. No undocumented API calls are used.

Inclusion of this utility on CD-ROMs (except for backup purposes) without permission from DreamLAN Network Consulting Ltd. is expressly prohibited.


Revision History