If you see this message when trying to initialize NICI on a Windows platform, it typically means that NICI is not installed, or the NICI device (in 1.x device driver versions) is not running. If the NICI device is not running, you can try to run it by entering net start niciccs on a Windows NT/2000 console. If it fails, reboot the system. Otherwise, reinstall NICI.
This error is returned when a security domain key (such as a tree key) is not found on the system. The API is CCS_GetPartitionKey. See Section 4.0, NICISDI: Security Domain Infrastructure for more information.
This is an error in NICI’s internal random number generator as defined by FIPS 140. NICI will try to recover, and returns this error if it can’t. The solution is to retry, reload, or restart the application. We don’t anticipate this error will occur.
This error condition was introduced with the FIPS 140-certified NICI, and is present regardless of the certification level of NICI on platforms other than NetWare. Upon loading or being instantiated by a process, NICI runs a set of tests for module integrity as well as cryptographic process integrity. If one of these tests fails, NICI puts itself in an inoperable state and returns this error. The typical cause of this problem is module verification failure. The solution is to reinstall NICI, or to uninstall and then reinstall NICI.
This error was introduced in NICI version 2.0.1. The most likely cause is installation of a weak NICI version on a strong NICI installed base. The solution is to install strong NICI.
Novell is shipping the strong NICI worldwide, and stopped shipping the import-restricted version with limited key sizes. We don’t anticipate seeing this error anymore.
Similar to error -1497, this is usually caused by the lack of NICI license materials or configuration files. Reinstalling NICI typically solves the problem. If it does not, first try the following:
Delete the UNIX/etc/nici.cfg configuration file.
Reinstall NICI.
Remove the NICI registry key.
Reinstall NICI
Simply reinstalling NICI does not remove the registry keys.
If this doesn’t solve the problem and you won’t lose data by deleting the NICI configuration files and keys, do the following:
Delete the NICI configuration directory together with the registry on Microsoft Windows or the UNIX configuration file.
Reinstall NICI.
Typical causes:
Lack of NICI licensing materials (.nfk file copied to the nicifk file). NICI on servers (NetWare, DHost, or the equivalent environment on other platforms) must have a NICI foundation key file in order to initialize key materials. NICI license materials are part of a Novell eDirectory license. Earlier NetWare installs had the option of installing eDirectory without licenses, which basically disabled NICI. eDirectory 8.5 and later uses NICI for a variety of cryptographic functionality, so a simple upgrade from an earlier version of eDirectory to a newer version renders eDirectory unusable because of NICI. NICI does not operate without NICI licensing materials, or a proper configuration file. The solution is to install a license (this can be the same license), or copy the .nfk file from the license diskette to the nicifk file, then reboot the server or restart the DHost process.
Lack of or corrupted NICI configuration files, especially on NetWare servers. A corrupted NICI configuration file is not fixable; it must be deleted. An effort was made to minimize this problem starting with NICI version 1.3.x. It is less likely for this to occur with NICI 2.x or later.
Cryptography module downgrade.
On NetWare, all NICI modules are signed NLM programs, and they have the .xlm extension. These modules are loaded by xim.xlm, which is in turn loaded by xldr.xlm as part of server.exe execution. The XIM module verifies multiple digital signatures during XLM loading. NetWare abends if any of the signatures is invalid. This is intentional, and not a problem or a bug. It makes sure that the cryptographic and key management modules are not tampered with, and that the module integrity is in place. We have seen corrupted XLMs because of CD burner and other copying problems.
The NICI license materials file (nicifk) is also signed. An invalid license file renders NICI dysfunctional.
Even though this error was first reported during eDirectory 8.6.0 upgrade testing, this error is not unique to version 8.6.0. It was first reported in eDirectory 8.6.0 probably because servers are not rebooted during the Novell eDirectory version 8.6.0 upgrade, but eDirectory is restarted. The problem is duplicated in other environments by restarting eDirectory (without rebooting and allowing NICI to reinitialize) on servers listed in the W0 object.
Workarounds:
Avoid restarting eDirectory on the servers listed in the W0 object without also initializing NICI.
Restart the server identified by the W0 object before requesting the security domain key (A restart allows NICI to reinitialize, but you still need to be careful not to restart eDirectory).
Upgrade to NICI version 2.4 or later.