By now, if you've no doubt heard the claims that Microsoft is designing Longhorn Server with security as the top priority. One of the cornerstones of this new security model is something called role based security. Although Windows Server 2003 does not use Longhorn Server's a role based security model it is possible to structure your Windows Server 2003 machines in a role based manner similar to the one that Longhorn Server will use. In this article, I will show you how.
What is role-based security?
Before I get started, I want to talk a little bit about role based security. The basic idea behind role based security in Longhorn Server is that you'll be able to tell Longhorn what roles the server will be performing (file server, domain controller, DNS server, etc.) and Longhorn will set the security accordingly.
There are at least a couple of reasons why role based security is advantageous. In the case of Longhorn Server, this type of role based configuration greatly simplifies the server configuration process. For example, have you ever attempted to install some server component, only to discover that there was an underlying dependency that needed to have been installed first? In Longhorn Server, configuring the server to perform a specific role will automatically install all of the necessary components, including dependencies. This allows you to be confident that the server has everything that it needs to perform the task at hand.
The flip side to this is that while the server has everything that needs, it doesn't have anything that it does not need. This is important for security reasons. There is a law of computing that states that the larger the code base that is executing on a machine, the greater the chance that the code will contain a security vulnerability that can be exploited. By removing any system services or components that are not necessary, you decrease the size of the running code base, inherently improving security in the process. A nice side effect is that by disabling any unnecessary system services, you will also improve the server's performance to some degree because it no longer has to dedicate processor time or memory to those services that have been disabled.
Organizing servers by role
In Longhorn Server, you will be able to use a utility called the Server Manager to add and remove server roles. When you do, the server's security will be configured automatically to support those roles. Unfortunately, Windows Server 2003 does not offer a comparable mechanism. You can implement role based security in Windows Server 2003, but it must be done manually.
One of the best ways of implementing role-based security in Windows Server 2003 is to begin by creating a baseline security policy. This baseline policy should be a general policy that can be used to harden all of your servers, regardless of their roles. Once the baseline policy has been established, then you can create containers in the Active Directory that will correspond to various server types. You would then apply the baseline security policy to each of these containers, and then modify the policy based on the role that the container corresponds to.
Keep in mind that by default the Active Directory places all servers into one of two containers; Domain Controllers and Computers. At first, it might seem logical to apply a domain controller specific policy to the Domain Controllers container and then apply a more generic baseline policy to the Computers container. There are a couple of reasons why you can do this though. First, group policies cannot be applied to the Domain Controllers container or to the Computers container. Group policies can only be applied to a Local Computer, site, domain, or Organizational Unit. Even if it were possible to apply a group policy to the Computers container, the Computers container also contains workstations. You would not want to apply a generic server policy to container containing workstations.
If you want to create specialized containers for the various server roles, then you really have two options. One option is to organize the servers into resource domains. A resource domain is just like any other domain, except that it does not contain users. The basic idea behind using resource domains is that you can apply a group policy to a domain. That being the case, you could create a domain for your file servers, another domain for your application servers, etc. There are a couple of issues with creating resource domains though. First, like any domain, resource domains require domain controllers. There is obviously some cost associated with purchasing and deploying these domain controllers.
Another issue is that in some cases establishing cross domain security can be a little bit tricky to get right. Remember that a resource domain does not contain any user accounts, so you'll have to use cross domain permissions in order to provide users with access to resources on the servers.
Your other option for organizing servers by role is to create a separate Organizational Unit for each role, and then move the servers into that Organizational Unit. In my opinion, this is the best way to get the job done because it is less expensive and less complex than creating resource domains.
Creating a baseline security policy
Now that I have talked a little bit about how you can organize servers by role, I want to turn my discussion to creating a generic baseline policy. Before I start going through individual policy settings, I just want to mention that although I have attempted to make these policies as universally useful is possible, they are not going to be appropriate for every organization. You may find that you have to fine-tune my generic security policy to better fit your organization's needs.
Creating audit policies
The first thing that I recommend defining within a baseline security policy is some audit policies. There are a couple of reasons for this. First, being that we are creating a new security policy, we will need information regarding how well that security policy is working. Audit policies provide us with this information. The second reason for creating an audit policy is so that if a security breach ever does occur, you'll have some forensic evidence that you can use to figure out what happened.
Before I show you how to create an audit policy, I want to point out that when it comes to auditing, less is more. When you create an audit policy, it is easy to audit so many events that a huge number of log file entries are produced. When this happens, the log files become almost useless because they contain so much information that it is almost impossible to find what you're looking for. Excessive auditing also kills a server's performance. As such, I recommend taking a minimalist approach to auditing.
You can access audit policies by opening the Group Policy Object Editor and navigating through the console tree to Computer Configuration | Windows Settings | Security Settings | Local Policies | Audit Policy. The Audit Policy container contains nine different audit policies that you can set. For each of these policies, you can enable success and/or failure audits. For example, the first item on the list is audit account logon events. If you were to audit successful account logon events, the audit log would create an entry any time someone logged in. If, on the other hand, you were to edit failures then a log entry would be created any time that a failed logon attempt occurred.
I tend to take a conservative approach to auditing in an effort to avoid having excessive log file entries. Below I have listed my recommended audit settings. You may wish to increase auditing on your own system though. My recommended audit settings are:
- Audit account logon events: Failure
- Audit account management: Success and Failure
- Audit directory service access: No auditing
- Audit logon events: Failure
- Audit object access: No auditing
- Audit policy change: Success and Failure
- Audit privilege use: Success
- Audit process tracking:No auditing
- Audit system events:No auditing
Disable system services
At the beginning of this article, I talked a lot about reducing the size of the executable code base. One way of accomplishing this is to disable any system services that are not specifically needed. Obviously, this is a little bit tricky because everybody has different needs for their servers. Remember though, that the basic idea is to create a secure generic baseline policy. You can re-enable any necessary services and the policies that apply to a specific server role that needs those services.
You can configure the state of each system service by navigating through the Group Policy Object Editor to Computer Configuration | Windows Settings | Security Settings | System Services. When you select the System Services container, the details pane will display a list of all of the system services. You can set the startup mode for each service. There are three different startup modes to choose from; Automatic, Manual, and Disabled.
If a service is set to start automatically, then the service will be initiated at boot up. There are some services that absolutely have to be set to use an automatic startup in order for a Windows to function correctly.
Other services tend to be used from time to time, but do not necessarily need to be running all the time. You can set these types of services to use a manual startup mode. Contrary to the name, you will not have to manually start services set to use a manual startup. Instead, Windows starts the services automatically, but does so at the time they are needed rather than at system boot up.
The last type of startup mode is disabled. If you set a service to disabled, then Windows will not start the service under any circumstances. Even if you attempt to start the service manually, you will not be able to start the service until you change its startup type.
Now that I have discussed the various service startup types, here is a list of my recommendations for the various system services and their startup types:
- Alerter Disabled
- Application Management Disabled
- Automatic Updates Automatic
- Background Intelligent Transfer Service Manual
- Clipbook Disabled
- COM+ Event System Manual
- Computer Browser Automatic
- DHCP Client Automatic
- Distributed File System Disabled
- Distributed Link Tracking Client Automatic
- A distributed Transaction Coordinator Disabled
- DNS Client Automatic
- Event Log Automatic
- Indexing Service Disabled
- IPSec Service Automatic
- License Logging Disabled
- Logical Disk Manager Automatic
- Logical Disk Manager Administrative Service Manual
- Messenger Disabled
- Net Logon Automatic
- NetMeeting Remote Desktop Sharing Disabled
- Network Connections Manual
- Network DDE Disabled
- Network DDE DSDM Disabled
- NT LM Security Support Provider Manual
- Performance Logs And Alerts Manual
- Plug And Play Automatic
- Print Spooler Disabled
- Protected Storage Automatic
- Remote Access Auto Connection Manager Disabled
- Remote Access Connection Manager Disabled
- Remote Procedure Call Automatic
- Remote Registry Automatic
- Removable Storage Disabled
- Routing and Remote Access Disabled
- Secondary Logon Disabled
- Security Accounts Manager Automatic
- Server Automatic
- Smart Card Disabled
- System Event Notification Automatic
- Task Scheduler Disabled
- TCP/IP NetBIOS Helper Automatic
- Telephony Disabled
- Terminal Services Manual
- Telnet Disabled
- Uninterruptible Power Supply Disabled
- Windows Installer Manual
- Windows Management Instrumentation Automatic
- Windows Management Instrumentation Driver Extensions Manual
- Windows Time Automatic
- Workstation Automatic
As you create this policy, there are two extremely important things that you must keep in mind. First, I can almost guarantee that there will be services listed in the Group Policy Object Editor that are not on my list. The reason why this occurs is because many software applications installed services of their own. Anytime a new service is installed on a server, the service is also listed in the Group Policy Object Editor. My advice for services that I have not specifically listed is that you should leave them alone.
The second thing that I need to explain is that you should not actually create this policy until you are ready to create the role based policies that alter the baseline policy. The reason why I say this is because some of these policy settings will break things. For example, you might have noticed that I recommended disabling the Distributed File System service. If you happen to have a file server that depends on the Distributed File System, then disabling the Distributed File System service will cause that server to malfunction. The same could be said for several of the other services that I have recommended disabling.
Keep in mind that my point in listing all of these services was to disable anything that is not going to be used globally throughout the servers in your organization. That's not to say that services that I have recommended disabling are not in use on any of your servers. That's why it is so important that you not put this policy into effect until you have had a chance to adapt it to the various server roles.