This is the second article in a three-part series devoted to hardening Windows 2000 across the enterprise, as opposed to focusing on individual servers or workstations. In the first installment, I discussed some of the security-enhancing tools that Windows 2000 offers, such as: Active Directory, Organizational Units, Security and Group Policies, and Security Configuration and Analysis. This article takes us right to the security policy options that can be used to strengthen our Win2k installations.

When I first began working with these options in Win2k, I was confused. I probably could have read through the help files, but I tend to attack new features like this as if they were bots in a Quake level: I jump in and start shooting. Right off the bat, I was presented with many options: I could set policy via the Domain Security Policy, Domain Controller Security Policy, or the Local Security Policy. The Domain Security Policies had a few more options than the LSP did, and I was not sure why. More exploration led me to the Group Policy options, which allowed even more configuration settings to be made (we'll cover the Group Policy stuff next time). I wasn't really sure what to do where, and was still trying to figure out why to do it in the first place.

I eventually downloaded Group Policy and Security Configuration white papers from the Microsoft web site, only to find that much of the content still referred to Beta and to-be-implemented options. While the documents were helpful, some of the errant content, such as references to Beta options and no-longer-valid naming conventions was not so helpful. After a fair bit of experimentation, I have finally arrived at a point at which I thought that I had a pretty good grasp on the entire structure, and really feel good about deploying custom configurations throughout my enterprise. If the dissemination of this information can save even one of you a little time, then I have done my job.

This can get a bit "fangy", (as in something with big nasty fangs) so be patient. OK, I know that "fangy" isn't a real word, but I figure if I use it enough, it will eventually become one, and I will finally get credit for the time I used it in a Scrabble game against Mike Parnell. Besides, it is apropos. So, here we go?

The Local Security Policy node contains 3 main areas where you can set policy options: Account Policies, Local Policies, and Public Key Policies. Once you get these down, you will see that you can then apply them at the Domain, Domain Controller, Site, or Organizational Unit levels (Note that the Kerberos Policy, a subset of the Account Policies, is only for domain accounts, even if set in a local policy, unless of course the local system is a DC. But you knew that). These system-specific options (as opposed to user-specific) can be set either directly in the LSP MMC, via an imported template, through the Security Configuration and Analysis Tool, or as part of a group policy. This also happens to be the proposed method of securing Internet-facing boxes that a team working with the Center for Internet Security is currently developing.

For your reading pleasure, I have compiled the complete list of options that can be set, along with a brief description of each option, based on the Microsoft white papers. I have also included my recommendations for some of the settings, based on my experience; but make sure you check these options out before you simply set them - I would hate to see you break anything! Finally, there will be a <.02> tag under the MS description, in which I have inserted my own comments - my own two cents worth, as it were.

Note that in some cases, I have used 'Not Defined' as my recommended setting, which means I have refrained from suggesting a setting. This could be because it is essentially a matter of individual preference, because it is based on other settings, or because I simply don't know enough about it to make recommendations. 'Not Defined' is quite different than 'Disabled'. A 'Disabled' policy is explicitly defined as not engaged, or is turned off. Also, note that the following explanations are not exhaustive: they have been summarized (and generalized) for the sake of brevity, and are offered as a reference. For more in-depth explanations, readers should refer to the original Microsoft white papers.

Account Policies - Password Policy, Account Lockout Policy, and Kerberos Policy

Password Policy

<.02>
Good passwords are the first step to securing your network. While Win2k now uses Kerberos, don't think that LM is dead and gone - there are still ways to revive that zombie, so it is best to keep your guard up. More on this below.
</.02>

Enforce password history

This policy keeps users from reusing passwords by keeping the password history according to the setting: someone could only reuse a password after changing it n times, where n equals the password history setting.

Author's recommended setting: 8

Maximum password age

The maximum number of days that a password can be used before a user must change it. The value can be between 1 and 999 (0 means that the passwords never expire.)

The GPO and LSA of workstations and servers sets the default to 42.

<.02>
I have seen recommendations from 30 to 120. There is no magic number - the thing to consider is how often you make users change passwords, how complex they have to be, and how much flack you will catch for making users do too much work. If the end result is a password written on a sticky note slapped up on the monitor, the policy has failed.
</.02>

Author's recommended setting: 90

Minimum Password Age

Sets the minimum time a password can be used before it can be changed. This must be less than the maximum password age.

The GPO and LSA of workstations and servers sets the default to 0, allowing immediate changes, so note this if you use Enforce Password History. Having a 0 allows users to keep changing the password to get back to one they want to effectively bypass history enforcement.

Author's recommended setting: Not Defined

Minimum password length

Enforces minimum password length in characters. A setting of 0 allows for a blank password, which is the default for the GPO and the LSA in workstations and servers.

<.02>
This is a hot topic. Now that we have Kerberos, why care about this 7- or 8-character password business? Well, because you can still force an LM connection to your box unless you otherwise disable it. Plus, the LM is still in the local SAM that was initially created, unless you specifically disable it via an undocumented registry setting. See Eric Schultze's article, Choosing Strong Passwords on the Security Focus web site.
</.02>

Author's recommended setting: 7

Passwords must meet complexity requirements

Forces password complexity, and is disabled by default. A complex password (as enforced by this setting's implementation of 'passfilt.dll') is one that:

• does not contain any part of the account name;
• is at least 6 characters in length; and,
• contains 3 out of 4 of character types of uppercase, lowercase, digits, and extended characters (like the shift of the upper number keys).

It is possible to create custom filters via the Platform SDK, though I have never done so.

Author's recommended setting: Enabled

Store password using reversible encryption for all users in the domain

For compatibility with third party SMB servers, you can choose to store your passwords in reversible encryption, which may as well be clear text. This should always be disabled unless you absolutely must enable it for application purposes.

Author's recommended setting: Disabled

Account Lockout Policy

Account lockout threshold

The number of times before a failed logon locks out an account. Upon lockout, an admin must clear the 'account locked out' flag, or the lockout duration period must expire. Valid arguments are between 1 and 999, as if anyone would actually set it to 999. A value of 0 will never lock out.

The setting is not enabled by default. Password protected screen saver attempts do not count, as you are not really logging on.

Author's recommended setting: 3

Account lockout duration

After failed logon attempts result in a lockout, this is the number of minutes before the account automatically clears itself, from 1 to 99999 minutes. 0 in this case means it will never unlock, and requires administrative clearing. This has to be greater than the reset time described below.

<.02>
I have seen smaller values than my recommended setting that are presumably set to save the user any extended down time while waiting for the reset. It has been my experience that the user never waits anyway, and will always contact an administrator. If it is on the weekend, you are going to get a page anyway, so you may as well set it pretty high to thwart automated/brute force attempts.
</.02>

Author's recommended setting: 90

Reset account lockout counter after

This is the number of minutes the system will wait before it resets the 'bad logon attempts' back to 0. If you fat-finger a password, giving you one strike, then it will be set back to 0 after n minutes. It is not defined by default, as the Account Lockout Threshold must be set for it to be useful.

Author's recommended setting: 30 minutes

Kerberos Policy

These options are all set by default in the Default Domain Controller GPO, and that is how I leave them. Others with more experience in the Kerberos arena, please share any insight with me.

Enforce user logon restrictions

When enabled, this makes the Kerberos KDC validate requests for sessions tickets against the local policies of the target system. It supposedly takes more resources for this action, though I have not tested it. The user must have 'Log on Locally' or 'Access this computer' from the Network rights to receive the ticket.

Author's recommended setting: enabled

Maximum lifetime for service ticket

This setting regulates the maximum number of minutes that a session ticket is valid to access a service after being granted. This is for new connections only, not for sessions that have already been authenticated. This setting must be more than 10 minutes, and equal to or less than the User Ticket setting.

Author's recommended setting: 600 minutes

Maximum lifetime for user ticket

Time (in hours, not minutes? why the inconsistency?) that the ticket-granting ticket is valid. This setting is set to 10 hours in GPO by default.

Author's recommended setting: 10 hours

Maximum lifetime for user ticket renewal

The threshold (in days) in which the ticket-granting ticket can be renewed.

This setting is set to 7 days in the GPO by default.

Author's recommended setting: 7 days

Maximum tolerance for computer clock synchronization

Differences in client and server time can make Kerberos authentication fail, as part of the way the protocol works. This setting determines the time differential tolerance. It is set to 5 as the default in the GPO.

Author's recommended setting: 5 minutes

Local Policies - Audit Policy, User Right Assignment, and Security Options

Audit policy

Auditing does absolutely no good unless the logs are reviewed by administrative personnel. This is particularly true for the following settings, which assume 'overwrite the logs as necessary' is set. Note that the Event Log properties of the Domain Security Policy GPO define the event log settings, not the Local Security Policy. The Domain (or equivalent OU Policy) should be used for this.

Audit account logon events

This audits when the system with this setting does or doesn't log a user on or off, depending on the setting. The default is 'No Auditing'.

<.02>
I like to log success as well as failure. Not just for identifying those 3:00 AM admin logons, but for general troubleshooting as well.
</.02>

Author's recommended setting: Success and Failure

Audit account management

Sets what type of event to audit when account management functions are executed on a system, such as user creation or deletion, password changes, etc. The default setting is 'No Auditing'.

Author's recommended setting: Success and Failure

Audit directory service access

Sets how to log Active Directory objects with System Access Control Lists (SACLs). This is similar to Audit Object Access, except this is at the AD level.

Author's recommended setting: Failure

Audit logon events

Audits when a user makes a network connections to this system, or logs on or off to this system. Unlike Account Logons, which take place at the DC or authenticating unit, this audits when the system itself is accessed.

Author's recommended setting: Failure

Audit object access

Sets the audit type for objects (files, directories, registry keys, etc.) Note that you must also go to the object and set the SACL for the object you wish to audit.

<.02>
I use this off and on, mostly for specific troubleshooting issues where I want to see how the objects are being accessed. Some people leave this on all the time, and only set auditing on specific objects when they need to. Some have said that this consumes system resources, but I have seen no evidence of that. I left this at 'Not Defined' so that you can make your own decision of how to go about doing this.
</.02>

Author's recommend setting: Not Defined

Audit policy change

Sets the audit type for changes in user right policy, trust policies, or audit policies themselves.

<.02>
It is important to know when audit policy changes succeed, as a successful change could stop auditing in the first place. If you only audit failure, you may not catch strange activity.
</.02>

Author's recommended setting: Success and Failure

Audit privilege use

Determines the audit type when users exercise their user rights. According to the help files, the following are not logged, even when success or failure is requested:

• bypass traverse checking;
• debug programs;
• create a token object;
• replace process level token;
• generate Security Audits;
• backup files and directories; and,
• restore files and directories;

<.02>
I have left systems with 'Failure Logging' on, but it really seems to generate a lot of extraneous log entries that are not self explanatory, almost to the point of creating a smoke screen effect - even with Admin users you stop really paying attention to them. If others have some insight into the proper use for this, I would like to know about it, please.
</.02>

Author's recommended setting: Not Defined

Audit process tracking

Audits program activation, process exits and stuff like that. This is like the Object Access: I use it for specific troubleshooting or process tracking, but don't keep it on all the time.

Author's recommended setting: Not Defined

Audit system events

Sets the audit type for when a system is shut down or restarted, or where events that affect the system or security log occur. Determines whether to audit when a user restarts or shuts down the computer, or when an event has occurred that affects either the system security or the security log.

<.02>
It might just be me, but I like to know when systems are restarted, or when the security log is affected by something. I log success and failure for that reason.
</.02>

Author's recommended setting: Success and Failure

User Rights Assessment

Access this computer from network

Sets who can connect to the system over the network. The defaults are too lenient, and I recommend that you change it to 'Authenticated Users' at least. It would be far better to build a group policy that makes for easy administration, and only grants access to a custom group.

Author's recommended setting: Authenticated Users

Act as part of the operating system

I recommend that this be given to the 'Everyone' group. Just kidding! I was checking to see if you were still paying attention.

This gets a bit complicated, but it basically allows you to give a process complete access to the system. This can result in custom token generation and all that jazz. That is why LocalSystem is the default. The recommendation is to have processes that need this use LocalSystem rather than giving the process itself this right.

Author's recommended setting: LocalSystem

Add workstations to domain

Valid only on a DC, this policy allows you to determine which users or groups can add workstations to the domain, by way of creating a computer account. Fortunately, only 10 accounts can be added (by default) by the "authenticated user", so you don't have to worry about an Account Stuffing that could bring down AD.

<.02>
Even though only 10 accounts can be added, you should still be careful who you give this right to - I don't know of any valid reason why you would want just anyone to be able to add a computer account to your domain.
</.02>

Author's recommended setting: Other than Authenticated Users

Backup files and directories

This setting determines who can perform backups. Permissions are bypassed during this operation, so the default is Admin and Backup Operators.

<.02>
The defaults let the same person backup and restore, if they are part of the Backup Operators group. This is not so smart because I can effectively bypass permissions to get to a file if I can back it up and then restore it again somewhere else. Let people back it up, but have different user accounts restore it.
</.02>

Author's recommended setting: Administrators/Backup Operators

Bypass traverse checking

This setting determines which accounts can traverse a directory, even if they do not permissions for that directory. They can't access the contents, they can only move through it.

Author's recommended setting: Not Defined

Change the system time

Sets who can change the system time. Since Kerberos authentication can be disabled if the threshold is exceeded, you want to limit who can do this, as alternate authentication methods can be used on failure.

Author's recommended setting: Administrators

Create a pagefile

This setting determines who can create or change pagefile settings. The default is Administrators.

Author's recommended setting: Administrators

Create a token object

Token creation allows access resources, so the recommendation is to keep this at LocalSystem. If other processes can create tokens, then there could be security problems. If you must create tokens, then do so under LocalSystem, don't set your process here.

Author's recommended setting: LocalSystem

Create permanent shared objects

This doesn't govern who can share resources, it sets what accounts a process can use to create Object Manager objects. This is kernel mode stuff, so leave it alone.

Author's recommended setting: LocalSystem

Debug programs

People who can debug programs have access to special system information. You should leave this set as the default, which is Administrators and LocalSystem.

Author's recommended setting: Administrators/LocalSystem

Deny access to this computer from the network

Specifically denies access from the network. All other permissions are ignored if 'Deny' is in place. This is not defined by default.

<.02>
This can be a powerful setting. Typically, service accounts are created locally for security reasons. However, if you use domain accounts that are part of a special group, that group can be denied access over the network to all other systems. 'Deny' supercedes all other explicit access. It is a bit tricky, and goes against some recommended procedures, but the new Group Policy management allows pretty easy administration of this, and it can provide a decent amount of security.
</.02>

Author's recommended setting: Not Defined

Deny logon as a batch job

Explicitly denies an account the 'Logon as Batch Job' privilege (See 'Logon as Batch Job' for more info.)

Author's recommended setting: Not Defined

Deny logon as a service

Explicitly denies an account the 'Logon as Service' privilege (See 'Logon as Service' for more info.)

Author's recommended setting: Not Defined

Deny logon locally

Explicitly denies the 'Logon Locally' privilege (See 'Logon Locally'.)

Author's recommended setting: Not Defined

Enable computer and user accounts to be trusted for delegation

This allows user accounts to be trusted for delegation, meaning a process can access other resources on a different computer with the delegated credentials.

Author's recommended setting: Administrators

Force shutdown from a remote system

This setting determines which accounts can remotely shut down another system.

Author's recommended setting: Administrators

Generate security audits

Sets which accounts can be used by a process to add entries to the security log. The default is 'LocalSystem'.

Author's recommended setting: LocalSystem

Increase quotas

This setting determines which accounts can use processes that have 'write property' access to other processes in order to increase the processor quota. The setting is used to tune performance, but it can be used maliciously to peg processor utilization.

Author's recommended setting: Administrators

Increase scheduling priority

Determines who can increase the priority of a process. As with 'Increase Quotas', it can be used maliciously to peg processor utilization.

Author's recommended setting: Administrators

Load and unload device drivers

This setting determines which user accounts can load device drivers. Device drives run in kernel mode, and can be dangerous, such as a rootkit.

<.02>
Consider creating a custom group, and only populating it with the user accounts of select administrators and only granting this group this right. Yes, it is security through obscurity, but it may save your patooty. Guys like Greg Hoglund and JD Glaser have some pretty cool kits that dynamically load without a reboot if you let them?
</.02>

Author's recommended setting: Administrators

Lock pages in memory

Determines which user accounts can keep data in physical memory, and not page to disk. Can affect performance.

Author's recommended setting: Not Defined

Logon as a batch job

Specifies which users can logon as a batch job, as in a task scheduler job. 'Local System' is the default.

Author's recommended setting: LocalSystem

Logon as a service

Determines which accounts can be used to run a service. By default, no accounts have this right, but they are automatically given the right when you select a user account for a service to run under.

Author's recommended setting: Not Defined

Logon locally

This setting determines who may log on locally (interactively) to the system.

Author's recommended setting: Not Defined

Manage auditing and security log

Determines who can manage auditing and the security log options.

Author's recommended setting: Administrators

Modify firmware environment variables

Determines who can modify system environmental variables.

Author's recommended setting: LocalSystem

Profile single process

This setting determines which user accounts can use Performance Monitor to profile non-system processes.

Author's recommended setting: Administrators/LocalSystem

Profile system performance

Sets which user accounts can use Performance Monitor to profile system processes.

Author's recommended setting: Administrators/LocalSystem

Remove computer from docking station

This setting determines which users can undock a laptop from its docking station (logically, of course). Upgrades to Win2k require explicit user rights to be given for this setting.

Author's recommended setting: Not Defined

Replace a process level token

This setting determines which users can replace a processes default token. By default, only LocalSystem has this right.

Author's recommended setting: LocalSystem

Restore files and directories

This setting determines who can restore files and directories. These users bypass security settings, so make sure you don't give the same dude Backup as you do Restore.

Author's recommended setting: Administrators/Backup Operators

Shut down the system

This setting determines who can shut down the local system (gracefully!)

<.02>
Too bad there is not a 'Deny Pull the Plug Access' policy.
</.02>

Author's recommended setting: Not Defined

Take ownership of files or other objects

This setting determines which users can take ownership of system objects.

Author's recommended setting: Administrators

Security Options

Additional restrictions for anonymous access

Sets restrictions (kind of) for Null User access to system information. You can set the following restrictions:

• 'None'
• 'Do not allow enumeration of SAM accounts and shares' - supposedly replaces 'Everyone' with 'Authenticated Users' for the token.
• 'No access without explicit anonymous permissions' - removes 'Everyone' and 'Network' when the token in being generated. You must then explicitly grant that the null user be given access.

<.02>
If you can get away with 'No access', then do. Anything other than that, and intruders can still get all kinds of information from the system. This won't work with downlevel trusts or with NT workstations the must authenticate to the box. See the author's article RestrictAnonymous: Enumeration and the Null User for more info.
</.02<

Author's recommended setting: Not Defined

Allow server operators to schedule tasks (domain controllers only)

If enabled, this gives Server Operators the ability to submit jobs via AT (not the Task Scheduler).

Author's recommended setting: Administrators

Allow system to be shut down without having to log on

If enabled, this allows the system to be shutdown without logging in first.

Author's recommended setting: Not Defined

Allowed to eject removable NTFS media

Sets which users can eject removal media if formatted NTFS.

Author's recommended setting: Not Defined

Amount of idle time required before disconnecting a session

Sets the amount of time in minutes before a server will disconnect an inactive SMB session. 15 minutes is the default, and a 0 makes the session disconnect as soon as is possible.

Author's recommended setting: Not Defined

Audit the access of global system objects

Sets the audit policy for global system objects like semaphores, events and DOS devices. When enabled, the SACL's are automatically set to audit.

Author's recommended setting: Not Defined

Audit use of all user rights including Backup and Restore

Remember how Audit Privilege Use does not audit all events? This is a means of getting all events logged when a user exercises rights.

Author's recommended setting: Not Defined

Automatically log off users when logon time expires

This is a domain-wide setting (as opposed to the next policy's local-only influence) that will forcibly log out users when the logon time expires.

<.02>
I don't know too many admins that set this, due to the potential "freak-factor" that a user may experience, but it is really a powerful way to limit access. In fact, I would just be happy to see more people have logon times set in the first place for the user accounts?
</.02>

Author's recommended setting: Not Defined

Automatically log off users when logon time expires (local)

Same as above, except that disconnects local users from resources.

Author's recommended setting: Not Defined

Clear virtual memory pagefile when system shuts down

This setting, when enabled, forces the page file to be cleared (wiped clean) every time the system shuts down.

Author's recommended setting: Not Defined

Digitally sign client communications (always)

This sets how the client will attempt to digitally sign its communications. When set, it must always sign SMBs, thus preventing man-in-the-middle attacks. Note that you must also require it on the server if you want the client to communicate with it.

<.02>
The word is that this takes about 10% more CPU time on the client and server (when establishing the SMB communications), though I have not personally verified this. Even so, I think it is worth the overhead to secure the communications. I still leave this one as Not Defined so that you can make your own choice.
</.02>

Author's recommended setting: Not Defined

Digitally sign client communications (when possible)

Same as the previous policy, except that is a best effort. If signing can take place, it will, but it is not required.

<.02>
I recommend enabling this, but would really rather see it required; however, I don't want to see you break anything, so there you have it.
</.02>

Author's recommended setting: Enabled

Digitally sign server communications (always)

This requires that SMB communications be signed at the server at all times. See above for comments regarding signing.

Author's recommended setting: Not Defined

Digitally sign server communications (when possible)

Same as above, except that it will sign when it can, but it is not required.

Author's recommended setting: Enabled

Disable CTRL+ALT+DEL requirement for logon

Sets the requirement for the user to use C+A+D to log on.

<.02>
I guess this helps some, but this does nothing to stop kernel mode root kits or physical keyboard loggers from capturing logon creds. Your best bet is to leave this policy disabled (which still requires C+A+D.)
</.02>

Author's recommended setting: Not Defined

Do not display last user name in logon screen

By default, the last user account name is displayed in the logon screen. Enabling this policy required the username to be entered each time.

<.02>
Again, I guess this could help some, but if I have my hands on the box, then I own it, so don't take this too seriously. Besides, if you require the account name to be secret, you have bigger problems.
</.02>

Author's recommended setting: Not Defined

LAN Manager authentication level

This sets what LM authentication level will be used when LM is used to validate creds. Your choices are as follows:

• send LM & NTLM responses: Clients use LM and NTLM authentication, and never use NTLMv2 session security; DCs accept LM, NTLM, and NTLMv2 authentication.
• Send LM & NTLM - use NTLMv2 session security if negotiated: Clients use LM and NTLM authentication, and use NTLMv2 session security if server supports it; DCs accept LM, NTLM, and NTLMv2 authentication.
• Send NTLM response only: Clients use NTLM authentication only, and use NTLMv2 session security if server supports it; DCs accept LM, NTLM, and NTLMv2 authentication.
• Send NTLMv2 response only: Clients use NTLMv2 authentication only, and use NTLMv2 session security if server supports it; DCs accept LM, NTLM, and NTLMv2 authentication.
• Send NTLMv2 response only\refuse LM: Clients use NTLMv2 authentication only, and use NTLMv2 session security if server supports it; DCs refuse LM (accept only NTLM and NTLMv2 authentication).
• Send NTLMv2 response only\refuse LM & NTLM: Clients use NTLMv2 authentication only, and use NTLMv2 session security if server supports it; DCs refuse LM and NTLM (accept only NTLMv2 authentication).

The default is "Send LM & NTLM responses."

<.02>
You can still force a box to use LM in different ways. I suggest 'Use v2 if negotiated' so as not to break anything, but you should see if you can get away with at least NTLM or v2 if possible. You'll have to get the client drivers for Win9x to use NTLMv2. This requires some work on your part to test.
</.02>

Author's recommended setting: Send LM & NTLM - Use v2 if neg.

Message text for users attempting to log on

This specifies what text to display when a user begins the logon process.

<.02>
Here is my logon text, which is pretty good. I got it from the Department of Energy:

"This is a private computer system and is the property of [Company]. It is for authorized use only. Users (authorized or unauthorized) have no explicit or implicit expectation of privacy. Any or all uses of this system and all files on this system may be intercepted, monitored, recorded, copied, audited, inspected, and disclosed to authorized site personnel, law enforcement personnel, as well as authorized officials of other agencies. By using this system, the user consents to such interception, monitoring, recording, copying, auditing, inspection, and disclosure at the discretion of authorized [Company]. personnel. Unauthorized or improper use of this system may result in administrative disciplinary action and civil and criminal penalties. By continuing to use this system you indicate your awareness of and consent to these terms and conditions of use. LOG OFF IMMEDIATELY if you do not agree to the conditions stated in this warning."

Of course, the user doesn't really have to hit "OK"? They can just wait a few minutes and the message goes away by itself, so I am just waiting for the legal ramifications of the fact that it would be possible for the user to continue without acknowledgement.
</.02>

Author's recommended setting: Legal Notice (clear with your corporation or organization)

Message title for users attempting to log on

Sets the title bar for the above notice.

<.02>
I've been told that the words "Legal Notice" have some binding power?
</.02>

Author's recommended setting: Legal Notice title (clear with your corporation or organization)

Number of previous logons to cache (in case domain controller is not available)

Sets how many logon credentials will be cached in case a DC cannot be reached. The default is 10 with a max of 50. 0 disables caching altogether. Cached creds are a security concern.

Author's recommended setting: Not Defined

Prevent system maintenance of computer account password

Computer account passwords are automatically reset each week by default. If you have some reason that you do not want a computer's account password to be reset, you can enable this policy, but it is not recommended.

Author's recommended setting: Disabled

Prevent users from installing printer drivers

Just like device drivers, printer drivers run in kernel mode. This policy keeps users from loading printer drivers on workstations, where they have the default right to do so (not on servers). Unfortunately, anyone on a workstation can add printer drivers.

<.02>
Printer drivers are great places to hide root kits and Trojans for this reason. Be careful where you let users load drivers, and where they get drivers from. See "Unsigned Driver Behavior" for more options.
</.02>

Author's recommended setting: Not Defined

Prompt user to change password before expiration

With a default of 14 days, this option allows you to set how far in advance the system warns a user that their password is about to expire.

Author's recommended setting: Not Defined

Recovery Console: Allow automatic administrative logon

This policy allows you to automatically log on to the system Recovery Console when set. This is obviously unsafe, but may be necessary, depending on your environment.

Author's recommended setting: Not Defined

Recovery Console: Allow floppy copy and access to all drives and folders

Enables the following Recovery Console SET commands: (from the Microsoft Help Documents)

• AllowWildCards - Enable wildcard support for some commands (such as the DEL command).
• AllowAllPaths - Allow access to all files and folders on the computer.
• AllowRemovableMedia - Allow files to be copied to removable media, such as a floppy disk.
• NoCopyPrompt - Do not prompt when overwriting an existing file.

These SET commands are disabled, and all these variables are not enabled by default.

Author's recommended setting: Not Defined

Rename administrator account

Sets, as a matter of policy, whether or not the admin account must be renamed.

<.02>
This is really only valuable for Terminal Server, where the TS logon is local - you can't lock out the admin account from a local logon, so a BF attack against TS is possible. Determining the real administrator account name on any box that you can hit with 139 is trivial.
</.02>

Author's recommended setting: Not Defined

Rename guest account

Sets, as a matter of policy, whether or not you must rename the guest account. See the previous policy for obscurity comments.

Author's recommended setting: Not Defined

Restrict CD-ROM access to locally logged-on user only

Sets whether or not the CD is available to local and network users.

Author's recommended setting: Not Defined

Restrict floppy access to locally logged-on user only

Sets whether or not the floppy CD is available to local and network users.

Author's recommended setting: Not Defined

Secure channel: Digitally encrypt or sign secure channel data (always)

This setting will make the system require that all secure channels be signed or encrypted. All DC's in all domains must share this setting, if specified. Enabling this setting automatically enables the 'Digitally sign secure channel (when possible)' setting.

Author's recommended setting: Not Defined

Secure channel: Digitally encrypt secure channel data (when possible)

Same as above, except that it is a best effort without requiring the channel be signed or encrypted.

Author's recommended setting: Enabled

Secure channel: Digitally sign secure channel data (when possible)

Sets whether outgoing secure channel data should be signed or not.

Author's recommended setting: Enabled

Secure channel: Require strong (Windows 2000 or later) session key

This requires that all secure channel data have a strong encryption key (Win2k+ only.)

Author's recommended setting: Not Defined

Secure system partition (for RISC platforms only)

Restricts access to the FAT system partition on RISC boxes to admin only (while the OS is running).

Author's recommended setting: Not Defined

Send unencrypted password to connect to third-party SMB servers

This setting allows you to send your creds in the clear to 3rd party SMB servers.

Author's recommended setting: Disabled

Shut down system immediately if unable to log security audits

This setting allows you to make the system halt should it not be able to log a security event with a Stop: C0000244 code.

<.02>
I'm a little bittersweet about this one. I would love to have the system automatically shut down if security log entries flooded it to the point that it could not log anymore, but I just don't trust it. Talk about a self-imposed denial of service!
</.02>

Author's recommended setting: Not Defined

Smart card removal behavior

Sets what action you want the system to take when a logged-on user yanks the smart card. You can choose from No Action, Lock Workstation, or Force Logoff.

Author's recommended setting: Enabled

Unsigned driver installation behavior

This allows you to lock down the installation of unsigned drivers. Your choices are: Silently Succeed, Warn by allow, or Do not allow installation.

<.02>
If you can get away with it, don't allow the installation of unsigned drivers. Users should not be loading drivers anyway. That could lead to problems though, so think it through before just setting it.
</.02>

Author's recommended setting: Not Defined

Unsigned non-driver installation behavior

Same as above, but for non-driver software.

Author's recommended setting: Not Defined

A few final words

So, is anyone still with me? I know that was a lot of material to cover, but we are only getting started! Next time, we will go into even more detail about the user options that can be set (and some tips on how to set them) with Group Policies.

If you want to get a jump on that and check out the Microsoft white papers that I used as the basis for this article, take a look at Windows 2000 Group Policy as well as Security Configuration and Analysis for the skinny on the Security Configuration and Analysis tools.

Until then?

To read Hardening Windows 2000 in the Enterprise: Seeing the Forest in spite of the trees, Part III, click here.