Local Security Policy in Windows
Local Security Policy allows enforcing many system, user and security-related settings, such as password policy, audit policy and user rights. Event Viewer can then be used to check log events. By default, most settings in Windows are fine, but some still need adjustment.
Sadly, Microsoft decided not to add the Local Security Policy console into home versions of Windows, so this article can be skipped by users of Windows Starter, Home, Home Basic and Home Premium editions.
In Windows 8 and 8.1, most user account settings affect Local accounts only, not Microsoft accounts. See the User management in Windows article for differences between these sign in options.
Please change only the settings listed in this article, other settings could very well make your computer inoperable or inaccessible by other computers in your home network in case you do not know what you're doing.
If you do decide to dig a little deeper, read a setting's description on Explain tab thoroughly before changing it!
Opening Local Security Policy console in Windows
In all non-home versions of Windows, open Run dialog using keyboard shortcut Windows Key+R. Type secpol.msc and click OK. Windows Vista and 7 users can also type this into Start menu Search box and press Enter.
Please note that in Windows 8 and 8.1, Local Security Policy is available in Start screen search results only if you have enabled the displaying of Administrative Tools.
Touch screen users can swipe in from the right edge of screen, tap Search, type a part of "administrative tools" into Search box and click the result. Then open Local Security Policy from the window.
Windows Vista will open another hot and sexy User Account Control dialog. Click Continue to open the console.
There is also a much more detailed configuration console available - Local Group Policy Editor. To access this, open Run dialog using keyboard shortcut Windows Key+R, type gpedit.msc and click OK.
Settings described below are in Computer Configuration, Windows Settings, Security Settings section of Local Group Policy console window.
Again, please do not change any settings not described below unless you really know what you are doing. Always read the setting explanation thoroughly!
If you want to make sure that you and other users of your computer have secure passwords and that passwords are changed after defined number of days, you need to set up a password policy.
Expand Account Policies and click Password Policy on the left side of Local Security Settings window. Double-click Enforce password history on the right side of the window.
This setting defines how many previously used passwords Windows remembers for each user to prevent frequent re-usage of passwords. Usually, 3-5 is enough. Click OK to close the dialog.
Now change other settings of Password Policy by double-clicking on them (settings not listed below are fine by default):
- Maximum password age - default is "42". This specifies how long a user can use the same password for his/her Windows account.
You can set the number higher if you want to ("120" is a suggested one), but keep in mind that you should change your password at least once a year, so do not enter more than "365" here.
- Minimum password age - default is "0", meaning that users can change their passwords whenever they like. If you set this to "1", it means that a password must be in effect for at least 1 day (24 hours) before a user can change it again.
- Minimum password length - set to at least "8", but "12" is recommended.
- Password must meet complexity requirements - set to "Enabled". This means that a password must include at least two opposite case letters, a number and a special character (punctuation marks, for example).
This is a very important step in keeping user accounts secure in Windows. Please read the Creating strong passwords tutorial on how to make and remember strong passphrases.
- Store passwords using reversible encryption - always leave to "Disabled". If you enable this policy, all users' passwords are easy to crack.
The next time a user changes his/her password, it must be in accordance with Password Policy. If not, error message "The password you typed does not meet the password policy requirements" will be displayed:
User must then enter a password that satisfies the Password Policy requirements.
The current passwords are not affected by the policy; requirements are checked only when changing a password. The only change that does apply is maximum password age - the current passwords will have to be changed after specified number of days.
You can read instructions on creating and remembering strong passwords in the Passwords article.
A strong password is good, but when a malicious program (or someone behind your keyboard) is trying to break your password, the attempts must be stopped quickly. By default, anyone or anything can enter any password any number of times without getting stopped by Windows. Such behavior is called brute-force attack and you can stop it by creating an Account Lockout Policy - when a user enters a wrong password several times, the account will be locked out for a specified period of time. The user then cannot log on during this time. Every attempt to login during the lockout period extends the period.
Expand Account Lockout Policy on the left and double-click Account lockout threshold:
Specify the number of times a user can enter a wrong password before Windows locks the user account. I recommend using "5" for this.
Next, Windows offers default settings for Account lockout duration and Reset account lockout counter after settings. These settings specify for how long a user account stays locked after entering a wrong password too many times (during that time, the user cannot log on to the computer) and after which period of time the count of wrong passwords entered will be set back to zero.
The defaults are fine, click OK.
The next article, Event Viewer, tells how to track successful and failed logons, password change attempts and policy changes. Before this can be done, Audit Policy must be in place.
Expand Local Policies on the left side and click Audit Policy. Double-click the first item, Audit account logon events.
If you have a home network (e.g multiple devices using HomeGroup or folders/printers shared over local network), check both Success and Failure boxes and then click OK. This means that both successful and failed logons/sign-ins from another computer/device on the same network are recorded in Security log of Event Viewer. Please note that this has nothing to do with Internet connections.
If you do not have a home network, you can safely leave these boxes unticked.
Adjust other Audit Policy settings as described below. "No auditing" means clearing both Success and Failure check boxes.
- Audit account management - this stores events related to creating, changing and deleting user accounts. Tick both Success and Failure.
- Audit directory service access - leave this at No auditing. This is related to Active Directory domain servers only.
- Audit logon events - always turn on both Success and Failure. This records all logon attempts on your computer.
- Audit object access - in most cases, leave this at No auditing. If enabled, it records events related to users accessing folders, printers, Registry entries, etc that have non-default access rights defined.
- Audit policy change - enable both Success and Failure. This starts storing events that deal with changing this policy and adding or removing user rights (for example, you add a Standard/Limited user to Administrators group).
- Audit privilege use - you can leave this to No auditing on most home computers. If you do need to record failed attempts to access a folder or a file, printer, etc, enable Failure only.
- Audit process tracking - this should be left at No auditing. If enabled, all program launches and exits, plus service and scheduled job creations and some technical details are recorded in Event Viewer. This would mean a lot of unneeded entries for home users.
- Audit system events - tick both Success and Failure here. This records events related to Windows starting up or shutting down, clearing event logs, etc - helpful stuff that might be useful while troubleshooting.
Expand Security Options (under Local Policies).
Verify that Accounts: Limit local account use of blank passwords to console logon only is set to Enabled. This prevents users with no password set from logging in over network or Remote Desktop. This setting is extremely important in Windows XP, where Administrator account is enabled and has a blank password. In Windows Vista and later, Administrator account is disabled by default.
Scroll down to Network access options and make sure that Network access: Allow anonymous SID/name translation is set to Disabled.
Then set both Network access: Do not allow anonymous enumeration of SAM accounts and Network access: Do not allow anonymous enumeration of SAM accounts and shares to Enabled. These settings make sure that only authenticated users get access to shared resources (printers, folders, etc) over local networks.
Changing these settings spawns a warning dialog "You are about to change this setting to a value that may affect compatibility with clients, services and applications". This can be safely ignored.
In the Network security options, make sure that Network security: Do not store LAN Manager hash value on next password change is set to Enabled. This prevents storing the weak LAN Manager (LM) hash of account password, easy target for hackers and malware.
Next, set the Network security: LAN Manager authentication level to Send NTLMv2 response only. Refuse LM if you're using home network. This prevents using older and easy-to-crack authentication methods while accessing shared resources.
Please remember that you must set the same authentication level for all Windows computers on your network, otherwise file and printer sharing will not work!
The setting is not very important for devices that are not connected to a local network, or not sharing files or printers.
Other settings in Local Security Policy are good by default, so we just need to enforce the policies we changed (again, do not mess with settings not described here, they can easily make your computer inoperable and ruin your day or even week!).
To do that, right-click on the Security Settings on the top of the left pane and click Reload.
You can now close Local Security Settings window and read on to find out about tracking system and security events using Event Viewer.
In case you used Local Group Policy console instead, open Run dialog (Windows Key+R), type gpupdate /force and click OK. You can also restart your computer for the same effect.