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:
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:
Create a new or open an existing hosts.nds file.
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
(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.
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:
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.
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:
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.
Checking its local known DA cache for a DA matching the specified scope.
Checking with the local service agent (SA) for a DA with the specified scope (and adding new addresses to the cache).
Querying DHCP for network-configured DA addresses that match the specified scope (and adding new addresses to the cache).
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 take the physical form of a separate process on the host machine. In the case of Windows, 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:
Checking all statically configured DA addresses (and adding new ones to the SA’s known DA cache).
Requesting a list of DA’s and scopes from DHCP (and adding new ones to the SA’s known DA cache).
Multicasting a DA discovery request on a well-known port (and adding new ones to the SA’s known DA cache).
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.
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.
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>
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.
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.
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.
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.
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.