Securing Windows Server 2003: Controlling The Administrator Account

In my last column, we investigated how we can lock down the Domain Admins Group on the domain; restricting network logon to only secure service administration workstations. As previously discussed this practice prevents the misuse of the Domain Admins privileges because membership of this group will not get the user (or abuser) access to the server. This practice reduces the attack surface against domain controllers and critical servers by a huge margin because it removes the utility of an interactive user interface or logon. It is difficult to attack what you cannot see, even if you do possess the correct password.

This practice also allows you to freely create service accounts that require Domain Admin rights and give them to engineers without the worry they will be used to access other services on the network. The account can thus be used for the service account requirements but it cannot be used to logon to a server, especially a domain controller.

Here's an example of such abuse: A network engineer requires an account with membership in Domain Admins for a service account used by a new firewall application running on a gateway or DMZ server. Soon after the firewall is installed you notice that the service account is being used to logon to other servers that have nothing to do with the firewall service. By preventing logon by Domain Admins you prevent this from happening.

Before we look at best practices for securing the Administrator account let's revisit our discussion with some tips and suggestions on group policy.

When you enable the "Deny logon locally" right in a GPO at the domain level the policy will affect all computers in the domain until the policy encounters another GPO either at the domain level below it or in some other OU below the domain level that at has a GPO linked to it.With group policy, the GPO settings that apply to computer and user objects are the ones that apply last. For example, in a GPO hierarchy of domain level "Default Domain" GPO, then Domain Controllers OU level, "Default Domain Controllers" GPO any settings enabled for Deny logon locally for the later domain controllers policy will be the settings that will apply.

Thus if you want to be sure that the Deny logon locally setting at the domain level propagates to the Domain Controllers, thus preventing direct logon to the DCs by Domain Admins members, either leave the policy undefined (so that the higher level policy is applied), or repeat the setting in the Domain Controllers GPO or another GPO linked at the Domain Controllers OU, which will apply after the Default Domain Controllers GPO is applied.

It is also better to create new GPOs for the Deny Logon Locally right no matter where you link the GPOs in the domain. This allows you deactivate the GPO with this single setting enabled if you have to without affecting other GPOs, especially the default ones that may have critical domain and security settings in place.

You will notice using the methods described here and in the previous article that the GPO prevents local logon to the actual console. It does not affect local logon over a terminal server connection. The reason for this is simple. A separate policy setting exists for remote logon. To block Domain Admins from logon over a terminal server connections enable the Deny logon through Terminal Services setting in the same GPO as the Deny logon locally setting. By enabling both settings members of Domain Admins will not be able to logon to a server either at the console or over a terminal connection.

Finally, here's an important tip to consider when locking down the Domain Admins as described here and in the last column. Do not remove the Domain Admins group from membership in the local Administrators group, especially through the use of the Restricted Groups policy you will find in a group policy object. If you do this you might find certain software and processes unable to work because they need access to the local Administrators group and they get this though membership in Domain Admins. This will not affect the deny logon effect.Securing Administrator
Now let's look specifically at the Administrator account. This account on the domain is a built-in account that gets its powers through its membership in key administrator groups, the most powerful being the Administrators group. This account is not the same administrator account you see on workstations and servers. The latter Administrator account is a member of the local machine's built-in Administrators group and thus has no access to domain objects.

However, the domain Administrator account has access to servers and workstations by its membership in Domain Admins. The Administrator does not need to be a member of Domain Admins to be affective on the domain. You can thus safely remove Adminstrator from Domain Admins. If you leave it in Domain Admins then Administrator will also be prevented from local logon everywhere except the protected service administration workstations.

Note: You cannot directly prevent Administrator from logon. Active Directory will tell you this if you try to directly add the Administrator to the GPO setting "Deny logon locally." However, you can still prevent the logon by making the Administrator account a member of Domain Admins.

Preventing local logon by the Administrator adds extra security in that if anyone gains access to this critical account they will not be able to logon anywhere. However, you should be comfortable with the practices described here and be sure that the Administrator can logon at the secure service administration workstations. At the least you can prevent remote logon by the Administrator though terminal services.

Now, despite the existence of the Administrator account adopt the practice of never using the account after the first domain controller is installed and a domain is created. You need to start somewhere with a new domain and if you don't have a domain you also don't have a domain controller and a Domain Admins group. As soon as a domain is created and the first domain controller exists in the domain, the Domain Admins privileges used via logon to the secure admin workstations are sufficient for all of the administrative tasks on the domain.When I create domains or take over the administration tasks on an existing domain the Administrator account is given a highly complex password, and then the account details are locked in a safety deposit box, vault or safe somewhere. I never use the Administrator account and therefore I have no idea what the Administrator passwords are for any of the domains I manage. This is a very valuable practice you would be well advised to follow. After you create a domain you just don't need the Administrator account, period. The only time you may need the Administrator account is in the unfortunate event you lock Domain Admins completely out of the domain by removing domain logon access to the service administration machines . . . a bad mistake.

If you manage a large network and are migrating to a Windows Server 2003 domain seriously consider the security benefits of a root domain. We won't go into the pros and cons in this article except to say that with a root and child domain you can safely prevent the Administrator of the child domain from local logon along with the child domain's Domain Admins group. The reason is simple. The administrators in the root domain are able to access administrative groups in the child domain. So in this case you don't need to worry that the child domain's domain Administrator cannot logon to any machine on the network. Your back door is the root domain. Using group policy settings you can rename and in effect hide the Administrator account. You can further confuse a potential hacker by creating a dummy Administrator account. This procedure is giving a lot of play in a number of books and by Microsoft. I have renamed several administrator accounts only to discover the renamed account under attack and the dummy account hacked and renamed by the hacker in defiance.

An attack on the inside of the network or a clever hacker using a variety of tools and techniques will easily discover the real Administrator account simply because the security identifier (SID) of the Administrator account always remains the same. It is the SID that has the privileges and no amount of hiding and renaming will change that. You can also hide the account in some obscure OU somewhere; it will take a couple of seconds for a hacker to find the account and begin a crusade to crack its password.

For this reason I don't really bother with renaming or hiding the Administrator account and more. In fact I leave it in plain sight and monitor the attempts to crack its password. By limiting where the Administrator can logon you are already doing more to protect the Administrator than any amount of renaming or hiding will do. Of course there is more you can do to secure it.

As discussed earlier give your Administrator a highly complex password (such as &%$#F)s%#d45sa5$d(*&#s23h5). If you follow good practice and never use the Administrator account then you will not need to memorize the password or store it somewhere it can be found.Getting Smart with Smart Cards
If the long and complex password and logon restrictions are still not secure enough you can make it impossible to use the account and crack its password by requiring the Administrator and all members of Administrators and Domain Admins to use smart cards. A smart card is a device that typically looks like a credit card and stores the private keys and digital certificates that are associated with the account in Active Directory.

In order for an account to be authenticated both the password for the card and the digital certificate stored on the card must be presented at the logon screen. This combination of authentication "bits" makes it impossible for a hacker or imposter to attack the account short of pick pocketing the network engineer and grabbing his or her smart card (and they you still need to crack the password on the smart card). If you try to crack a smart card the card locks up after a number of attempts (typically three) and is rendered useless.

Some companies give smart cards to every employee, which can be a little expensive. However, if you manage a large and complex network with a large IT department that employs a large group of server and domain administrators then you should seriously consider smart card technology.

Smart card technology has come a long way. Instead of using the traditional credit card smart card, which requires a special slot to be installed in the machine to read the card, you can use a so-called token device which works with USB technology. Every machine nowadays is equipped with USB ports, including servers, so you don't have additional costs and burden of installing card readers. The tokens are small and can be attached to key rings and carried with you when you leave your desk.

Smart cards are also great for security the service administration workstations because you can force the machine to lock down up as soon as you extract the card.In order for the smart card to be used at the servers and secure workstations you need to install the necessary drivers on the machines and the login screen software that will recognize the insertion of the card or token. The login software simply hooks into the Graphical Identification and Authentication (GINA) library in Windows and replaces the standard login screen to prompt for the smart card password.

Implementing smart cards is not difficult and not very expensive if you need to issue between 10 and 20 cards. The difficult and time consuming part is installing the public key infrastructure (PKI) required to support the digital certificates that get issued for the cards and tokens. This might be a no-brainer for you if the security department has already installed a PKI and the certificate authorities (PKI servers) are already on your network. Adding the necessary smart card certificate templates to the CA is not a difficult task.

To associate a smart card with the Administrator account or a member of Domain Admins open the account properties in Active Directory Users and Computers and click on the Account tab. In the list of account options associated with the user simply select check "Smart card is required for interactive logon." Almost instantly your administrator accounts will need a smart card or token to logon to the domain.

Coupled with the restricted logon scenario we have implemented in group policy you now have an infallible system to prevent abuse and attack of the Administrator and administrative accounts on your network.

Server Pipeline columnist Jeffrey R. Shapiro is the co-author of Windows Server 2003 Bible (Wiley) and is an infrastructure architect who manages a large Windows Server network for an insurance firm.0