Everyone seems to feel a bit guilty after I ask these next few questions. The two questions are:
- When was the last time you changed the password for all Administrator accounts on your network?
- When was the last time you changed the password for all service accounts running on servers throughout your network?
If you said anything but “in the last month”, your network is exposed and vulnerable. However, by the end of this article you will have the knowledge, desire, and solutions to answer these questions with a greater desire.
Evaluating the Threat
The reason that the two questions are dealing with the Administrator account and service accounts is due to the privileges that these user accounts have on a computer and on the network. The Administrator account is a very special account, as we all know. This account has super-human powers and can control almost anything that steps into its path. Most of the administrative privileges given to Administrator can’t be taken away. This includes the ability to create user accounts, the ability to logon to a domain controller, etc. For those privileges that can be taken away from the Administrator, the denial of access is not permanent. Administrator can always gain access to anything within its realm of power.
Due to this great power, the Administrator account is the golden egg for most attackers. Gaining access to a computer, server, or network as Administrator is the ideal result from an attack on the system. To help the attackers in their endeavor, there is a built-in configuration that pinpoints the Administrator account within a Windows environment. Every user account has a Security Identifier (SID) associated with it so the operating system can track it. The Administrator account always has a SID that ends with 500. This is for all Administrator accounts on a Windows computer. This gives the attacker leverage in tracking down the username of the Administrator, if the user account is renamed.
With regard to service accounts, the power that they possess is nearly that of the Administrator in most cases. When a service account is configured on a server, it is almost always given elevated privileges. These privileges might include the ability to logon locally, backup files, access the system, or have membership in one or more “Admin” groups. With this excessive power, attackers stalk service accounts to gain privileged access to the system.
How Many Administrator Accounts do You Have?
To gain the full appreciation for the issue with the Administrator account password, consider how many Administrator accounts you have on your network. I will make the assumption that you no longer have Windows 95, 98, or Me clients. With that assumption, you are running Windows NT Workstation or greater on the desktop. These clients all have a local Administrator account. That means that you need to consider not only the Administrator account that lives in each Windows Active Directory domain, you also have an Administrator account on every desktop and server. For some companies, that is 10,000 Administrator accounts or more.
Before we talk more about the local Administrator on each client, there are some key points to discuss with regard to the domain Administrator. First, it is ideal that you don’t use this account, except for in the case of troubleshooting the domain or Active Directory. This means that this account should not be used to logon for anything. This allows you to create a very complex password, possibly even generated by a third party program solely dedicated to the task.
To continue with the list of things that are taboo with regard to the domain Administrator, you should not use this account as a service account. Although common and a default for many applications, this is a dangerous practice based on the information that you are reading about the Administrator and service accounts in this article. Finally, you can go to the extreme to disable this account through Group Policy. A great configuration, but one that should be preceded with the creation of another user account that is placed in the Domain Admins (or Enterprise Admins) group.
With only a few domain Administrator accounts and the best practice of not using the account for production, it is rather easy to change the password for these accounts on a regular basis. Therefore, I want to focus primarily on the local Administrator accounts on the clients and servers in your enterprise. With thousands of these accounts, it is no easy task to consider changing the password on a regular basis. There are some scripts that have attempted to tackle this dilemma. However, since scripts rely on an event (typically the computer restarting) to apply, it might take months for the password to ever get changed.
The great thing is that there is a solution to this age old dilemma. The key is to rely on the built-in technology that we all have grown to know and love: Group Policy. With a solution in place from DesktopStandard, an administrator can configure a single policy setting which will effectively change the password on all computers in the entire domain within 90 minutes. With security at the forefront of everyone’s mind, the password can either be consistent on every computer, or it can be configured to be similar for each department. This is possible through the flexibility of Group Policy and the ability to target specific objects through the Active Directory design.
The solution from DesktopStandard is called PolicyMaker, which can control the local Administrator fully, as shown in Figure 1.
Figure 1: PolicyMaker can change the local Administrator password easily
Now, there is no excuse to not change the password on all of the Administrator accounts on a regular basis, preferably every 30 days or more frequent.
Getting to Those Hard to Reach Service Accounts
A bigger task than the Administrator password, not to say that is an easy task, is to change the password for the service accounts throughout your enterprise. These service accounts run key services on servers such as Exchange, SQL, IIS, backup programs, etc. Most of these applications (services) use a user account from the domain as the service account. This makes the altering of the password for the account rather easy. The big issue comes when every server that relies on that account must be reconfigured with the new password. In some cases, this can be hundreds of computers. Since the service account and its password is tucked inside the service configuration properties, the task of regularly changing the password for the service account is typically avoided.
This of course leaves the service, computer, and network in a vulnerable state. To change the password for the service account that resides with the service on a regular basis would increase security greatly. The good thing is that PolicyMaker can also handle this task. PolicyMaker can control almost any aspect of the service, running on any computer. The service account can be established (or targeted if already established) and the password changed within the service, as shown in Figure 2.
Figure 2: The password for the service account can be changed within the service on any target computer
With this new solution, there is no reason that the service account passwords should go unchanged for any length of time that is insecure. The ability to target any server, or group of servers, using Group Policy filtering or PolicyMaker filtering, gives the administrator ultimate control over which servers are affected.
The issues of Administrator and service account password staleness are a worldwide concern. I have not met any administrator that has a solution that works efficiently and effectively. When I ask the two questions to my customers and students, they all give me the same level of answer, because they have not seen a solution to make the task easier. Even though you answered the initial two questions with an answer that you are not particularly proud of, you now have a solution to your password changing issues. By using Group Policy, you can quickly and efficiently affect all clients and servers to update the appropriate password. To top off this never before possible feat, the updates are automatically processed by the target computer within 90 minutes of being configured in the Group Policy object on the domain controller. This obviously meets and beats every company’s security requirements and standards.