SSLock

Version PK-4.61
(Dec 16, 1998)


 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 screen saver, 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 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. Also available is SSLock3X, a bindery-based works with NetWare 3.12 and higher (but not with NetWare 4.0 and higher--this is by design).


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

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

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

  4. 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 CPU #0. Testing has only been done with NetWare 3.12 and higher.

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

  6. 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 NetWare 5, you'll notice a NOT-LOGGED-IN connection taken by SSLock and this is normal..

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

  8. 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"!).

  9. Because SSLock doesn't "hook" into REMOTE.NLM or the O/S kernel in any way, you'll 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: As a result, someone can overwrite SSLOCK.NLM / SSLOCK3X.NLM (or any files on the server), even if the file is flagged Read-Only, via RCONSOLE if that person has the RCONSOLE password. This will be addressed in the next major revision update of SSLock.

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

  11. 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've 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.

  12. Sometimes a countdown clock may be seen on the lower-left of the screen. This is the countdown timer for clearing the intruder detection counter.

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

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

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

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


Installation

SSLock

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'd put it in SYS:SYSTEM.

A SSLOCK.INI (or SSLOCK3X.INI) configuration file is supplied. 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.

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 Usage for more details. SSKEY.NLM provides the same function as SSKEY.EXE and is included in case you're in the server room and don't have handy access to a workstation.

The NDS schema is not extended in any way.


Usage

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

There's going to be times when the person in front of a SSLock'ed console isn't in one of the SSLock groups but you need that person to perform some tasks but you're not able to add that user into the SSLock group (say, because you're 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'll 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.

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

  4. 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 used.

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

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


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:

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


SSLock Groups

You'll 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 don't need to be a member of the UNLOAD_SS or SS_UNLOCK group. It doesn't 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 (same for SSLock3X and SSLock for NDS) is as follows:

     1  - 49 servers     $20 US or $30.00 CDN+GST per server
     50 - 99 servers     $15 US or $22.50 CDN+GST per server
     100+ servers        $10 US or $15.00 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 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