SMS 2003 Management Point IIS Account Permissions

I’d like to share information regarding how SMS 2003 Management Points leverage IIS. Lately Product Support has seen an increasing number of issues with IIS account entanglements at the root of the problem.

 

Unfortunately it is beyond this blog to provide everything you might need to know about MP’s (and related SMS Roles) and IIS or specifics to the Windows Server version in use. However with that stated, the following is information I believe will be useful in correcting problems where a Management Point is failing and the cause has its root in the IIS account permissions

 

MP Structure Within IIS

On a server with IIS installed and properly configured, the MP installation will add a virtual directory under the default website. The virtual directory is called SMS_MP. This virtual directory is how the advanced clients are able to communicate with the MP.

Two other virtual directories will be created called CCM_Incoming and CCM_Outgoing. These two directories handle the BITS transfer of Policy to and from the Clients.

Two Accounts and one Group are worth noting at this time:

o IUSR_ComputerName - This is the Internet Guest Account and is used to permit users to connect anonymously to Internet sites hosted on the server. If the account is disabled or locked out, anonymous access will no longer function. This account is a member of the local Guests Group. If installed on a DC this is also added to the Domain Users group.

o IWAM_ComputerName– This account is used by IIS to run out-of-process applications. If this account is locked-out or disabled, these out-of-process applications will not be able to be started. This account is a member of the IIS_WPG group. IF installed on a DC this is also added to the Domain Users group.

o IIS_WPG – The IIS Worker Process Group. This account is used by worker processes running in IIS. If this account is disabled or locked out, IIS will not function properly.

Common Account Permissions

The following may be used as a guide to the default NTFS permissions for the structures in a typical SMS environment. Starting with these as a guide, you may be able to correct or at least identify when IIS configurations or account restrictions are impacting the MP’s functionality.

Management Point (SMS_MP virtual directory)

?        Default path: c:\SMS_CCM\SMS_MP

?        Default NTFS Permissions:

¦        Administrators-Full Control

¦        Interactive-List Folder Contents

¦        IUSR account-List Folder Contents

¦        IWAM account-List Folder Contents

¦        SYSTEM-Full Control

Management Point (CCM_Incoming virtual directory)

?        Default path: c:\sms\ccm\incoming

?        Default NTFS Permissions:

¦        Administrators-Full Control

¦        IUSR account-Special:

? Traverse Folder/Execute File

? List Folder/Read Data

? Read Attributes

? Read Extended Attributes

? Create Files/Write Data

? Create Folders/Append Data

? Delete subfolders and files

? Read Permissions

¦        IWAM account Special:

? Traverse Folder/Execute File

? List Folder/Read Data

? Read Attributes

? Read Extended Attributes

? Create Files/Write Data

? Create Folders/Append Data

? Delete subfolders and files

? Read Permissions

¦        SYSTEM-Full Control

Management Point (CCM_Outgoing virtual directory)

?        Default Path: c:\SMS\CCM\Outgoing

?        Default Permissions:

¦        Administrators-Full Control

¦        IUSR Account-Read

¦        IWAM Account-Read

¦        SYSTEM-Full Control

Management Point (CCM_SYSTEM virtual directory)

?        Default Path: C:\SMS_CCM\ServiceData\System

?        Default Permissions:

¦        Administrators-Full Control

¦        Interactive-List folder contents

¦        IUSR Account-List folder contents

¦        IWAM Account-List folder contents

¦        SYSTEM-Full Control

Common Problem Scenarios:

Two common problems you may encounter involve one or more of the IIS accounts being locked or out of sync. The resolutions provided assume some level of knowledge and comfort with IIS.

IUSR Lockouts

IUSR lockouts are defined when the IUSR password that is stored in the Metabase.bin or Metabase.xml file, dependant on the version you have of IIS is different from either the IUSR password stored in DCOM for that site or application pool. Alternatively, is different from the password stored in either Active Directory if on a Domain Controller or locally if on a member server.

Resetting the Password for IUSR

This describes how to perform a manual IUSR reset if the issue arises where the IUSR becomes out of sync via either a attempted manual removal of IIS or a failed attempt to reset the password via the AD Users and Computers or local user interface of a member server.

1. Reset the IUSR Password via the local user reset password option or use AD Users and Computers if the machine happens to be a domain controller.

2. Reset the IUSR Password in the metabase.xml or metabase.bin file using the Metabase Explorer tool. You can learn more about this and other IIS tools here:

https://support.microsoft.com/default.aspx?scid=kb;EN-US;840671

a. Open metabase explorer on the target machine where the password will be reset.

b. in the left pane navigate to the LM\W3SVC path

c. In the right pane, locate ID 6020 “AnonymousUserPass”. Notice how the section under the Data column states “***Secure Data***.

d. Click up top on the toolbar on View then select Secure Data, notice now that the password is exposed for the AnonymousUserPass.

e. Double-click on the AnonymousUserPass row and this will bring up the properties for that row so now the editing of the Password can take place.

f. Enter the same password that was defined during the password reset in the local user account properties that was performed in step 1.

g. Once the password is reset here, close out of Metabase Explorer and open a command prompt. Type “iisreset” without the quotes to restart the IIS services.

         

IWAM Lockouts

IWAM lockouts similar to IUSR lockouts are defined when the IWAM password that is stored in the Metabase.bin or Metabase.xml file, dependant on the version you have of IIS is different from either the IWAM password stored in DCOM for that site or application pool. Alternatively, if different from the password stored in either Active Directory if on a Domain Controller or locally if on a member server.

          Resetting the Password for IWAM

SyncIWAM.vbs is a vb script that is included by default with the installation of IIS. This script is used to synchronize the password that may be skewed in either the metabase or DCOM.

1. Open a command prompt and navigate to c:\inetpub\adminscripts

2. type “cscript.exe synciwam.vbs –v” to execute the script in verbose mode

One drawback to this tool is that it assumes that the password between the metabase and the SAM (or Active Directory) is accurate. However if this is not true, then the synciwam.vbs will reset the DCOM permissions to that of the password that is stored in the metabase.

To determine the current password stored in the metabase, and to ensure that the password in the SAM or Active Directory matches, you can again use the Metabase Explorer tool and look at ID 7502 “WAMUserPass”. The password reset on the SAM or Active Directory for the IWAM account can then be run to ensure match ability

Please be aware of these articles for issues following a Windows 2003 SP1 upgrade:

KB 903220 Description of the changes to DCOM security settings after you install Windows Server 2003 Service Pack 1
https://support.microsoft.com/default.aspx?scid=kb;EN-US;903220

         

Cannot launch COM objects with IUSR_computername or IWAM_computername accounts (IIS 6.0)
https://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/4d96e6b2-2518-4246-90b3-1a1221eb4fab.mspx?mfr=true

 

 

Additional Resources:

SMS 2003 IIS Hardening Checklist:

https://www.microsoft.com/technet/prodtechnol/sms/smssp2/spsecurity/d3be8aca-ca56-49c6-a27f-c18db788f7bf.mspx?mfr=true

 

Scenarios and Procedures for Microsoft Systems Management Server 2003: Security

 - Sub page of Appendix C regarding IIS Accounts

https://www.microsoft.com/technet/prodtechnol/sms/smssp2/spsecurity/81bd4dfa-0644-4bc2-afa5-1eadc86016ae.mspx?mfr=true

 

IIS Built-In Accounts
https://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/3648346f-e4f5-474b-86c7-5a86e85fa1ff.mspx?mfr=true  

 

 

I hope this provides insight to your MP’s use of IIS and can help clear up issues caused by changes made to or applied to IIS accounts and groups. Please keep track of where these accounts are being used on your servers and what policies are applied to them. Often an IIS related problem for SMS stems from a policy limiting necessary rights for one or more of these accounts or groups. Also be aware that the IIS accounts require permissions within DCOM. The information provided today is not meant to be comprehensive and did not discuss DCOM but rather is an attempt to provide information which may help you resolve simple IIS account problems without the need to open a support call.

 

A reminder: Always back up your servers before you act!

And please let us know if this is useful or on what topics you might like more information.