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:
- Access to objects, such as files and folders
- 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.