5.1 Security Considerations for Implementers

  • Article

The Exchange Server NSPI Protocol is not suitable for general administration of the data held by a 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 Exchange Server 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, a server can apply local security policies. When applying these security policies, the 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 server is accessible to all clients of the Exchange Server 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 Exchange Server 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

  • PidTagAddressBookDisplayNamePrintable

  • 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 MUST create a secure RPC session such that the server can identify and determine the authorization for the client. For details about 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 is not constrained by the protocol.