Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Download
Standard view
Full view
of .
Look up keyword
Like this
9Activity
0 of .
Results for:
No results containing your search query
P. 1
Security Best Practices for Windows 2000 and Windows Server 2003

Security Best Practices for Windows 2000 and Windows Server 2003

Ratings: (0)|Views: 605|Likes:
Published by api-3852474

More info:

Published by: api-3852474 on Oct 19, 2008
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

03/18/2014

pdf

text

original

TechNet Home> Products & Technologies> Server Operating Systems> Windows Server 2003> Clustering Services
Server Clusters: Security Best Practices for Windows 2000 and
Windows Server 2003
Published: January 1, 2003
On This Page
General Assumptions
There are a number of general assumptions and operational best practices that should be in place for the
infrastructure to ensure a secure environment in which to run Server clusters.
Top of page
Deployment and Operational Management
Cluster administrators

Administrators can specify groups or individuals that are allowed to manage the cluster. In current versions of Server cluster, there are no fine granularity of control; either a user has rights to administer the cluster or the user does not. To grant a user or group rights to administer the cluster, the user or group must be added to the

General Assumptions
Deployment and Operational Management
1. Servers and storage are in physically secure locations.
2. Practical security implementations to detect irregular traffic, such as firewalls, network probes and
management tools, are in place.
3. Best practices/ common sense in terms of security are adhered to in areas like administration, storage of
logs, backup and restore etc.
4. Platform level security best practices are adhered to in terms of assigning administrative permissions,
ACLing resources, and other housekeeping roles.
5. The network infrastructure services such as Active Directory, DNS, DHCP, WINS etc. must be secure. Any
compromise of these infrastructure services can lead to a compromise of the cluster service itself.

6. The cluster administrator must ensure that applications that call the cluster APIs (ClusAPI) are run from trusted computers. Any compromise on the computers on which the applications are executing (that the cluster administrator runs) can compromise the cluster. For example, if there are untrusted users with elevated privileges on the workstation from where the administration tools are run, untrusted or

malicious code can be run against the cluster by the cluster administrator without the cluster
administrator realizing.

7. Access to the set of objects created and maintained by the cluster service must not be compromised by
adjusting the default settings placed on these objects to a less restrictive setting. The cluster service
utilizes a set of objects in the operating system such as files, devices, registry keys etc. These objects
have a default security setting that ensures non-privileged users cannot impact the cluster configuration
or the applications running on the cluster. Changing these security settings to less restrictive security
settings can lead to the cluster being compromised and the application data being corrupted.

Page 1 of 17
Windows Server Clusters: Security Best Practices
29/01/2005
htt ://www.microsoft.com/technet/ rodtechnol/windowsserver2003/technolo ies/...
cluster security descriptor. This can be done through cluster administrator or the cluster.exe command line tool.
Note: Apart from the local Administrators group on a node, all other members of the cluster security
configuration MUST be either domain user accounts or global groups. This is to ensure that the account is the

same, well defined and authorized account on all nodes in the cluster.
By default, the local Administrators group is added to the cluster service security descriptor.
Adding a user or group to the cluster security descriptor means that the user can manage all aspects of the

cluster configuration including (but not limited to):
Because of the scope of impact on the applications and services running in the cluster, careful consideration
must be taken when adding a user to the cluster security descriptor.

The cluster service runs the code associated with a resource under the cluster service domain user account (this should not be confused with the account used to administer the cluster). Since a cluster administrator can add new resources to a cluster and since those resources run as the cluster service account, a cluster administrator can install code that runs with local administrator rights on the machine.

Best Practices
Remotely managing and configuring clusters

Administration tools or other applications that call the Server cluster APIs (ClusAPI) can be run from remote
workstations. The general assumption is that the cluster administrator must ensure that the applications are run
from trusted computers. Any compromise on the computers on which the applications are executing (that the
cluster administrator runs) can compromise the cluster.

When a cluster is created or the configuration is changed (such as adding a new cluster node), the Cluster
Configuration Wizard will create a log file on the machine on which the wizard is run so that in the event of
failures, the administrator can use the log for debugging and troubleshooting. This log file can contain cluster
configuration data such as cluster IP addresses, network names etc. This data could be used to extend the
attack surface if it is read by unauthorized users.

Cluster service account

The cluster service account is the account under which the cluster service is started. The credentials for this account are stored in the service control manager (SCM) which is the Windows component that is responsible for starting the cluster service when the cluster nodes are booted.

The cluster service account must be the same on all nodes in a cluster and it must be a domain-level account

that also has local administrative rights to each node in the cluster. The domain account must exist before the cluster is created and the Cluster Configuration Wizard will prompt you for an existing account to be used. If the account is not already a member of the local Administrators group, the Cluster Configuration Wizard will

\u2022Taking resources offline and bringing resources online
\u2022Shutting down the cluster service on nodes
\u2022Adding and removing nodes from the cluster
\u2022Adding and removing resources from the cluster

\u2022Cluster administrators should use a different account than the cluster service account to administer the
cluster. This allows different policies (such as password expiration etc.) to be applied separately to the cluster
service account and the domain account(s) used to administer the cluster.
\u2022You should only add users with local Administrator rights to the cluster service security descriptor.
Note: By adding a domain user or global group to the local Administrator group, that group or account will
automatically be a cluster administrator.
\u2022Do not remove the local Administrator group from the cluster service security configuration.
Page 2 of 17
Windows Server Clusters: Security Best Practices
29/01/2005
htt ://www.microsoft.com/technet/ rodtechnol/windowsserver2003/technolo ies/...

automatically add it to the local Administrator group when the cluster is created. Likewise, when nodes are added to the cluster, the cluster service account will be added to the local Administrators group. If a node is evicted from a cluster or the last node is removed, the cluster service account is not removed from the local Administrators group.

You need to be aware of these semantics to avoid unintentionally granting a domain account local administrator
rights to a given set of nodes.
Note: Evicting a node from a cluster does NOT remove the cluster service account from the local Administrators
group. When you have removed a node from the cluster, you should manually remove the cluster service
account from the local Administrators group to avoid having stale accounts with local administrator rights to a
m achine.

The nodes in a Server cluster use authenticated communication mechanisms to ensure that only valid members of the cluster can participate in the intra-cluster protocols. It is essential that each node in the cluster has the same cluster service account in order to provide authentication consistency. It is also a requirement of the cluster service account password utility introduced in Microsoft Windows Server 2003.

Required Privileges
As well as being a member of the local Administrator group, the cluster service account requires a set of
additional, locally granted privileges:
You should NOT remove any of these privileges from the cluster service account. If you remove any of these
required privileges, the cluster service may not start up or operate correctly.
During the cluster server setup process, these privileges are granted locally to the account. If you ever need to
manually re-create the cluster service account, you must also grant these additional privileges. KB article
269229: How to Manually Re-Create the Cluster Service Account describes the steps necessary to re-create the
cluster service account.
Passw ord Policies

The cluster service account is just like any other domain account, it has a password that can have password
expiration policies associated with it. If the password has expiration policies assigned to it, then the cluster
account password must be changed before it expires. Failure to do so will cause the cluster to stop functioning
when the password expires (since the intra-cluster communication can no longer be successfully authenticated).

Changing the Passw ord
In most production deployments, domain accounts will have password expiration policies that force the
password to be changed relatively frequently (for example every 30 days). Changing the cluster service account
password requires careful planning.
Window s 2000
The cluster service account on ALL nodes in the cluster must match to ensure that the intra-cluster

\u2022Act as part of the operating system (required for Windows 2000 and beyond).
\u2022Back up files and directories.
\u2022Increase quotas.
\u2022Increase scheduling priority.
\u2022Load and unload device drivers.
\u2022Lock pages in memory.
\u2022Log on as a service.
\u2022Restore files and directories.

Page 3 of 17
Windows Server Clusters: Security Best Practices
29/01/2005
htt ://www.microsoft.com/technet/ rodtechnol/windowsserver2003/technolo ies/...

Activity (9)

You've already reviewed this. Edit your review.
1 hundred reads
1 thousand reads
Lotus Perfaction liked this
Gbenga Oyebade liked this
ananthakrish77 liked this
Mian liked this
imboise liked this
aeganhot123 liked this
imboise liked this

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->