Novell is now a part of Micro Focus

Understanding and Trouble-shooting Novell's Security Infrastructure

Articles and Tips: article

Marcus Gould
CNE, MCNE, CDE
Primary Support Engineer
Novell Technical Services
mgould@novell.com

01 May 2002


This AppNote provides information about Novell's security infrastructure, including the Public Key Infrastructure (PKI) and the Novell International Cryptographic Infrastructure (NICI). After a brief overview of basic security concepts, it offers tips and procedures for troubleshooting issues related to these network security components. (Because this AppNote was written in the U.K., it retains the British spelling used by the author.)


Topics

network security, NIKI, PKI, architecture, troubleshooting

Products

Novell International Cryptographic Infrastructure (NICI), Public Key Infrastructure Services (PKIS)

Audience

network administrators, support technicians

Level

intermediate

Prerequisite Skills

familiarity with basic security concepts

Operating System

n/a

Tools

none

Sample Code

no

Introduction

Novell's vision holds the promise of a world in which all types of networks work together to provide the power and flexibility organizations need to succeed in the Net economy. The benefits are to simplify the complexities of the Net, to securely extend and integrate applications and networks between companies, and to accelerate eBusiness transformations.

The products discussed in this AppNote are involved with delivering the "secure" part of this vision. Novell has combined best-of-breed security components from a variety of vendors with the ability to control policies and privileges for all Net resources. These provide a foundation for integrating business-critical information and automating intranet- and extranet-based business functions between trusted supply-chain partners. Using this secure foundation, users can connect, communicate, and collaborate from anywhere through the Internet.

This AppNote offers an overview of the Novell International Cryptographic Infrastructure (NICI) and Public Key Infrastructure (PKI), which will serve as a foundation for the troubleshooting methodologies which are also presented.

Overview of Novell's Security Infrastructure

This section provides a brief overview of basic security concepts such as cryptography, public/private keys, and certificates. If you are already familiar with these concepts, you can skip ahead to the troubleshooting section. For additional background information on these topics, visit Novell's security Web site at http://www.novell.com/info/security.

Cryptography and the Public Key Infrastructure (PKI)

Cryptography is the practise and study of encryption and decryption. Encryption refers to the action of transforming plaintext into a seemingly unreadable form (ciphertext) by applying a mathematical function (algorithm), part of which is held in a key. Decryption is the reverse: when ciphertext is transformed back into readable plaintext by a mathematical function using a key. Complex mathematics are used so that, without the right key, it is very difficult to figure out how to decrypt ciphertext-even if you know how it was encrypted!

A key is simply a long string of digits that, when pushed through a formula along with some data, encrypts that data into a form that cannot be understood by anybody who does not have the appropriate key to decrypt it. A key's strength is proportional to the number of binary bits that comprise the key file. Generally, the greater number of bits, the greater degree of security-depending on the algorithm used and whether the key is symmetric or asymmetric.

A symmetric key is one where the decryption key can be deduced from the encryption key, and vice versa (in fact, it is the same key). This is analogous to a conventional car key: you can use it to lock your car, but if a thief steals your key he can easily unlock your car. Thus symmetric keys are great as long as you keep them very safe. Popular symmetric key algorithms include DES, RC2, and RC4.

An asymmetric key is analogous to a combination lock. You can lock it, but unless someone knows the combination, it cannot be unlocked. Asymmetric keys come in pairs: a Private Key and a Public Key. One key can be used to encrypt, but a different one must be used to decrypt. By using these key pairs, how to decrypt cannot be worked out from analyzing how to encypt. This is the principle behind Public/Private Key encryption. One popular asymmetric key algorithm is RSA.

Novell's Public Key Infrastructure Services (PKIS) implementation uses Public/Private Key cryptography. PKIS is a Novell product component that allows you to request, manage, and store public key certificates and their associated key pairs in the eDirectory tree. It also allows you to establish a Certificate Authority that is specific to your organization. PKIS is a consumer of services provided by NICI.

Certificates

The whole PKI system relies on the widespread availability of Public Keys, which are used to encrypt and verify signatures. To prevent these keys themselves from being forged or tampered with, we use certificates. A certificate is much like a physical passport; it proves the identity of the holder and is issued by a trusted source. In the digital world, a certificate can belong to a user or a server. The certificate holds such information as the certificate owner, the Public Key, and the encryption algorithm it uses, which information can be used to encrypt or digitally sign data. The current standard for digital certificates is X.509 v3, and it is controlled by the Internet Engineering Task Force (IETF).

Certificate Authority (CA). In computer systems, if the same person creates two servers that interact, that person can set up a direct trust relationship. This is analogous to two individuals who already know each other and have established a personal trust relationship between themselves.

PKI requires access to users' public keys, but every user in an organisation can't be expected to know about everybody else. There has to be a method of proving that any given Public Key belongs to the person who claims it as theirs. One method is that any two users would trust each other because they both trust a third party who will vouch for both of them. This third party is known as the Certificate Authority (CA). The CA is analogous to a country's passport office. Because it is the only legitimate source for passports, the passport office is trusted and the documents it issues to individuals certify that the bearers are who they say they are.

Cross-Certification. The CA signs all the certificates and says they are trust- worthy. But how do you know that the CA itself is trustworthy? Consider the following logic that explains how Bob, a UK Immigration Officer, would trust Alice, a US tourist, whom he has never met before:

  • Bob trusts the UK government.

  • The UK government trusts the US government.

  • The US government issued Alice's passport.

  • Alice's passport has her photograph and signature on it.

  • Bob trusts Alice.

In this example, Bob doesn't have to make a decision as to whether or not to trust the US government. He trusts them because his own government trusts them. This is known as cross-certification. Cross-certification is actually an extended form of third-party trust in which two CAs can vouch for each other.

Certificate Chain and Root CA. With passports, there are various methods to prevent and detect forgery and tampering; for example, a photograph, signature, serial number, watermarks, and even the kind of ink used. In the digital world, one can ensure that a certificate has not been tampered with by using cross- certification. But how is this actually implemented in practice? And if a certificate becomes untrustworthy or out of date, how can it be revoked?

When a message is sent, it may include a hierarchy of certificates where one certificate certifies the authenticity of the previous one. At the very top of this hierarchy is a Root CA. For each pair of certificates, one validates the other by making sure the subject and issuer names match, the certificates are still valid, neither certificate is revoked, and the Public Key in the issuer's certificate validates signature on other certificate. The Root CA is self-signing. As there is nobody else to verify it, you can't authenticate the source of the signature, so you can only rely on the integrity of the certificate's contents. This means you just have to trust it, because somebody told you to, or because you agree with their published practices. For example, an employee of Novell would trust a Root CA Certificate issued by a Novell Root CA. An External CA is managed by a third party outside of your organization, such as Verisign, Entrust, and others.

The Security Domain Infrastructure (SDI). The Security Domain Infrastructure, or SDI, is initialized the first time any of the following products is installed into the tree:

  • NetWare 5.1

  • Novell Certificate Server 2.x

  • Single Sign-on v1.x

  • Novell Modular Authentication Services (NMAS)

The SDI has three main components:

  • Machine Unique CA and SDI Key. In order to encrypt and decrypt the Tree CA, Server Certificates, and User Certificates, each server's Machine Unique Certificate Authority uses the Security Domain Key (SDI Key) and its Unique Machine Key (which is generated from the NICI Foundation Key). One specific server (usually the first one to be installed with NetWare 5.1, Certificate Server, NMAS, or SSO) is the Security Domain Key Server.

  • Server Certificates. When browsing your tree, you may have seen objects with a class of NDSPKI:Key Material. These are Server Certificates. SSL CertificateDNS and SSL CertificateIP are two such server certificates created by default when you install the server. Also known as Key Material Objects (KMOs), Server Certificates are primarily used for secure communications over SSL.

  • User Certificates. With sufficient rights, users can create their own certificates. This essentially allows one user to distribute his or her own Public Key to various other users. That user can then send encrypted e-mails to other users and digitally sign these e-mails, which the recipients can verify as authentic.

Novell International Cryptographic Infrastructure (NICI)

NICI is not really a product in itself; rather, it is a base set of cryptographic services for NetWare 5.x and above. It includes a number of modules that provide security functionality, and a consistent interface that application developers can write to. Applications or services that use NICI services are called consumers. PKIS, eDirectory Secret Store, and NCP Packet Signatures are examples of NICI consumers.

NICI is designed to facilitate putting together a global network without having to worry about local cryptography laws. Different countries have different laws on such things as cryptography strength. Many regard encryption as a dual- or military-use technology or claim that criminals could use it cover up their activities. For this reason, governments place restrictions on encryption technology. The United States, for example, may not export any encryption to certain countries (Afghanistan, Cuba, Iran, Iraq, Libya, North Korea, Sudan, or Syria). France may not import or use any encryption with a key strength greater than 56 bits. Within the last few years, US export laws have relaxed somewhat and larger key sizes are now legitimately available for use.

NICI's modular approach allows the cryptography strength, or even the underlying algorithms, to be changed easily by Novell or by third parties. At no time do the applications or services that use NICI have to be changed, thereby simplifying network management. All you need is a slot in the relevant cryptography module and off you go. As laws or requirements change, NICI's modular architecture can be modified to suit, without any change to the applications using it and without even having to restart the server.

There is a potential drawback to NICI's building-block approach to cryptography. Suppose you are in a country where strong cryptography is not allowed, in which case the necessary modules for strong cryptography would not be supplied. It would be relatively simple for anyone to write their own cryptography module and plug it into the NICI architecture. This is known as "crypto-with-a-hole." The drawback is that countries such as the United States deem this type of system illegal to export.

NICI Architecture. NICI's logical architecture is depicted in Figure 1.

NICI architecture.

MABLE. MABLE stands for Module Authentication and Binding Library Extensions. When NICI initializes, its MABLE authenticates the upper part of NICI to the application by using a public key challenge-response mechanism. It then maintains a dynamic link between the two. Challenge-response is a technique whereby an individual is prompted (the challenge) to provide some private information (the response). It is analogous to scenes in spy stories where one spy (Bob) says, "The rain in Spain falls mainly on the plain" and the other spy (Alice) knows that only the real Bob will reply, "But the water in Majorca don't taste like how it oughta!"

With MABLE, the application can be sure that it is talking to the real NICI and not a forged one because as the binding process is continually running, the NICI modules cannot be changed once they have initialised. The digital signatures on the certificates that are built into each NICI module are checked before they are loaded to ensure that the modules are legitimate.

Keys Used by NICI. The following keys are all used by NICI and are created in a variety of key sizes, depending on where you are in the world:

  • Data Confidentiality and Integrity Keys. These keys are used to encrypt/ decrypt and sign/verify user data. They can be symmetric or asymmetric.

  • Key Management Keys. Sometimes keys themselves have to be sent to a different server or to a third party entity. Key Management Keys are used to encrypt other keys in order to protect them while they are in transit. They can be symmetric or asymmetric.

  • Key Archival Keys. All NICI modules are signed by Novell's NICI Module Signer (XIM.XLM) to ensure that they are genuine modules and not modified in order to get round local cryptography laws. The NICI Module Signer also generates the Key Archival Keys and keeps a copy for itself. When XMGR generates the server's machine-specific key sets, it makes an archive copy for disaster recovery purposes. This archive copy is encrypted using the Key Archival Public Key. Novell keeps the private key on its B3-rated system.

  • Public Key Certification Keys. The Public Key Certification Keys are used to sign and verify all the public key certificates that are generated by the local server's CA. Like the Key Archival Keys, Public Key Certification Keys are generated on Novell's B3 NICI Module Signer.

  • NICI Operational Keys. These keys are also generated on the Module Signer and embedded in the .XLM modules (XIM.XLM). NICI Operational Keys are used internally by NICI itself, for such things as signing and verifying NICI modules, policies, public key certificates, and the keys mentioned above.

A Quick Example of How NICI Works. As a quick example of how all of the NICI modules work together, here is the process that takes place when an application wants to encrypt some data.

  • The application asks to use the Data Encryption Service via the CCS API (XLIB).

  • XLIB asks an XMGR to encrypt the data.

  • XMGR checks to see what encryption policies are in place, which will determine what XENG to use: In the USA or Canada, it uses the U.S. & Canada XENG with key sizes up to 2048 bits; in the rest of the world, it uses the Import Restricted XENG with key sizes up to 512 bits; in areas where encryption is not allowed, it uses the Null XENG (which effectively plugs the "crypto-with-a-hole").

  • The appropriate XENG is used to encrypt the file according to whatever algorithm and key size is specified therein (if the XENG needs to use specific Operating System services, it will access these via XSUP).

  • The resulting encrypted file is passed back to the XMGR.

  • The XMGR passes this back to the application via the CCS API in the XLIB.

The "NICI Component Descriptions" section below describes each of these components in more detail.

NICI Component Descriptions

This section builds on the architectural information described above. It details the NICI components, including physical things such as files and logical things such as eDirectory objects.

Server Modules

The following server modules are involved with NICI. Note that the extension for NICI modules is XLM, not NLM. XLM modules have a NICI-signed loader to ensure that they are real Novell NICI modules and have not been tampered with or forged.

XIM.XLM. The XIM is part of the NLM Loader and ensures that only genuine NICI modules are loaded by checking their built-in digital signatures at load time.

Each NICI module's built-in certificates are signed by a NICI Module Signer that runs on a system held in a highly restricted area within Novell. This system has been evaluated by the US National Computer Security Center (NCSC) who have rated it at a B3 security level. (B3 is very high security. Only A1 systems are more secure, and the US government seems to have all of those!) Therefore, each module's sender can be identified and verified as Novell via the CA hierarchy. The root certificate is trusted by virtue of its being produced by the trusted NICI Module Signer. There's a great deal more math involved, with hashing and all sorts of cross-checking going on. But the important thing to know is that if a NICI module says it comes from Novell, it comes from Novell.

XIM.XLM is loaded from the DOS boot directory (typically C:\NWSERVER).

CCS.XLM (The XLIB). The XLIB is CCS.XLM, which stands for Controlled Cryptography Services. CCS is Novell's current generic XLIB, which provides most of the services that might be required. However, anyone can develop their own if they want (provided that it does not break import/export rules).

At the "top," CCS provides access to an API that applications can use, with calls such as: Encrypt/Decrypt, Create/Verify Certificate, and Generate Random Number. (This API is fully documented in the Novell Developer Kit (NDK), available for download at http://developer.novell.com.)

At the "bottom," CCS interfaces with the rest of NICI proper, specifically the XMGR module(s). CCS also provides the MABLE components.

Note: There is no XLIB.NLM in NICI. If you see an XLIB.NLM loaded on a server, it is actually part of the X-Windows GUI used by ConsoleOne!

CCS.XLM is loaded from the DOS boot directory (typically C:\NWSERVER).

XMGR.XLM. XMGR's main job (apart from marshalling requests to and from the XLIBs) is to enforce the NICI policies. These policies, which control exactly how the cryptographic algorithms therein can be used, are bound to the XENGs. When an XLIB makes a request, XMGR decides which is the appropriate algorithm to use and which cryptography engine (XENG) to call upon.

XMGR.XLM is loaded from the DOS boot directory (typically C:\NWSERVER).

XENGxxxx.XLM (The XENG). The XENG is the Cryptography Engine, and this is where the hard work is done. XENG provides the actual algorithms used and the cryptographic services (such as encryption, decryption, digital signature verification, and so on) that NICI can use. By default, NICI is supplied with multiple XENGs:

  • XENGNUL.NLM. This is the NICI Null XENG from Novell, which provides support for applications that depend on NICI. Such applications don't have to be rewritten for countries that cannot use cryptography. The actual module name is NULXENG.XLM (renamed to NOVXENG.XLM). This module will always be loaded. If XENGNUL.NLM is loaded, but not XENGUSC or XENGEXP, the server will run with no cryptography. (Novell's PKIS will not run with just the Null cryptography NLM installed.)

  • XENGEXP.NLM. This is the NICI worldwide (listed as "Import Restricted" in NetWare 6) XENG from Novell, and it includes XENGNUL. It allows cryptography to run with key sizes up through 512 bits. The actual module name is EXPXENG.XLM (renamed to NOVXENG.XLM).

  • XENGUSC.NLM. This is the NICI U.S./Canada (listed as "US/Worldwide" in NetWare 6) XENG from Novell, and it includes XENGEXP and XENGNUL. It allows cryptography to run with key sizes up through 2048 bits. The actual module name is DOMXENG.XLM (renamed to NOVXENG.XLM).

Simply renaming one of the xxxXENG.XLM files to NOVXENG.XLM allows the cryptography algorithms to be upgraded. To upgrade from Export to Domestic, simply copy DOMXENG.XLM (instead of EXPXENG.XLM) to NOVXENG.XLM and reboot. A server can be upgraded to a higher level of cryptography, but it cannot be downgraded.

The XENGs are effectively isolated from the rest of the operating system; access is available only via XMGR or XSUP.

The above modules (which must be renamed to NOVXENG.XLM) are loaded from the DOS boot directory (typically C:\NWSERVER).

XSUP.XLM. XSUP provides access to operating system functions. It is effectively an abstraction layer. If NICI were ported to a different OS platform (such as Windows NT or UNIX), only the XSUP would need to be rewritten. It also ensures that the interface to the XENGs is closed.

XSUP.XLM is loaded from the DOS boot directory (typically C:\NWSERVER).

SAS.NLM, SASDFM.XLM, SASI.NLM, and the SAS Service Object. The SAS Service Object identifies the NDSPKI:Key Material objects (server certificates) that belong to any given server. If anyone needs to know what KMOs a server created, they can look at the SAS Service Object.

SAS.NLM (Secure Authentication Services) is the module that actually implements and runs the SSL encryption protocol. SASDFM.XLM (SAS Data Flow Manager) sets up the session key for encryption between a client and server.

SASI.NLM is the SAS install routine. It performs the following tasks:

  • Creates the SAS Security Object

  • Creates the SAS Service Object

  • Links KMOs to the SAS Service Object (but does not re-create any KMOs)

  • Updates AUTOEXEC.NCF with the relevant LOAD lines (LOAD SAS and LOAD PKI)

Therefore, SASI can be used at any time to re-create or re-link any part of the SAS infrastructure.

Note: SASI.NLM is not provided with all versions of NetWare 5.x and its Service Packs. As of this writing, it ships with service packs NW50SP6a and NW51SP3.

PKI.NLM. PKI.NLM is the Novell Certificate Server. Remember that each server needs to be able to make its own certificates for internal use. Therefore, PKI.NLM needs to be loaded on every server, not just on the tree CA.

NICKSDI.XML. NICISDI.XLM is the NLM at the center of SDI Key management and distribution. In other words, it ensures that the tree key is available on the server you are communicating with.

eDirectory Objects

The following eDirectory objects are also involved with NICI.

Note: For these eDirectory objects, if LDAP clients access this class, the LDAP server must map this class to a name that does not contain spaces or colons.

The Security Container. The SAS:Security Object (also known as the Security Container) identifies a container object that holds tree-wide security configuration information, such as the DN of the tree's Organisational CA. It also contains other security objects, which are detailed in later sections. This Security Container must always be named Security and must exist under [Root] in the tree. It must not be renamed or moved. Obviously, there can't be more than one of them. In a WAN environment, replicas of the partition containing this object need to be widely distributed.

Organisational CA Object. This object defines the Certificate Authority (CA) for the entire eDirectory tree. The Host Server attribute contains the distinguished name of the NCP server that hosts the Certificate Authority Service (PKI.NLM). This attribute was added for NetWare 5. NDS/eDirectory 8 replaces this class with the pkiCA class.

Trusted Root Object. This is a container object for holding Trusted Root Certificate Objects from a Certificate Authority that is trusted.

Trusted Root Certificate Object. This object holds a Trusted Root Certificate from a Certificate Authority that is trusted. These Trusted Root Certificates could have been minted by anyone: the tree's Organisational CA itself, an external CA, or even certificates exported by users. But the bottom line is, if they're here, they're implicitly trusted by whoever uses them.

KAP Object. The Key Access Partition (KAP) object contains the Key objects for the Security Domain. The default Key Object is W0.

NICI SDI Key and W0 Object. The Security Domain Key (NICISDI.KEY), which is shared among all the servers, is at the heart of the Security Domain Infrastructure (SDI). The SDI Key is created, encrypted, and stored on that server's local hard disk in the SYS:SYSTEM\NICI directory. This server is known as the Security Domain Key Server. Its job is to distribute the Security Domain Key to other servers that need it but don't already have it. The SDI Key is used in many encryption operations. All servers in the tree must have the same SDI Key so that any server that holds a replica of the User object can decrypt the data for the user. This is why you must never change the SDI Key or allow different versions in the tree.

When the second (and all subsequent) instance of one of the above products is installed into the tree, it asks the first server (which it knows about through the W0 object) for a copy of the Security Domain Key. This is how all servers obtain the same key.

In addition, the W0 Key List Object (also known as the NDSPKI:SD Key List) is created in the tree and points to the server that holds the Security Domain Key. The W0 object does not hold any information about the key itself, just the DN of the server where it is held.

Files and Certificates

Several other files and certificates are involved with NICI, as listed in this section.

NICI Foundation Key, License File, and Other Hidden NICI Files. The NICI Foundation Key (NICIFK.NLM) is created from files on the License Disk. In normal operation, you should never see the NICIFK file on a server's hard disk, unless you are recreating it manually:

  • With MLA Licenses, rename and copy xxxxxxxx.NFK to SYS:\SYSTEM\ NICIFK.

  • With non-MLA Licenses, use the Install Licenses option in NWCONFIG.

NICIFK is a Foundation Key seed; this is what's mathematically known as a unique highentropy random value. (Again, you don't need to worry about the math. Just know that this seed is needed because computers are not very good at truly random behaviour. Without such a seed, it is possible that two machines could generate the same random number.)

During the boot process, XMGR.XLM scans for SYS:SYSTEM\NICIFK. If it is present, it creates a number of files and then deletes the NICIFK file itself. The five files created in this process are:

  • SYS:\_NETWARE\XMGRCFG.INF

  • SYS:\_NETWARE\XMGRCFG.DS0 (or .KS0 if MLA licenses are used)

  • SYS:\_NETWARE\XMGRSEED.INF

  • SYS:\SYSTEM\NICI\XMGRCFG.DS1 (or .KS1 if MLA licenses are used)

  • SYS:\SYSTEM\NICI\XARCHIVE.000

These files comprise the Machine-Specific Key, other base keys, the seed for random number generation, and critical information that can be used to try to recreate the security configuration in the event of a disaster-assuming they have been backed up! NICI will load only when these files are present.

In NetWare 6, all of the above NICI files are stored in the SYS:SYSTEM/NICI directory, which means they can be backed up just like any other files.

Warning: Machine-Specific Keys are used in the generation of certificates. If NICIFK is replaced, so will the Machine-Specific Keys. Thus, certificates minted by the server using the previous keys will no longer be usable!

Key Material Objects (Server Certificates). Key Material Objects (KMOs) are the same thing as Server Certificates. A KMO is an object that stores the following information:

  • Public Key

  • Private Key

  • Public Key Certificate

  • Certificate Chain

Two KMOs are created by default: SSL CertificateDNS and SSL CertificateIP. These are the certificates used by LDAP or Web servers to ensure secure client-server SSL communications.

Admin-equivalent users can create as many Server Certificates as they want for use with products such as Novell BorderManager and other security applications. Remember that KMOs are server-specific-you can't create a KMO on one server and use it on another server.

User Certificates and Certificate Console. Normally the network administrator creates User Certificates with ConsoleOne. The certificates are stored as part of the User object itself. Users can create their own certificates using the Novell Certificate Console (see Figure 2). This utility can be installed on a workstation by running SETUP.EXE from SYS:PUBLIC\mgmt\CertConsole.

Creating a user certificate in the Novell Certificate Console.

In order to create certificates, users must have the following rights:

  • Read to the attribute NDSPKI:Private Key on the Organisational CA object

  • Read and Write to the attribute NDSPKI:userCertificateInfo on the User object

  • Read and Write to the attribute SAS:SecretStore on the User object

  • Read and Write to the attribute userCertificate on the User object

Once users have a certificate, they can export it as a file and access their public and private keys which they can then use to encrypt or sign e-mails. User Certificates can also be downloaded (exported) via ConsoleOne.

The Big Picture

How do these NLMs, files, and objects all fit together? Figure 3 shows where all of these components are located and the relationship between them. It is not a flow diagram!

Location of and relationships between NICI components.

Troubleshooting NICI and PKI Issues

First-time installation of all the products mentioned in this AppNote is a simple, wizard-driven affair, so there is no real value in covering that here. However, here are a few things to keep in mind:

  • Security is not just about data. One of the most important, yet most neglected, aspects is physical security. It doesn't matter what level of encryption you have if somebody has physical access to the server and can steal the hard disk containing raw data.

  • Similarly, encrypted e-mail transmitted over SSL is worthless if you have a lax password policy that allows an outsider to easily discover user passwords. Once passwords are compromised, intruders can just log in and read confidential e-mail messages straight from users' mailboxes.

  • The current architecture of NICI and PKI relies on a single server. This can be regarded as a single point of failure, as the server could become unavailable for reasons such as hardware failure, software failure, network failure, sabotage, and so on. You would do well to ensure that your Certificate Server is on a dedicated server that is fault-tolerant and is in a physically secure location.

Beware the Domino Effect

It should be reasonably clear by now that there are many interdependencies in a NICI-based network. Therefore, you need to be aware of what will result from any diagnostic or remedial action you take. Just the simple act of "rebuilding" a server could cause problems across the entire network.

For example, the Security Domain Key (NICISDI) is a single entity from a single source that is used in all user certificate operations on the network. If you lose or change this key, all user certificates could end up useless. At best, you will have to re-create your certificates; at worst, you will be unable to decrypt previously- encrypted data.

Before changing or removing a component, review the component information in this AppNote to ensure that you understand the consequences. Don't just charge in and start reinstalling things!

General Troubleshooting

Identifying problems with NICI starts off just like any other troubleshooting exercise. You should first determine the answers to basic questions such as:

  • Has the system ever worked or is it a new installation?

  • Is the problem random or predictable?

  • What is the scope of the problem: the entire network/tree, a server, a segment, a workstation, or a user?

  • What was happening at fail-time, and what has changed recently?

  • Have the latest versions and software patches been applied? (Generate a CONFIG report to help determine this.)

  • What is the general health of the system? (Check by running utilities such as Vrepair and DSRepair, and by performing standard network checks.)

NICI-Specific Troubleshooting

From here on, you should investigate the following NICI-specific issues.

  • Check NICI and PKI objects with ConsoleOne (use DSBrowse for a server-centric view):

    • Verify that the W0 Object exists and points to the Security Domain Key Server.

    • Verify that the SAS Security, SAS Service, and KMO objects exist.

    • Verify that the SAS Service object correctly points to its Host Server and KMO objects.

    • Verify that the Organizational CA object correctly points to the SAS Security Object and Host Server.

  • Verify that the NICI and PKI modules are actually loaded (use the MODULES console command with wildcards, such as MODULES PKI* and so on).

  • Obtain a CONLOG report of the server booting up and check it for error messages. (Some error messages occur only at boot-time; some are displayed before you can load CONLOG, so you'll have to watch the server to catch those.)

  • Check for expiration or revocation of certificates via ConsoleOne.

  • Verify that the necessary key files exist (you may need to use NetBASIC or similar utility to see hidden files):

    • SYS:\_NETWARE\XMGRCFG.DS0 (or .KS0 if MLA licenses are used)

    • SYS:\_NETWARE\XMGRCFG.INF

    • SYS:\_NETWARE\XMGRSEED.INF

    • SYS:\SYSTEM\NICI\XMGRCFG.DS1 (or .KS1 if MLA licenses are used)

    • SYS:\SYSTEM\NICI\XARCHIVE.000

    • SYS:SYSTEM\NICI\NICISDI.KEY

      Note: SYS:SYSTEM\NICIFK should not exist immediately after a reboot.

  • Check for correct cryptography strength using the MODULES XENG* console command. Remember that cryptography strength on a server can not be downgraded, only upgraded.

Deleted or Corrupted eDirectory Objects

If one of the necessary eDirectory objects is deleted (or becomes corrupted and has to be deleted), the following sections detail how to re-create them. Where possible, use the Organizational CA object, W0 object, and SAS Service objects to understand your infrastructure.

KMO (Server Certificate) Objects. If a KMO object needs to be replaced, re-create it with ConsoleOne. Remember that KMOs are server-specific and must be recreated for the correct server. Anything that used the deleted KMO will need to obtain the new one.

SAS Service Object. The SAS Service Object can be re-created by using SASI.NLM.

SAS Security Object. The SAS Security Object can be re-created by using SASI.NLM. Bear in mind that if this object is replaced, you will need to recreate the KAP and W0 objects.

KAP and W0 Objects. Before proceeding here, it is imperative to determine whether NetWare 5.1, Novell Certificate Server 2,x, Single Sign-On v1.x, or Novell Modular Authentication Services were installed into the tree after W0 was deleted. If they have, another server will have a copy of NICISDI.KEY.

Scenario 1 - No Products Installed After Deleting W0

If none of the products listed above has been installed, first try to restore W0 from a backup. If that is not possible, use ConsoleOne to carry out the following steps:

  1. Find a server on which NICISDI.KEY exists (the server which hosts the Organizational CA is a good place to start). This server will become the Security Domain Key Server.

  2. In the Security Container, create an NDSPKI:SD Key Access Partition container named KAP (if it doesn't already exist).

  3. In the KAP Container, create an NDSPKI:SD Key List object named W0.

  4. Add an attribute named NDSPKI:SD Key Server DN (under the Other tab) and browse to the server identified in the first step.

Scenario 2 - Products Installed After Deleting W0 or No Other Servers Have a Copy of NICISDI.KEY

If the KAP and W0 objects don't already exist, they will be created when you install one of the products listed above. If KAP and W0 did exist but were deleted, creating new ones in an uncontrolled way is bad because of the following:

  • The original Security Domain Key Server creates and distributes the original SDI Key to all other servers.

  • The new Security Domain Key Server creates and distributes the new SDI Key to all other servers subsequently installed, as well as having a copy itself.

  • Eventually the tree will consist of servers with mismatched keys and decryption will succeed or fail depending on which server is involved.

Note that the Security Domain Key only affects user data and not the Organisational CA, Key Material Objects, and so on.

If you could be 100% certain that none of the original servers had been involved in encrypting anything, you could just delete the SDI Key from all of them and reinstall one of the above products so that they obtain the new key. However, it is unlikely that you could ever be absolutely sure! Follow these steps instead.

  1. Check all User objects in the tree and delete the following attributes:

    • Certificates created by Novell Certificate Server

    • User Secrets created by Single Sign-On

    • Authentication Data created by Novell Modular Authentication Services

  2. Delete the W0 object.

  3. Delete NICISDI.KEY from all servers in the tree. The SDI Key should only exist on servers with one of the above products installed; however, you should still check that it is removed from all servers in the tree. Make a note of which servers you removed the key from and which products they were running.

  4. Install a new instance of one of the products listed above. Certificate Server is a good choice-except for the changes we want it to make here, it is reasonably unobtrusive, quick to install, and can be installed on an existing server.

  5. Reinstall the products on the servers from which NICISDI.KEY was deleted. They will get their new key from the server created in the previous step.

  6. Recreate the attributes you deleted in the first step.

Organizational CA Object. Do not attempt to recreate the Organizational CA until you are certain that you have a good Security Domain Key Server and that the W0 Object correctly points to it. Then follow these steps.

  1. Make a detailed note of all the details from all Server Certificates (KMOs) that were signed by the Organizational CA. Then delete these objects.

  2. Make a detailed note of all the details from all User Certificates that were signed by the Organizational CA. Then delete these certificates.

  3. Reinstall the Certificate Server product for that server. It is not possible to merely recreate the object as it has public and private keys associated with it.

  4. Using the detailed notes made previously, recreate the deleted Server Certificates using ConsoleOne. (Reinstalling Certificate Server only recreates SSLCertificateIP and SSLCertificateDNS.)

  5. Using the detailed notes made previously, replace the deleted User Certificates with ConsoleOne. (Remember to tell the users that their certificates have changed.)

  6. Any users who imported the original Organizational CA's certificate into their browsers as a trusted root must delete that certificate and replace it with the self-signed certificate of the new Organizational CA.

Server Object. The only way to recreate a deleted server object is to remove eDirectory from that server and reinstall it. The side effect of this is that the Security Objects will subsequently all be disabled. Remember, NICI configuration details are held on SYS:SYSTEM\NICI and in the hidden SYS:_NETWARE directory. Removing and reinstalling eDirectory has no effect on these files, but the loss of an entire server or SYS volume will. If it is likely the NICI files have been lost, see "SYS Volume (Physical Server)" below.

Some procedures require some attributes to be edited directly; however, it is not possible to edit certain attributes unless ConsoleOne is loaded without the security snap-ins. The following procedure effectively disables the security snap-ins. Note that <ConsoleOne Root> is wherever ConsoleOne is installed (for example, SYS:\PUBLIC\mgmt\ConsoleOne\1.2).

  • If it exists, rename <ConsoleOne Root>\SNAPINS\REGISTRARS.SER to REGISTRARS.SAV.

  • Rename <ConsoleOne Root>\SNAPINS\SECURITY\PKI.JAR to PKI.SAV.

  • Attributes will now be listed under the Other tab and can be edited. If the attributes do not exist, they can be added.

  • Remember to rename the modules back to their original names when your task is completed!

The following steps assume that the replaced Server object has been deleted and recreated (that is, eDirectory was removed and replaced):

  1. (This must be the first step.) If the replaced server object was the Security Domain Key Server, edit the W0 object's NDSPKI:SD Server DN attribute to point to the correct server. If the replaced server object was the Organisational CA, edit the Organisational CA's Host Server attribute to point to the correct server (this requires the security snap-ins to be disabled).

  2. If the replaced Server object had Server Certificates (KMOs), edit the KMO's Host Server attribute to point to the correct server (this requires the security snap-ins to be disabled).

  3. Link the SAS Service Object back to the replaced server. Edit the SAS Service object's Host Server attribute to point to the correct server (this requires the security snap-ins to be disabled).

SYS Volume (Physical Server). If the SYS volume fails, it will take the NICI- specific files, license file, and other hidden NICI files with it. To recover from this, first remove the Server Object and clean up the replica rings. Then follow the appropriate procedure below.

  • If the failed server was the Security Domain Key Server, find another server on which the NICISDI.KEY exists. This server will become the new Security Domain Key Server. Edit the attribute named NDSPKI:SD Key Server DN (under the Other Tab) and browse to the server identified as having the key.

  • If the failed machine was the only Security Domain Key Server in the tree, delete the KAP and W0 objects and follow the procedure outlined in Scenario 2 above for recreating them.

  • If the failed server was the Organizational CA and was not recreated in the previous step, delete the Organizational CA Object and reinstall the Certificate Server.

Directory Services. The loss of Directory Services from a server is dealt with the same way as the loss of a Server object, as described above.

Deleted or Corrupted Files

If one of the following files is deleted or becomes corrupted and has to be deleted, the following sections detail how to recreate them.

*.XLM Files. Since none of the .XLM modules are server-specific, they can be replaced by copying them from a backup, from a known good server, or from the product CD-just ensure you have the right versions. The NOVXENG.XLM file in the server's DOS directory (usually C:\NWSERVER) is a copy of one of the region-specific XENGs; you should replace like-with-like. If you accidentally upgrade cryptographic strength, you will not be able to downgrade it.

PKI.NLM, SAS.NLM and SASDFM.NLM. Since none of these modules are server-specific, you can copy them from a backup, from a known good server, or from the product CD. Make sure you have the right versions!

Hidden and Key Files. The following Machine Specific CA files cannot be recreated with the same contents; they can only be regenerated with new, different contents:

  • SYS:\_NETWARE\XMGRCFG.DS0 (or .KS0 if MLA licenses are used)

  • SYS:\_NETWARE\XMGRCFG.INF

  • SYS:\_NETWARE\XMGRSEED.INF

  • SYS:\SYSTEM\NICI\XMGRCFG.DS1 (or .KS1 if MLA licenses are used)

  • SYS:\SYSTEM\NICI\XARCHIVE.000

To recreate these files, copy the xxxxxxxx.NFK file from a license disk to SYS:\SYSTEM\NICIFK and reboot the server.

Note: If these files become badly corrupted, they sometimes must be manually deleted before you can re-create them. This can be done with NRepair (see TID 2958511), NetBASIC, or a similar utility.

Once you have re-created these files, any Server Certificates (KMOs) created on that server need to be recreated. If the server on which these files were recreated was the Organisational CA, information encrypted by that CA can no longer be decrypted. You will also need to re-request the Security Domain Key, as the previous one will have been encrypted using the old version of the above files.

SYS:SYSTEM\NICIFK. The only time this file is supposed to exist is immediately after it has been created from the license disk and before the server is rebooted.

Security Domain Key (NICISDI.KEY). The NICISDI.KEY file is distributed around servers that require it by the Security Domain Key Server. If this file becomes corrupt or inconsistent throughout the tree, carry out the appropriate procedure below.

Scenario 1 - From Security Domain Key Server

An Organisational CA must already exist for this procedure to work.

  1. Re-create the NICISDI.KEY file by using INITSDI.NLM (these commands are case-sensitive).

    Syntax:     INITSDI -new <log file> <error file>

    Example: INITSDI -new sys:system\nici\initsdi.log sys:system\nici\initsdi.err

    INITSDI does not return any feedback to the screen. If the log file contains a "0", the procedure was successful.

  2. You must copy the new NICISDI.KEY to all the other servers, as described in Scenario 2 below.

Scenario 2 - From Any Other (Non-SDI Key) Server

An Organisational CA must already exist for this procedure to work.

  1. Copy the NICISDI.KEY file from the Security Domain Key Server by using INITSDI.NLM (these commands are case-sensitive).

    Syntax:     INITSDI -get <log file> <error file> <SDI Server DN> <tree name>

    Example: INITSDI -get sys:system\nici\initsdi.log sys:system\nici\initsdi.err .srv1.uk.emea secure_tree

    INITSDI does not return any feedback to the screen. If the log file contains a "0", the procedure was successful.

  2. INITSDI does not return any feedback to the screen. Check to see that the log file contains a "0", which means the procedure was successful.

Note: An alternative method of replacing NICISDI.KEY is described in "KAP and W0 Objects" above. The methods described here only replace the file; none of the eDirectory objects are updated.

Rebuilding PKI Objects with PKIDIAG.NLM

PKIDIAG.NLM is a tool available from Novell that allows parts of the PKI to be reconstructed as per the following information (taken from TID 2961343):

  • Verify the Link to the SAS:Service Object. This option checks that either a link exists, or an object with the correct naming scheme exists, in the container. If the link exists, it checks the name. If the name exists, it fixes the link. If neither exists, it creates the object and links it.

  • Verify the SAS:Service Object. This option checks the link from the SAS:Service to the host server and gives rights, if necessary.

  • Verify the Link to the KMO Objects. This option checks that the names are correct, and moves or renames them if needed.

  • Verify the KMO Objects. This option checks all of the KMOs in the container to see if the server can use the key. If a KMO is linked to a different server, it just logs that and goes on. If the KMO is linked to this server, it makes sure that this server can use it; if not, it unlinks it. If a KMO is unlinked and this server can use it, it links it (and also checks the name).

  • Verify the SSL Certificates. This option checks to see if the SSLCertificateIP and the SSLCertificateDNS exist. If they don't, it creates them. If they do, it checks to see if their subject names match the current default IP and DNS names of the server. If not, the user is given the choice to either leave things alone, rename and replace the existing objects, or re-key the existing objects. It also verifies the validity dates, and gives the user the same three options if they are out of date or nearly out of date.

Conclusion

This AppNote has presented both conceptual and practical information to help you understand and troubleshoot issues relating to Novell's PKI and NICI security infrastructures. For more information, refer to the following AppNotes:

  • "Taking Advantage of NetWare's Public Key Infrastructure with Novell Certificate Server 2.0" - January 2000 (http://support.novell.com/techcenter/articles/ana20000105.html)

  • "Assessing the Business and Technical Aspects of Public Key Infrastructure Deployment" - October 1998 (http://support.novell.com/techcenter/articles/ana19981004.html)

  • "New Security Features in NetWare 5" - September 1998 (http://support.novell.com/techcenter/articles/ana19980906.html)

Other Useful References

The following are some of the many references that may be helpful as you try to understand and troubleshoot security-related issues:

  • Novell documentation (http://www.novell.com/documentation/)

  • Novell TIDs - search the Knowledgebase for security-related topics (http://support.novell.com)

  • Entrust "Security 101" paper (http://www.entrust.com/security101)

  • RSA Labs Cryptography FAQ (http://www.rsasecurity.com/rsalabs/faq)

* Originally published in Novell AppNotes

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Copyright Micro Focus or one of its affiliates