3.2 Preparing to Install the Identity Vault

Your environment for the Identity Vault must be configured appropriately. For example, the server must have a method (a service or specified file) that can be used to resolve tree names in Identity Vault to server referrals. This section helps you prepare your environment before you install the Identity Vault.

3.2.1 Using Escape Characters when a Container Name Includes a Period (“.”)

You can add a Windows server that has a period in the server name to a directory tree. For example, O=netiq.com or C=u.s.a. However, if the names of your containers in the tree include a period (“.”), you must use escape characters. Review the following considerations:

  • Do not use a period at the beginning of a server name. For example, .netiq.

  • Escape the period in the container name with a backslash (“\”). For example:

    O=novell\.com

    or

    C=a\.b\.c

Include the escape characters when you enter a dotted admin name and context for utilities such as iMonitor, iManager, DHost iConsole, DSRepair, Backup, DSMerge, DSLogin, and ldapconfig. For example, when logging in to iMonitor, if the name of the O in your tree is netiq.com, enter 'admin.netiq\.com' or admin.netiq\.com.

3.2.2 Using OpenSLP or hosts.nds for Resolving Tree Names

Before installing the Identity Vault infrastructure, the server should have a method (a service or specified file) that can be used to resolve tree names in Identity Vault to server referrals. NetIQ recommends using Service Location Protocol (SLP) services to resolve tree names. Previous versions of eDirectory included OpenSLP in the installation. However, starting with eDirectory 8.8, the installation does not include OpenSLP. You must separately install an SLP service or use a hosts.nds file. If you use an SLP service, the directory agents for the service (SLPDAs) must be stable.

This section provides the following information:

Using a hosts.nds File to Resolve Tree Names

The hosts.nds file is a static lookup table that Identity Vault applications use to search Identity Vault partitions and servers. It helps you avoid SLP multicast delays when SLP DA is not present in the network. For each tree or server, you must specify the following information in a single line in the hosts.nds file:

  • Server Name or Tree Name: Tree names should end with a trailing dot (.).

  • Internet Address: This can be a DNS name or IP address. Do not use localhost.

  • Server Port: Optional, appended with a colon (:) to the Internet address.

You do not have to include an entry for the local server in the file, unless the server listens on a non-default NCP port.

To configure a hosts.nds file:

  1. Create a new or open an existing hosts.nds file.

  2. Add the following information:

                      partition_name.tree_name. host_name/ip-addr:port server_name dns-addr/ip-addr:port
                    

    For example:

    # This is an example of a hosts.nds file:
    # Tree name Internet address/DNS Resolvable Name
      CORPORATE. myserver.mycompany.com
      novell.CORPORATE. 1.2.3.4:524
    
    # Server name Internet address
      CORPSERVER myserver.mycompany.com:524
  3. (Optional) If you later decide to use SLP to resolve the tree name and ensure that the Identity Vault tree is available on the network, add the following text to the hosts.nds file:

    /usr/bin/slptool findattrs services:ndap.novell///(svcname-ws==[treename or *])"

    For example, to search for the services whose svcname-ws attribute match with the value SAMPLE_TREE, enter the following command:

    /usr/bin/slptool findattrs services:ndap.novell///(svcname-ws==SAMPLE_TREE)"

    NOTE:Perform this action after you install SLP and the Identity Vault.

    If you have a service registered with its svcname-ws attribute as SAMPLE_TREE, then the output will be similar to service:ndap.novell:///SAMPLE_TREE. Otherwise, you will not receive an output response.

Understanding OpenSLP

OpenSLP is an open-source implementation of the IETF Service Location Protocol Version 2.0 standard, which is documented in IETF Request-For-Comments (RFC) 2608.

The interface provided by OpenSLP source code is an implementation of another IETF standard for programmatically accessing SLP functionality, documented in RFC 2614.

To fully understand the workings of SLP, it is worth reading these documents and internalizing them. They are not necessarily light reading, but they are essential to the proper configuration of SLP on an intranet.

For more information on the OpenSLP project, see the OpenSLP and the SourceForge websites. The OpenSLP website provides several documents that contain valuable configuration tips. Many of these are incomplete at the time of this document’s publication.

This section includes the following discussions about the use of SLP and how it relates to the Identity Vault:

NetIQ Service Location Providers

The NetIQ version of SLP takes certain liberties with the SLP standard in order to provide a more robust service advertising environment, but it does so at the expense of some scalability.

For example, in order to improve scalability for a service advertising framework, you can limit the number of packets that are broadcast or multicast on a subnet. The SLP specification manages this by imposing restrictions on service agents and user agents regarding directory agent queries. The first directory agent discovered that services the desired scope is the one that a service agent (and consequently, local user agents) will use for all future requests on that scope.

The NetIQ SLP implementation actually scans all of the directory agents it knows about looking for query information. It assumes a 300-millisecond round trip time is too long, so it can scan 10 servers in about 3 to 5 seconds. This doesn't need to be done if SLP is configured correctly on the network, and OpenSLP assumes the network is in fact configured correctly for SLP traffic. OpenSLP’s response timeout values are greater than that of NetIQ’s SLP service provider, and it limits the number of directory agents to the first one that responds, whether or not that agent’s information is accurate and complete.

User Agents

A user agent (UA) takes the physical form of a static or dynamic library that is linked to an application. It allows the application to query for SLP services. The user agent’s job is to provide a programmatic interface for clients to query for services, and for services to advertise themselves. A user agent contacts a directory agent to query for registered services of a specified service class and within a specified scope.

User agents follow an algorithm to obtain the address of a directory agent to which queries will be sent. Once they obtain an address of a directory agent (DA) for a specified scope, they continue to use that address for that scope until it no longer responds, at which time they obtain another DA address for that scope. User agents locate a directory agent address for a specified scope by:

  1. Checking to see if the socket handle on the current request is connected to a DA for the specified scope. If the request happens to be a multipart request, there may already be a cached connection present on the request.

  2. Checking its local known DA cache for a DA matching the specified scope.

  3. Checking with the local service agent (SA) for a DA with the specified scope (and adding new addresses to the cache).

  4. Querying DHCP for network-configured DA addresses that match the specified scope (and adding new addresses to the cache).

  5. Multicasting a DA discovery request on a well-known port (and adding new addresses to the cache).

The specified scope is “default,” if not specified. That is, if no scope is statically defined in the SLP configuration file, and no scope is specified in the query, then the scope used is the word “default”. It should also be noted that Identity Vault never specifies a scope in its registrations. If there is a statically configured scope, that scope becomes the default scope for all local UA requests and SA registrations in the absence of a specified scope.

Service Agents

Service agents take the physical form of a separate process on the host machine. The slpd.exe runs as a service on the local machine. User agents query the local service agent by sending messages to the loop-back address on a well-known port.

The service agent’s job is to provide persistent storage and maintenance points for local services that have registered themselves with SLP. The service agent essentially maintains an in-memory database of registered local services. In fact, a service cannot register with SLP unless a local SA is present. Clients can discover services with only a UA library, but registration requires an SA, primarily because an SA must reassert the existence of registered services periodically in order to maintain the registration with listening directory agents.

A service agent locates and caches directory agents and their supported scope list by sending a DA discovery request directly to potential DA addresses by:

  1. Checking all statically configured DA addresses (and adding new ones to the SA’s known DA cache).

  2. Requesting a list of DA’s and scopes from DHCP (and adding new ones to the SA’s known DA cache).

  3. Multicasting a DA discovery request on a well-known port (and adding new ones to the SA’s known DA cache).

  4. Receiving DA advertising packets that are periodically broadcast by DAs (and adding new ones to the SA’s known DA cache).

Since a user agent always queries the local service agent first, this is important, as the local service agent’s response will determine whether or not the user agent continues to the next stage of discovery (in this case DHCP-- see Step 3 and Step 4 in User Agents.

Directory Agents

The directory agent’s job is to provide a long-term persistent cache for advertised services, and to provide a point of access for user agents to look up services. As a cache, the DA listens for SAs to advertise new services, and caches those notifications. Over a short time, a DA’s cache becomes more full or more complete. Directory agents use an expiration algorithm to expire cache entries. When a directory agent comes up, it reads its cache from persistent storage (generally a hard drive), and then begins to expire entries according to the algorithm. When a new DA comes up, or when a cache has been deleted, the DA detects this condition and sends out a special notification to all listening SAs to dump their local databases so the DA can quickly build its cache.

In the absence of any directory agents, the UA will resort to a general multicast query that SAs can respond to, building a list of the requested services in much the same manner that DAs use to build their cache. The list of services returned by such a query is an incomplete and much more localized list than that provided by a DA, especially in the presence of multicast filtering, which is done by many network administrators, limiting broadcasts and multicasts to only the local subnet.

In summary, everything hinges on the directory agent that a user agent finds for a given scope.

Configuring SLP for the Identity Vault

The following parameters in the %systemroot%/slp.conf file control directory agent discovery:

net.slp.useScopes = comma-delimited scope list
net.slp.DAAddresses = comma-delimited address list
net.slp.passiveDADetection = <"true" or "false">
net.slp.activeDADetection = <"true" or "false">
net.slp.DAActiveDiscoveryInterval = <0, 1, or a number of seconds>
useScopes

Indicates which scopes the SA will advertise into, and which scopes queries will be made to in the absence of a specific scope on the registration or query made by the service or client application. Because Identity Vault always advertises into and queries from the default scope, this list will become the default scope list for all Identity Vault registrations and queries.

DAAddresses

Represents a comma-delimited list of dotted decimal IP addresses of DAs that should be preferred to all others. If this list of configured DAs does not support the scope of a registration or query, then SAs and UAs will resort to multicast DA discovery, unless such discovery is disabled.

passiveDADetection

Is True by default. Directory agents will periodically broadcast their existence on the subnet on a well-known port if configured to do so. These packets are termed DAAdvert packets. If this option is set to False, all broadcast DAAdvert packets are ignored by the SA.

activeDADetection

Is True by default. This allows the SA to periodically broadcast a request for all DAs to respond with a directed DAAdvert packet. A directed packet is not broadcast, but sent directly to the SA in response to these requests. If this option is set to False, no periodic DA discovery request is broadcast by the SA.

DAActiveDirectoryInterval

Represents a tri-state parameter. The default value is 1, which is a special value meaning that the SA should only send out one DA discovery request upon initialization. Setting this option to 0 has the same effect as setting the activeDADetection option to false. Any other value is a number of seconds between discovery broadcasts.

These options, when used properly, can ensure an appropriate use of network bandwidth for service advertising. In fact, the default settings are designed to optimize scalability on an average network.

3.2.3 Improving Identity Vault Performance

eDirectory, the underlying infrastructure for the Identity Vault, is I/O intensive application rather than being processor-intensive. Two factors increase performance of Identity Vault: more cache memory and faster processors. For best results, cache as much of the Directory Information Base (DIB) Set as the hardware allows.

While eDirectory scales well on a single processor, you might consider using multiple processors. Adding processors improves performance in areas such as user logins. Also, having multiple threads active on multiple processors improves performance.

The following table provides a general guideline for server settings, based on the expected number of objects in your eDirectory.

Objects

Memory

Hard Disk

100.000

384 MB

144 MB

1 million

4 GB

1.5 GB

10 million

2+ GB

15 GB

For example, a base installation of eDirectory with the standard schema requires about 74 MB of disk space for every 50,000 users. However, if you add a new set of attributes or completely fill in every existing attribute, the object size grows. These additions affect the disk space, processor, and memory needed. Also, requirements for processors depend on additional services available on the computer as well as the number of authentications, reads, and writes that the computer is handling. Processes such as encryption and indexing can be processor intensive.

3.2.4 Using IPv6 Addresses on the Identity Vault Server

Identity Vault supports both IPv4 and IPv6 addresses. You can enable IPv6 addresses when you install the Identity Vault. If you upgrade from a previous version, you must manually enable IPv6 addresses.

Identity Vault also supports Dual IP stack, Tunneling, and Pure IPv6 transition methods. It supports only the global IP addresses. For example:

  • [::]

  • [::1]

  • [2015::12]

  • [2015::12]:524

You must specify IPv6 addresses within square braces [ ]. To use hostname instead of an IP address, you must specify the name in the C:\Windows\System32\drivers\etc\hosts file and associate it with the IPv6 address.

To use IPv6 addresses on a Windows server, you must select the Enable IPv6 check box under IPv6 Preference during the installation. This option enables the NCP, HTTP, and HTTPS protocols for the IPv6 addresses. If you do not enable IPv6 addresses during the installation process, and then decide to use them later, you must run the setup program again. For more information, see Section 3.0, Installing the Identity Vault.

You can access iMontior over IPv6 addresses using the following link: http://[2015::3]:8028/nds.

3.2.5 Using LDAP to Communicate with the Identity Vault

When you install the Identity Vault, you must specify the ports that the LDAP server monitors so that it can service LDAP requests. As part of default configuration, the ports numbers for clear text and SSL/TLS are set to 389 and 636.

An LDAP Simple Bind requires only a DN and a password. The password is in clear text. If you use port 389, the entire packet is in clear text. Because port 389 allows clear text, the LDAP server services Read and Write requests to the Directory through this port. This openness is adequate for environments of trust, where spoofing does not occur and no one inappropriately captures packets. By default, this option is disabled during the installation.

The connection through port 636 is encrypted. TLS (formerly SSL) manages the encryption. A connection to port 636 automatically instantiates a handshake. If the handshake fails, the connection is denied.

NOTE:The installation program selects port 636 by default for TLS/SSL communications. This default selection might cause a problem for your LDAP server. If a service already loaded on the host server (before eDirectory was installed) uses port 636, you must specify another port. Installations earlier than eDirectory 8.7 treated this conflict as a fatal error and unloaded nldap. After eDirectory 8.7.3, the installation program loads nldap, places an error message in the dstrace.log file, and runs without the secure port.

During the installation process, you can configure Identity Vault to disallow clear passwords and other data. The Require TLS for Simple Bind with Password option discourages users from sending observable passwords. If you do not select this setting, users are unaware that others can observe their passwords. This option, which does not allow the connection, only applies to the clear-text port. If you make a secure connection to port 636 and have a simple bind, the connection is already encrypted. No one can view passwords, data packets, or bind requests.

Consider the following scenarios:

Require TLS for Simple Bind with Password Is Enabled

Olga is using a client that asks for a password. After Olga enters a password, the client connects to the server. However, the LDAP server does not allow the connection to bind to the server over the clear-text port. Everyone is able to view Olga's password, but Olga is unable to get a bound connection.

Port 636 Is Already Used

Your server is running Active Directory. Active Directory is running an LDAP program, which uses port 636. You install eDirectory. The installation program detects that port 636 is already used and does not assign a port number for the NetIQ LDAP server. The LDAP server loads and appears to run. However, because the LDAP server does not duplicate or use a port that is already open, the LDAP server does not service requests on any duplicated port.

To verify whether port 389 or 636 is assigned to the NetIQ LDAP server, run the ICE utility. If the Vendor Version field does not specify NetIQ, you must reconfigure LDAP Server for eDirectory and select a different port. For more information, see “Verifying That the LDAP Server is Running” in the NetIQ eDirectory Administration Guide.

Active Directory Is Running

When Active Directory is running and clear-text port 389 open, you can run the ICE command to port 389 and ask for the vendor version. The report displays Microsoft*. You then reconfigure the NetIQ LDAP server by selecting another port, so that the eDirectory LDAP server can service LDAP requests.

iMonitor can also report whether port 389 or 636 is already open. If the LDAP server is not working, use iMonitor to identify details. For more information, see “Verifying That the LDAP Server is Running” in the NetIQ eDirectory Administration Guide.