In my last checklist, I provided a basic overview for locking down standalone computers, workgroup computers and Active Directory domains by
Now it's time to dig into the details. As I review the following three Security Options, you should come to understand why they are called "options." In other words, good security should not be optional, but the definition of "good security" will vary from computer to computer.
These Security Options should be mandatory in any environment. Surprisingly, they are all things most people can live with.
You may download a printer-friendly version.
|Checklist: Three security mandates for any Windows environment|
|1. Disable or rename the Administrator account|
|It's important to prevent or restrict access to the local Administrator account. Attackers are well aware of it and its all-powerful presence on the computer. Malicious software|
|is often written to use this account. While the attacker would still have to know or deduce the account's password to use it, he won't have the chance to try if the account is disabled.|
|Security Option: Use "Accounts: Administrator account status" to disable the Administrator account on Windows XP and Windows Server 2003 computers.|
|On Windows 2000 computers this option is not available. Instead you can thwart attacks by renaming the Administrator account. If an attack involves the use of an account named|
|"Administrator" and no such account exists, then the attack will not work.|
|Security Option: Use "Accounts: Rename Administrator Account" to rename this account in Windows 2000.|
|However, please keep in mind that internally Windows computers use a unique security ID (SID) -- not a name. If the attacker knows the Administrator account SID, simply renaming|
|the account does nothing. This SID is composed of a unique number and a standard relative ID (RID). An attacker or well-crafted malicious program can easily determine the|
|Administrator account SID, unless you change that as well. (A future checklist will tell you how to protect Windows from such attacks.)|
|Even on computers where you can disable the Administrator account you should rename the account. Another account with administrative privileges can always be used to|
|re-enable the Administrator account.|
|So what are the problems with disabling or renaming the Administrator account? First, many people will complain that this is security through obscurity. An attacker might be able|
|able to deduce the account name or SID, so disabling or renaming the account is not a sure preventative. Second, some people are under the false impression that they must|
|use the Administrator account to administer the computer. If it's disabled, they say, how can they administer the computer? Preventing the use of the Administrator account does|
|not mean you or others can't have administrative rights on the computer. Each user requiring such access can have an account with membership in the Administrators group.|
|Disabling and renaming the account does not prevent administrative access, it just makes it harder for would-be attackers to get in.|
|2. Disable or rename the Guest account|
|While the Guest account has few privileges, it is included in the Everyone group when permissions are being evaluated -- and the Everyone group can access many systems.|
|The Guest should be disabled by default. You just have to make sure it stays that way or rename it. Disabling and renaming this account may only remove low access rights, but|
|this is a step that can be done quickly and easily, and doing so will typically cause no problems.|
|Security Option: Use "Accounts: Rename Guest Account" to rename the account.|
|3. Hide logon names|
|By default the last account used to logon is displayed on the logon screen after the user has logged off. This allows anyone in close proximity to the machine to read the name,|
|giving him half of the information he needs to access the computer and perhaps the network. He still has to know or deduce the password, but his job is easier than if he had to|
|obtain both the account name and its password.|
|Security Option: Use the "Interactive: Do not display last user name" option to ensure the previously used logon name is removed from the logon screen.|
|Once again, some people will say these measures are security by obscurity and offer little value. They'll ask who cares if someone knows Joe User's logon name. They'll also|
|maintain that it's a nuisance for users to enter their account names each time they logon. Baloney! A few keystrokes are all it takes. Requiring users to enter their information each|
|time also ensures that they know their account names. Remember that not every user has limited access. You really don't want others to know the logon account names for|
|administrators or other highly privileged users. Hiding the logon name can help you guard that information.|
|How to find and set the above Security Options|
|On a workgroup server or desktop (computers that are not joined in a domain)|
|1. Start/Administrative Tools/Local Security Policy
2. Navigate to Local Policies/Security Options
|3. Scroll down to the appropriate setting.
4. Make the recommended change.
|In a domain environment|
|The first step in making any change to Group Policy in a domain environment is to ensure that the change does not violate official organization security policy. Make sure you clear|
|changes appropriately. In a domain environment, Group Policy management should be assigned to a limited number of administrators. Technical controls should also be in|
|place to enforce this. Use the following steps to stay in compliance:|
|1. Create or open the Group Policy Object that will apply to computers you
want to manage.
2. Navigate to Windows Settings/Security Settings/Local Policies/Security Options.
|3. Scroll to the appropriate setting.
4. Make the recommended change.
Windows Security Checklists offer you step-by-step advice for planning, setting up and
hardening your Windows security infrastructure.
E-mail the editor to suggest additional checklist topics.
More Checklists by Roberta Bragg
- Lock down PCs, workgroups and AD domains
- Seven steps to properly set account lockout
- Lock down Joe User's administrator rights
ABOUT THE AUTHOR: Go back to Checklists Roberta Bragg is author of "Hardening Windows systems" and a SearchWindowsSecurity.com resident expert. She is an MCSE, CISSP and Microsoft MVP, and a well-known information systems security consultant, columnist and speaker.
Sean M. writes:
I enjoy your series of checklists for securing Windows systems. I think they are a great starting point for people learning about Windows security. If you don't mind, I'd like to make a suggestion for Item 2 in your Three security mandates for any Windows environment. While you are busy renaming the Guest account and ensuring it is disabled, why not take the time to give it a password as well?
I know some people may argue that this is simply too much, but I believe in providing layers of defense. If an attacker ever decided to re-enable the Guest account as a back door (who thinks to keep checking if it's still disabled?), then there would be the extra defense that the account has a password on it.
Another suggestion I would add concerning this account is to add it to the following policies:
- Deny access to the computer from the network
- Deny logon as a batch job
- Deny logon as a service
- Deny logon locally
One can never be too safe.
This was first published in March 2005