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 4.0 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

  • Windows 10 operating system

  • Windows Server 2016 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 3.1.4.1: Transferring sensitive data without IIS IMSAdminBaseW Remote Protocol-level encryption.

Windows NT operating system supports a mode where client and server can exchange sensitive data (see section 3.1.4.1) over the IIS IMSAdminBaseW Remote Protocol without having a valid secure session negotiated. That mode applies to only machines with the French locale.

To negotiate cleartext mode of operation, client and server still go through the secure session negotiation. They have to handle R_KeyExchangePhase1 and R_KeyExchangePhase2 but with the following changes:

  • Any key exchange public key BLOB is replaced with a IIS_CRYPTO_BLOB structure with the BlobSignature field set to the CLEARTEXT_BLOB_SIGNATURE signature, and where the BlobData field contains the "KeYk" string without the terminating null character.

  • Any signature public key BLOB is replaced with a IIS_CRYPTO_BLOB structure with the BlobSignature field set to the CLEARTEXT_BLOB_SIGNATURE signature, and where the BlobData field contains the "SiGk" string without the terminating null character.

  • Any session key BLOB is replaced with a IIS_CRYPTO_BLOB structure with the BlobSignature field set to the CLEARTEXT_BLOB_SIGNATURE signature, and where the BlobData field contains the "SeSk" string without the terminating null character.

  • Any hash exchanged is replaced with a IIS_CRYPTO_BLOB structure with the BlobSignature field set to the CLEARTEXT_BLOB_SIGNATURE signature, and where the BlobData field contains one byte set to 0x00.

Sensitive data will not be encrypted in this mode of operation. Instead of using a IIS_CRYPTO_BLOB structure with the BlobSignature field set to ENCRYPTED_DATA_SIGNATURE, the sensitive data will be placed into a IIS_CRYPTO_BLOB structure with the BlobSignature field set to CLEARTEXT_DATA_SIGNATURE in a call to R_SetData, R_GetData, R_EnumData, and R_GetAllData.

Decryption does not apply in this mode of operation. Instead of decrypting data store in a IIS_CRYPTO_BLOB structure, the data is simply retrieved from the IIS_CRYPTO_BLOB instance with a CLEARTEXT_DATA_SIGNATURE signature.

<2> Section 3.1.4.1: Windows Server 2003, Windows Vista, and Windows Server 2008 take advantage of the RPC/COM packet privacy feature. It provides a protective layer over the weak encryption used to protect data that is part of the IMSAdminBaseW Remote Protocol. Note that RPC/COM packet privacy is not a replacement of the IIS IMSAdminBaseW Remote Protocol security features.

<3> Section 3.1.4.2: On Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2 operating system, Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016, the /LM/W3SVC path and all its child paths do not implement the locking behavior described in 3.1.1. OpenKey calls on these paths will succeed and will not return ERROR_PATH_BUSY even if other keys are open to parent or child paths.

<4> Section 3.1.4.4: On Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, Windows Server 2016, there is no check of the permission level of the metabase handle used in the AddKey method for metabase paths under and including /LM/W3SVC.

<5> Section 3.1.4.5: On Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016, the implementation of CopyKey does not check that the destination handle is opened with write permissions for metabase paths under and including /LM/W3SVC. Instead, the implementation checks the source handle for write access. This will cause valid calls to CopyKey to fail with E_ACCESSDENIED.                      

<6> Section 3.1.4.6: On Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016, there is no check of the permission level of the metabase handle used in the DeleteKey method for metabase paths under and including /LM/W3SVC.

<7> Section 3.1.4.7: On Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016, all calls to the DeleteChildKeys method return ERROR_INVALID_HANDLE for the "/LM/W3SVC" path and all its child paths.

<8> Section 3.1.4.8: On Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016, there is no check of the permission level of the metabase handle used in the DeleteData method for metabase paths under and including /LM/W3SVC.

<9> Section 3.1.4.9: On Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016, there is no check of the permission level of the metabase handle used in the DeleteAllData method for metabase paths under and including /LM/W3SVC.

<10> Section 3.1.4.9: On Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016, the server does not treat ALL_METADATA as matching the user type of data in the DeleteAllData method for metabase paths under and including /LM/W3SVC. The dwMDUserType parameter has to exactly match the data to be deleted.

<11> Section 3.1.4.10: The CopyData method will return ERROR_PATH_NOT_FOUND on Windows NT 4.0 operating system Service Pack 2 (SP2), Windows 2000, Windows XP, and Windows Server 2003 when the destination path specified by pszMDDestPath does not exist.

For destination paths under and including /LM/W3SVC, the CopyData method will not return an error on Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016 when the destination path specified by pszMDDestPath path does not exist.

<12> Section 3.1.4.11: On Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016, there is no check of the permission level of metabase handle used in the EnumKeys method for paths under and including /LM/W3SVC. There is also no permission check performed for EnumKeys when enumerating the path /LM if dwMDEnumObjectIndex is 0 or 1.

<13> Section 3.1.4.12: On Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016, there is no check of the permission level of the metabase handle used in the R_EnumData method for paths under and including /LM/W3SVC.

<14> Section 3.1.4.16: On Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016, the ChangePermissions method returns E_INVALIDARG for the "/LM/W3SVC" path and all its child paths.

<15> Section 3.1.4.20: Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016 do not store a separate change time for the metabase path /LM/W3SVC or any child paths. GetLastChangeTime returns the same modification time for all paths at or below /LM/W3SVC.

<16> Section 3.1.4.21: On Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016, two separate system change numbers are kept, one for paths under and including /LM/W3SVC and another for all other paths. The system change number for /LM/W3SVC and child paths is not persisted. Changes made to these paths will increment the system change number as long as the metabase service process, iisadmin, is running. When the service is restarted this record of changes is lost.

When the GetSystemChangeNumber method is called, the sum of these two numbers is returned. When the system change number is returned from a GetHandleInfo call, only the change number corresponding to the path of the open handle is returned.

<17> Section 3.1.4.27: Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016 do not check the state of the METADATA_SECURE flag on existing data items in the R_SetData method for paths under and including /LM/W3SVC.

<18> Section 3.1.4.28: On Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016, there is no check of the permission level of the metabase handle used in the RenameKey method for paths under and including /LM/W3SVC.

<19> Section 3.1.4.30: On Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016, open write handles to paths under and including /LM/W3SVC do not interfere with the SaveData operation.

<20> Section 3.1.4.31: On Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016, there is no check of the permission level of the metabase handle used in the SetLastChangeTime method for paths under and including /LM/W3SVC.

<21> Section 3.1.4.31: Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016 do not update the change time on demand for the metabase path /LM/W3SVC or any child paths. SetLastChangeTime succeeds but has no effect for all paths at or below /LM/W3SVC.

<22> Section 3.3.4.2: Default path is %windir%\system32\inetsrv\history.

<23> Section 3.3.4.3: On Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016, the server returns ERROR_NOT_SUPPORTED for the metabase path /LM/W3SVC or any child paths which map to nodes in the data hierarchy.

<24> Section 3.3.4.4: On Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016, the IMSAdminBase2::Import method is not supported for the destination metabase path /LM/W3SVC or any child paths. The server will return an error when an Import is attempted with one of these paths.

<25> Section 3.3.4.5: The default history path on Windows Server 2003 is "%windir%\system32\inetsrv\history".

<26> Section 3.7.4.1: The metabase path for a web application is valid if it is below the root node of a website. A website metabase path is a numeric key underneath the Web service key, "/LM/W3SVC". For example, "/LM/W3SVC/1" defines a website with site id 1. The root of the website is a key with the name "ROOT". For example, "/LM/W3SVC/2/ROOT" is the root node of the website with site id 2. The <AppCreate> method will allow applications to be created on valid web application paths as well as on paths underneath the Web service key that are not under a website. On Windows NT 4.0 SP2, Windows 2000, Windows XP, and Windows Server 2003 the <AppCreate> method will allow applications to be created on any child path of the Web service key, "/LM/W3SVC". Attempts to create an application on an invalid path will return an error.

<27> Section 3.7.4.4: For Windows Vista, Windows Server 2008 operating system, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016, IWamAdmin methods are not able to query or modify the running state of an application.

<28> Section 3.8.4.1: The metabase path for a website application is valid if it is below the root node of a website. A website metabase path is a numeric key underneath the Web service key, "/LM/W3SVC". For example, "/LM/W3SVC/1" defines a website with site id 1. The root of the website is a key with the name "ROOT". For example, "/LM/W3SVC/2/ROOT" is the root node of the website with site id 2. The <AppCreate> method will allow applications to be created on valid website application paths as well as on paths underneath the Web service key that are not under a website. On Windows NT 4.0 SP2, Windows 2000, Windows XP, and Windows Server 2003, the <AppCreate> method will allow applications to be created on any child path of the Web service key, "/LM/W3SVC". Attempts to create an application on an invalid path will return an error.

<29> Section 3.9.4.1: The metabase path for a web application is valid if it is below the root node of a website. A website metabase path is a numeric key underneath the Web service key, "/LM/W3SVC". For example, "/LM/W3SVC/1" defines a website with site id 1. The root of the website is a key with the name "ROOT". For example, "/LM/W3SVC/2/ROOT" is the root node of the website with site id 2. The <AppCreate> method will allow applications to be created on valid web application paths as well as on paths underneath the Web service key that are not under a website. On Windows NT 4.0 SP2, Windows 2000, Windows XP, and Windows Server 2003, the <AppCreate> method will allow applications to be created on any child path of the Web service key, "/LM/W3SVC". Attempts to create an application on an invalid path will return an error.

<30> Section 3.10.4: Returns ERROR_NOT_IMPLEMENTED. Opnum 7 is never used.

<31> Section 3.10.4: Returns ERROR_NOT_IMPLEMENTED. Opnum 8 is never used.

<32> Section 3.10.4: Returns ERROR_NOT_IMPLEMENTED. Opnum 9 is never used.

<33> Section 3.10.4.1: The format of the InstanceName string in the Windows implementation is "/LM/W3SVC/N" where N is a number which identifies the particular web server instance and W3SVC represents the web server. For example, "/LM/W3SVC/1" indicates the default web server instance.

<34> Section 3.10.4.4: The Issuer field is searched using the Windows API function CertGetNameString using CERT_NAME_SIMPLE_DISPLAY_TYPE and CERT_NAME_ISSUER_FLAG to specify the Issuer field. This API will return an attribute value from the Issuer field by looking for the first occurrence of the Common Name, Organizational Unit Name, Organization Name, or RSA Email Address. If one of these attributes is not found, it uses the Issuer Alternative Name extension. If there is still no match, it uses the first attribute.

<35> Section 3.10.4.4: The Windows implementation performs the date to string conversion using the Windows API function GetDateFormat and passing the flag DATE_AUTOLAYOUT. On Windows 7, Windows Server 2008 R2, Windows 8.1, Windows Server 2012 R2, Windows 10, and Windows Server 2016, Unicode bidirectional ordering control characters are inserted into the resulting date string. One of the Unicode characters 0x200E (left-to-right mark) or 0x200F (right-to-left mark), depending on the server’s system locale setting, will appear in the date string immediately before each numeric component of the date.

<36> Section 3.10.4.4: The Windows implementation retrieves a descriptive name for the extended key usage OID using the CryptFindOIDInfo Windows API function. A complete example of the string built by the GetCertInfoRemote method might be the following:

 1.2.840.113549.1.9.1=somebody@microsoft.com
 2.5.4.3=testcert
 2.5.4.11=IIS
 2.5.4.10=Microsoft
 2.5.4.7=Redmond
 2.5.4.8=WA
 2.5.4.6=US
 4=RSACERTSRV
 6=7/7/2009
 2.5.29.37=Server Authentication
              

<37> Section 3.10.4.5:  The Windows implementation uses the PFXImportCertStore API when importing a certificate via ImportFromBlob or ImportFromBlobGetHash. If the bAllowExport parameter is set to 1 or VARIANT_TRUE, the CRYPT_EXPORTABLE flag is set in dwFlags parameter in the call to PFXImportCertStore.

<38> Section 3.10.4.5: The Windows implementation exports certificates using the PFXExportCertStoreEx API. The encryption method of the exported data is dependent on the implementation of this API. On import via ImportFromBlob or ImportFromBlobGetHash, the password is validated using PFXVerifyPassword, and the import is performed by PFXImportCertStore.

<39> Section 3.10.4.6: Memory is allocated in the Windows implementation using CoTaskMemAlloc and is released by the client using CoTaskMemFree.

<40> Section 3.10.4.6: The Windows implementation uses the PFXImportCertStore API when importing a certificate via ImportFromBlob or ImportFromBlobGetHash. If the bAllowExport parameter is set to 1 or VARIANT_TRUE, the CRYPT_EXPORTABLE flag is set in dwFlags parameter in the call to PFXImportCertStore.

<41> Section 3.10.4.6: The Windows implementation exports certificates using the PFXExportCertStoreEx API. The encryption method of the exported data is dependent on the implementation of this API. On import via ImportFromBlob or ImportFromBlobGetHash the password is validated using PFXVerifyPassword and the import is performed by PFXImportCertStore.

<42> Section 3.10.4.6: The IDL attributes of pCertHash will not allow the entire certificate hash buffer to be returned to remote clients. Because no size is indicated in the parameter attributes for pCertHash, the RPC/DCOM implementation will return a single byte of data to the client when the method is called remotely. A correct IDL specification for this parameter might have been [out, size_is(*pcbCertHashSize)].

<43> Section 3.10.4.7: Memory is allocated in the Windows implementation using CoTaskMemAlloc and has to be released by the client using CoTaskMemFree.

<44> Section 3.10.4.7: The Windows implementation uses the PFXExportCertStoreEx API to export the certificate and optional chain and private key data. The specific format of the exported data blob does not affect client interoperability as long as a server implementation is capable of passing data blobs between import and export methods.

<45> Section 3.10.4.7:  The pBlobBinary parameter is specified as a [string] in the IDL. The RPC/DCOM layer will marshal the data buffer created on the server up to the first null (0x00) byte encountered. The Windows implementation does not null-terminate the encoded data buffer, so remote clients might receive a null-terminated buffer with some arbitrary number of additional bytes. The pcbSize parameter correctly indicates the number of valid bytes in the returned buffer.

<46> Section 4.1: A Windows implementation of this protocol requires the RPC_C_IMP_LEVEL_IMPERSONATE impersonation level to be set.

<47> Section 5.1: Windows Server 2003, Windows Vista, and Windows Server 2008 take advantage of the RPC/COM packet privacy feature RPC_C_AUTHN_LEVEL_PKT_PRIVACY. This feature provides a protective layer over the weak encryption, as described in section 3.1.4.1.1.

Show: