Export (0) Print
Expand All

7 Appendix B: Product Behavior

The information in this specification is applicable to the following Microsoft products or supplemental software. References to product versions include released service packs:

  • Windows NT operating system

  • Windows 2000 operating system

  • Windows XP operating system

  • Windows Server 2003 operating system

  • Windows Vista operating system

  • Windows Server 2008 operating system

  • Windows 7 operating system

  • Windows Server 2008 R2 operating system

  • Windows 8 operating system

  • Windows Server 2012 operating system

  • Windows 8.1 operating system

  • Windows Server 2012 R2 operating system

Exceptions, if any, are noted below. If a service pack or Quick Fix Engineering (QFE) number appears with the product version, behavior changed in that service pack or QFE. The new behavior also applies to subsequent service packs of the product unless otherwise specified. If a product edition appears with the product version, behavior is different in that product edition.

Unless otherwise specified, any statement of optional behavior in this specification that is prescribed using the terms SHOULD or SHOULD NOT implies product behavior in accordance with the SHOULD or SHOULD NOT prescription. Unless otherwise specified, the term MAY implies that the product does not follow the prescription.

<1> Section 2.1: The NSPI server implementation in Windows 2000 Server and Windows Server 2003 enforces a target level of 5.0.

<2> Section 2.1: The NSPI server implemented on Windows Server apply local security policies. All versions limit access to data, both read and modification access, based on these security policies. All versions apply local security policies on a per property, per object, and per container basis, as outlined in section 5. These policies render some data inaccessible to some clients. All versions use the identity information from the RPC connection when applying security policies. These policies are not configurable or discoverable via the NSPI Protocol.

<3> Section 2.1: The NSPI servers implemented on Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 limit the maximum allowable RPC packet to be 13 megabytes.

<4> Section 2.2.10: The NSPI server implemented on Windows 2000 Server does not support the SortTypePhoneticDisplayName sort order.

<5> Section 2.2.10: The NSPI servers implemented on Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 support the SortTypePhoneticDisplayName sort order, but only for the LCID_JAPANESE LCID, and only when the server has been configured to do so. This is not configurable via the NSPI Protocol.

<6> Section 2.3.8.3: The NSPI server implemented on Windows Server allows an object's distinguished name (DN) to be modified. There is no mechanism for performing this modification via the NSPI Protocol. When an object's DN is modified, all versions of the NSPI server implemented on Windows Server continue to map Permanent Entry IDs containing the old DN to the original object.

<7> Section 2.3.8.3: The NSPI server implemented on Windows Server allow an object's DN to be modified. There is no mechanism for performing this modification via the NSPI Protocol. When an object's DN is modified, all versions of the NSPI server implemented on Windows Server continue to map Permanent Entry IDs containing the old DN to the original object.

<8> Section 3.1.1.2.3: The NSPI server implemented on Windows Server apply special handling to the string representations of the following properties when specified by the server to the client:

  • PidTag7BitDisplayName

    • This value is natively of type PtypString8. The NSPI server constructs this value as follows:

      1. If the server has a stored value for this property, the value is used.

      2. If step 1 did not yield a value, the server reads the value of the property with the Property ID 0x8202. This value is natively Unicode. The server converts this value to an 8-bit character representation in the codepage specified by the client. If the server can convert the Unicode representation to an 8-bit character representation without the use of any default characters, the converted value is used.

      3. If step 2 did not yield a value, the constant 8-bit character string "Unavailable" is used.

  • PidTagTransmittableDisplayName

  • PidTagDisplayName

    • These values are natively of type PtypString. The NSPI server constructs these values as follows:

      1. If the server has a stored value for this property, the value is used.

      2. If step 1 did not yield a value, the server obtains the value of PidTag7BitDisplayName and converts the 8-bit representation to a Unicode representation and uses the converted value.

      3. If the client requests the PtypString8 version of these properties, the server converts the Unicode representation to an 8-bit representation in the client's codepage. If the server can convert the Unicode representation to an 8-bit character representation without the use of any default characters, the converted value is used. Otherwise, the value of PidTag7BitDisplayName is used.

When these properties are specified by the client to the server, no such conversion is done. It is therefore possible for a client to read these properties from an object and then apply the value read as a restriction, and have the resultant set of objects returned from the server be empty.

<9> Section 3.1.1.2.5.1: The NSPI server implemented on Windows 2000 Server does not support locating a closest LCID. If the server does not support the explicit LCID specified by the client, the results of the string representation conversions are undefined. All comparing and sorting of strings is done using the protocol's required default LCID.

The NSPI servers implemented on Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 locate a closest supported LCID as follows:

  1. If the server supports the LCID specified by the client, the server uses that LCID. Otherwise

  2. The server removes any sublocale information from the LCID specified by the client. If the server supports the resultant LCID, the server uses that LCID. Otherwise

  3. The server uses the server's default LCID.

The LCID chosen by the server is not discoverable via the NSPI Protocol.

<10> Section 3.1.1.4.1: The NSPI server implemented on Windows 2000 Server does not support locating a closest LCID. If the server does not support the explicit LCID specified by the client, the results of the string representation conversions are undefined. All comparing and sorting of strings is done using the protocol's required default LCID.

The NSPI servers implemented on Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 locate a closest supported LCID as follows:

  1. If the server supports the LCID specified by the client, the server uses that LCID. Otherwise:

  2. The server removes any sublocale information from the LCID specified by the client. If the server supports the resultant LCID, the server uses that LCID. Otherwise:

  3. The server uses the server's default LCID.

The LCID chosen by the server is not discoverable via the NSPI Protocol.

<11> Section 3.1.1.4.2: For the NSPI server implemented on Windows Server, approximate positioning in tables (both in servicing client position requests and in reporting approximate numeric positions) has no upper bound on the possible error of the approximation. That is, the server cannot guarantee where in a table it has actually set current position when applying an approximate location received from the client. Also, it cannot guarantee that the approximate position reported to the client is accurate.

<12> Section 3.1.1.4.2: The NSPI server implemented on Windows 2000 Server does not support locating a closest LCID. If the server does not support the explicit LCID specified by the client, the results of the string representation conversions are undefined. All comparing and sorting of strings is done using the protocol's required default LCID.

The NSPI servers implemented on Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 locate a closest supported LCID as follows:

  1. If the server supports the LCID specified by the client, the server uses that LCID. Otherwise:

  2. The server removes any sublocale information from the LCID specified by the client. If the server supports the resultant LCID, the server uses that LCID. Otherwise:

  3. The server uses the server's default LCID.

The LCID chosen by the server is not discoverable via the NSPI Protocol.

<13> Section 3.1.4: The gaps in the opnum numbering sequence apply to Windows as follows.

Opnum

Description

15

Used only locally by Windows, never remotely.

<14> Section 3.1.4.1: The NSPI server implemented on Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 limits the number of simultaneous NSPI connections from a single client. The limit is not configurable or discoverable via the NSPI Protocol.

<15> Section 3.1.4.1: The NSPI server implemented on Windows 2000 Server always honors the fAnonymous flag for the NspiBind method.

The NSPI servers implemented on Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 can be configured to honor or ignore the fAnonymous flag. This setting is not configurable or discoverable via the NSPI Protocol.

<16> Section 3.1.4.1: When verifying an RPC client, all versions of the NSPI server implemented on Windows Server authenticate RPC clients by verifying the client's identity as a member of the Windows domains Authenticated Users well known group.

<17> Section 3.1.4.1: The NSPI server implemented on Windows Server uses a single GUID for multiple NSPI sessions for as long as the server can guarantee no object's Minimal Entry ID (MId) has changed. Modifications to the data stored in the NSPI server by mechanisms outside of the NSPI Protocol can result in the modification of an object's MId. These modifications can only take place while there are no active NSPI sessions.

<18> Section 3.1.4.3: The NSPI server implemented on Windows Server applies local security policies. The NSPI server limits access to data, for both read and modification access, based on these security policies. The NSPI server local security policies on a per-property, per-object, and per-container basis. These policies render some data inaccessible to some clients. The NSPI server uses the identity information from the RPC connection when applying security policies. These policies are not configurable or discoverable through the NSPI protocol.

<19> Section 3.1.4.4: The NSPI server implemented on Windows Server apply local security policies. The NSPI server limits access to data, for both read and modification access, based on these security policies. The NSPI server applies local security policies on a per-property, per-object, and per-container basis. These policies render some data inaccessible to some clients. The NSPI server uses the identity information from the RPC connection when applying security policies. These policies are not configurable or discoverable through the NSPI protocol.

<20> Section 3.1.4.5: The NSPI server implemented on Windows Server apply local security policies. The NSPI server limits access to data, for both read and modification access, based on these security policies. The NSPI server applies local security policies on a per-property, per-object, and per-container basis. These policies render some data inaccessible to some clients. The NSPI server uses the identity information from the RPC connection when applying security policies. These policies are not configurable or discoverable through the NSPI protocol.

<21> Section 3.1.4.6: The NSPI server implemented on Windows Server apply local security policies. The NSPI server limits access to data, for both read and modification access, based on these security policies. The NSPI server applies local security policies on a per-property, per-object, and per-container basis. These policies render some data inaccessible to some clients. The NSPI server uses the identity information from the RPC connection when applying security policies. These policies are not configurable or discoverable through the NSPI protocol.

<22> Section 3.1.4.7: The NSPI server implemented on Windows Server apply local security policies. The NSPI server limits access to data, for both read and modification access, based on these security policies. The NSPI server applies local security policies on a per-property, per-object, and per-container basis. These policies render some data inaccessible to some clients. The NSPI server uses the identity information from the RPC connection when applying security policies. These policies are not configurable or discoverable through the NSPI protocol.

<23> Section 3.1.4.8: The NSPI server implemented on Windows Server apply local security policies. The NSPI server limits access to data, for both read and modification access, based on these security policies. The NSPI server applies local security policies on a per-property, per-object, and per-container basis. These policies render some data inaccessible to some clients. The NSPI server uses the identity information from the RPC connection when applying security policies. These policies are not configurable or discoverable through the NSPI protocol.

<24> Section 3.1.4.9: The NSPI server implemented on Windows Server apply local security policies. The NSPI server limits access to data, for both read and modification access, based on these security policies. The NSPI server applies local security policies on a per-property, per-object, and per-container basis. These policies render some data inaccessible to some clients. The NSPI server uses the identity information from the RPC connection when applying security policies. These policies are not configurable or discoverable through the NSPI protocol.

<25> Section 3.1.4.10: The NSPI server implemented on Windows Server apply local security policies. The NSPI server limits access to data, for both read and modification access, based on these security policies. The NSPI server applies local security policies on a per-property, per-object, and per-container basis. These policies render some data inaccessible to some clients. The NSPI server uses the identity information from the RPC connection when applying security policies. These policies are not configurable or discoverable through the NSPI protocol.

<26> Section 3.1.4.11: The NSPI server implemented on Windows Server apply local security policies. The NSPI server limits access to data, for both read and modification access, based on these security policies. The NSPI server applies local security policies on a per-property, per-object, and per-container basis. These policies render some data inaccessible to some clients. The NSPI server uses the identity information from the RPC connection when applying security policies. These policies are not configurable or discoverable through the NSPI protocol.

<27> Section 3.1.4.12: The NSPI server implemented on Windows Server apply local security policies. The NSPI server limits access to data, for both read and modification access, based on these security policies. The NSPI server applies local security policies on a per-property, per-object, and per-container basis. These policies render some data inaccessible to some clients. The NSPI server uses the identity information from the RPC connection when applying security policies. These policies are not configurable or discoverable through the NSPI protocol.

<28> Section 3.1.4.13: The NSPI server implemented on Windows Server apply local security policies. The NSPI server limits access to data, for both read and modification access, based on these security policies. The NSPI server applies local security policies on a per-property, per-object, and per-container basis. These policies render some data inaccessible to some clients. The NSPI server uses the identity information from the RPC connection when applying security policies. These policies are not configurable or discoverable through the NSPI protocol.

<29> Section 3.1.4.14: The NSPI server implemented on Windows Server apply local security policies. The NSPI server limits access to data, for both read and modification access, based on these security policies. The NSPI server applies local security policies on a per-property, per-object, and per-container basis. These policies render some data inaccessible to some clients. The NSPI server uses the identity information from the RPC connection when applying security policies. These policies are not configurable or discoverable through the NSPI protocol.

<30> Section 3.1.4.15: The NSPI server implemented on Windows Server apply local security policies. The NSPI server limits access to data, for both read and modification access, based on these security policies. The NSPI server applies local security policies on a per-property, per-object, and per-container basis. These policies render some data inaccessible to some clients. The NSPI server uses the identity information from the RPC connection when applying security policies. These policies are not configurable or discoverable through the NSPI protocol.

<31> Section 3.1.4.16: The NSPI server implemented on Windows Server apply local security policies. The NSPI server limits access to data, for both read and modification access, based on these security policies. The NSPI server applies local security policies on a per-property, per-object, and per-container basis. These policies render some data inaccessible to some clients. The NSPI server uses the identity information from the RPC connection when applying security policies. These policies are not configurable or discoverable through the NSPI protocol.

<32> Section 3.1.4.17: The NSPI server implemented on Windows Server apply local security policies. The NSPI server limits access to data, for both read and modification access, based on these security policies. The NSPI server applies local security policies on a per-property, per-object, and per-container basis. These policies render some data inaccessible to some clients. The NSPI server uses the identity information from the RPC connection when applying security policies. These policies are not configurable or discoverable through the NSPI protocol.

<33> Section 3.1.4.18: The NSPI server implemented on Windows Server apply local security policies. The NSPI server limits access to data, for both read and modification access, based on these security policies. The NSPI server applies local security policies on a per-property, per-object, and per-container basis. These policies render some data inaccessible to some clients. The NSPI server uses the identity information from the RPC connection when applying security policies. These policies are not configurable or discoverable through the NSPI protocol.

<34> Section 3.1.4.19: The NSPI server implemented on Windows Server apply local security policies. The NSPI server limits access to data, for both read and modification access, based on these security policies. The NSPI server applies local security policies on a per-property, per-object, and per-container basis. These policies render some data inaccessible to some clients. The NSPI server uses the identity information from the RPC connection when applying security policies. These policies are not configurable or discoverable through the NSPI protocol.

<35> Section 3.1.4.20: The NSPI server implemented on Windows Server apply local security policies. The NSPI server limits access to data, for both read and modification access, based on these security policies. The NSPI server applies local security policies on a per-property, per-object, and per-container basis. These policies render some data inaccessible to some clients. The NSPI server uses the identity information from the RPC connection when applying security policies. These policies are not configurable or discoverable through the NSPI protocol.

<36> Section 4: When processing the NspiQueryRows method, the NSPI server implemented on Windows Server enforces time and size constraints, limiting the number of rows returned to be less than the number of rows requested, if the limits of the constraints are reached. These constraints are local policy and are not configurable or discoverable via the NSPI Protocol.

<37> Section 5.1: The NSPI server implemented on Windows Server apply local security policies. The NSPI server limits access to data, for both read and modification access, based on these security policies. The NSPI server applies local security policies on a per-property, per-object, and per-container basis. These policies render some data inaccessible to some clients. The NSPI server uses the identity information from the RPC connection when applying security policies. These policies are not configurable or discoverable through the NSPI protocol.

<38> Section 5.1: The NSPI server implemented on Windows Server apply local security policies. The NSPI server limits access to data, for both read and modification access, based on these security policies. The NSPI server applies local security policies on a per-property, per-object, and per-container basis. These policies render some data inaccessible to some clients. The NSPI server uses the identity information from the RPC connection when applying security policies. These policies are not configurable or discoverable through the NSPI protocol.

<39> Section 5.1: The NSPI server implemented on Windows Server apply local security policies. The NSPI server limits access to data, for both read and modification access, based on these security policies. The NSPI server applies local security policies on a per-property, per-object, and per-container basis. These policies render some data inaccessible to some clients. The NSPI server uses the identity information from the RPC connection when applying security policies. These policies are not configurable or discoverable through the NSPI protocol.

 
Show:
© 2014 Microsoft