Win2k3 Security Settings Break PerfMon

[Jon Martin]

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/sgch00.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 revesed 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 . . .

 

[Steven Umbach]

You didn't say what the operating system is of the servers you are having
difficulty with, but I suppose they would be W2K/W2003. Anyhow my guess is that
it is a security option. You mention that it is odd that increasing security
would make it more difficult to communicate with another server. But not really
if you think about it. The new template is probably not allowing communications
with another server that can not comply with it's higher standard such as smb
signing, so it refuses communications with it. My guess is that it is either a
problem with "digitally sign" communications security options in that the
enterprise and high secure templates require always or network security: minimum
session security for ntlm ssp which may be too high for the other non dc
servers. Network security:lan manager authentication level, is another possible
though less likely area. I would first check that the other servers can
digitally sign communications in their security policy. --- Steve

 

[Jon Martin]

Steve,

Thanks for the reply - you were right on with your answer, but there
is a catch, as detailed below.

Here is the $245 MS PSS solution (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.

 

[Steven Umbach]

Thanks for posting back. Using secedit or gpupdate is supposed to refresh most
everything, but I have found that reboot is usually the only way to be sure and
even then things do not always appear as they seem in the settings and running
Security Configuration and Analysis Tool is often helpful. --- Steve