5.1 Security Considerations for Implementers

  • Article

The NSPI Protocol is not suited for general administration of the data held by an NSPI server. It is suitable for client read access to data with limited modification of existing objects, not including address book container objects. Administration tasks the NSPI Protocol does not support include (but are not limited to) adding new objects to an address book, removing existing objects, and moving existing objects from one address book to another.

Beyond the basic support for address book browsing, an NSPI server can apply local security policies. When applying these security policies, an NSPI server can limit a client's access to data, either reading access and/or modification access. The simplest form of local security policy is the empty set; all data held by the NSPI server is accessible to all clients of the NSPI Protocol for both reading and modifying, regardless of the identity of the client. Local security policy is, with one exception, an implementation-specific detail and is not constrained by the NSPI Protocol. If local security policy allows a client read access to an object, the server is required to allow the client read access to the properties of the object specifying the objects identity. The following properties specify an object's identity:

  • PidTagTransmittableDisplayName

  • PidTagDisplayName

  • PidTag7BitDisplayName

  • PidTagEmailAddress

  • PidTagAddressType

  • PidTagInitialDetailsPane

  • PidTagInstanceKey

  • PidTagAddressBookContainerId

  • PidTagObjectType

  • PidTagContainerContents

  • PidTagContainerFlags

  • PidTagDisplayType

  • PidTagTemplateid

  • PidTagEntryId

  • PidTagMappingSignature

  • PidTagRecordKey

  • PidTagSearchKey

The protocol does not provide support for administration of local security policy or for client discovery of a server's security policy.

The protocol carries identity information from the client to the server in the form of an authenticated remote procedure call (RPC) connection. The client has to create a secure RPC session such that the server can identify and determine the authorization for the client. For information on secure RPC, see [MS-RPCE]. This requirement exists so that the server can implement its security model.

The server can use this information to apply local security policy. How the server uses this information is an implementation-specific detail and not constrained by the protocol.

Note: For information about whether and how local security policies are applied in the Microsoft implementation, and the limitations that result, see the following product behavior note:<16>