Top 2012 Windows Security Settings Which Fail to Be Configured Correctly
It has been a very busy year for me. I have had the opportunity to speak and consult to thousands of IT and security professionals in 2012. During my tour of the world I found that there were some common, important, and key security settings that were not being configured at all, or if they were configured, were not set properly. As a recap to the 2012 year and the articles I have written on security for Windows, I figured it was appropriate to give feedback on what I have seen in hopes that it will give all of you something to shoot for in 2013, so when I ask you if these settings are correct, you can answer “yes!”
Password Policy is Weak
I find that most organizations allow for employees to use a weak password. The password requirements that Microsoft has configured for Active Directory by default is not a good quality password. Sure, it is better than a blank password, but not much better with the technologies that are available. Tools such as L0phtCrack, Cain, and more can break into weak passwords and their hashes quickly. By using additional technologies such as RainBow Tables and dictionary attacks, these tools become extremely precise and efficient.
It is a best practice to ensure that passwords are created and tested against all of the different technologies that are available. Ideally, passwords should be 15 or more characters minimum in length. One way to help achieve this length of password is to use passphrases. Examples would include:
- I love my puppy Hercules.
- My favorite vacation spot is Cancun.
- Honesty is the best policy.
All of these meet complexity requirements, are longer than 15 characters, and are much easier to remember and type than traditional passwords.
Password Policy is Not Configured Correctly
I still find companies and network admins that don’t fully understand the Active Directory password policy. Since 2000, Windows 2000 to be exact, the password policy for domain users has been the same. By default the password policy is defined in the Default Domain Policy. It is possible to redefine all or part of the password policy settings in a different GPO. However, that GPO must be linked to the domain and have higher precedence than the Default Domain Policy. When this is configured, then the new GPO will override the original password policy for all settings that are defined in the new GPO.
What is not possible and what I find often is when a GPO is created and linked to an OU. It is not possible for a GPO linked to an OU to control the password for the users contained within the OU. First off, the only way to control the password policy for domain users is in a GPO linked to the domain! Second, the password policy suite of settings is a Computer Configuration grouping of settings and not for users. These settings will only affect computer objects, not users!
Windows 2008 and later domains do have an option for Fine-Grained Passwords, but these are defined in a new object type, not in Group Policy.
Anonymous is More Than a Single Setting
There are 4 key anonymous settings which need to be configured to deny anonymous access. The reason for all 4 is due to the way that anonymous connections can be made and what each type of access allows. Microsoft has done a good job of setting most of the configurations, but all need to be set!
Even with a freshly installed Windows Server 2012 domain, the settings are not all defined in group policy. The settings that need to be configured are listed in Figure 1.
Figure 1: Anonymous settings.
As you can see from Figure 1, only one of the 4 settings is defined in a GPO from Active Directory. This is not a good use of Group Policy and needs to be configured properly in your Active Directory domain.
The settings should be set as follows:
- Network access: Allow anonymous SID/Name translation – Disabled
- Network access: Do not allow anonymous enumeration of SAM accounts – Enabled
- Network access: Do not allow anonymous enumeration of SAM accounts and Shares – Enabled
- Network access: Let Everyone permissions apply to anonymous users – Disabled
Yes, 3 out of the 4 are correct, but there are two issues with this. First, it needs to be 4 out of 4. Second, all settings need to be delivered from a GPO in Active Directory, not just one.
User Account Control is Disabled or Not Configured Properly
User Account Control (UAC) was first released in Windows Vista. This point alone does not mean that the technology should be ignored! Instead, understanding of what UAC does and how to properly configure it should be instilled. I have written many articles on UAC and you can find them on the www.windowsecurity.com site.
After reading these articles, please be sure to configure UAC properly and ensure that it is enabled. The proper way to configure UAC is shown in Figure 2, which is for a Windows 7 computer.
Figure 2: UAC configuration.
Notice that the slider in Figure 2 is at the top, not anywhere in the middle and certainly not at the Never Notify option. Anything but the top option, Always Notify, is not secure! Microsoft knows this and has reported on it over and over again. The only reason that it is set to anything but the top level is to reduce or eliminate prompts, which is not security!
Many say that Windows is not a secure operating system, which is just not the truth. If anything, with the correct settings Windows can become one of the most secure operating systems available. However, if security is not configured properly, the computer and overall network are put in jeopardy. Reducing security risk is key for securing your enterprise. Since all of you reading this are concerned with Windows, your Windows Active Directory security and stability relies on the security you set on domain controllers, servers, and desktops. With passwords being the main entry into a computer, ensuring they are secure is paramount to the overall security of the system and network. Without good password foundations, the entire security model is jeopardized. Not fully understanding how password management and security works within Active Directory could give you false assurance and results.
Anonymous access is key to a Windows network as the attacker does not need to have any relation to the Windows network, only network access to exploit the vulnerability. Ensuring that all settings on all domain controllers, servers, and desktops are correct must be done 100%. Even one system allowing anonymous access could cause inappropriate access and generate an attack on the network. UAC is a painful technology, I will agree. However, the security benefits that it promotes are well worth the few weeks of pain to get over the hump of clicking on the OK button to elevate processes. Without UAC enabled to the fullest level possible, your system is not better off than when you were using Windows XP!