New or Updated Group Policy Settings
Now that we have a handle on the new features in Group Policy in Windows Vista, let's turn our attention to the things that really matter: the knobs! There are lots of new knobs, dials, buttons, and switches that we can use to turn on security, and just to pass an afternoon after we locked everyone else out from doing their jobs.
In this section we will go over a selection of the new settings. As mentioned earlier, there are almost 1,000 of them. There are relatively few new security options, however. These are the settings under Computer Configuration\ Windows Settings\Security Settings\Local Policies\Security Options. These are important because they are enforced even if the central policy has not been changed. They are also reapplied consistently, not only when the version number changes as with regular Group Policy. Therefore, we will go through all the new security options, as well as those that have been modified from Windows XP, and the few that are removed.
New Security Options
Table 1 shows the new security options and their default values.
Table 1: New Security Options in Windows Vista
 Open table as spreadsheet
|
NAME
|
DEFAULT VALUE
|
NOTES
|
|
Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings
|
Not defined
|
This setting configures how Windows Vista interprets the audit sub-category settings configured with auditpol .exe. The default behavior is to override sub-category settings with the category settings, which requires Group Policy changes for the sub-category settings to be used. If this setting is set to "enabled" the sub-category, settings will take precedence over the category settings.
|
|
Interactive Logon: Display user information when the session is locked
|
Not defined
|
Some organizations are considerably more paranoid than others and find it an unacceptable risk to display the last logged on user in the logon dialog box. However, when a user is logged on but the console is locked, the username is shown on the screen. This new setting permits those organizations to configure the computer not to show the username on the logon screen at any time.
|
|
Network Access: Remotely accessible registry paths and sub-paths
|
System\CurrentControlSet\Control\Print\Printers System\CurrentControlSet\Services\Eventlog Software\Microsoft\OLAP Server Software\Microsoft\Windows NT\CurrentVersion\Print Software\Microsoft\Windows NT\CurrentVersion\Windows System\CurrentControlSet\Control\ContentIndex System\CurrentControlSet\Control\Terminal Server System\CurrentControlSet\
|
This setting was actually added in Windows 2003. Prior to Windows Server 2003, there was no way to specify whether a registry key and all its sub-keys or just the key itself were to be accessible accessible remotely. To close a vulnerability caused by that limitation in Windows 2000, the semantics of the "Network Access: Remotely accessible registry paths" setting were changed in Windows Server 2003 to only make the key specified accessible remotely.
|
|
Network Access: Remotely accessible registry paths and sub-paths
|
Control\Terminal Server\UserConfig System\CurrentControlSet\Control\Terminal Server\DefaultUserConfiguration Software\Microsoft\Windows NT\CurrentVersion\Perflib System\CurrentControlSet\Services\SysmonLog
|
The "Network Access: Remotely accessible registry paths and sub-paths" setting was added with the same semantics as the old setting had in Windows 2000 and Windows XP.
|
|
System cryptography: Force strong key protection for user keys stored on the computer
|
Not defined
|
This setting is used to configure whether users have to use a password to access private key certificates. By default, the setting is not defined. This means that each certificate can define its own protection level.
|
|
System settings: Optional sub-systems
|
Posix
|
This setting is not at all new. It has existed in every version of Windows that has supported multiple sub-systems. However, it has never been present in Security Policy before.
|
|
System settings: Use certificate rules on Windows Executables for Software Restriction Policies
|
Disabled
|
Normally you cannot use certificate rules to restrict execution of Windows binaries using Software Restriction Policies (SRP). This setting can enable that behavior.
|
|
User Account Control
| |
There are nine User Account Control polices built in.
|
Security Options with Modified Defaults
There are also a few security options that have different defaults than they had in Windows XP. The following list shows which options are affected and the old and new defaults.
Table 2: Security Options with Modified Defaults in Windows Vista
Open table as spreadsheet
|
NAME
|
WINDOWS XP DEFAULT
|
WINDOWS VISTA DEFAULT
|
NOTES
|
|
Accounts: Administrator Account Status
|
Enabled
|
Disabled
| |
|
Devices: Allowed to format and eject removable media
|
Administrators
|
Not Defined
|
This is no net change in the setting. The default value is Administrators if the setting is not defined.
|
|
Devices: Restrict CD-ROM access to locally logged on user only
|
Disabled
|
Not Defined
|
This is no net change. The default behavior is disabled if the setting is not defined. Please note that this setting applies only if (a) there is a CD in the drive, and (b) a user is currently logged on, and (c) the drive has been shared out. If any of those conditions do not hold this setting has no effect at all.
|
|
Devices: Restrict floppy access to locally logged on user only
|
Disabled
|
Not defined
|
Same notes apply as for the CD-ROM setting listed previously.
|
|
Interactive logon: Require smart card
|
Not defined
|
Disabled
|
This is simply a clarification. The default state of the setting was always disabled.
|
|
Network Access: Named Pipes that can be accessed anonymously
|
COMNAP, COMNODE, SQL\QUERY, SPOOLSS, LLSRPC, browser
|
netlogon, lsarpc, samr, browser
|
There are still a few named pipes that are anonymously accessible by default, but many of the old ones have been removed, including the SQL\QUERY pipe, which has not been needed for many years.
|
|
Network Access: Remotely accessible registry paths
|
System\CurrentControlSet\Control\ProductOptions System\CurrentControlSet\Control\Print\Printers System\CurrentControlSet\Control\Server Applications System\CurrentControlSet\Services\Eventlog Software\Microsoft\OLAP Server Software\Microsoft\Windows NT\CurrentVersion System\CurrentControlSet\Control\ContentIndex System\CurrentControlSet\Control\Terminal Server System\CurrentControlSet\Control\Terminal Server\UserConfig System\CurrentControlSet\Control\Terminal Server\DefaultUserConfiguration
|
System\CurrentControlSet\Control\ProductOptions System\CurrentControlSet\Control\Server Applications Software\Microsoft\Windows NT\CurrentVersion
|
This setting was changed mostly because of the introduction of the "Remotely accessible registry paths and subpaths" setting. The entries in here, which includes the very important Software\Microsoft\Windows NT\CurrentVersion have been suitably restricted. The remainder have mostly been moved and are treated the same as they were in Windows XP.
|
|
Network access: Shares that can be accessed anonymously
|
COMCFG, DFS$
|
Not Defined
|
It seems logical and good that there are no longer any shares accessible anonymously. However, Windows clients never had a DFS$ share-only servers that were running DFS had that. Windows Vista does include DFS but
|
| | | |
the DFS$ share does not exist. COMCFG is created by Microsoft's Host Integration Server (formerly SNA Server). It is quite unlikely that this share will exist on clients as well. Therefore, the net change here is nil.
|
|
Network security: Do not store LAN Manager hash value on next password change
|
Disabled
|
Enabled
|
This setting has limited security value, but huge symbolic value! For the very first time, Microsoft has turned off an extremely old and widely discredited (from a security perspective) protocol. It is an all around positive change.
|
|
Network security: LAN Manager authentication level
|
Send LM & NTLM Responses (Level 0)
|
Send NTLMv2 response only (Level 3)
|
Just as with the LAN Manager hash setting, this setting marks a departure whereby Microsoft has chosen security over backward compatibility, but unlike LAN Manager hashes, this one actually has a positive security impact. This setting prevents the use of three old, and insecure by today's standards, protocols for outbound authentication. It is a very positive, and long overdue step in the right direction. This setting means Windows Vista cannot connect to Windows 9x servers hosting shares, unless the Windows 9x server can pass the authentication off to a domain.
|
Removed Security Options
Table 3 shows which security options were removed in Windows Vista.
Table 3: Security Options That Were Removed in Windows Vista
Open table as spreadsheet
|
NAME
|
NOTES
|
|
Devices: Unsigned driver installation behavior
|
This setting was more or less useless. The proportion of signed to unsigned 32-bit drivers is somewhere in the ratio of 5:95. Microsoft should have barred unsigned drivers from the beginning and it would have alleviated many problems, including the rootkit issue. On the x64 platform, where Microsoft got a chance to start over, unsigned kernel drivers are not allowed.
|
|
System objects: Default Owner for objects created by members of the Administrators group
|
This setting controls who is the owner of objects created by members of the administrators group. In early versions of Windows NT, the Administrators group was the owner of any object created by members of the Administrators group. This behavior changed in Windows 2000, but was controllable via Group Policy. Now the setting has been removed altogether. The user that created the object becomes the owner of it.
|
New Administrative Template Settings
In contrast to the relatively few changes made to the security options, there are so many administrative template settings that we could probably devote the entire book to them and still not do all of them justice. We highly encourage you to explore on your own, particularly using the list of group policy settings in Windows Vista that we mentioned earlier. By sorting the spreadsheet you can see very easily which settings are new.
In this section we will focus on some areas that we find interesting and important from a security perspective, and that are not covered in other chapters. No doubt you can find security-relevant settings sprinkled throughout other areas of Group Policy. It is quite interesting that Group Policy, in many ways, is getting so large and complex that it may already have more settings than the original registry that it was in part designed to abstract!
Attachment Manager
The Attachment Manager was introduced in Windows XP Service Pack 2 (SP2). The Attachment Manager provides a set of Application Programming Interfaces that applications that deal with attachments, primarily mail clients, can use to ensure consistent security controls are applied to those attachments. The Attachment Manager settings, shown in Figure 1, can be used to configure the risk level for specific file types as well as how antivirus programs are notified of attachments. The settings are available only in User Group Policy.
Antivirus programs can register themselves with Attachment Manager and will then receive notification any time attachments are opened. This enables them to use documented and stable ways to intercept attachments, instead of the traditional way of attempting to hack up the mail clients. It is also Attachment Manager that causes the popups when you execute a downloaded file because a downloaded file is treated just like an attachment. Attachment Manager preserves the Internet Explorer security zone the file came from within the file metadata in an alternate data stream. This behavior can also be configured in Group Policy. If you remove the alternate data stream, by, for instance, copying the file to a USB key formatted with FAT32, you lose the Attachment Manager protection.
Printer Deployment
Using the Package Point and Print functionality introduced in Windows Vista, administrators can relatively easily deploy printers to users. Using the settings under User Configuration\Administrative Templates\Control Panel\Printers, you can also restrict users to only using Package Point and Print servers.
Print drivers are very often kernel mode drivers and have full access to everything on the computer. This means that installing print drivers is a highly privileged operation. Package Point and Print is the latest mechanism Microsoft has developed to make printer installation easier and not require all end-users to be administrators. Jeremy Moskowitz has a great how-to article on his Web site (http://www.gpanswers.com/newsletters/17).
Device Installation
After the release of the movie "The Recruit," administrators seemed to become inordinately concerned with users' ability to connect USB flash drives and steal sensitive data on them. Notwithstanding the fact that hardly anyone needs the same level of security as the Central Intelligence Agency, and the fact that while almost everyone was concerned about USB flash drives, few companies installed metal detectors at the exits. Microsoft did something about the situation. The new device installation settings are shown in Figure 2.
Device installation restrictions are done based on device IDs or device classes, shown in Figure 3. There are both whitelist and blacklist settings for both types of restrictions. Obviously, blacklisting device IDs is an entirely pointless, but potentially very time-consuming exercise. Each device may have a unique ID, and the ID can typically be modified using less than $15 of electronic parts and third-year college level electrical engineering skills.
The only meaningful restrictions are whitelists, but those, of course, require a tremendous amount of work to develop a list of all the devices/device classes to permit. The level of user-pain involved is quite significant, as well as inevitable. Some devices will not make it into the first few iterations of the list.
Microsoft published a lengthy (20 pages) white paper with a step-by-step guide for how to use the new device installation restrictions. It shows how to restrict a device based on device ID, but unfortunately the information on how to find device class GUIDs was left out. These are listed in the MSDN Library.
A slightly more useful, or at least easier-to-implement, solution, is to ban writing to removable media. This can be done using the Removable Storage Access setting under Computer Configuration\Administrative Templates\System.
Keep in mind when considering whether to manage devices that you are inherently trying to restrict what some, potentially evil, person with physical access to a computer can do to that computer. With physical access, that person can do anything! Restricting device installation is nothing more than trying to restrict what authorized personnel can do with data that they are authorized to access and use. The proper way to restrict that is in the data itself. Data needs to be responsible for its own protection. It cannot rely on a device using a specific driver or a certain device ID. If you really need to restrict data, look at a way to persist protection with the data, such as the solution from Avoco Secure (http://www.avocosecure.com/), or Microsoft's Rights Management.
Remote Procedure Call
After the Blaster worm came out, Microsoft started providing administrators with more control over how the COM and RPC interfaces on computers behaved. These settings were primarily added in Windows XP SP2, and are available in Computer Configuration\Administrative Templates\System\Remote Procedure Call. For the most part, these settings are acceptable at their defaults.
Terminal Services
Windows Vista contains an entirely new Terminal Services client, which is also available down-level. Together with this client comes some new, very exciting security technology. For instance, the client can now validate the identity of the server and can be configured to not connect to servers that do not validate their identities, as shown in Figure 4.
The Terminal Services Group Policy settings are in Windows Components/Terminal Services/Remote Desktop Connection Client under Computer Configuration. Some of the same settings are also available as User Configuration settings in the same location. If the same setting is configured in both places, the Computer Setting will prevail. For instance, the setting to permit or block users storing their terminal services passwords is available in both places. As a side-note, the password is stored using the Credential Manager API, which is a quite safe way to store passwords.
The most interesting settings are available in the Terminal Server/Security node in the Computer Configuration section, as shown in Figure 5.
As shown in Figure 5, Windows Vista can specify different encryption algorithms for the RDP connections. Instead of using native RDP encryption, the connection can make use of TLS 1.0 (yes, we are aware of the fact that TLS 1.0 is not the same thing as SSL). Native RDP encryption is not bad, but TLS 1.0 uses industry standard, vetted protocols and is probably a better option.
Using the Device and Resource Redirection node, also shown in Figure 5, an administrator can configure whether audio or resource redirection is permitted. This controls whether the client is permitted to make its local devices available inside the terminal services window. In a situation where clients should not be permitted to share data with a terminal server it is important to disable clipboard, ports, and drive redirection.
|
