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/sec...3hg/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 . . .

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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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/sec...3hg/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 . . .

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" <(E-Mail Removed)> wrote in message news:<m1KPb.99842$sv6.429691@attbi_s52>...
> 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" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > 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/sec...3hg/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 . . .

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

"Jon Martin" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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" <(E-Mail Removed)> wrote in message
news:<m1KPb.99842$sv6.429691@attbi_s52>...
> > 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" <(E-Mail Removed)> wrote in message
> > news:(E-Mail Removed)...
> > > 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/sec...3hg/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 . . .