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.
Details
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 Location column shows the address of each known shadow.
- The State column shows the current state of the shadow (as far as the server can tell. Note that the server must be able to reach the shadow to determine the state). The possible states are:
- Unknown Shadow is on the hint list but cannot be reached in order to determine a more accurate state.
- Disabled Service for this shadow has been disabled for the given protocol. This appears only in the KeyShadow State dialog for an individual shadow and reflects only the Shadow state for a given protocol. When an entire shadow has been disabled it no longer appears in the Shadows Window.
- Inactive The KeyShadow is inactive. Either the administrator deactivated it, or it has provided emergency service for over seven days. It is not distributing licenses.
- Offline Service for this KeyShadow is not being supported on the protocol because for some reason the protocol is not working correctly on the shadow machine.
- Registering The KeyShadow is initiating shadow service. It is not distributing licenses when in this state. This state is temporary (less than 1 minute long).
- Serving The KeyShadow has lost contact with the KeyServer due to network failure or KeyServer machine failure, so it is distributing licenses to users. For AppleTalk shadows, only one KeyShadow in each zone can be in this state at any given time; an AppleTalk shadow will not register if there is already a shadow (or server) present in that zone. Should the existing server or shadow become unavailable however, that second shadow will take its place.
- Sleeping The KeyShadow has been put to sleep, or has not yet begun service (soon after restart).
- Shadowing The KeyShadow is in contact with its parent KeyServer (in a different zone), so it is not distributing licenses. This is the normal state.
- Waiting The KeyShadow is starting shadow service after being inactive. It is not distributing licenses. This state is temporary (less than 1 minute long).
- Last Synched column shows when the shadow last synched up to the KeyServer (got up to date program and policy configuration, etc).
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