KeyAccess

The Windows client OS must include the "Windows Management Interface", WMI, in order to fully support K2's hardware audit functionality. WMI is not necessary for gathering some basic hardware information (e.g. ethernet hardware address and free disk space) or for auditing software. WMI is included as a standard part of Windows beginning with Windows 98. It can be added to Windows 95 with a component installer from Microsoft.

By default, KeyAccess settings are stored globally for all users in the registry:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\KeyAccess

The KeyAccess installer (K2Client.exe) provides an option to install settings individually for each user account. These will take precedence:

HKEY_CURRENT_USER\Software\Sassafras\KeyAccess

A third option is to read all settings from the file "keyacc.ini" which is located in the windows (or \winnt) directory.  Unless a site has a specific reason to store settings uniquely for each user or to avoid the registry altogether, the default should be used. Note: the file keyacc.ini is created in all cases and it contains an entry specifying what registry entry, if any, to use.

The client installer (k2client.exe or k2mobile.exe) contains both an .exe and an .msi-based installer.  The .msi is used unless the OS is older (Windows/9x or NT) and has not been retrofitted with .msi support. Sites using a GPO or other means of distribution may need to extract the .msi in order to facilitate deployment.  In the Miscellaneous folder of the K2 image archive, there is a tool called "kscustom.exe" that will do the extraction and also allow customization of the msi based installer. Type "kscustom.exe" (unqualified) at the command prompt to see all the various available options including the ability to customize for a silent install with the correct server address. Note: kscustom only customizes the msi portion of the installer (regardless of whether it has been extracted), so when you run the customized k2cleint.exe on Windows 98 (which by default does not include msi support), the custom configuration will not be honored.

Normally, KeyAccess is installed to run as an application with a shortcut in Startup Items. When not using Terminal Services (including Fast User Switching), it is possible to install KeyAccess as a service - first remove the startup item and then enter "keyacc32.exe -install" into the Run item in the Startup Menu (run "keyacc32.exe -remove" to un-install the service). When the computer first boots up and starts KeyAccess as a service (before any user logs in), KeyConfigure will display the name, "SYSTEM" in the User Window. This will change to the login name when the first user logs in, and it will be updated with the next user name whenever a new user logs in (after the first user has logged out). Note: KeyConfigure will never revert the session name to "SYSTEM" until the computer is re-booted, even though the user has logged out and the computer has returned to its login screen.

While it is possible to install KeyAccess as a service as described above, this is not generally recommended. When supporting fast user switching (under Windows XP) or when installing KeyAccess on a Windows Teminal Server (see comments below), KeyAccess must be installed as a program so that KeyConfigure's User window will display a separate record for every active account (instead of just one user record for each active computer).

If you have no need to control any 16-bit programs, you can remove the file named keyacc.exe (but not keyacc32.exe) from your windows (or \winnt) directory.

 KeyConfigure

The Windows Admin installer, K2Admin.exe, also installs the KeyServer ODBC driver and customizable example reports written in Crystal Reports and Microsoft Access. You don't have to install KeyConfigure to use these external reports (K2Admin.exe will let you install just the reports and driver), but these reporting tools are only available on Windows.

KeyConfigure's "internal reports" can be used to query usage data exported through KeyServer's export feature. An appropriate Windows ODBC driver matching the external database server must be used. Mac OS does not fully support ODBC so internal reports in Macintosh KeyConfigure cannot be so easily used with exported data.

 KeyServer

When hosting KeyServer on Windows NT, Windows 2000, Windows XP, or Windows 2003 (using K2Server.exe), the installer will configure KeyServer as a service set to start "automatically" whenever your system starts up. If you install the KeyServer as a service on any drive other than your system drive (typically C:), you may have to change the default privileges: the SYSTEM account (used by KeyServer) must have "Full Control" rights for all folders in the resulting path (e.g., D:\Program Files\Sassafras K2\Server). It's easiest to install the KeyServer in the default location of C:\Program Files\..., if that is possible.

KeyServer must be hosted on Windows in order to support:

• Data export through ODBC
• Windows NT authentication method
• SQL authentication method

 KeyAccess

There is no point in using the mobile client installer, K2Mobile.exe, since thin clients are always connected - use K2Client.exe. When installing for thin client support on WTS (or Citrix Winframe), you should be sure to enter "install mode" and then use the "Add/Remove Programs" control panel to run the installer. If your server does not enter install mode automatically, follow these steps:

1. Login as the Administrator (or installation) account
2. Open a command prompt window and type: change user /install
3. Install KeyAccess via the K2Client.exe
4. Return to the command prompt and type: change user /execute

The essential KeyAccess client files will be placed in the WTS (or WINFRAME) directory with a shortcut in Startup Items. Note: KeyAccess must not be run as a service on a Terminal Server.

When WTS is serving out a "complete Windows desktop" to a thin client, then KeyAccess will startup/ shutdown when the thin client session is opened/closed and application usage within the session will be tracked as expected - no further configuration is required.

When serving "Published apps" (e.g. without a surrounding Windows desktop), you must configure special options to ensure that KeyAccess is properly launched and quit so it can correctly report the Published Application activity to KeyServer.

KeyAccess has been optimized for minimal processor overhead so even on a Terminal Server running 20 instances of KeyAccess on a single cpu (ie, with 20 thin client sessions active) it will not tie up undue system resources.

Note: thin clients with KeyAccess installed on a Terminal Server as described above will have K2's auditing feature turned off by default. If you want to include an audit of the server volume in your K2 audit database, you will have to pick one of the thin client computers listed in KeyConfigure's Computers window (computer ID begins with W) and turn its audit option back on. There is probably little point in turning auditing on for more than one thin client since they all share the same disk.

 KeyConfigure

KeyConfigure is installed like any other application program: you may want to restrict access to specific users and make it available to only a few, if any, thin clients. Note: KeyConfigure running from any Windows or Mac computer (including a thin client, if you wish) will be able to manage the KeyServer process - just enter the KeyServer IP address and password.

 KeyServer

KeyServer will function properly when hosted on a Terminal Server, providing license management to both thin and regular clients. However, it is recommended that you host the KeyServer process on a different computer in order to ensure the best performance from Terminal Server and KeyServer.

 

 KeyServer

The components for KeyServer on NetWare are installed from any Windows computer that is connected to the NetWare server with the SYS volume mounted, and with access privileges to write into the SYS:\SYSTEM directory.

From your Windows computer, run the K2srvNLM.exe program. When prompted for an install directory, be sure to specify the drive letter and path of your SYS:\SYSTEM directory (if you run server NLMs from a different directory, you can install KeyServer there instead). During the install process, you are asked whether your NetWare server is version 4.x or version 5.x or higher. It is important that you indicate the proper version.

The standard install of KeyServer for NetWare does not set KeyServer to run automatically when NetWare starts up. You should edit the AUTOEXEC.NCF file, adding the following line:

      LOAD KS.NLM

The KeyServer NLM recognizes a few command line options that you can use to control how it runs. The most useful options are listed below.

d <dir>

By default, KeyServer looks for its data folder (KeyServer Data Folder or KSDATA) in the same directory as the KS.NLM. If you want to store the data folder in a different location, use this option to specify the directory in which the data folder is stored.

l

By default, KeyServer will try to use long file names when support for long file names is installed on the volume that contains KeyServer and its data folder (SYS by default). To force KeyServer to use short file names, even when long file name support is available, use this option.

s

By default, KeyServer displays its status in a simple text screen. Use this option if you want this status to be displayed on a formatted screen, with usage statistics and additional information.

x

KeyServer requires that the NETDB NLM be loaded in order to function as a shadow server, send status e-mail messages, and refer clients to other KeyServers. Normally, when KeyServer first starts up, it will attempt to automatically load this NLM. If you are not using the e-mail or referral features on this KeyServer, and if this KeyServer is not acting as a shadow, you can tell KeyServer not to load the NETDB NLM by using this option.

A Netware host can still support Macintosh clients using the AppleTalk protocol even though most sites will find IP to be better supported (both by your network and by Apple). If you need Appletalk support, make sure that the AppleTalk NLMs are configured for automatic load in the AUTOEXEC.NCF or some other startup script.

To use KS NDS authentication, KeyServer must run on Netware.

 KeyAccess

Run the installer named K2Client.sea or K2Mobile.sea to install KeyAccess on a Mac OS X computer. The installer must be run from a Login session that has Admin privileges - the installer will require re-entry of an admin password. It will prompt for the IP address (or DNS name) of the KeyServer during installation. Appletalk is not supported for Mac OS X clients (nor is it supported by the Mac OS X KeyServer).

Mac OS X, Classic, & Mac OS 9

On a typical Mac OS X computer that has a System Folder containing Mac OS 9, you can "start the Classic environment" as a process within the running OS X operating system, or you can reboot the computer as a Mac OS 9 machine. Version 6.x of the KeyAccess extension (in System Folder/Extensions) will work in either case - under Classic (within OS X) or under Mac OS 9 (as the boot OS).

The K2Client.sea and K2Mobile.sea installers include the installation of the 6.x KeyAccess extension for the Classic environment. Management of Classic programs requires this new version of the KeyAccess extension to be installed into the "blessed" System Folder. KeyAccess versions prior to 5.2.3 will not communicate correctly with Mac OS X. Do not install an older KeyAccess extension in the Mac OS 9 system folder.

If you do not need to control or log any Classic applications, the KeyAccess Chooser extension is unnecessary so the K2Client.sea installer gives the option to install only the Mac OS X components. Note: the KeyAccess OS 9 system extension running in Classic within Mac OS X will do nothing without the required Mac OS X KeyAccess files properly installed (but if you boot in Mac OS 9, it is all that is required).

Note: if you have multiple OS 9 System Folders, each one should have the 6.0 KeyAccess extension installed. This comment applies regardless of whether you have Mac OS X installed. It is perhaps worth emphasizing in a Mac OS X context, however, since the Mac OS X System Preference for starting Classic makes shifting among various Classic environments so easy. It is all right to duplicate the KeyAccess extension from one Classic environment to another without running the client installer. You won't have to set up the KeyServer address in Classic since it is managed globally by OS X.

Un-Install

KeyAccess client software for Mac OS X runs as a process owned by root, so root privileges are required in order to shut it down and to un-install the KeyAccess components. Remove the folder /Library/KeyAccess/ (and if you have a Classic System Folder, remove the KeyAccess Chooser device). You can use the command:

     sudo rm -R /Library/KeyAccess     ;remove the KeyAccess folder and contents

After a reboot, KeyAccess will no longer be active. You can also remove the folder /Applications/Sassafras K2/Client/ and the KeyAccess chooser extension (if you also have a Classic System Folder). Consult the File Locations document if you want to remove all traces.

KeyConfigure

The KeyConfigure application uses CarbonLib, so it will run under either Mac OS 9 or Mac OS X. However, if a Mac OS 9 computer is running both the KeyServer and KeyConfigure processes on the same machine, you won't be able to run Internal Reports. For a large KeyServer, reporting will be noticeably faster when KeyConfigure is run under Mac OS X or Windows.

 KeyServer

To install KeyServer on Mac OS X, first login with Administrator privileges and shut down any running KeyServer process. Use the Process manager to look for "ks" owned by the system - an admin password will be required to shut it down. Run the installer package to update any previously installed components to the latest version while preserving your custom configuration information.

The KeyServer process will start up automatically when you reboot, or you can follow the instructions in the "startup.txt" document to avoid the reboot. To disable KeyServer's automatic startup, delete or change the name of the startup script: /Library/StartupItems/KeyServer/KeyServer.

Since ks is just a unix program, you can also start it by typing "sudo /Library/KeyServer/ks" in a terminal window. This is useful when you want to see diagnostic output (or when installing a shadow and starting it for the first time), but the ks process will quit when the terminal window is closed.

Command Line options:
The KeyServer program recognizes a few command line options that you can use to control how it runs. The most useful options are listed below.

b <dir>

By default, KeyServer looks for its data folder (KeyServer Data Folder or KSDATA) in the current working directory. If you want to store the data folder in a different location, use this option to specify the directory in which the data folder is stored.

d

By default, KeyServer runs as a simple console program, and writes basic status information to the terminal in which it was started. If the terminal is closed, the KeyServer will stop running. To run KeyServer as a "daemon" process, use this option. When running as a daemon, KeyServer does not write status information to the terminal, and continues to run even after the originating terminal is closed.

e <log-file-path>

KeyServer can optionally write some status messages to a separate log file, other than the KeyServer log (where program usage information is stored) and the system log (where startup and shutdown information is written). If you want a simple log of KeyServer's startups and shutdowns, specify the log's location using this option.

n <hostname>

When KeyServer is running on a multi-homed host (a host with more than one IP address assigned to it), it will open its service port on the default IP address. Use this option to force KeyServer to open its service port on a specific IP address.

To use the Unix Authentication method, KeyServer must run on Mac OS X or Linux.

On Mac OS X 10.4 (Tiger), the Spotlight search facility will continuously attempt to index files in preparation for speedy searches. While Spotlight documentation is not completely clear (and the implementation doesn't always conform to the documentation anyway!), it is probably best to add the KeyServer Data Folder to Spotlight's "Privacy" list (since the database files are in a proprietary data format).

There are no separate installers for Mac Classic versus Mac OS X - the installers will recognize the target platform and behave accordingly.

KeyAccess

On Mac OS 8 and 9, KeyAccess is a Chooser device that resides in the Extensions folder within the classic System Folder. The target KeyServer address is configured from the Chooser - either select the Appletalk name of the KeyServer, or use the Configure button to enter an IP address or DNS name.

When Classic is run from within Mac OS X, this same KeyAccess extension must be in the Extensions folder, but using the Chooser for configuration does nothing in this case - use Mac OS X program, KeyAccess Setup, to configure the address. If your original installation is from a Mac OS X boot, and there is a "blessed" Mac OS 9 System Folder, then you will be able to boot back and forth between OS 9 and OS X - KeyServer will correctly identify the client as the same computer. Note: Appletalk is only supported for clients that boot in Mac OS 8 or 9, and then only for legacy reasons (the IP protocol is recommended).

KeyConfigure

The KeyConfigure application uses CarbonLib, so it will run under either Mac OS 9 or Mac OS X. However, if a Mac OS 9 computer is running both the KeyServer and KeyConfigure processes on the same machine, you won't be able to run Internal Reports. For a large KeyServer, reporting will be noticeably faster when KeyConfigure is run under Mac OS X or Windows.

KeyServer

When hosting the KeyServer process on a Macintosh computer booted under classic Mac OS 8 or 9 (as opposed to Classic running from within Mac OS X), there are special KeyServer components that must be used. The Macintosh server installer, K2Server.sea, will install the correct components depending on whether the installer is run under Mac OS X or not. Don't install under a Classic boot and then switch to a Mac OS X boot - you will have the wrong KeyServer version!

Hosting KeyServer under Mac OS 9 will limit the responsiveness of KeyConfigure connections. Report query response will be slow when the usage databases become large. When KeyConfigure is loaded on the KeyServer host itself, under Mac OS 9 internal reports are disabled. For a KeyServer supporting a few hundred clients, these limitation may not be noticeable, but to support greater numbers of clients, it will be best to host KeyServer under Mac OS X, Windows, Linux, or Netware

If you must support Appletalk clients for legacy reason, host the KeyServer on Mac OS 8 -9, Novell Netware, or Linux.

 KeyServer

The KeyServer process requires version 2.3 or better of the glibc library.

There is no formal installer for KeyServer on Linux (there is no RPM), but the server components are collected into a tar archive named K2Server.x86.tar. To extract the components from the archive, use the following command:

     tar xvf K2Server.x86.tar

This will extract the files into a directory named KeyServer with a subdirectory called KeyServer Data Folder.

To set up KeyServer to start each time Linux boots, you will need to add a line to your rc.local file. Alternatively, you can use the init.d mechanism if that is available on your system. Consult your Linux administration documentation or the man pages for information on how to do this.

To stop a running KeyServer process, use the 'kill' command (use 'pidof' to get the process id of the 'ks' process). Do not use 'kill -9' unless absolutely necessary, since this does not give KeyServer a chance to flush its file buffers.

The KeyServer program recognizes a few command line options that you can use to control how it runs. The most useful options are listed below.

b <dir>

By default, KeyServer looks for its data folder (KeyServer Data Folder or KSDATA) in the current working directory. If you want to store the data folder in a different location, use this option to specify the directory in which the data folder is stored.

d

By default, the "sudo ks" command will run KeyServer as a simple console program and write basic status information to the terminal in which it was started. Running in a terminal window is often useful for diagnositc purposes but when the terminal is closed, the KeyServer will stop. Use the -d option to run KeyServer as a "daemon" process so it will continure to run even after the originating terminal is closed.

e <log-file-path>

KeyServer can optionally write some status messages to a separate log file, other than the KeyServer log (where program usage information is stored) and the system log (where startup and shutdown information is written). If you want a simple log of KeyServer's startups and shutdowns, specify the log's location using this option.

n <hostname>

When KeyServer is running on a multi-homed host (a host with more than one IP address assigned to it), it will open its service port on the default IP address. Use this option to force KeyServer to open its service port on a specific IP address.

z <zone>

When KeyServer is running on a multi-homed AppleTalk host (a host with more than one AppleTalk address assigned to it), it will open its service port in the default AppleTalk Zone. Use this option to force KeyServer to open its service port in a specific AppleTalk Zone.

In order for KeyServer to support clients over the AppleTalk protocol, you only need to have your Linux kernel configured to support AppleTalk. On most Linux distributions, this support is built in by default (although you must still set up things like the default zone, etc.) You do not need to be running netatalk daemons, although KeyServer will operate alongside these services.

To use the Unix Authentication method, KeyServer must run on Mac OS X or Linux.