Atlanta .NET Regular Guys

WARNING! AD Group Policy changes can kill your applications

In an effort to resolve a Kerberos authentication problem affecting Sql Server Reporting Services, a change was made to the security policy on the domain controller while following the advice of this Microsoft TechNet article.  This change DID fix the authentication problem but caused the following unintended side effects:

• · Applications which require TCP/IP access to network resources such as ClickOnce deployed applications failed to start due to an apparent inability to check the version information from the deployment source
• · The Microsoft Office 2007 Compatibility Add-in for Office XP (to enable reading of 2007 Word doc files) fails to start and displays an error message pointing at the Windows Installer service
• · In the Control Panel’s Add/Remove Programs applet, clicking the Change/Remove button for any application fails to have any effect
• · The Application Log contained many COM+ error messages indicating error code 4609 (error contents below)
• Event Type: Error
  Event Source: EventSystem
  Event Category: (50)
  Event ID: 4609
  Date:  5/2/2007
  Time:  8:34:35 AM
  User:  N/A
  Computer: ********
  Description:
  The COM+ Event System detected a bad return code during its internal processing.  HRESULT was 80070005 from line 44 of d:\qxp_slp\com\com1x\src\events\tier1\eventsystemobj.cpp.  Please contact Microsoft Product Support Services to report this error.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

• · Attempting to expand the Computers node of the Control Panel’s Administrator Tools Component Services COM+ browser causes the entire COM+ browser window to unload itself
• · The Network Connections window, launched from the Control Panel, is empty of any entries

We found that any computer which had been entirely rebooted since the policy settings changes experience the above symptoms, but any machine which had only been logged off did not.  This has to do with the way services are not restarted with new login credentials until the system is entirely shut down.

We found that a System Restore does fix the problem, but only until the machine is rebooted (where-upon the incorrect credentials are loaded)

Following this forum posting, we were able to reset the group policy to the default values following these steps:

On the affected workstation:
1) Go to Start/Settings/Control Panel/Administrative Tools
2) Run 'Local Security Policy'
3) Go to Security Settings/Local Policies/User Rights Assignments
4) Double click on 'Create global objects'.
        The correct default settings are 'Administrators', 'INTERACTIVE' and 'SERVICE'.
5) Double click on 'Impersonate a client after authentication'.
        The correct default settings are 'Administrators', 'ASPNET' (if you have the .NET framework installed) and 'SERVICE'

Even if the settings are set correctly, you may need to 'refresh' them to fix the problem.  To do this, on each policy, remove one of the entries ('SERVICE' is probably the best to remove), then press OK to save the changes, and then go back in and add it back in again (click 'Add User or Group...', type 'SERVICE' into the white box, and press OK).

Then close the Local Security Settings box and reboot. If you are running in a domain with Group Policy you might want to force a group policy refresh before you reboot by running 'gpupdate /force'.

Then, by rebooting an affected machine two times (the first time to get the corrected settings, the second time to actually USE the corrected settings), we were able observe that everything was back to normal.

*********  Recommendations to prevent this sort of problem in the future  *********************

This problem was caused by an inadvertent end-run around procedural policies.  Changes to the domain controller should have been approved by the IT staff but were not.  To prevent this capability, network users, developers, and consultants should not be using a Domain Administrator account to access network resources.  If we instead had limited or no access to the primary domain controller, we would have had to request permission and justify the reasons. 

Long term, it is recommended that you do not use the Domain Administrator account as an identity to run services and applications.  Being in this situation makes it difficult to change the password to the Domain Admin account to prevent PDC access in the future.  Instead, an AD group should be created and given permissions as power users or administrators on the required boxes and consultants should be added as members to this security group.