Publishing Services in Active Directory

Observe the following principles when publishing services:

• Create connection point objects when you install services so that a user with sufficient privileges is able to install the published service using that connection point.

• Restrict the service to the update at run time of existing connection point objects.

Regardless of the publishing method you choose, you must understand and allow for access restrictions on the directory in your installation procedure and at run time. The RpcNs and RnR APIs create connection points in the RpcServices and WinsockServices containers, respectively. These are located in the System container in each domain. Service-Connection-Point objects need to be created as children of the Computer object for the computer where the service is installed.

To create an object of any kind, the process that creates the object must have permission to create a child for the class and container in which the object is to be created. To remove an object, the process that deletes the object must have permission to delete a child for the class and container in which the object is to be deleted. Or, it needs to have permission to delete the object itself. To update a connection point, the process performing the operation must have permission to write to the properties of the object that need to be updated.

These permissions might not be available to a service account or computer account to create objects during installation of a service, but an administrator, or anyone with the necessary permission, can perform the installation. When installing a published service, set the protection on any connection point object to allow update by the service at run time. This allows the service to run with a minimally privileged account and still be able to maintain its connection point.

For more information about the publishing of services, see the MSDN link on the Web Resources page at https://windows.microsoft.com/windows2000/reskit/webresources .

The Service Connection Point (SCP) class is a base object class for use in publishing and locating services. SCP is intended for use in publishing client bindings. The properties defined for this class are sufficient for a service to publish the information that a client requires to be able to bind to an instance of the service. The clients of the service must have prior knowledge of how to interpret and use the binding attributes; Active Directory does not define usage. Services that need to publish additional information about themselves can extend the schema by subclassing the Service-Connection-Point, giving the subclass a distinct name that makes it easily recognizable. For more information about extending the schema, see "The Active Directory Schema" in this book.

A setup program (or installation option for the executable routine of the service) installs the service and creates a service account, if necessary, and the service connection point. At service startup, the service itself checks to ensure that the service connection point contains the correct binding information.

Multiple instances of a service can exist in a network. Each instance can have different capabilities. For example, different database servers might contain entirely different data, although they are all of the same kind of service, or service class .

In addition, services can be replicated. A replicated service has multiple instances that have identical capabilities. A client can connect to any copy of a replicated service and receive identical service. Active Directory is an example of a replicated service for which all domain controllers for a given domain store identical data and provide identical services. When you create a service connection point for your service, you need to consider by what method clients will locate it. If you will have multiple instances of the service, you must consider how the clients will distinguish the instance with the desired capabilities from similar instances with different capabilities.

The serviceConnectionPoint Attributes

The attributes defined for the serviceConnectionPoint class are sufficient for a service to publish the information that a client needs to be able to bind to an instance of the service.

The serviceConnectionPoint object has an attribute, the keywords multivalued attribute, that contains string values — keywords — that enable client applications to find service connection point objects for a specific type of service. This attribute is indexed and is replicated to the Global Catalog server. The service that publishes the service connection point needs to add each keyword as an individual element in the multivalued attribute.

For information about keywords and publishing your service connection points, see the MSDN link on the Web Resources page at https://windows.microsoft.com/windows2000/reskit/webresources .

Publishing with the RPC Name Service (RpcNs)

RPC services use the RpcNs API to publish themselves in a namespace; the Windows 2000 RpcNs APIs publish the RPC entries in Active Directory. Services create RPC bindings and publish them in the Active Directory namespace as named RPC Server entries with attributes. The attributes include the unique interface ID and a GUID that are known to clients. Clients can then search for RPC servers that offer the desired interface, import the binding, and connect to the server.

For information about RPC Name Service and Active Directory, see "Windows 2000 RPC Name Service and Integration with Active Directory" later in this chapter.

Publishing with Windows Sockets Registration and Resolution (RnR)

Windows Sockets services can use the RnR APIs to publish services and to locate those services. RnR publication occurs in two steps. The first step installs a service class that associates a GUID with a name for the service. The service class can hold service-specific configuration information. Services can then publish themselves as instances of the service class. After the services are published, clients can query Active Directory for instances of a given class using the RnR APIs, and select an instance to which to bind. When a class is no longer useful, it can be removed.