I know you folks were all losing sleep over this so here is the $245 MS PSS answer (actually, they non-decremented this one). The setting is Microsoft network client: Digitally sign communications (always), which was enabled by the Enterprise\High Security templates. This can be disabled using Local Security Policy and drilling down through Security Settings - Security Options - Microsoft network client: Digitally sign communications (always).
This was one of the settings that I modified while troubleshooting the problem. The reason it did not fix the problem is that this is one of a handful of settings that do not take effect until the next reboot, which I did not do while trying to track this down. According to the Microsoft folks they do not have a list of settings that do or do not require reboots. Their rule of thumb is that if the setting is related to a service that can be restarted via the Services control panel then a reboot is not required - these services re-poll the registry periodically. If the setting is specifically related to LSASS, the kernel, or Winlogon then a reboot is necessary, as they only check the registry at system startup. However, they did not point me to a good tool to determine if a particular setting related to those three items or not. So the bottom line is that when you use pre-defined templates to do a mass update of security settings, something breaks, and you are making individual changes to determine which new setting is causing the problem, a reboot is the foolproof ticket to knowing that the change has taken effect. Jon -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin, Jon Posted At: Tuesday, January 20, 2004 5:13 AM Posted To: exch list Conversation: OT: Win2k3 Security Settings Break PerfMon Subject: OT: Win2k3 Security Settings Break PerfMon OK, here is (in my opinion) a weird one. Microsoft has published the Microsoft Windows Server 2003 Security Guide (at http://www.microsoft.com/technet/security/prodtech/win2003/w2003hg/sgch0 0.asp) and along with it, a bevy of security templates which automate the implementation of the majority of the recommendations in the guide. We applied each of the three templates (Legacy Client, Enterprise Client and High Security) for member servers to a test box. When either the Enterprise Client or High Security templates are in place, I am unable to use PerfMon from that newly-secured server to monitor any remote servers, except the AD domain controllers. (Applying the Legacy Client template does not affect the ability to use PerfMon from the secured server to monitor other servers in our company.) This seems odd for two reasons. One is that applying the security templates to the server should make that server more secure (which it does), not make it more difficult to monitor other non-template-secured servers from my secured server. Also, the most important servers in our company - the AD domain controllers - are immune from this reverse-security fallout. Obviously one (or more) settings in the Enterprise Client and High Security templates is preventing me from using that secured server to monitor other servers; the question is which one of the 12,000 changes (he says facetiously) is causing this problem? Focusing on settings that were different between the Legacy and Enterprise/High combo, I reversed a wide variety of settings related to communication issues (digitally encryptions, signatures, secure channels, etc) that would seem to be potential candidates, without success. (It is possible that these changes never took effect. My method was to make the change and the reload the policy in GPEDIT.MSC, run GPUPDATE at a command prompt, recheck the settings in GPEDIT.MSC, and then use PerfMon to attempt to check the remote servers. If this method is faulty then maybe I made the appropriate change but it never took hold.) In any event, I am stumped so I thought I'd ask the experts here if anyone knows of the magic local setting(s) that affect the ability to monitor remote servers from a local machine?? Thanks . . . Jon _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchange&text_mode=&; lang=english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED] To unsubscribe via postal mail, please contact us at: Jupitermedia Corp. Attn: Discussion List Management 475 Park Avenue South New York, NY 10016 Please include the email address which you have been contacted with. _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchange&text_mode=&lang=english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED] To unsubscribe via postal mail, please contact us at: Jupitermedia Corp. Attn: Discussion List Management 475 Park Avenue South New York, NY 10016 Please include the email address which you have been contacted with.
