This page (revision-1) was last changed on 29-Nov-2024 16:16 by jeem

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links
NICI
NICI

Version management

Difference between version and

At line 1 added 71 lines
!!! Overview
[{$pagename}] is [Novell International Cryptographic Infrastructure] (NICI) is Novell's solution to a cross-platform, [policy] driven, independently certified, and extensible [Cryptographic] service.
[{$pagename}] with [Security Domain Infrastructure] is the [Cryptographic] module that provides [keys], [algorithms], various [Keystore] and usage mechanisms, and a large-scale [Key Management] system.
[{$pagename}] controls the introduction of algorithms and the generation and use of keys. [{$pagename}] allows a single commodity version of security products to be produced for worldwide consumption that supports strong cryptography and multiple cryptographic technologies. Initial services built on this infrastructure are Directory Services [eDirectory], [Novell Modular Authentication Service] ([NMAS]), [Novell Certificate Server], Novell [SecretStore]®, and [TLS]/[SSL].
[{$pagename}] first shipped with NetWare® 5.0. This document is provided to help resolve [{$pagename}] issues found in the field or during testing of various Novell or [third-party] products. A particular product may use [{$pagename}] directly or indirectly via another module (NLMTM, DLL, so, etc.).
%%warning
If certain [{$pagename}] [keys] are irrecoverably lost, even backed-up data might be useless, as without them there can be no [Decryption].
%%
!! [{$pagename}] Modules on [File Systems] [1]
[{$pagename}] Modules on [Linux]
* libccs2.so - is the [{$pagename}] shared object (.so) named libccs2.so. Typically, it is a symbolic link to the actual file named per [Operating System] and [version]. [{$pagename}] does not depend on [eDirectory] services to be installed.
* libniciext.so - is the [NICIEXT] and is shipped with [eDirectory] and provides [eDirectory] [applications] with [Session Key] [communication] and the [Server Storage Key] for common secured [Data Store|DataStore].
[{$pagename}] on [Microsoft Windows]
* ccswx64.dll (64-bit) or ccs.dll (32-bit) - is the [{$pagename}] is typically installed in the %windir%\system32 directory.
* niciextwx64.dlm - is the [NICIEXT] and is shipped with [eDirectory] and provides [eDirectory] [applications] with [Session Key] [communication] and the [Server Storage Key] for common secured [Data Store|DataStore].
!! [{$pagename}] [certificates]
The [Private Key] of the [certificates] is wrapped by [{$pagename}]. Therefore if the [NICI Configuration Files] are lost or corrupted the [certificates] can no longer be used. These certificates can be backed up as well. This task is performed by exporting the certificates to a PKCS#12 file (PFX). Detailed information on the procedure can be found in the [Certificate Server Administration Guide.|http://www.novell.com/documentation/crt33/|target='_blank']
Though the certificates are held in the eDirectory database and can be restored by restoring the database they are still tied to the server's NICI files. As an added protection, the exporting and safekeeping the certificates in a PFX file so the certificates can be restored to the server even if the [{$pagename}] files are different or to another server altogether since the private key is stored in the PFX file. The certificates would no longer wrapped by [{$pagename}], the certificate is now protected by a password.
What is or can be effected
If [{$pagename}] is lost and there is no backup of [{$pagename}] or the certificates
* Encrypted Replication policy - Novell Technical Support can be engaged to remote in and remove the Encrypted Replication policy.
* Encrypted attributes are wrapped via NICI in a server specific database key which is in turn wrapped in a server specific storage key both of which are held in the eDirectory database within FLAIM. If a server's NICI files are lost not only are these attributes' data lost but the database itself cannot be opened. Since the database storage key is generated when the server is upgraded to or installed with eDirectory 8.8 SP1 or higher the database cannot be opened regardless of whether the encrypted attribute functionality is being used or not.
* Add no servers to the Tree
* No passwords can be used or recovered.
! [{$pagename}] and [Licensing|License]
The [NICI Configuration Files] are [Digitally Signed] and partially [encrypted]. An invalid [license] file (NICIFK) renders [{$pagename}] nonfunctional.
!! [{$pagename}] Installation
Note that, [{$pagename}] does not require a special user to run, except during the installation.
For [{$pagename}] installation a privileged user who can install setuid programs [MUST] install [{$pagename}].
!! [EDirectory Multiple Instance]
We recommend running each instance of [eDirectory] on the same host with different user IDs to separate their [cryptographic] materials using the host system's security mechanisms.
Otherwise, the server based [Security Domain Infrastructure] [Private Key] will be the same for all instances.
! [NICISDI]
[NICISDI] stands for [{$pagename}] [Security Domain Infrastructure]. This module is responsible for managing domain keys, where a domain is typically defined as the whole tree. In the future, a directory partition or custom domains will be able to be defined.
Up to [{$pagename}] version 1.5.x, [{$pagename}] supports one single partition key, the partition being the whole tree. Starting with NICI version 2.0.1, NICI can manage multiple partition keys of varying strengths and algorithms. Such keys are called Security Domain keys.On NetWare®, Windows, and libniciext.so on UNIX platforms, the module manages security domain keys in coordination with NICI. Various other services rely on the availability on security domain keys, including but not limited to:
* SecretStore/Single-Sign-On,
* [PKI] - [Certificate] Server
* [NMAS] - which includes [Universal Password].
NOTE: The [NICISDI] module has nothing to do with the [SASDFM] module. [SASDFM] manages [Session Keys] between two boxes, typically between a client and a server. The modules are both loaded during autoexec.ncf processing on NetWare.
Security domain servers manage security domain keys. Any server can be configured as a security domain server. There can be multiple security domain servers in a tree. Security domain keys are not intended for clients.
One tree key is installed by an eDirectory installation. The tree key is created or retrieved from the security domain key server during the server installation.
! [NICI Version]
Need to know how to [NICI Determine What Version|NICI Version]
!! Category
%%category [eDirectory]%%
!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [Understanding the NICI Modules|https://www.netiq.com/documentation/edirectory-91/nici_admin_guide/data/b1haazi5.html|target='_blank'] - based on information obtained 2018-05-09-
This page (revision-1) was last changed on 29-Nov-2024 16:16 by jeemTop