Introduction
Member servers are those servers in your Active Directory environment that don’t provide authentication for domain user accounts. This task is left to the domain controllers. Even though member servers don’t provide authentication for domain users, they still provide essential functions for your company. When it comes down to it, member servers provide the backbone of services, applications, file storage, and more for your company.
Member servers come in all sizes, responsibilities, and functions. Some of the more common tasks that member servers are responsible for include:
- File storage
- Printer management
- SQL Database storage and management
- E-mail management
- Web services
- Applications
- Faxing
- Image management
- Human resource functions
- Financial application functions
With member servers driving and containing such important information and data, it is no wonder that these servers should be at the top of the list when it comes to protecting computers on the network. There are of course obvious security measures that you can take, such as locking the servers in an isolated room and then within a locked cage within the room. However, there are logical configurations that you can also make to help protect these servers. Here, we will expose those areas and discuss the best ways to accomplish securing your member servers.
Security Areas of Member Servers
There are plenty of security areas that need to be addressed when it comes to protecting your member servers. Some of the most important areas are also some of the easiest to configure, once you are aware of the tools available to ensure the security configurations are made correctly. The most important areas that all member servers need protected include:
- Local SAM
- Ports
- Services
- User Rights
- Application permissions
We will investigate each of these areas, exposing the most efficient methods available to configure each member server to ensure the settings are correct and persistent. By far one of the most useful tools for configuring security of member servers, or any computer in the Active Directory network for that matter, is Group Policy. Each of the solutions will include using Group Policy, which is being used more and more by companies today. (To get more information on Group Policy, refer to “The Group Policy Guide,” by Microsoft Press.)
Protecting the Local SAM
The Local SAM on each member server is unique, so every member server must be considered when protecting the assets that reside on the server. The Local SAM contains both configurations and objects which are essential to consider when locking down access to the server. Within the Local SAM, you will want to consider the following areas for protection:
Account Policies – the account policies for the member server control the password policies and account lockout policies for all user accounts stored in the Local SAM. It is a best practice to ensure that the account policies meet or exceed the account policies established for the domain user accounts, which is configured on the domain controllers. By default member servers will have the same account policies as domain controllers, but it is very easy to modify this using a Group Policy Object (GPO).
User Accounts – there is always one user account active on each member server by default, which is the Administrator account. This account needs to be protected at all costs. If an attacker gains control of the server as this account, there is nothing that the attacker can’t do or access. Some best practice settings for protecting this account include: renaming it, not using it for anything but recovering the server, establishing a complex password/passphrase, and disabling it. All of these options are available through a GPO, except for establishing a complex password/passphrase. However, with tools like PolicyMaker (www.desktopstandard.com/policymaker), the password can be set using a GPO setting.
Groups – each member server comes with a suite of local groups. Some groups provide elevated privileges to perform administrative tasks on the server. These groups should be protected and configured properly, to ensure that only the proper users have membership in these groups. There is a GPO setting called “Restricted Groups,” which can control the membership in existing groups, as shown in Figure 1.
Figure 1: Restricted Groups controls the membership in existing groups on a member server
Again, PolicyMaker takes the control of local groups to a new level, allowing for the finite control of the members of the group, including a filter option to target only specific member servers.
Configuring User Rights
User rights are privileges that are configured on a member server by member server basis. Some of the more common, and security sensitive user rights include:
- Backing up files and folders
- Restoring files and folders
- Logging in locally
- Log on as a service
- Manage auditing and security log
- Take ownership of files or other objects
Regardless of the user right, the list of users and groups that have been granted these privileges on member servers should be investigated and controlled. The best way to control user rights for member servers is to use a GPO, as shown in Figure 2.
Figure 2: User rights for member servers can be controlled centrally by using a GPO
Controlling Ports and Services
Often ports and services go hand-in-hand, since some services require the use of certain ports. For example, Internet Information Services (IIS) is responsible for the World Wide Web (WWW) Publishing Service, which relies on port 80 by default. Many services, like IIS and WWW, provide excellent benefits, but can expose security vulnerabilities. If a member server does not require a service or port to be enabled, then the service or port should be disabled.
The control of ports and services is not as simple a task as the others in this article. Services can be controlled by the use of GPOs, but not all of the essential settings associated with services. To control a service it is ideal that you control the service startup mode and service account. The built-in GPO settings for services only supports the control of the startup mode, not the service account. With PolicyMaker, you can include the control of the service account within a GPO.
If you run Windows 2000 Server on your member servers, the control of the ports is a manual process. This can cause some ports to be exposed and thus cause the server to be vulnerable. However, if you run Windows Server 2003, Microsoft has just released a new tool in Service Pack 1 that can help you control both ports and services. The tool is called the Security Configuration Wizard. The wizard creates security policies (which can then be turned into GPOs) which enable and disable the appropriate ports and services, depending on which roles the server is responsible for. (For more information about the Security Configuration Wizard, refer to https://techgenix.com/Security-Configuration-Wizard-Windows-Server-2003-SP1/).
If you want to control ports and services independent of the roles that Microsoft has specified, you can read up on which ports and services are essential and what each is responsible for providing in Microsoft’s Security Guides (which can be located at http://www.microsoft.com/technet/security/topics/ServerSecurity.mspx).
Application Level Security
For your member servers that run one or more applications, you might be stuck in a common situation. Basically, you want to have one or more users have administrative control over the application, but not the server. With the built-in configurations that Microsoft provides, there is no method to specify that a user has administrative control over one application, but not the server. If you are in this situation, your best solution is to attempt to place the user in the Power Users group on the member server, and hope that this is enough privilege to run the application. If not, then you might need to add the user to the Administrators group to provide them with the proper privilege to support the application.
If you want to take your solution to the next level, install Application Security (http://www.desktopstandard.com/PolicyMakerApplicationSecurity.aspx) to control which groups can control which applications, on a server-by-server basis. This will take the security of your application servers to a whole new level, allowing full control of who can administer which applications.
Summary
Member servers are responsible for most of the companies data, financial applications, HR resources, and other mission critical company resources. It is essential that member servers are protected to ensure that the data they house remain protected from attackers. This is best accomplished by utilizing the built-in GPO settings, and can be expanded by using some excellent third party GPO extension tools. After the Local SAM, user rights, ports, services, and applications are protected, you are well on your way to making your member servers well protected.
