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 updates to those products.

  • 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

  • Windows 10 operating system

  • Windows Server 2016 operating system

  • Windows Server operating system

Exceptions, if any, are noted in this section. If an update version, service pack or Knowledge Base (KB) number appears with a product name, the behavior changed in that update. The new behavior also applies to subsequent updates 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 1.7: The only capability currently versioned in Windows is the ability to batch multiple requests into a single client/server round trip. Batching capabilities are available with version 1.1.0.0 or higher. All versions of the RMS server use a <MinimumVersion> of "1.0.0.0" for all SOAP responses. RMS 1.0 and RMS 1.0 SP1 use a <MaximumVersion> of "1.0.0.0" for all SOAP responses. RMS 1.0 SP2, Windows Server 2008, and Windows Server 2008 R2 use a <MaximumVersion> of "1.1.0.0" for all SOAP responses. Windows Server 2008 R2 operating system with Service Pack 1 (SP1), Windows Server 2012, Windows Server 2012 R2, Windows Server 2016, and Windows Server operating system use a <MaximumVersion> of "1.2.0.0" for all SOAP responses.

<2> Section 2.1: Protocol messages are transported using the HTTP or HTTPS protocol between client and server. Windows always attempts to use standard ports for these protocols. The Windows Rights Management client and Rights Management server always use the same transport protocol. The RMS: Client-to-Server Protocol does not directly manipulate network layers below the transport layer.

The Windows RMS implementation supports HTTPS for securing its ports, although Secure Sockets Layer (SSL) is not configured by default when RMS is installed.

<3> Section 2.2.4.2: The Windows RMS server does not return the VersionData header with error responses.

<4> Section 2.2.9.1.12:  SHA-256 is not supported in Windows NT operating system, Windows 2000, Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, and Windows Server 2008 R2 prior to Windows Server 2008 R2 Service Pack 1 (SP1). These Windows releases use a SHA-1 hash.

<5> Section 2.2.9.1.13.1: In Windows 2000, Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2, the Reserved field is always set to 0xFFFF.

<6> Section 2.2.9.2: With RMS: Client-to-Server Protocol version 2.0, you can enroll an RMS server in the appropriate hierarchy without sending information to Microsoft. When the RMS role is installed, a self-enrollment certificate and private key are also installed. These are used to automatically create the server licensor certificate.

<7> Section 2.2.9.3.3: Applicable Windows Server releases set the value attribute of the [[- serverversion -]] SECURITYLEVEL element to a string containing additional version information of the server. This information is not used in the RMS protocol.

<8> Section 2.2.9.3.3: Applicable Windows Server releases set the value attribute of the [[- serversku -]] SECURITYLEVEL element to a string containing additional version information of the server. This information is not used in the RMS protocol.

<9> Section 2.2.9.4.2: In Windows, the [[- type -]] element is taken from the OBJECT of the PRINCIPAL of the ISSUEDPRINCIPALS of the issuer's certificate. For a version 1 client, this element is set to "MS-DRM-Server". For a version 1 SP1, version 1 SP2, or version 2 client, this element is set to "MS-DRM-Desktop-Security-Processor".

<10> Section 2.2.9.4.2: In Windows, the [[- name -]] element used in the ISSUER element has the following values:

  • For a version 1 client, this value is "Machine Activation Server".

  • For a version 1 SP1, version 1 SP2, or version 2 client, this value is "Microsoft DRM Production Desktop Security Processor Activation Certificate".

  • If the RMS server is using the pre-production hierarchy, this value is "Microsoft DRM ISV Desktop Security Processor Activation Certificate".

<11> Section 2.2.9.4.2: In Windows, the [[- cps -]] element used in the ISSUER element is a SECURITYLEVEL element with the name "Certificate Practice Statement" and has the value of a URL pointing to a certificate practice statement. It is present in SPCs for version 1 clients, and not be present in SPCs for version 1 SP1, version 1 SP2, or version 2 clients.

<12> Section 2.2.9.4.3: The RMS machine activation cloud service endpoint used in this example is the Windows RMS machine activation cloud service endpoint. Implementations are free to use the Microsoft cloud service so long as they do not deviate from this protocol specification.

<13> Section 2.2.9.4.3: In Windows, the [[activation location]] used in the DISTRIBUTIONPOINT element is "file:///rmactivate.exe" (without quotes).

<14> Section 2.2.9.5.2: Applicable Windows Server releases set the value attribute of the [[- serverversion -]] SECURITYLEVEL element to a string containing additional version information of the server. This information is not used in the RMS protocol.

<15> Section 2.2.9.5.2: Applicable Windows Server releases set the value attribute of the [[- serversku -]] SECURITYLEVEL element to a string containing additional version information of the server. This information is not used in the RMS protocol.

<16> Section 2.2.9.5.3: In Windows, the GUID for the DISTRIBUTIONPOINT element is 8BA9EA80-99E4-4a2b-9764-4CD84F77C3A0.

<17> Section 2.2.9.5.4: For a RAC issued by the Windows RMS Account Certification cloud service using Passport authentication, the type is "Passport".

<18> Section 2.2.9.5.4: In Windows, there is a setting in the RMS Server for the validity time of RACs. The default is 1 year validity for persistent RACs, 15 minutes for temporary RACs.

<19> Section 2.2.9.6.2: Applicable Windows Server releases set the value attribute of the [[- serverversion -]] SECURITYLEVEL element to a string containing additional version information of the server. This information is not used in the RMS protocol.

<20> Section 2.2.9.6.2: Applicable Windows Server releases set the value attribute of the [[- serversku -]] SECURITYLEVEL element to a string containing additional version information of the server. This information is not used in the RMS protocol.

<21> Section 2.2.9.6.3: In Windows, the GUID for the DISTRIBUTIONPOINT element is 0F45FD50-383B-43EE-90A4-ED013CD0CFE5 for intranet URLs and 94BF969A-CA04-44d6-AA96-51071281FEF2 for extranet URLs.

<22> Section 2.2.9.10.3: In Windows, the GUID for the DISTRIBUTIONPOINT element is 9A23D98E-4449-4ba5-812A-F30808F3CB16.

<23> Section 3: The RMS: Client-to-Server Protocol retains configuration information and RAC key data.

<24> Section 3.1.1.1.1: The Windows RMS server implementation contains the public key of the SPC CA and checks that this key appears in the second or third certificate in the chain when validating SPC chains.

<25> Section 3.1.1.1.1: The Windows RMS server implementation currently generates a random 1,024-bit RSA key pair on installation and retains this state.

<26> Section 3.1.1.2.3: serviceConnectionPoint (SCP) is the Active Directory attribute that stores the RMS service location in Windows.

<27> Section 3.1.3.2: In Windows, RMS version 1.0, 1.0 SP1, and 1.0 SP2 servers contacted the Microsoft enrollment service to sign the SLC key into the hierarchy. The RMS version 2 server has a shared enrollment private key and certificate chain. When the RMS version 2 server initializes, it generates its own unsigned SLC, signs it with this shared enrollment private key, and appends the certificate chain.

<28> Section 3.1.4.1: In Windows, RMS 1.0 SP2 clients and RMS 2.0 clients and servers support Microsoft Web Browser Federated Sign-On authentication, as specified in [MS-MWBF].

<29> Section 3.1.4.2: In Windows, RMS 1.0 SP2 client and RMS 2.0 client and server support Microsoft Web Browser Federated Sign-On authentication, as specified in [MS-MWBF].

<30> Section 3.1.4.4: Windows provides the administrator with the option to specify the SCP in Active Directory.

<31> Section 3.1.4.4: Windows RMS clients search Active Directory for the SCP unless one of the following registry keys is present.

  • "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDRM\ServiceLocation\Activation" can be used to specify the location of the certification service, http(s)://servername/_wmcs/certification.

  • "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDRM\ServiceLocation\EnterprisePublishing" can be used to specify the location of the licensing service, http(s)://servername/_wmcs/licensing.

In addition, applications can specify an alternate service URL when invoking Windows APIs that would normally search Active Directory for the SCP.

Windows RMS servers search Active Directory for the SCP unless the GICURL value of one of the following registry keys contains the location of the certification service, http(s)://servername/_wmcs/certification.

  • For RMS 1.0 SP2 or earlier, the registry key is "HKEY_LOCAL_MACHINE\Software\Microsoft\DRMS\1.0".

  • For Windows Server 2008, the registry key is "HKEY_LOCAL_MACHINE\Software\Microsoft\DRMS\2.0".

  • For Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016, and Windows Server operating system, the registry key is "HKEY_LOCAL_MACHINE\Software\Microsoft\DRMS".

<32> Section 3.1.4.7: Support for multiple cryptographic modes is not implemented in Windows 2000 Server operating system, Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2 prior to Windows Server 2008 R2 SP1. These Windows releases implement a single cryptographic mode equivalent to Mode 1.

<33> Section 3.2: Support for the RMS Client version 1.0 has ended, and the Cloud Service is no longer available for activation requests. Activate requests from RMS 1.0 can still be made to the RMS server, but activation calls from the RMS server to the Cloud Service will fail. This failure results in the server returning a failure to the RMS client.

RMS: Client-to-Server protocol versions 1.0 SP1, 1.0 SP2, and 2.0 use self activation. Self activation continues to function as expected.

<34> Section 3.2.4.1: Support for the RMS Client version 1.0 has ended, and the Cloud Service is no longer available for activation requests. Activate requests from RMS 1.0 can still be made to the RMS server, but activation calls from the RMS server to the Cloud Service will fail. This failure results in the server returning a failure to the RMS client.

RMS: Client-to-Server protocol versions 1.0 SP1, 1.0 SP2, and 2.0 use self-activation. Self activation continues to function as expected.

<35> Section 3.2.4.1.2.3: Windows uses a one-way hash of various machine characteristics to generate a HID. An example of machine characteristics includes the network address.

<36> Section 3.2.4.1.2.3: SHA-256 is not supported in Windows NT, Windows 2000, Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, and Windows Server 2008 R2 prior to Windows Server 2008 R2 SP1. These Windows releases use a SHA-1 hash.

<37> Section 3.3.4.1: In Windows, the RMS server uses Microsoft Internet Information Services (IIS) to authenticate Certify requests.

The IIS authentication for the RMS server uses NTLM authentication by default. It can be configured to use other types of authentication, including Microsoft Web Browser Federated Sign-On (MWBF). Kerberos, and Digest.

<38> Section 3.3.4.1: In Windows, this can only happen when the RMS client and server are on the same machine and the client is running as a well-known local account. This is not recommended in production environments. The behavior described here is implemented in Windows to support testing RMS with the client and server on the same machine.

<39> Section 3.3.4.1: In Windows, RMS supports NTLM authentication as described in [MS-NTHT]. RMS 2.0 server supports Microsoft Web Browser Federated Sign-On authentication, as specified in [MS-MWBF].

In Windows, authentication data comes from IIS. RMS depends on IIS to pass on the authentication details. RMS does not authenticate users; IIS does. Windows makes use of the authentication data received, which is not part of the SOAP message; it comes from the IIS in the HTTP communication.

<40> Section 3.3.4.1.3.3: The QuotaResponse structure is kept in the protocol for backward compatibility but is not used. The CurrentConsumption member is set to 5 by the current server implementation. The Maximum member is set to 10 by the current server implementation. The Verified member of this structure is set to true. If the server is in the preproduction hierarchy, the CurrentConsumption member is set to 1 and the Maximum member is set to 0.

<41> Section 3.4.4.1: Windows limits the size of an ApplicationData parameter to 102,400 bytes.

<42> Section 3.4.4.1.3.3: Windows limits the size of a LicenseeCert to 30720 bytes. Windows limits the number of LicenseeCerts to 100.

<43> Section 3.4.4.1.3.3: Windows limits the size of an IssuanceLicense to 8*1024*1024 bytes.

<44> Section 3.4.4.1.3.4: The ReferenceCertificates response parameter is always returned as an empty value.

<45> Section 3.5.4.2: In Windows, The RMS server generates a unique 1,024-bit RSA key pair each time it generates a CLC. This key pair is not stored on the server.

<46> Section 3.7.4.2: The Windows client stores the service discovery location in the registry.

<47> Section 3.7.4.2: The RMS server uses NTLM authentication according to [MS-NTHT] through Internet Information Services (IIS) for FindServiceLocationsForUser requests.

<48> Section 3.7.4.2.4.1:  Windows 2000 and Windows XP prior to Windows XP operating system Service Pack 2 (SP2) do not support the GroupExpansionService, LicensingInternalService, and CertificationInternalService enumeration values.

<49> Section 3.7.4.2.4.1: The GroupExpansionService enumeration is not implemented in Windows 2000 and Windows XP prior to Windows XP SP2.

<50> Section 3.7.4.2.4.1: The LicensingInternalService enumeration is not implemented in Windows 2000 and Windows XP prior to Windows XP SP2.

<51> Section 3.7.4.2.4.1: The CertificationInternalService enumeration is not implemented in Windows 2000 and Windows XP prior to Windows XP SP2.

<52> Section 3.8.3.2: serviceConnectionPoint (SCP) is the Active Directory attribute that stores the RMS service location in Windows.

<53> Section 3.8.3.2.2: The RMS client checks the following string values in the Windows registry for server locations.

 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDRM\ServiceLocation]
 "EnterprisePublishing"=
    [URL of server used for publishing and licensing]
 "Activation"=[URL of server used for the Certify request]
  

<54> Section 3.8.4.2: The RMS client in Windows 2000, Windows XP, Windows Server 2003, and Windows Vista prior to Windows Vista operating system with Service Pack 1 (SP1) cannot acquire rights policy templates from an RMS 2.0 server.

<55> Section 3.8.4.2: To maintain templates in the client store, Windows comes with a Task Scheduler job that can be enabled within an organization, as specified in [MSDN-TaskSch]. The frequency of template acquisition by the Task Scheduler job is configurable through a group policy. When the Task Scheduler job is invoked, it invokes the RMS client functionality previously explained. This Task Scheduler job is not implemented in Windows 2000, Windows XP, Windows Server 2003, and Windows Vista prior to Windows Vista SP1.

<56> Section 4.1: These binaries are installed as part of Windows except in Windows 2000, Windows XP, and Windows Server 2003. In these operating systems, a user downloads and installs a separate package that deploys the client binaries.

<57> Section 4.2: These binaries are installed as part of Windows except in Windows 2000, Windows XP, and Windows Server 2003. In these operating systems, a user downloads and installs a separate package that deploys the client binaries.

<58> Section 4.2: Microsoft Office persists the UL obtained using AcquireLicense alongside the protected content.

Show: