Hot Security issues after installing Windows 2003 SP1
Windows 2003 Service Pack 1 makes some significant changes to security including start up account for services, DCOM security and etc. Services such as RPC and DCOM are integral to Windows Server 2003, but they are also an alluring target for hackers. By requiring greater authentication for RPC and DCOM calls, Service Pack 1 establishes a minimum threshold of security for all applications that use these services, even if they possess little or no security themselves. Since SP1 has stronger defaults and privilege reduction on services, it may result in some issues after installing SP1.
Here we list some typical security related issues after installing SP1:
RPC Service related issues:
Windows 2003 SP1 uses Network Service account for the RPC service. Prior to SP1, OS was using Local System account for the same. After installing SP1 for Windows Server 2003 services will not start that use the Network Service or Local Service account.
Symptoms:
RPC service or other services dependent on RPC will not start properly.
Slow boot up process
Network connection fails to open or Network adapter icons do not appear in Network Connections.
Blank desktop or sometimes icons stop responding
COM+, Volume Shadow Copy and Shell Hardware Detection services are in the “starting” state
Receive “Access is denies” when selecting the dependencies tab of a service that does not start
Unable to search.
Unable to use Windows Update.
Unable to add or remove programs
Receive “Access Denied” when opening disk management.
Windows Firewall reports that the network setting is corrupted.
Cause:
Remote Procedure Call (RPC) service has been changed from Local System account to Network System account for better security. “Impersonate a client after authentication” right is required to include Administrators and the SERVICE group if the RPC Service runs as the “NetworkService” account.
Resolution:
a. Open the Group Policy configuration window (gpedit.msc or open it in Active Directory Users and Computers).
b. Locate the policy entry: Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\Impersonate a client after authentication.
c. Ensure that the “Administrators” group and the “SERVICE” group are granted this privilege.
d. If the problem remains, correct the Access Control List for HKEY_CLASSES_ROOT\CLSID (and all child keys and values) to ensure NT Authority\Network Service can read. This can be accomplished by adding Authenticated Users or Users group and providing Read permissions.
Additional Info:
W32time service issue:
Symptoms:
After you upgrade a DC from Windows 2003 to Windows Server 2003 SP1, the Windows Time service may not start. You may get event 7023 or 46 in the Windows System log.
Cause:
Windows 2003 SP1 made several changes including running W32Time service with account "Local Service Account" as opposed to traditional "Local System Account".
Resolution:
Certification Authority issue:
Symptom 1:
Certificate enrollment against a Windows Server 2003 SP1 CA fails using the MMC.
Error: There are no trusted Certification Authorities (CAs) available.
- You do not have permissions to requiest certificates from the available CAs.
- The available CAs issue certificates for which you do not have permissions.
Symptom 2:
Computer autoenrollment against a Windows Server 2003 SP1 CA fails
Cause:
Windows Server 2003 SP1 introduces enhanced default security settings for the DCOM protocol. Specifically, SP1 introduces more precise rights that give an administrator independent control over local and remote permissions for launching,activating, and accessing COM servers.
A new local group named CERTSVC_DCOM_ACCESS is created when SP1 is installed. This group is added to the DCOM Security Limits for DCOM Access and DCOM Launch and Activation permissions. By default, the Domain Users and Domain Computers global groups are added to the CERTSVC_DCOM_ACCESS group. If Certificate Services is installed on a Domain Controller, CERTSVC_DCOM_ACCESS is created as a Domain Local group.
Resolution:
Follow these steps to verify that DCOM permissions have been correctly configured.
1. Determine if the CERTSVC_DCOM_ACCESS Local Security group has been created in the domain that hosts the Certification Authority (CA). This group is created in the CN=Users container.
2. If the group exists, verify that the following groups are members: Domain Users and Domain Computers. If there are users or computers in other domains that also need to enroll against the CA, then those users and computers will also need to be added to the CERTSVC_DCOM_ACCESS group.
If these errors are occurring on a Domain Controller, then add ENTERPRISE DOMAIN CONTROLLERS to the CERTSVC_DCOM_ACCESS group. Domain Controllers are not members of the Domain Computers global group and will not have sufficient DCOM permissions by default.
3. Verify that CERTSVC_DCOM_ACCESS has been added to the DCOM Security Limits on the CA.
a. Click on Start, then Programs, then Administrative Tools, the Component Services.
b. Expand the Component Services node.
c. Expand the Computers node.
d. Right-click on My Computer and select Properties from the context menu.
e. Click on the COM Security tab.
f. Under Access Permissions, click Edit Limits.
g. Verify that the CERTSVC_DCOM_ACCESS group has been granted Allow Local Access and Allow Remote Access permissions.
h. Click Cancel.
i. Under Launch and Activation Permissions, click Edit Limits.
j. Verify that the CERTSVC_DCOM_ACCESS group has been granted All Local Activation and Allow Remote Activation permissions.
k. Click Cancel.
l. Click Cancel.
m. Close Component Services.
4. If any of the settings checked above are not correct -- the CERTSVC_DCOM_ACCESS group has not been created, the default membership is not correct, or the group does not have the correct DCOM permissions, then run the following commands:
certutil -setreg SetupStatus -SETUP_DCOM_SECURITY_UPDATED_FLAG
net stop certsvc
net start certsvc
These commands cause Certificate Services to perform the default configuration changes in order to allow DCOM access to the CA. The following changes are made:
- CertSrv Request DCOM interface:
- The Everyone security group is granted local and remote access permissions.
- The Everyone security group is granted local and remote activation permissions.
- The Everyone security group is not granted local or remote launch permissions.
- DCOM Computer Restriction Settings:
- A new security group, CERTSVC_DCOM_ACCESS, is automatically created. If the certification authority is installed on a member server, CERTSVC_DCOM_ACCESS is a computer local group, and the Everyone security group is added to it.
If the certification authority is installed on a domain controller, CERTSVC_DCOM_ACCESS is created as a domain local group. The Domain Users security group and the Domain Computers security group from the certification authority's
domain are added to it.
- The CERTSVC_DCOM_ACCESS security group is granted local and remote access permissions.
- The CERTSVC_DCOM_ACCESS security group is granted local and remote activation permissions.
- The CERTSVC_DCOM_ACCESS security group is not granted local or remote launch permissions. Note that if the certification authority is installed on a domain controller, and the enterprise is made up of more than one domain, Certificate Services cannot automatically update the DCOM security settings for enrollees from outside the certification authority's domain. Therefore, these enrollees must be manually added to the CERTSVC_DCOM_ACCESS group.
5. Checks steps 1-3 again to verify the configuration changes were made.
Note: Changes that affect the group membership of the CA server itself may require a reboot to be immediately effective.
Additional Info:
Changes to Functionality in Microsoft Windows Server 2003 Service Pack 1
Technical Overview of Windows Server 2003 Service Pack 1 (SP1)
-End-
Author: Pearson Peng