Shadows Window

The Shadows window (available from the Windows menu) lists every known KeyShadow, as well as the current state of the Shadow. KeyShadows can be configured by an administrator to avoid KeyServer service outages during network failures.

  Note that the use of Shadows is considered a legacy mechanism is and rarely used anymore. Robust virtual server hosting has made this redundant server setup antiquated. Additionally, it's important to note all data during a Shadow event is not reported to the main server, but cached data on a client due to short outage is.


The Shadows windows list has three column headers: Location, State, and Last Synchronized. Within the list there is a group header named KeyServer, which represents the actual KeyServer. Clicking on the expansion icon on the left of the line will reveal the Shadows. In the group header, the State column simply tells the number of clients and the version of KeyServer.

The Shadows window shows the basic state of each known shadow. Double-clicking on a particular shadow will contact the shadow to get further details, and open up a Shadow Details Window. Note that if the shadow cannot be reached from the server, no details window will be opened, since all the information shown in the details window comes from the shadow.

Shadow Install

The KeyServer service functions as a Shadow when it is installed with a “shadow” license (shadow.lic) instead of a server license (server.lic). The installed service then becomes a “KeyShadow” which mirrors the KeyServer's data in order to take over service in the event of a network failure. KeyShadows are not necessary. Assuming the defaults are accepted while setting up policies, then managed programs will be allowed to run when the client computer is off-line or when the KeyServer is unreachable for any reason. It is only when the default "Relaxed" Enforcement option is changed to "Strict" or when the optional "keyed" management method is used that KeyShadows become important.

Not only are shadows usually unnecessary, they also can result in KeyServer's reports being less accurate than they might be, since offline usage on a given client is loaded up to the KeyServer at next connection, and subsequently included in reports. Client usage accrued against shadows is, on the other hand, left on the shadows and consequently not included in reports. Also, when administrator rights are used on a client computer to run a product updater for a keyed executable, typically the application will be "set free" - it will no longer be under KeyServer control and usage will no longer be reported.

If the optional “keyed” method of securing software against piracy has been employed for one or more applications, then installation of one or more KeyShadows is advisable. A keyed program is altered in such a way that it must obtain its key in order to run. Hence for keyed programs, KeyShadow's ability to provide an alternate path for a client computer to obtain a key can be a very important fail safe mechanism whenever the KeyServer is unreachable for any reason (e.g. network failure or hardware failure of the KeyServer host). Note: an unkeyed program that is managed by a KeyServer can be configured to use “Strict” enforcement - in this case, KeyShadow will be just as important for this managed unkeyed program as it is for keyed programs.

KeyServer will add a KeyShadow address to its “shadow hint list” when an installed KeyShadow first makes contact with its parent KeyServer. Clients will receive a list of shadow addresses automatically every time they login. KeyShadow is designed to automatically mirror all of KeyServer's configuration data (in an encrypted form). A KeyShadow will start serving whenever KeyServer doesn't respond to periodic status requests from the shadow process. If there is a network or hardware failure that prevents clients from reaching the KeyServer, they will then try to reach a KeyShadow.

Requirements for hosting a KeyShadow are similar to KeyServer but without the storage or performance requirements.

When the KeyServer component is running as a KeyShadow process, clients must be able to connect to the shadow host address using UDP port 19315 (instead of 19283 used by KeyServer).

Since the standard eval.lic does not have a custom serial number for unique identification, it is not possible to “shadow” a standard evaluation KeyServer. Hence KeyConfigure connected to an evaluation KeyServer will not allow creation of a shadow certificate.

To create a KeyShadow, choose a computer host that is strategically located so clients are likely to be able to reach it even when the network link to the KeyServer host is broken. Then:

1. Create a Shadow Certificate.

2. Run the KeyServer installer to create a fresh install (never an upgrade!). The installer will finish up with a dialog suggesting that you start up the KeyServer process - choose "no, don't startup KeyServer".

3. Copy the shadow.lic file into the KeyServer Data Folder. [Note: the installation of a shadow.lic instead of the server.lic is what makes the process run as a KeyShadow instead of the KeyServer.]

If your KeyServer has in addition to its server.lic file, some special “vendor License certificates” (e.g. vendor_name.lic ), these must be copied to the shadows along with the shadow.lic. Note: if the vendor requires a dongle on the KeyServer, shadows will need one as well (along with dongle driver files).

4. If you are using a shadow.lic that was created without a password, start the ks process as you normally would start the KeyServer itself.

But if your shadow.lic is password protected, then from an account with administrative rights, start up the KeyShadow process for the first time in a command window in order to set the password:

Use the Services Control Panel to sure the ks.exe process is not currently running, then Open a DOS command prompt window with administrative rights and start up the ks.exe process with the -s option to set the password. For example, to set the password to "foo", your command would look like this:

         \Program Files\Sassafras K2\Server\ks.exe -s foo

Once this is done, close the DOS command window to quit the ks.exe program and start the KeyServer service using the services control panel.


For the first launch on Mac OS X, bring up a terminal window and type in the command:

       cd /Library/KeyServer; sudo /Library/KeyServer/ks -c

You will be asked for your admin password. Then several message lines will appear followed by a request for the “shadow first-run password” created above. After entering it and hitting the enter key, the shadow process will start and the terminal window will say “ready”. Use ctrl-c to quit the ks process so that you can then restart it as a faceless process (e.g. a daemon outside of any terminal session) using the ks-StartSop applet.
Or use the terminal command:

       sudo launchctl load /Library/LaunchDaemons/com.sassafras.KeyServer.plist