Local Security Policies

A local security policy specifies various security settings on the local machine. These can include password and account lockout policies, audit policies and user rights assignments. Domain security policies will override local security policies so care should be taken when applying local policies on a domain.

Local Policies are set through the Local Security Policy MMC. This can be easily accessed from the Administrative Tools folder from the Start Menu.

Expand Account policies…

..then Password Policy…

Each of these options adds to the burden on the user logging in, but increases the security accordingly.

Password history can be set to prevent a user reusing the same set of passwords over and over, as these might be inadvertently disclosed or guessed. Up to 24 passwords can be remembered,

Passwords need to be changed regularly. How frequently they should change is determined by  these two settings. The maximum settings makes a user refresh a password after a set period of time, whilst the minimum age prevents a user changing his password too often.

The maximum value for both settings is 999 days.

A longer password is harder to crack. Therefore a user can be required to use a password of a minimum length.  7 characters is recommended for most networks. Up to 14 characters is the most that can be required by the security policy. A machine will accept a password of 127 characters

Although secure, very long passwords are a nuisance as users tend to forget passwords and assigning a very long password requiring varied characters is making a rod for your own back as you will have to reset them. For less critical data and functions, simpler passwords can be acceptable.

Password complexity rules prevent a user using, for example, a long string of zeroes or their name as a password.

Once enabled, an administrator might be warned that a new password doesn’t meet complexity rules, but it wouldn’t tell him what these are. Strangely, a user required to change a password at next login IS informed what the complexity rules are. ( See “Security Considerations”.)

The complexity rules are fixed in unless the Microsoft Software Development kit is installed. The Default rules are as follows.

Password Complexity Rules

Passwords must be at least 6 characters (regardless of minimum lengths set in security policy).  Passwords must contain characters from three of the following groups: capitals, lowercase letters, numerals, punctuation symbols.  Passwords must not include a login name, or any of a user’s real names.

Jo, JSmith, js1234, do not meet complexity rules

Joh?#n, JS2ith, Js1234, meet complexity rules

Connection to non-Windows machines requires CHAP authentication. For this, passwords are stored in an encrypted form so they can be more safely passed over a network.

To set one of these policies, right-click on it and choose Properties.

Set the number of characters required. 7 is recommended by Microsoft for most purposes. A user is free to use more.

Click OK to complete this.

The policy is now configured.

Account Policies

Malicious (or capricious) persons may occasionally attempt to guess at passwords, especially those for the administrator account. It is possible to deter this practice by locking out further attempts for a period of time.

If the Account Lockout Policy object is expanded, the pane of options is revealed.

Lockout Duration determines how long attempts at login are ignored after a specific number of failed logons. This can be anywhere between 1 and 99999 minutes (over two months) The 0 minute option locks the machine until an administrator unlocks it.

Lockout threshold determines how many wrong attempts at login are allowed before lockout. Up to 999 attempts can be allowed.  A figure of zero permits unlimited guesses at the login name and password.

The Reset Counter has its function in the following sort of scenario: A user mistypes her password a couple of times and, to avoid the inconvenience of being locked out for the next half hour, chooses to wait a shorter period of time before making another  hopefully correct attempt.

There is a logical connection between these three lockout policy settings, and a change in one has an implication for the others. By way of illustration, right-click on the Lockout Threshold item and select Properties.

Select a sensible figure for the number of invalid logon attempts, and see what happens when OK is clicked.

Whichever option is set, this dialogue box appears to suggest reasonable settings for the other two. Click OK to review all the settings which result.

The suggested selection of settings is usually entirely reasonable.

Local Policies

Expand Local Policies.

Expand Security Options.

These are some of the options that can be configured as part of a security policy.  Some, all or none of these options can be configured depending on your requirements.

For example If the security requirements of the local machine dictate that the last user’s name not be displayed in the logon screen then, Right click on this setting and select properties.

Enabling this setting is simply a matter of checking the radio button: …and clicking OK.

Now the security list has this setting listed as Enabled.

User Rights Assignment

User rights assignment determines which users or groups have logon or task privileges on the computer.  Using these is the best and most flexible way to secure a workstation, while still permitting access to a variety of users.  Remember that these can be set locally, but domain-wide settings can override these.

There’s a lot of them, and they each have their uses, depending upon the circumstances of the Company using the network.

For example users can be given Back up and restore rights by selecting this option.

Notice the default groups that have this privilege are the Administrators and Backup Operators group. Additional Users and Groups can easily be added from here by selecting the Add User or Group button.

Auditing and Audit Policies

Auditing allows you to log security related events on the local computer. These events can be anything from a user logging on, to a specific file being accessed.  Security events can be either audited for success or failure or both. You should only audit what is absolutely necessary as auditing can use up valuable disk space.

By default Windows Server 2003 has auditing already enabled. However a Windows XP or 2000 machine does not.  All auditing events are logged to the event viewer. The event viewer is covered in the Monitoring and Optimisation Module.

Selecting the Audit Policy folder reveals the options above.

The most common types of events that are audited apart from the default options are:

1. Access to objects, such as files and folders
2. Management of user and group accounts.

Account logon events relate to user accounts who are logging on to this computer over the network from another machine. This option is mainly used on Domain Controllers.

Every time a change is made to a user account an account management event is audited.

Directory Service is used to audit access to Active Directory Objects. Again, this is more useful on a Domain.

Auditing Logon events is a useful option because it allows you to log who is logging on to the local machine.

Object access can be used to audit access to resources on the local machine. As well as enabling it here the object will also need to be configured.

Policy Change audits will log anything relating to security policies being modified on the machine.

User’s who are using their privileges to perform tasks on the machines can be logged by enabling Audit privilege use.

Process tracking can be used to log which processes are running on the machine. This should be not be enabled unless absolutely necessary because of the large amount of entries it can create.

The Audit system events setting determines whether to audit when a user restarts or shuts down the computer or when an event occurs that affects either the system security or the security log.

Right-click on the item to be audited and select Properties.  (Alternatively, click on the Action button in the toolbar.)

Checking either or both of these boxes is all that’s required to enable auditing of logon events. Click OK to close this window.

confirm that auditing for this action has been enabled.

The event viewer contains a security log which shows audit events.

Double-click on an entry to view its contents.

This entry shows that someone attempted to login as an Administrator and failed to type the correct password. From here the date, time and the machine which was used to make the logon attempt can be seen.

Sometimes details need to be printed to a file. Clicking here copies the details to the clipboard.

Auditing Object Access

Auditing Object Access allows you to log when specific resources on the machine are accessed, e.g. A file. Auditing Object Access is a two stage process.  Object Access Auditing firstly needs to be enabled for either success, failure or success and failure and then the object needs to be configured.

Right-click on the object to be audited, e.g. a file on an NTFS partition.

Select the security tab and click Advanced.

Select the Auditing Tab.

Click on Add to add an audit entry.

Choose a user and click OK.

And then specify what you want auditing on the file.

If an attempt is made to delete this file by the user Ross Jackson an entry will be added to the security log.

Refreshing Policies

Security Policies aren’t immediately applied to the machine and often a restart is required. However a command line utility “gpupdate” can be used to refresh the computer’s security policy without a restart.  The command “gpupdate /target:computer” can be used to refresh the computer policy. The “gpupdate /target:user” policy is used when refreshing user group policy settings, which are covered later.