 TechNet Magazine June 2007

TechNet Magazine June 2007

Security: Inside Windows Vista User Account Control

User Account Control, or UAC, is one of the most misunderstood new features in Windows Vista. But its goal—to enable users to run with standard user rights—can solve many security issues. Get an inside look at the problems UAC is designed to address and see exactly how this new feature works.

Mark Russinovich Security: Keys to Protecting Data with BitLocker Drive Encryption

BitLocker serves two very important purposes: it provides both full-volume data encryption and a way to validate the integrity of early startup components before Windows Vista starts. Get an overview of how BitLocker works and see how it can help you protect your organization.

Byron Hynes Security: Exploring The Windows Firewall

Mobility has changed computer threats and the techniques that guard against them. As laptops wander outside the perimeter and come back to the network, you need better ways to protect your systems. Find out how you can use Windows Firewall to protect your computers—on the Internet and on your own internal network.

Steve Riley Security: New ACLs Improve Security in Windows Vista

While ACLs haven’t had a major overhaul, there are a number of important changes you need to know about when managing ACLs in a Windows Vista environment. Discover how 30 ACLs have changed to improve security, find out how they will impact your organization, and learn how to manage these changes in your infrastructure.

Jesper Johansson Security: Managing Hardware Restrictions via Group Policy

USB thumb-disk keys and other removable devices can make your personal life easier but your professional life harder. For improved security, you need a way to control what hardware devices your users are installing on their work systems. Now you can use Group Policy to control which devices they can use and which ones they can’t.

Jeremy Moskowitz Security: 4 Security Technologies Every IT Organization Must Have

Most businesses share similar security issues. In today’s connected world, there are four general types of security tools that every organization absolutely must have. Find out what these tools are and explore how the technologies involved may work together in the future to create the ideal security solution.

Matt Clapham and Todd Thompson Security: A Powerful New Tool for Certificate Management

Certificates are a key component in your infrastructure— when one expires, productivity can come to a halt. If you rely on a Microsoft PKI environment, the new Identity Lifecycle Manager Certificate Management (ILM-CM) solution can help keep things running smoothly. Find out how this tool can help you improve authentication processes and reduce certificate management costs.

Kevin Dallmann From the Editor: Security Issues

Joshua Trupin Toolbox: New Products for IT Pros

Greg Steen SQL Q&A: 64-Bit Installations, Allocating Cluster Memory, and More

Edited by Nancy Michell Utility Spotlight: Script Elevation PowerToys for Windows Vista

While User Account Control offers an important improvement in security, the ability to elevate permissions is essential for accomplishing certain administrative tasks and functions. Here are some Elevation PowerToys that make elevation more flexible and powerful.

Michael Murgolo The Cable Guy: The Secure Socket Tunneling Protocol

The VPN protocols in Windows XP and Windows Server 2003 don’t work for some configurations. Get an in depth look at the various issues and see how Windows Server “Longhorn” and Windows Vista with Service Pack 1 will use the Secure Socket Tunneling Protocol to solve these problems.

Joseph Davies Windows PowerShell: Working with Active Directory

Windows PowerShell doesn't provide a Get-ADSIObject cmdlet, but that doesn't prevent it from ogffering strong ADSI support. Get an introduction to type adapters and learn how you can use Windows PowerShell to work with directiory objects.

Don Jones Hey, Scripting Guy!: Scripting Around the Squiggly Red Line

Looking for an easier way to add terms to the Microsoft Word dictionary without doing it by hand, one word at a time? Who isn't? This month, the Scripting Guys show you how to create custom dictionaries in Microsoft Word, and how to programmatically configure Word to use those dictionaries.

The Microsoft Scripting Guys The Desktop Files: How Not to Lose Your Data

It’s surprising how often important data is lost. But the reality is that information is lost because people fail to protect it. Explore the important steps you can and must take to secure your organization's data.

Wes Miller Field Notes: Talk to Your Developers

Getting developers to build more manageable applications is easier than you think. It all starts with communication. Developers see software differently than administrators. But by talking to developers, administrators can explain what is important to them and developers can do a better job designing code accordingly.

David Aiken Windows Confidential: What New Users See on the Start Menu

Imagine buying a new computer, firing up Windows, clicking the Start button, and seeing a blank menu. There's a reason why the Start menu includes applications in the most frequently used spot before you've used anything--to provide a good out-of-box experience. Find out how these apps are chosen.

Raymond Chen Letters: Answers to Your Questions


 Security: Inside Windows Vista User Account Control
Security Mark Russinovich

Inside Windows Vista User Account Control
At a Glance:
  • Running as a standard user
  • File and registry virtualization
  • Elevating account status

User Account Control (UAC) is an often misunderstood feature in Windows Vista. In my three-part TechNet Magazine series on Windows Vista kernel changes, available online at technetmagazine.com, I didn’t cover UAC because I felt that it merited its own article.
In this article I discuss the problems UAC solves and describe the architecture and implementation of its component technologies. These technologies include the refactoring of operations that previously required administrative rights, lightweight virtualization to help programs run correctly without administrative rights, the ability for programs to explicitly request administrative rights, and isolation of administrative processes from non-administrative processes running on the same user desktop.

UAC’s Goal
UAC is meant to enable users to run with standard user rights, as opposed to administrative rights. Administrative rights give users the ability to read and modify any part of the operating system, including the code and data of other users—and even Windows® itself. Without administrative rights users cannot accidentally (or deliberately) modify system settings, malware can’t alter system security settings or disable antivirus software, and users can’t compromise the sensitive information of other users on shared computers. Running with standard user rights can therefore reduce urgent help desk calls in corporate environments, mitigate the impact of malware, keep home computers running more smoothly, and protect sensitive data on shared computers.
UAC had to address several problems to make it practical to run with a standard user account. First, prior to Windows Vista™, the Windows usage model has been one of assumed administrative rights. Software developers assumed their programs could access and modify any file, registry key, or operating system setting. Even when Windows NT® introduced security and differentiated between accesses granted to administrative and standard user accounts, users were guided through a setup process that encouraged them to use the built-in Administrator account or one that was a member of the Administrators group.
The second problem UAC had to address was that users sometimes need administrative rights to perform such operations as installing software, changing the system time, and opening ports in the firewall.
The UAC solution to these problems is to run most applications with standard user rights, obviate the need for administrator rights all the time, and encourage software developers to create applications that run with standard user rights. UAC accomplishes these by requiring administrative rights less frequently, enabling legacy applications to run with standard user rights, making it convenient for standard users to access administrative rights when they need them, and enabling even administrative users to run as if they were standard users.

Running as Standard User
A full audit of all administrative operations during the development of Windows Vista identified many that could be enabled for standard users without compromising the security of the system. For example, even corporations that adopted standard user accounts for their Windows XP desktop systems were unable to remove their travelling users from the Administrators group for the sole reason that Windows XP does not differentiate changing the time zone from changing the system time. A laptop user who wants to configure the local time zone so that their appointments show correctly in their calendar when they travel must have the have the "Change the system time" privilege (internally called SeSystemTimePrivilege), which by default is only granted to administrators.
Time is commonly used in security protocols like Kerberos, but the time zone only affects the way that time is displayed, so Windows Vista adds a new privilege, "Change the time zone" (SeTimeZonePrivilege), and assigns it to the Users group, as seen in Figure 1. This makes it possible for many corporations to have their laptop users run under standard user accounts.
Figure 1 The “Change the time zone” privilege
Figure 1 The “Change the time zone” privilege
Windows Vista also lets standard users configure WEP settings when they connect to wireless networks, create VPN connections, change power management settings, and install critical Windows updates. In addition, it introduces Group Policy settings that enable standard users to install printer and other device drivers approved by IT administrators and to install ActiveX® controls from administrator-approved sites.
What about consumer and line of business (LOB) applications that do not run correctly in standard user accounts? While some software legitimately requires administrative rights, many programs needlessly store user data in system-global locations. Microsoft recommends that global application installers that expect to run with administrative rights create a directory under the %ProgramFiles% directory to store their application’s executable files and auxiliary data and create a key under HKEY_LOCAL_MACHINE\Software for their application settings. When an application executes, it can be running in different user accounts and it should therefore store user-specific data in the per-user %AppData% directory and save per-user settings in the user’s registry profile under HKEY_CURRENT_USER\ Software. Standard user accounts don’t have write-access to the %ProgramFiles% directory or HKEY_LOCAL_MACHINE\Software, but because most Windows systems are single-user and most users have been administrators up until Windows Vista, apps that incorrectly save user data and settings to these locations work anyway.
Windows Vista enables these legacy applications to run in standard user accounts through the help of file system and registry namespace virtualization. When an application modifies a system-global location in the file system or registry and that operation fails because access is denied, Windows redirects the operation to a per-user area; when the application reads from a system-global location, Windows first checks for data in the per-user area and, if none is present, permits the read attempt from the global location.
For the purposes of this virtualization, Windows Vista treats a process as legacy if it’s 32-bit (versus 64-bit), is not running with administrative rights, and does not have a manifest file indicating that it was written for Windows Vista. Any operations not originating from a process classified as legacy according to this definition, including network file sharing accesses, are not virtualized. A process’s virtualization status is stored as a flag in its token, which is the kernel data structure that tracks the security context of a process, including its user account, group memberships, and privileges.
You can see the virtualization status of a process by adding the Virtualization column to Task Manager’s Processes page. Figure 2 shows that most Windows Vista components, including Desktop Window Manager (Dwm .exe), Client Server Runtime Subsystem (Csrss.exe), and Explorer, either have virtualization disabled because they have a Windows Vista manifest or are running with administrative rights and hence do not allow virtualization. Internet Explorer® (iexplore.exe) has virtualization enabled because it can host multiple ActiveX controls and scripts and must assume that they were not written to operate correctly with standard user rights.
Figure 2 Task Manager shows virtualization status
Figure 2 Task Manager shows virtualization status
The file system locations that are virtualized for legacy processes are %ProgramFiles%, %ProgramData%, and %SystemRoot%, excluding some specific subdirectories. However, any file with an executable extension, including .exe, .bat, .scr, .vbs, and others, is excluded from virtualization. This means that programs that update themselves from a standard user account fail instead of creating private versions of their executables that aren’t visible to an administrator running a global updater. To add additional extensions to the exception list, enter them in the following registry key and reboot:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Luafv\Parameters\ExcludedExtensionsAdd
Use a multi-string type to delimit multiple extensions and do not include a leading dot in the extension name.
Modifications to virtualized directories by legacy processes redirect to the user’s virtual root directory, %LocalAppData%\VirtualStore. For example, if a virtualized process that is running on my system creates C:\Windows\Application.ini, the file that it actually creates is C:\Users\Markruss\AppData\Local\VirtualStore\Windows\Application.ini. The Local component of the path highlights the fact that virtualized files don’t roam with the rest of the profile when the account has a roaming profile.
If you navigate in Explorer to a directory containing virtualized files, Explorer displays a button labeled Compatibility Files in its toolbar, as shown in Figure 3. Clicking the button navigates you to the corresponding VirtualStore subdirectory to show you the virtualized files.
Figure 3 Compatibility Files button indicates virtualized files nearby
Figure 3 Compatibility Files button indicates virtualized files nearby
Figure 4 shows how the UAC File Virtualization Filter Driver (%SystemRoot%\System32\Drivers\Luafv.sys) implements file system virtualization. Because it’s a file system filter driver, it sees all file system operations, but it only implements functionality for operations from legacy processes. You can see that it changes the target file path for a legacy process that creates a file in a system-global location, but does not for a process running a Windows Vista application with standard user rights. The legacy process believes that the operation succeeds when it really created the file in a location fully accessible by the user, but default permissions on the \Windows directory deny access to the application written for Windows Vista.
Figure 4 File system virtualization
Figure 4 File system virtualization
Registry virtualization is implemented slightly differently than file system virtualization. Virtualized registry keys include most of the HKEY_LOCAL_MACHINE\Software branch, but there are numerous exceptions, such as the following:
HKLM\Software\Microsoft\Windows
HKLM\Software\Microsoft\Windows NT
HKLM\Software\Classes
Only keys that are commonly modified by legacy applications, but that don’t introduce compatibility or interoperability problems, are virtualized. Windows redirects modifications of virtualized keys by a legacy application to a user’s registry virtual root at HKEY_ CURRENT_USER\Software\Classes\VirtualStore. The key is located in the user’s Classes hive, %LocalAppData%\Microsoft\Windows\UsrClass.dat, which, like any other virtualized file data, does not roam with a roaming user profile.
Instead of maintaining a fixed list of virtualized locations as Windows does for the file system, the virtualization status of a key is stored as a flag, REG_ KEY_DONT_VIRTUALIZE, in the key itself. The Reg.exe utility can show the flag as well as the two other virtualization-related flags, REG_KEY_ DONT_SILENT_FAIL and REG_KEY_ RECURSE_FLAG, as seen in Figure 5. When REG_KEY_DONT_SILENT_FAIL is clear and the key is not virtualized (REG_KEY_DONT_VIRTUALIZE is set), a legacy application that would be denied access performing an operation on the key is instead granted any access the user has to the key rather than the ones the application requested. REG_KEY_RECURSE_FLAG indicates if new subkeys inherit the virtualization flags of the parent instead of just the default flags.
Figure 5 Reg utility shows virtualization flags
Figure 5 Reg utility shows virtualization flags
Figure 6 shows how registry virtualization is implemented by the Configuration Manager, which manages the registry in the operating system kernel, Ntoskrnl.exe. As with file system virtualization, a legacy process creating a subkey of a virtualized key is redirected to the user’s registry virtual root, but a Windows Vista process is denied access by default permissions.
In addition to file system and registry virtualization, some applications require additional help to run correctly with standard user rights. For example, an application that tests the account in which it’s running for membership in the Administrators group might otherwise work, but won’t run if it’s not in that group. Windows Vista therefore defines a number of application-compatibility shims so that such applications work anyway. The shims most commonly applied to legacy applications for operation with standard rights are shown in Figure 7. Corporate IT professionals can use tools like the Application Compatibility Toolkit (ACT, available from technet.microsoft .com/windowsvista/aa905066.aspx) and its Standard User Analyzer (SUA) utility, or Aaron Margosis’s LUA Buglight to identify the shim requirements for their LOB applications. They assign shims to an application using the Compatibility Administrator, also part of ACT, and then deploy the resulting compatibility database (.sdb file) to their desktops via Group Policy. Note that, if required, virtualization can be completely disabled for a system using a local security policy setting.
Figure 7 Common user shims (Close Figure 7)

Shim | Purpose
ElevateCreateProcess | Changes CreateProcess to handle ERROR_ELEVATION_REQUIRED errors by calling the Application Information Service to prompt for elevation.
ForceAdminAccess | Spoofs queries of administrator group membership.
VirtualizeDeleteFile | Spoofs successful deletion of global files and directories.
LocalMappedObject | Forces global section objects into the user’s namespace.
VirtualizeHKCRLite, VirtualizeRegisterTypeLib | Redirects global registration of COM objects to a per-user location.
The Effects of Virtualization
You can change the virtualization status of a process by selecting Virtualization from the context menu that appears when you right-click it in Task Manager. Figure A shows the behavior of a command prompt when its virtualization status changes. It starts out with virtualization disabled because it has a Windows Vista manifest. Because it’s running with standard user rights, it is unable to create a file in the \Windows directory, but after it becomes virtualized with Task Manager it appears to create the file successfully. When its virtualization returns to its disabled state it can’t find the file, which is actually in the user’s virtual store.
Figure A A virtualization status change
Figure A A virtualization status change

Administrator Approval Mode
Even if users run only programs that are compatible with standard user rights, some operations still require administrative rights. The vast majority of software installations require admin rights to create directories and registry keys in system-global locations or to install services or device drivers. Modifying system-global Windows and application settings also requires administrative rights, as does the Windows Vista parental controls feature. It would be possible to perform most of these operations by switching to a dedicated admin account, but the inconvenience of doing so would likely result in most users remaining in the administrative account to perform their daily tasks.
Windows Vista therefore includes enhanced "run as" functionality so that standard users can conveniently launch processes with administrative rights. This functionality required giving applications a way to identify operations for which the system can get administrative rights on behalf of the application as necessary, which I’ll describe shortly.
Further, so that users acting as system administrators can run with standard user rights, but not have to enter user names and passwords every time they want to access administrative rights, Windows Vista introduces Admin Approval Mode (AAM). This feature creates two identities for the user at logon: one with standard user rights and another with administrative rights. Since every user on a Windows Vista system is either a standard user or running for the most part as a standard user in AAM, developers must assume that all Windows users are standard users, which will result in more programs working with standard user rights without virtualization or shims.
Granting a process administrative rights is called elevation. When it’s performed by a standard user account, it’s referred to as an Over the Shoulder (OTS) elevation because it requires the entry of credentials for an account that’s a member of the administrator’s group, something that’s usually completed by another user typing over the shoulder of the standard user. An elevation performed by an AAM user is called a Consent elevation because the user simply has to approve the assignment of his administrative rights.
Windows Vista considers a user an administrator if the user is a member of any of the administrator-type groups listed in Figure 8. Many of the groups listed are used only on domain-joined systems and don’t directly give users local administrative rights, but allow them to modify domain-wide settings. If a user is a member of any of those groups, but not the actual administrators group, then the user accesses his administrative rights via OTS elevations instead of Consent elevations.
Figure 8 Administrative groups (Close Figure 8)

Built-In Administrators
Certificate Administrators
Domain Administrators
Enterprise Administrators
Policy Administrators
Schema Administrators
Domain Controllers
Enterprise Read-Only Domain Controllers
Read-Only Domain Controllers
Account Operators
Backup Operators
Cryptographic Operators
Network Configuration Operators
Print Operators
System Operators
RAS Servers
Power Users
Pre-Windows 2000 Compatible Access
When a user belonging to one of the listed groups logs on, Windows Vista creates a token representing the standard-user version of the user’s administrative identity. The new token is stripped of all the privileges assigned to the user except those listed in Figure 9, which are the default standard user privileges. In addition, any of the administrator-type groups are marked with the USE_FOR_DENY_ONLY flag in the new token. Figure 10 shows the Sysinternals Process Explorer (a process management tool you can download from microsoft .com/technet/sysinternals) displaying the group memberships and privileges of a process running with administrative rights on the left and without administrator rights on the right. (To prevent inadvertent use, the Windows security model requires that a privilege with the disabled flag be enabled before it can be used.)
Figure 9 Standard user privileges (Close Figure 9)

Friendly Name | Internal Name
Bypass traverse checking | SeChangeNotifyPrivilege
Shut down the system | SeShutdownPrivilege
Remove computer from docking station | SeUndockPrivilege
Increase a process working set | SeIncreaseWorkingSetPrivilege
Change the time zone | SeTimeZonePrivilege
Figure 10 AAM administrator and standard user tokens
Figure 10 AAM administrator and standard user tokens
A group with the deny-only flag can only be used to deny the user access to a resource, never to allow it, closing a security hole that could be created if the group was instead removed altogether. For example, if a file had an access control list (ACL) that denied the Administrators group all access, but granted some access to another group the user belongs to, the user would be granted access if the administrators group was absent from the token, giving the standard user version of the user’s identity more access than their administrator identity.
Standalone systems, which are typically home computers, and domain-joined systems treat AAM access by remote users differently because domain-connected computers can use domain administrative groups in their resource permissions. When a user accesses a standalone computer’s file share, Windows requests the remote user’s standard user identity, but on domain-joined systems Windows honors all the user’s domain group memberships by requesting the user’s administrative identity.

Conveniently Accessing Administrative Rights
There are a number of ways the system and applications identify a need for administrative rights. One that shows up in the Explorer UI is the "Run as administrator" context menu entry and shortcut option. These items include a colored shield icon that should be placed on any button or menu item that will result in an elevation of rights when it is selected. Choosing the "Run as administrator" entry causes Explorer to call the ShellExecute API with the "runas" verb.
The vast majority of installation programs require administrative rights, so the image loader, which initiates the launch of an executable, includes installer detection code to identify likely legacy installers. Some of the heuristics it uses are as simple as detecting if the image has the words setup, install, or update in its file name or internal version information; more sophisticated ones involve scanning for byte sequences in the executable that are common to third-party installation wrapper utilities.
The image loader also calls the application compatibility (appcompat) library to see if the target executable requires administrator rights. The library looks in the application compatibility database to see if the executable has the RequireAdministrator or RunAsInvoker compatibility flags associated with it.
The most common way for an executable to request administrative rights is for it to include a requestedElevationLevel tag in its application manifest file. Manifests are XML files that contain supplementary information about an image. They were introduced in Windows XP as a way to identify dependencies on side-by-side DLL and Microsoft .NET Framework assemblies. The presence of the trustInfo element in a manifest (which you can see in the excerpted string dump of Firewallsettings.exe below), denotes an executable that was written for Windows Vista and the requestedElevationLevel element nests within it. The element’s level attribute can have one of three values: asInvoker, highestAvailable, and requireAdministrator.
<trustInfo
 xmlns=”urn:schema-microsoft-com:asm.v3”>
 <security>
  <requestedPrivileges>
   <requestedExecutionLevel
    Level=”requireAdministrator”
    uiAccess=”false”/>
  </requestedPrivileges>
 </security>
</trustInfo>
Executables with no need for administrative rights, like Notepad.exe, specify the asInvoker value. Some executables expect administrators to always want maximum access, so they use the highestAvailable value. A user who runs an executable with that value will be asked to elevate only if he is running in AAM or considered an administrator according to the rules defined earlier and must elevate in order to access his administrative rights. Regedit.exe, Mmc.exe, and Eventvwr.exe are examples of applications that use highestAvailable. Finally, requireAdministrator always causes an elevation request and is used by any executable that will fail to operate without administrative rights.
Accessibility applications specify "true" for the uiAccess attribute in order to drive the window input of elevated processes, and they must also be signed and in one of several secure locations, including %SystemRoot% and %ProgramFiles%, to get that power.
An easy way to determine the values specified by an executable is to view its manifest with the Sysinternals Sigcheck utility like this:
sigcheck –m <executable>
Executing an image that requests administrative rights causes the Application Information Service (also known as AIS, contained in %SystemRoot%\System32\Appinfo.dll), which runs inside a Service Host process (%SystemRoot%\System32\Svchost .exe), to launch Consent.exe (%SystemRoot%\System32\Consent.exe). Consent captures a bitmap of the screen, applies a fade effect to it, switches to a desktop that’s only accessible to the Local System account, paints the bitmap as the background, and displays an elevation dialog box that contains information about the executable. Displaying on a separate desktop prevents any malware present in the user’s account from modifying the appearance of the dialog box.
Figure 11 OTS elevation dialogs
Figure 11 OTS elevation dialogs
If an image is a Windows component digitally signed by Microsoft and the image is in the Windows system directory, then the dialog displays a blue stripe across the top as shown at the top of Figure 11. The gray stripe (middle dialog) is for images that are digitally signed by someone other than Microsoft, and the orange stripe (bottom dialog) is for unsigned images. The elevation dialog shows the image’s icon, description, and publisher for digitally signed images, but only a generic icon, the file name, and "Unidentified Publisher" for unsigned images. This makes it harder for malware to mimic the appearance of legitimate software. The Details button at the bottom of the dialog expands to show the command line that will be passed to the executable if it launches. The AAM Consent dialog, shown in Figure 12, is similar, but instead of prompting for administrator credentials the dialog has Continue and Cancel buttons.
Figure 12 AAM elevation dialog
Figure 12 AAM elevation dialog
If a user declines an elevation, Windows returns an access-denied error to the process that initiated the launch. When a user agrees to an elevation by either entering administrator credentials or clicking Continue, AIS calls CreateProcessAsUser to launch the process with the appropriate administrative identity. Although AIS is technically the parent of the elevated process, AIS uses new support in the CreateProcessAsUser API that sets the process’s parent process ID to that of the process that originally launched it (see Figure 13). That’s why elevated processes don’t appear as children of the AIS Service Hosting process in tools like Process Explorer that show process trees.
Figure 13 Elevation Flow
Figure 13 Elevation Flow
Even though elevation dialogs appear on a separate secure desktop, users have no way by default of verifying that they are viewing a legitimate dialog and not one presented by malware. That isn’t an issue for AAM because malware can’t gain administrative rights with a faked Consent dialog, but malware could wait for a standard user’s OTS elevation, intercept it, and use a Trojan horse dialog to capture administrator credentials. With those credentials they can gain access to the administrator’s account and infect it.
For this reason, OTS elevations are strongly discouraged in corporate environments. To disable OTS elevations (and reduce help desk calls), run the Local Security Policy Editor (Secpol.msc) and configure "User Account Control: Behavior of the elevation prompt for standard users" to "Automatically deny elevation requests."
Home users who are security-conscious should configure the OTS elevations to require a Secure Attention Sequence (SAS) that malware cannot intercept or simulate. Configure SAS by running the Group Policy Editor (Gpedit.msc), navigating to Computer Configuration | Administrative Templates | Windows Components | Credential User Interface, and enabling "Require trusted path for credential entry." After doing so you will be required to enter Ctrl+Alt+Delete to access the elevation dialog.

Isolating Elevated Processes
Windows Vista places a barrier around elevated processes to protect them from malware running on the same desktop with standard user rights. Without a barrier, malware could drive an administrative application by sending it synthesized mouse and window input via window messages. And although the standard Windows security model prevents malware running in a process with standard user rights from tampering with an elevated process running as a different user, it does not stop malware running as the standard-rights version of an administrative user from opening the user’s elevated processes, injecting code into them, and starting threads in them to execute the injected code.
The Windows Vista shield for window messages is called User Interface Privilege Isolation (UIPI). It’s based on the new Windows Integrity Mechanism that Windows Vista also uses as the barrier around elevated processes. In this new security model, all processes and objects have integrity levels, and an object’s integrity policy can restrict the accesses that would otherwise be granted to a process by the Windows Discretionary Access Control (DAC) security model.
Integrity levels (IL) are represented by Security Identifiers (SIDs), which also represent users and groups, where the level is encoded in the SID’s Relative Identifier (RID). Figure 14 shows the display name, SID, and hexadecimal version of the SID’s RID for the four primary ILs. The hex numbers reveal gaps of 0x1000 between each level that allows for intermediate levels for use by UI accessibility applications as well as future growth.
Figure 14 Primary integrity levels (Close Figure 14)

Name | SID | RID
Low Mandatory Level | S-1-16-4096 | 0x1000
Medium Mandatory Level | S-1-16-8192 | 0x2000
High Mandatory Level | S-1-16-12288 | 0x3000
System Mandatory Level | S-1-16-16384 | 0x4000
Figure 15 lists the object IL policies and the access types they restrict, which correspond to the generic accesses defined for an object. For example, No-Write-Up prevents a lower IL process from gaining any of the accesses represented by the GENERIC_WRITE accesses. The default policy for most objects, including files and registry keys, is No-Write-Up, which prevents a process from obtaining write access to objects that have a higher IL than itself, even if the object’s discretionary access control list (DACL) grants the user such access. The only objects with a different policy are the process and thread objects. Their policy, No-Write-Up plus No-Read-Up, stops a process running at a lower IL from injecting code into and reading data—like passwords—out of a process that has a higher IL.
Figure 15 Integrity level policies (Close Figure 15)

Policy | Effect
No-Write-Up | A Lower IL process cannot modify a higher IL object
No-Read-Up | A lower IL process cannot read from a higher IL object
No-Execute-Up | A lower IL process cannot execute a higher IL object
Windows assigns every process an IL that it places in the process’s token alongside the SIDs of the groups to which the user running the process belongs. Figure 16 lists examples of processes assigned to different ILs. Processes usually inherit the IL of their parent, but a process can also launch a process at a different IL, as AIS does when it launches an elevated process. You can view process integrity levels with the built-in Whoami utility by specifying the /all option, or with Sysinternals Process Explorer or AccessChk. Process Explorer can display process ILs with the addition of the Integrity Level column.
Figure 16 Sample process integrity level assignment (Close Figure 16)

Integrity Level | Example Processes
Low Mandatory Level | Protected Mode Internet Explorer and processes launched by Protected Mode Internet Explorer
Medium Mandatory Level | Standard user and non-elevated AAM processes
High Mandatory Level | Processes running with administrative rights
System Mandatory Level | Local System, Local Service, and Network Service processes
Every securable object has an IL that’s either explicit or implicit. Process, thread, and token objects always have an explicitly assigned IL that’s usually the same as the IL stored in the corresponding process token. Most objects have no explicit IL and so default to an IL of Medium. The only objects created with an IL other than Medium are the objects created by a process running at Low IL, which therefore have a Low IL. You can use the built-in iCacls tool (%SystemRoot%\System32\iCacls.exe) to view the ILs of files and the Sysinternals AccessChk utility to view the ILs of files, registry keys, services and processes. Figure 17 reveals that the IL of a directory that needs to be accessible by Protected Mode Internet Explorer is Low.
Figure 17 AccessChk showing the IL of a user’s favorites directory
Figure 17 AccessChk showing the IL of a user’s favorites directory
If an object has an explicit IL, it is stored in an access control entry (ACE) of a type new to Windows Vista, the Label ACE, in the System Access Control List (SACL) of the object’s security descriptor (see Figure 18). The SID in the ACE corresponds to the object’s IL, and the ACE’s flags encode the object’s integrity policy. Prior to Windows Vista, SACLs stored only auditing ACEs, which require the "Manage auditing and security log" privilege (SeSecurityPrivilege), but reading a Label ACE requires only Read Permissions (READ_CONTROL) access. For a process to modify an object’s IL it must have Change Owner (WRITE_OWNER) access to the object and an IL that’s equal to or higher than the object, and the process can only set the IL to its own IL or lower. The new "Modify an object label" (SeRelabelPrivilege) privilege gives a process the ability to change the IL of any object the process has access to and even raise the IL above the process’s own IL, but by default that privilege is not assigned to any account.
Figure 18 An object's Label ACE
Figure 18 An object's Label ACE
When a process tries to open an object, the integrity check happens before the standard Windows DACL check in the kernel’s SeAccessCheck function. Given the default integrity policies, a process can only open an object for write access if its IL is equal to or higher than the object’s IL and the DACL also grants the process the accesses it desires. For example, a Low IL process cannot open a Medium IL process for write access, even if the DACL grants the process write access.
With the default integrity policy, processes can open any object—with the exception of process and thread objects—for read access so long as the object’s DACL grants them read access. That means a process running at Low IL can open any files accessible to the user account in which it’s running. Protected Mode Internet Explorer uses ILs to help prevent malware that infects it from modifying user account settings, but it does not stop malware from reading the user’s documents.
Process and thread objects are exceptions because their integrity policy also includes No-Read-Up. That means a process’s IL must be equal to or higher than the IL of the process or thread it wants to open and the DACL must grant it the accesses it wants for an open to succeed. Assuming the DACLs allow the desired access, Figure 19 shows the accesses that the processes running at Medium and Low have to other processes and objects.
Figure 19 Object and Process Accesses
Figure 19 Object and Process Accesses
The Windows messaging subsystem also honors integrity levels to implement UIPI by preventing a process from sending all but a few informational windows messages to the windows owned by a process having a higher IL. That disallows standard user processes from driving input into the windows of elevated processes or from shattering an elevated process by sending it malformed messages that trigger internal buffer overflows. Processes can choose to allow additional messages past the guard by calling the ChangeWindowMessageFilter API. UIPI also blocks window hooks from affecting the windows of higher IL processes so that a standard user process can’t log the key strokes the user types into an administrative app, for example.

Elevations and Security Boundaries
It’s important to be aware that UAC elevations are conveniences and not security boundaries. A security boundary requires that security policy dictates what can pass through the boundary. User accounts are an example of a security boundary in Windows because one user can’t access the data belonging to another user without having that user’s permission.
Because elevations aren’t security boundaries, there’s no guarantee that malware running on a system with standard user rights can’t compromise an elevated process to gain administrative rights. For example, elevation dialogs only identify the executable that will be elevated; they say nothing about what it will do when it executes. The executable will process command-line arguments, load DLLs, open data files, and communicate with other processes. Any of those operations could conceivably allow malware to compromise the elevated process and thus gain administrative rights.
Playing in a Low-IL Sandbox
Protected Mode Internet Explorer runs at Low IL to create a fence around malware that might infect its process. This prevents the malware from changing the user’s account settings and installing itself in an autostart location. You can use the Sysinternals PsExec utility, along with the -l switch, to launch arbitrary processes at Low IL in order to explore the sandbox. Figure B shows how a command prompt running at Low IL can’t create a file in the user’s temporary directory, which has a Medium IL, but can do so in the Internet Explorer temporary directory, which has a Low IL.
Figure B Command prompt can only create files in similar IL
Figure B Command prompt can only create files in similar IL

Elevated AAM processes are especially susceptible to compromise because they run in the same user account as the AAM user’s standard-rights processes and share the user’s profile. Many applications read settings and load extensions registered in a user’s profile, offering opportunities for malware to elevate. For example, the common control dialogs load Shell extensions configured in a user’s registry key (under HKEY_CURRENT_USER), so malware can add itself as an extension to load into any elevated process that uses those dialogs.
Even processes elevated from standard user accounts can conceivably be compromised because of shared state. All the processes running in a logon session share the internal namespace where Windows stores objects such as events, mutexes, semaphores, and shared memory. If malware knows that an elevated process will try to open and read a specific shared memory object when the process starts, it could create the object with contents that trigger a buffer overflow to inject code into the elevated process. That type of attack is relatively sophisticated, but its possibility prevents OTS elevations from being a security boundary.
The bottom line is that elevations were introduced as a convenience that encourages users who want to access administrative rights to run with standard user rights by default. Users wanting the guarantees of a security boundary can trade off convenience by using a standard user account for daily tasks and Fast User Switching (FUS) to a dedicated administrator account to perform administrative operations. On the other hand, users who want to forgo security in favor of convenience can disable UAC on a system in the User Accounts dialog in the Control Panel, but should be aware that this also disables Protected Mode for Internet Explorer.

Conclusion
Running as standard user has numerous benefits, including helping to protect systems from accidental or deliberate damage and protecting the data and integrity of users sharing a system from unauthorized access. UAC’s various changes and technologies will result in a major shift in the Windows usage model. With Windows Vista, Windows users can for the first time perform most daily tasks and run most software using standard user rights, and many corporations can now deploy standard user accounts.

Mark Russinovich is a Technical Fellow at Microsoft in the Platform and Services Division. He is a coauthor of Microsoft Windows Internals (Microsoft Press, 2004) and a frequent speaker at IT and developer conferences. He joined Microsoft with the recent acquisition of the company he cofounded, Winternals Software. He also created Sysinternals, where he published the Process Explorer, Filemon, and Regmon utilities.
© 2007 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.


 Security: Keys to Protecting Data with BitLocker Drive Encryption
Security Byron Hynes

Keys to Protecting Data with BitLocker Drive Encryption
At a Glance:
  • Full volume encryption
  • BitLocker keys
  • Setting up BitLocker

Windows BitLocker Drive Encryption is certainly one of the most talked-about features in Windows Vista. However, most people haven’t yet had much opportunity to test BitLocker to find out firsthand
what it does and how it works—particularly not on a computer with a Trusted Platform Module (TPM). In this article, I introduce you to the basics of BitLocker™ so that you can evaluate its potential and include it in your upgrade planning. I will begin with some background and conceptual information, and then I take a look at enabling BitLocker, data recovery, administration, and how BitLocker can help at the end of a computer’s life. To better understand the terminology here, take a look at the sidebar "Disks and Volumes."
Disks and Volumes
The terminology around disks and volumes can often be confusing. Here’s an abbreviated glossary for your reference.
Partition A partition is a section of a physical hard disk. It is a logical structure defined in a partition table stored on the disk.
Volume A volume is a logical structure in Windows made up of one or more partitions and defined by a Windows component called the volume manager. Except for the volume manager and startup components, the rest of the operating system and applications work with volumes, not partitions. In the case of Windows client operating systems, including Windows Vista, partitions and volumes normally have a one-to-one relationship. In servers, a volume is often made up of multiple partitions, such as in a typical RAID configuration.
Active Partition Only one partition at a time can be marked as the active partition. This is the partition that contains the boot sector used to start the operating system. The active partition is sometimes called the system partition or system volume, but don’t confuse those terms with the Windows OS Volume.
Windows OS Volume This volume contains the Windows installation, including the System and System32 folders. Prior to the release of Windows Vista, the term boot partition was used (and is still used often). The term Windows OS volume is clearer and avoids the never-ending confusion between boot partition and system partition. In the old days, trainers would sometimes tell students to remember that you "boot from the system partition and find the system files on the boot partition."
Before Windows Vista, the Windows OS volume (also known as the boot partition), and the active partition (also known as the system partition) were the same thing, because the hard disks in most client computers were configured as one single, large partition. In Figure A you can see the functions assigned to each partition or volume in the Disk Management console in Windows Vista.
Figure A Partition Functions
Figure A Partition Functions

BitLocker really does two things that are complementary but distinct. First, BitLocker provides full-volume encryption for the Windows® OS volume. Second, on computers with a compatible TPM, BitLocker provides a way to validate the integrity of the early startup components before allowing Windows Vista™ to start.
To use all of the BitLocker functionality, your computer must have a compatible TPM microchip and BIOS. Compatible means a version 1.2 TPM and BIOS that supports the TPM and the Static Root of Trust Measurement as defined by the Trusted Computing Group (TCG). However, computers without a compatible TPM and BIOS can still use BitLocker encryption.

Full Volume Encryption
BitLocker provides full-volume encryption to ensure that all data written to the Windows OS volume is encrypted. This is key to protect confidential information stored on your organization’s computers, especially laptops and mobile computers.
Mobile computers are lost or stolen every day. With increased portable computing capacity and an increasingly mobile workforce, a single worker can be carrying hundreds of gigabytes of your organization’s trade secrets, confidential documents, or customers’ personally identifiable information (PII). Any news search will tell you that too much of that data is being lost. (The Privacy Rights Clearinghouse states that over 104 million records containing personal information have been lost or released just since 2005.)
Most organizations are already under legal and corporate mandates to protect many types of private information; and even if you’re not already legally required to, you probably have compelling a business interest to do so.

Why Encrypt the Entire Volume?
If you’re an experienced Windows administrator, you’re probably already familiar with Windows-based encryption options such as the Encrypting File System (EFS) and perhaps the encryption and protection provided by Rights Management Services (RMS). The big difference with BitLocker is that, once enabled, it is automatic, transparent, and includes the entire volume.
For example, with EFS, you have to specifically indicate which files and folders will be protected. In Windows Vista, there are some new options that make EFS more flexible, and EFS and RMS each address some scenarios that BitLocker does not. But both EFS and RMS require significant administrator configuration and are not designed to protect everything stored on the volume.
Conversely, BitLocker encrypts everything written to a BitLocker-protected volume, including the operating system itself, the registry, the hibernation and paging files, applications, and data used by applications.
There are three items not encrypted: the boot sector, any bad sectors already marked as unreadable, and the volume metadata. The volume metadata consists of three redundant copies of data used to manage BitLocker, including statistical information about the volume, and protected copies of some decryption keys. These items do not require encryption because they are not unique, valuable, or personally identifiable.
Full-volume encryption protects against offline attacks—the kind of attacks that are mounted by trying to bypass the operating system. For example, a common offline attack is to steal a computer, remove the hard drive, and install it as a second drive in another computer (running a different copy of Windows or a different operating system) to avoid NTFS permissions and user passwords. It is not possible to read a BitLocker-protected volume using this kind of attack.

How BitLocker Encrypts Data
BitLocker uses the Advanced Encryption Standard (AES) algorithm with 128-bit keys. For better protection, the keys can be increased to 256-bit keys using Group Policy or the BitLocker Windows Management Instrumentation (WMI) provider.
Each sector in the volume is encrypted individually, with a part of the encryption key being derived from the sector number itself. This means that two sectors containing identical unencrypted data will result in different encrypted bytes being written to the disk, making it much harder to attempt to discover keys by creating and encrypting known pieces of information.
Before data is encrypted using AES, BitLocker also uses an algorithm called a diffuser. Without going into the cryptography, a simple description of the diffuser is that it ensures that even minute changes to the plaintext result in the entire sector changing in the encrypted ciphertext. This also makes it much harder for an attacker to discover keys or data.
If you are interested in the details of the BitLocker encryption algorithm, you can read Neil Ferguson’s paper on it, "AES-CBC + Elephant Diffuser: A Disk Encryption Algorithm for Windows Vista".

BitLocker Keys
Any time you deal with encryption, you need to know about keys, and BitLocker is no exception. BitLocker uses an elegant, but somewhat complex, architecture of keys.
The sectors themselves are encrypted using a key called the full-volume encryption key (FVEK). The FVEK, though, is not used by or accessible to users. The FVEK is in turn encrypted with a key called the volume master key (VMK). This level of abstraction gives some unique benefits, but can make the process a bit more difficult to understand. The FVEK is kept as a closely guarded secret because, if it were to be compromised, all of the sectors would need to be re-encrypted. Since that would be a time-consuming operation, it’s one you want to avoid. Instead, the system works with the VMK.
The FVEK (encrypted with the VMK) is stored on the disk itself, as part of the volume metadata. Although the FVEK is stored locally, it is never written to disk unencrypted.
The VMK is also encrypted, or "protected," but by one or more possible key protectors. The default key protector is the TPM. Use of a TPM is discussed in the following section on integrity checking. A recovery password is also created as a key protector, for emergencies. Recovery is also discussed later.
You can combine the TPM with a numeric PIN or with a partial key stored on a USB drive for increased security. Each of these is a form of two-factor authentication. If your computer does not have a compatible TPM chip and BIOS, BitLocker can be configured to store a key protector completely on a USB drive. This is called a startup key.
BitLocker can be disabled without decrypting the data; in this case, the VMK is protected only by a new key protector that is stored unencrypted. Note that this clear key allows the system to access the drive as if it were unprotected.
At startup, the system looks for an appropriate key protector by querying the TPM, checking the USB ports, or, if necessary, prompting the user (which is called recovery). Finding a key protector lets Windows decrypt the VMK, which decrypts the FVEK, which decrypts the data stored on disk. The process is shown in Figure 1.
Figure 1 BitLocker default startup process
Figure 1 BitLocker default startup process

Integrity Checking
Because the components in the earliest part of the startup process must be available unencrypted so that the computer can start, an attacker could change the code in those early startup components (think rootkit), and then gain access to the computer, even though the data on the disk was encrypted.
By using this kind of attack, an intruder could possibly gain access to confidential information, such as BitLocker keys or user passwords, and leverage that information to get around other security protections.
Preventing this kind of attack was one of the original goals of the program and team that created BitLocker. In some ways, the encryption was almost a means to an end. The full-volume encryption allows BitLocker to protect the integrity of the system and prevent Windows from starting if the early startup components have been changed.
On computers equipped with a compatible TPM, each time the computer starts, each of the early startup components—such as the BIOS, the master boot record (MBR), the boot sector, and the boot manager code—examines the code about to be run, calculates a hash value, and stores the value in specific registers in the TPM, called platform configuration registers (PCRs). Once a value is stored in a PCR, the value cannot be replaced or erased unless the system is restarted. BitLocker uses the TPM and the values stored in PCRs to protect the VMK.
A TPM can create a key that is tied to specific PCR values. When this type of key is created, the TPM encrypts the key and only that specific TPM can decrypt it. Beyond that, though, the TPM decrypts the key only if those current PCR values match the values specified when the key was created. This is called sealing the key to the TPM.
By default, BitLocker seals keys to the measurements of the Core Root of Trust Measurement (CRTM), the BIOS and any platform extensions, option ROM code, MBR code, the NTFS boot sector, and the boot manager. If any of these items are changed unexpectedly, BitLocker will lock the drive and prevent it from being accessed or decrypted.
By default, BitLocker is configured to look for and use a TPM. You can use Group Policy or a local policy setting to allow BitLocker to work without a TPM and store keys on an external USB flash drive, but without a TPM, BitLocker cannot verify system integrity.

Enabling BitLocker for the First Time
BitLocker is available in Windows Vista Enterprise and Windows Vista Ultimate. (BitLocker will also be an optional component included with the next version of Windows Server®, code-named "Longhorn.")
The following discussion assumes that you have a computer with a compatible TPM available for testing. If you want to enable BitLocker on a computer without a TPM, follow the steps listed in the sidebar "Using BitLocker without a TPM."
Using BitLocker without a TPM
BitLocker is configured by default to use a TPM, and if you don’t have one, Windows out-of-the-box will not allow you to enable BitLocker. However, the following procedure, which was taken from the Windows BitLocker Drive Encryption Step-by-Step Guide, will allow you to use BitLocker without a TPM.
To perform these steps, you must be logged on as an administrator. Even without a TPM, your computer must support reading from a USB flash drive during the start-up process. Furthermore, you must have a USB flash drive available when you enable BitLocker and each time you restart the computer.
Follow these steps to turn on BitLocker Drive Encryption on a computer without a compatible TPM:
  1. Click Start, type gpedit.msc in the Start Search box and then press ENTER.
  2. If the User Account Control dialog box appears, verify that the proposed action is what you requested and then click Continue.
  3. In the Group Policy Object Editor console tree, click Local Computer Policy, click Administrative Templates, click Windows Components, and then double-click BitLocker Drive Encryption.
  4. Double-click the setting Control Panel Setup: Enable Advanced Startup Options. The Control Panel Setup: Enable Advanced Startup Options dialog box appears.
  5. Select the Enabled option, select the Allow BitLocker without a compatible TPM checkbox, and then click OK. You have changed the policy setting so that you can use a startup key instead of a TPM.
  6. Close the Group Policy Object Editor.
  7. To force Group Policy to apply immediately, you can click Start, type gpupdate.exe /force in the Start Search box, and then press ENTER. Wait for the process to finish.

An important part of enabling BitLocker is making sure that your volumes are configured correctly. BitLocker requires that the active partition be unencrypted so that the boot sector, the boot manager, and the Windows loader program can be read (these components are protected by the system integrity steps described previously). Since other Windows components may require temporary use of the active partition, Microsoft recommends that the active partition be at least 1.5GB. It’s also a good idea to configure NTFS permissions so that users cannot accidentally write data to this volume.
Windows itself will be installed to a second larger volume, which can be encrypted. If you are installing Windows on a new system, you can manually configure the volumes following the instructions available in Windows BitLocker Drive Encryption Step-by-Step Guide.
You can use the BitLocker Drive Preparation Tool to help set up your system for BitLocker. This tool takes the hard work out of configuring the drives, and it is available as a Windows Vista Ultimate Extra or to customers who are deploying Windows Vista Enterprise. For detailed instructions on the BitLocker Drive Preparation Tool, visit support.microsoft.com/kb/930063.
The BitLocker Drive Preparation Tool automatically shrinks the volume (if you have only one), creates the second partition, makes it active, makes all necessary configuration changes, and moves the startup files to the right place.
Once your volumes are configured, enabling BitLocker is straightforward. In the Security section of the Control Panel, click the BitLocker Drive Encryption icon. After you acknowledge the UAC consent prompt, a screen similar to Figure 2 appears.
Figure 2 Enabling BitLocker
Figure 2 Enabling BitLocker
The exact sequence of what happens next will vary according to the state of the TPM chip in your computer. If the TPM chip is not initialized, the TPM Initialization Wizard will run. Follow the prompts to initialize the TPM, which will include restarting your computer.
After your TPM is initialized, the Save the recovery password page appears, as shown in Figure 3. To be able to recover your data in the event of a TPM failure or other problem, you need a recovery password. This page allows you to save a recovery password to a USB flash drive or to a local or network disk, or to print it for safekeeping. You must choose at least one of these options, and you can chose to save multiple copies. Once the recovery password has been saved, the Next button will be enabled. Click it.
Figure 3 Saving your recovery password
Figure 3 Saving your recovery password
The Encrypt the selected disk volume page appears and you can choose whether or not to run a system check before the encryption starts. The system check will require a restart, but it is the best way to make sure that your TPM, BIOS, and USB ports will work properly with BitLocker. After the restart, if any problems were detected, then you will see an error message. Otherwise, the Encryption in Progress status bar is displayed.
That’s it. Encryption will complete in the background, and you can continue using your computer. Once the initial encryption is complete, a message will appear to let you know. You can also monitor the ongoing completion status of the disk volume encryption by dragging your cursor over the BitLocker Drive Encryption icon in the tool bar at the bottom of your screen. For more details, you can refer to the Step-by-Step Guide mentioned earlier.
Some users have been surprised to see that BitLocker doesn’t prompt the user or make any other obvious interruptions when the computer starts up. That’s because, in its default configuration, BitLocker is relying on the TPM to confirm the system integrity prior to unlocking the volume. This is automatic and transparent to the user.
You can configure BitLocker to require the entry of a PIN or the presence of a key stored on a USB flash drive at startup. This increases security and is recommended for situations where the increased security outweighs the inconvenience of entering the PIN. In my opinion, that’s always. (In other words, my desktop requires a PIN and my laptop requires a USB key.)

BitLocker Recovery
When dealing with encryption—especially in a business or enterprise environment—it is essential that you have a way for an authorized user to get their data back, even if the normal access methods or keys aren’t available. BitLocker calls this recovery.
If something changes unexpectedly in the early startup components, or you lose a USB startup key or a user forgets his PIN, BitLocker will not be able to complete the normal startup process. BitLocker will leave the volume locked, and Windows will not be able to start up. Instead, the BitLocker code in the boot manager will present a text screen. If a recovery password has been saved to a USB flash drive (sometimes called a recovery key), a screen similar to Figure 4 appears.
Figure 4 Looking for a recovery key
Figure 4 Looking for a recovery key
For BitLocker to read a USB flash drive, it has to be connected at startup. So if you have a USB flash drive with a recovery password, insert it and press ESC. If you don’t have such a thing, press Enter to see the screen shown in Figure 5. This screen will also appear if a recovery key was never saved to a USB drive.
Figure 5 Entering a BitLocker password
Figure 5 Entering a BitLocker password
BitLocker is now looking for a 48-digit numerical password that can unlock the drive. This number appears on the page if you chose to print the recovery password, and it is also stored in a file if you saved the recovery password to a folder.
The easiest way to manage recovery passwords in a business is to have them automatically stored in Active Directory®. You can get all of the details on how to do that at go.microsoft.com/fwlink/?LinkId=87067.
In a follow-up article I’ll elaborate on the manageability of BitLocker, but as part of this overview, you should know that BitLocker ships with a full WMI provider that allows BitLocker (and the TPM) to be managed through any WMI-compatible Web-Based Enterprise Management (WBEM) system. This means that BitLocker can also be scripted using any scripting language that can access WMI objects, such as VBScript or Windows PowerShell™.
BitLocker also ships with a command-line tool called manage-bde.wsf that uses the WMI provider to let you manage BitLocker, on local or remote computers. For more information, launch an elevated command prompt and type manage-bde.wsf /?.

Secure Decommissioning
There comes a point where every computer needs to be decommissioned. Businesses usually expend significant funds and effort making sure that disk drives are completely sanitized before they are released. Most processes that remove confidential data from disk drives are time-consuming, costly, or result in the permanent destruction of the hardware. BitLocker provides other more cost-effective options.
Rather than worrying about removing the data after the fact, BitLocker helps ensure that confidential data isn’t stored on disk in a risky way in the first place. Since everything written to the disk is encrypted, the data can be permanently rendered completely inaccessible by destroying all copies of the encryption keys. The hard disk itself is completely unharmed and can be reused.
You can choose from a number of approaches in decommissioning volumes that have been protected by BitLocker. You can choose to delete all copies of keys from the volume metadata, while keeping them archived in a secure central site. This can enable systems to be transported safely or temporarily decommissioned if they will be left unattended for long periods of time. It ensures that authorized users could still access the data, but not any unauthorized users, such as new owners of the equipment.
You can also choose to delete all copies of keys from the volume metadata and from any archives, such as Active Directory (perhaps by creating new keys that are not stored). Since no decryption keys then exist, no one can recover or retrieve the data.
In either of these cases, the removal and destruction of the keys contained in the volume metadata is almost instantaneous and can be performed across multiple systems by an administrator. A minimal investment of time and effort is required but results in a very high level of permanent protection. The format utility in Windows Vista has been updated so that a format command deletes the volume metadata and overwrites those sectors to securely delete any BitLocker keys.

A Few Final Points
BitLocker is a powerful tool designed to protect against specific threats, and it does an excellent job. However, it would be a mistake to expect BitLocker to protect against all threats. It is absolutely critical that you continue to use proper defenses and controls, such as strong passwords.
Understand that BitLocker is geared towards offline attacks. That means that if Windows is running, BitLocker has unlocked the volume. In other words, BitLocker does not offer protection to a running system. Technologies such as EFS and RMS complement BitLocker by protecting information while the OS is running.
For more information about BitLocker, visit the Microsoft Web site, starting at technet.microsoft.com/windowsvista/aa905065.aspx. For more about TPM specifications and the TCG, visit the TPM Specifications section of the TCG Web site at go.microsoft.com/fwlink/?LinkId=72757.

Byron Hynes works in the Windows Server User Assistance group at Microsoft. In the past, he worked as a consultant and trainer. You can reach him at bhynes@microsoft.com.


 Security: Exploring The Windows Firewall
Security Steve Riley

Exploring The Windows Firewall
At a Glance:
  • Inbound vs. outbound protection
  • The Windows Filtering Platform
  • The Advanced Security interface
  • Network profiles

Back in the days of the paleocomputing era, no one ever thought about installing firewalls on individual computers. Who needed to? Hardly anyone had heard of the Internet, TCP/IP was nowhere in sight, and LAN protocols didn’t route beyond your building or campus. Important data lived on
the mainframe or file servers—the information people kept on their desktop computers was rarely mission critical and the computer’s own weight afforded a certain amount of decent physical security. If there was a connection to the Internet available, there were likely some protocol translators in the way and a packet-filtering router (I mean "firewall") at the edge, probably configured with too many rules and exceptions.
Modern computing environments wildly diverge from those ancient times. Everything is connected to the Internet (and talks TCP/IP now) and portable devices are now the standard. Your employer has likely given you a laptop, not because they care about you, but because they care about getting more out of you—they fully expect you to work anytime you’ve got five spare minutes and a Wi-Fi connection. Laptops might cost more than desktops, but that investment is surely repaid in productivity. You see, it’s the portability that makes them so alluring—to you and your adversaries.
Think about this: of the total amount of time your laptop is powered up and connected to some network, what percentage of that time is it connected to your corporate network? If you’re anything like me, maybe 20 percent max. That means that only 20 percent of the time is my laptop safely within the confines of the Microsoft corporate network, protected by the network’s perimeter defenses from outside attack. But what about the 80 percent of time when my laptop is, for all practical purposes, connected directly to the Internet? (And I’m quite often connected to the most dangerous network in the world: the hotel LAN at a computer security conference!) And those times when I am connected to the corporate network, how about threats posed by other computers within that environment?
Security controls evolve to follow—sometimes too far behind—the threats. Viruses were a client problem because people traded floppy disks, so antivirus programs first appeared on clients. Then as e-mail became popular and malware matured into worms that relied on e-mail distribution, anti-malware programs evolved and appeared on e-mail gateways. With the rise of the Web, malware matured into Trojans and anti-malware followed onto Internet access proxy servers. This is a well-understood evolutionary path that no one quibbles with.
Now let’s apply the same logic to firewalls. While a firewall at your network’s edge was sufficient protection against the threats of yesterday, this is no longer the case as threats are different, they’re more sophisticated, and they’re more prevalent. Not to mention that devices and work styles differ significantly from the past. Many computers carry sensitive information stored locally, and they spend a lot of time away from the corporate network (that is, outside the edge). Therefore, the firewall must evolve into an individual client protection mechanism. Make no mistake: client firewalls are no longer optional. To protect your computers from your own corpnet and from the Internet, client firewalls are required.

Client Firewalls and Security Theater
Many people didn’t realize that the initial release of Windows® XP included a client firewall. That’s not really surprising since the firewall was switched off by default and it was buried behind too many mouse clicks. In its own rather stealthy way, the firewall just showed up without any real indication of its purpose or guidance on how to use it. But it did work. If you had enabled that firewall, it would have saved you from Nimda, Slammer, Blaster, Sasser, Zotob, and anything else that tried to hurl unsolicited traffic at your network port. Realizing the importance of client protection, Windows XP Service Pack 2 (SP2) enabled the firewall by default, created two profiles (Internet and corpnet), and allowed for Group Policy enablement.
Unfortunately, two barriers slowed the adoption of the Windows XP SP2 firewall: application concerns and security theater. Many people worried that the firewall would stop their applications from working correctly. This was rarely the case, though, because of the firewall’s design. The firewall allowed all outbound traffic to leave your computer, but blocked all inbound traffic that wasn’t in reply to some previous outbound request. The only time this design would break an application on a client was if the application created a listening socket and expected to receive inbound requests. The Windows XP firewall allowed for simple configurations of exceptions for programs or ports (but, unfortunately, not through Group Policy).
The bigger deterrent was the security theater performed by manufacturers of other client firewalls. Some people believed that the design of the Windows XP firewall—namely allowing all outbound traffic to leave unfettered—was insufficient functionality for a client firewall. The argument was that a sufficient client firewall should block all traffic, inbound and outbound, unless the user has specifically granted permission.
Now, let’s think this through for a moment. Two scenarios emerge.
  • If you’re running as a local administrator and you are infected by malware, the malware will simply disable the firewall. You’re 0wn3d.
  • If you aren’t running as a local administrator and you get infected by malware, the malware will cause a third-party firewall to raise a dialog filled with a foreign language involving ports and IP addresses and a very serious question: "Do you want to allow this?" The only answer, of course, is "Yes, you stupid computer, stop harassing me!" And once that dialog goes away, so does your security. Or, more commonly, the malware will simply hijack an existing session of a program you’ve already authorized, and you won’t even see the dialog. Again, you’re 0wn3d.
There’s an important axiom of security that you must understand: protection belongs on the asset you want to protect, not on the thing you’re trying to protect against. The correct approach is to run the lean yet effective Windows firewall on every computer in your organization, to protect each one from every other computer in the world. If you try to block outbound connections from a computer that’s already compromised, how can you be sure that the computer is really doing what you ask? The answer: you can’t. Outbound protection is security theater—it’s a gimmick that only gives the impression of improving your security without doing anything that actually does improve your security. This is why outbound protection didn’t exist in the Windows XP firewall and why it doesn’t exist in the Windows Vista™ firewall. (I’ll talk more about outbound control in Windows Vista in a bit.)

What’s New in Windows Vista?
The Windows Filtering Platform, part of the new network stack, is the foundation for the Windows Vista firewall. Like Windows XP, Windows Vista blocks inbound traffic by default. Depending on which profile your computer is using, there might be some default exceptions for network services (I’ll discuss profiles later). You can, if you wish, write rules to allow inbound connections. Also like Windows XP, Windows Vista by default allows all outbound traffic from interactive processes, but restricts outbound traffic from services that participate in service restriction. And, again, you can write rules to block additional outbound connections.
The big difference between Windows XP and Windows Vista is the new Advanced Security interface and full Group Policy support for configuration and rules (see Figure 1). The old Control Panel UI is still there and it’s mostly unchanged except for logging and Internet Control Message Protocol (ICMP) settings, which are now in the new UI. This new UI, the Advanced Security MMC snap-in, offers all the new features and flexibility. There’s also a new context in the netsh command, netsh advfirewall, through which you can script rule addition and deletion, set and show global and per-profile policies, and display the firewall’s active state. And for you developers, FirewallAPI.dll and Netfw.h provide programmatic control over all of the firewall’s settings.
Figure 1 Windows Firewall with Advanced Security
Figure 1 Windows Firewall with Advanced Security
The Advanced Security MMC is wizard-driven. When creating a rule, you can choose one of four types: program, port, predefined, or custom. These are explained in Figure 2.
Figure 2 Four types of rules (Close Figure 2)

Type | Purpose
Program | Used to allow or block traffic for a particular program.
Port | Used to allow or block traffic on particular TCP or UDP ports.
Predefined | Uses a pre-existing group of rules to enable Windows functionality on the network (such as file and print sharing or remote assistance).
Custom | Exposes all the knobs and dials and buttons and switches so you can configure as specific a rule as you want.
There are many elements that you can reference when writing rules, all of which are available for local rules and rules applied through Group Policy. These include: Active Directory® user and computer accounts and groups, source and destination IP addresses, source and destination TCP and UDP ports, IP protocol numbers, programs and services, types of interfaces (wired, wireless, or remote access), and ICMP types and codes.
Once configured, the firewall processes rules in the following order:
Service Restrictions Some of the services in Windows Vista will restrict themselves to limit the likelihood of another Blaster-style attack. One of the restrictions is a list of ports the service requires. The firewall enforces this and prevents the service from using (or being told to use) any other port.
Connection Security Rules The Advanced Security MMC incorporates IPsec as well as the firewall. Any rules that include IPsec policies are processed next.
Authenticated Bypass These allow specified authenticated computers to bypass other rules.
Block Rules These explicitly block specified incoming or outgoing traffic.
Allow Rules These explicitly allow specified incoming or outgoing traffic.
The firewall rules are stored in the registry, but I’m not going to tell you exactly where. Oh, OK, you’ll find them at these locations:
  • HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\SharedAccess\Defaults\FirewallPolicy\FirewallRule
  • HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\FirewallRules
  • HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\RestrictedServices\Static\System
Just please don’t edit the rules directly in the registry. If you do, we’ll find you and sell your pet on eBay! Well, maybe not, but the only supported way to edit rules is to use the Advanced Security MMC.

Network Profiles
Windows Vista defines three network profiles: domain, private, and public. When the computer is domain-joined and has successfully logged into the domain, the computer automatically applies the domain profile—you never get to make this choice on your own. When the computer is connected to an internal network that lacks a domain (like a home or small office network), you (or an administrator) should apply the private profile. Finally, when the computer is directly connected to the Internet, you should apply the public profile.
How does Windows Vista decide where to place your computer? Whenever there’s a network change (say it receives a new IP address or sees a new default gateway or gets a new interface), a service called Network Location Awareness (NLA) detects the change. It builds a network profile—which includes information about existing interfaces, whether the computer authenticated to a domain controller, the gateway’s MAC address, and so on—and assigns it a GUID. NLA then notifies the firewall and the firewall applies the corresponding policy (there’s a policy defined for each of the three profiles).
If this is a new interface that the computer hasn’t seen before and NLA didn’t choose the domain profile, then you’ll see a dialog box that asks you to indicate what kind of network you’re connecting to. Mysteriously, there are three choices: Home, Work, and Public. You might think that Work means the domain profile, but that’s not actually the case. Remember, you never see the domain profile because NLA automatically selects that when the computer logs onto a domain. In reality, both Home and Work correspond to the private profile. Functionally, they’re equivalent—only the icons are different. (Note: you must be a local administrator, or able to elevate to a local administrator, to select the private profile.) As you’d expect, public corresponds to the public profile.
In Windows Vista, a network profile applies to all the interfaces in the computer. Here’s a rundown of the NLA decision tree:
  1. Examine all connected networks.
  2. Is any interface connected to a network classified as public? If yes, set the computer’s profile to public and exit.
  3. Is any interface connected to a network classified as private? If yes, set computer’s profile to private and exit.
  4. Do all interfaces see a domain controller and did the computer successfully log on? If yes, set computer’s profile to domain and exit.
  5. Else set computer’s profile to public.
The goal is to select the most restrictive profile possible. There are two obvious side effects, however. First, if your computer’s Ethernet port is connected to your corpnet and its wireless NIC is connected to the Starbucks downstairs, the computer will select the public profile, not the domain profile. Second, if your computer is directly connected to the Internet (in the public profile) or is connected to your home LAN (in the private profile) and you make a VPN connection to your corpnet, your computer will remain in the public or private profile.
What might this mean? The firewall’s policy for the domain profile includes rules for remote assistance, remote administration, file and print sharing, and so on. If you rely on these rules in order to get to a client remotely, you won’t be able to if the client has chosen some other profile. But don’t despair—you can write firewall rules to allow whatever inbound connections you need and then apply them only to VPN connections. Now you can still administer your clients over the VPN even when they aren’t in the domain profile.

Controlling Outbound Connections
Earlier, I said that the typical form of outbound protection in client firewalls is just security theater. However, one form of outbound control is very useful: administratively controlling certain types of traffic that you know you don’t want to permit. The Windows Vista firewall already does this for service restrictions. The firewall allows a service to communicate only on the ports it says it needs and blocks anything else that the service attempts to do. You can build on this by writing additional rules that allow or block specific traffic to match your organization’s security policy (see Figure 3).
Figure 3 New Inbound Rule Wizard
Figure 3 New Inbound Rule Wizard
Say, for instance, that you want to prohibit users from running a particular instant messaging client. You can create a rule (in Group Policy, of course) to block connections to the login servers for that client.
There are practical limitations to this approach, though. For example, Windows Live™ Messenger (which you might still know as MSN® Messenger) has a variety of servers it can use to log in, and the list is always changing. Plus, it’ll fall back to port 80/tcp if the default port 1863/tcp is blocked. A rule to block Windows Live Messenger from connecting to its login servers would be too complex and always in flux. I mention this to illustrate that administrative outbound control can be useful, but isn’t a substitute for Software Restriction Policies if you need to maintain tight control over the software users are allowed to install and run.

Protect Your Computer
The perimeter is gone. Every computer must now take responsibility for its own protection. Just as anti-malware moved from the client to the edge, so firewalls must move from the edge to the client. You can take immediate action by enabling the firewall you’ve already got installed.
Whether your systems are running Windows XP or you’re already transitioning to Windows Vista, the Windows firewall is available to all your clients and will provide the protection you need to improve security within your organization—even when your mobile workers are thousands of miles away from the office.

Where to Learn More
  • Windows Vista TechCenter: Getting Started with Windows Firewall with Advanced Security
  • Windows Vista TechCenter: Windows Firewall with Advanced Security—Diagnostics and Troubleshooting
  • Steve Riley’s TechEd Europe Presentation: Windows Vista Firewall and IPSec Enhancements
  • The Cable Guy: The New Windows Firewall in Windows Vista and Windows Server "Longhorn"
  • Windows Vista Firewall Virtual Lab

Steve Riley, a senior security strategist in the Microsoft Trustworthy Computing Group and contributing editor for TechNet Magazine, jets around the world to speak at conferences and spend time with customers to help them get and stay secure. His latest book is Protect Your Windows Network (Addison-Wesley, 2005). You can reach him at steve.riley@microsoft.com.


 Security: New ACLs Improve Security in Windows Vista
Security Jesper Johansson

New ACLs Improve Security in Windows Vista
At a Glance:
  • What’s new in ACLs
  • Tighter controls on administrator
  • Trusted installer permissions
  • Modified users and groups

The fundamental structure of access control lists (ACLs) has not changed much for Windows Vista, but there are a number of small yet important changes you need to be aware of. Some changes
were necessary because in Windows® XP, ACLs played a part in several problems. First, most Windows XP users run as administrator. That is, they use an account that is a member of the built-in Administrators group. For home users, this is a virtual certainty because all accounts added during setup become administrators. Therefore any programs such users execute will also execute with administrative privileges, giving them unfettered access to the operating system. Of course, this is especially problematic if those programs are of the unsavory variety.
The second problem that needed to be addressed was that the default ACLs in earlier versions of Windows made many people nervous as they included ACL entries (ACEs) for Everyone, Power Users, and the like. For instance, the default ACL on the root of the boot volume (normally C:\) in Windows XP gave Read access to Everyone and granted permission to create folders for members of the Users group. Finally, in Windows XP there were limitations on what you could do with ACLs. For instance, there was no way in Windows XP to assign permissions to the current owner of an object. You could give the owner permissions but if the owner changed, those permissions were not transferred. Likewise, owners always had implicit rights to an object, no matter what permissions they were assigned on that object.
With Windows Vista™, Microsoft embarked on a project to resolve many of these issues, and to enable support for other features, such as User Account Control (UAC). This article focuses on the major changes related to access control in Windows Vista. Next month I’ll continue with a look at the tools you can use to manage access control.

New and Modified Users and Groups
Some users and groups in Windows Vista are new, and some old friends from Windows XP have been removed. Moreover, the way some of them work has been modified. Each of the changes has some impact on how you manage access control.
Administrator—Disabled By Default The built-in Administrator account, the one with a relative identifier (RID) of 500, is now disabled by default in most cases. Administrator was meant to be an emergency account, used for salvaging the computer when all else failed. Far more often, however, it ended up being used as the standard administrative account, thereby violating several principles of security. The most notable of these—accountability—means you lose ability to track who is making changes on your system. Therefore, the account was partially deprecated. Eventually, Microsoft may deprecate the account altogether, but for now it is disabled by default. If you have no other local accounts in the Administrators group, RID 500 is still usable in the recovery console and safe mode, but otherwise it cannot, and should not, be used.
Note that there is a difference between the built-in Administrator account and other accounts in the Administrators group. We typically capitalize "Administrator" when referring to the account with RID 500 to distinguish it from an "administrator," which is any other account that is a member of the built-in Administrators group. Group names are similarly capitalized.
In Windows XP, the built-in Administrator account had a number of special rights and privileges that no other administrator had. Many of these have been removed in Windows Vista, but there are two notable exceptions: First, a disabled Administrator account can be used in the recovery console if there are no other local administrators. Second, the Administrator is not subject to UAC and will always have a full administrative token. The same is true of the Domain Administrator (RID 500 on a domain).
Power Users Permissions Removed The old Power Users group has, for all practical purposes, been abolished. The group is still there, but most of the permissions granted to it have been removed. It was not exactly a secret that a user who was a member of Power Users was effectively an administrator who had simply not yet made himself an administrator. I once took over a machine that was fully patched, running Windows XP Service Pack 2 (SP2), in less than 45 minutes by granting myself administrative privileges. That included the reconnaissance, writing a small program in C++, and logging off and on again to complete the take-over—all enabled because I was a member of Power Users.
Many organizations have granted sophisticated permissions to the Power Users group and rely on their users being members of it, so it was not feasible to remove the group in Windows Vista. However, Microsoft is likely to completely remove Power Users in an upcoming version of Windows. You would be well advised to start planning to migrate away from Power Users.
Trusted Installer The Trusted Installer is actually a service, not a user, even though you see permissions granted to it all over the file system. Service hardening allows each service to be treated as a full-fledged security principal that can be assigned permissions just like any other user. For an overview of this feature, see the January 2007 issue of TechNet Magazine. The book Windows Vista Security (Grimes and Johansson, Wiley Press, 2007) explores service hardening in detail, including how it is leveraged by other features, such as the firewall and IPsec.
Service SIDs are not issued from the authorities we have seen before, such as NT AUTHORITY or a domain. The full name for the TrustedInstaller virtual account is NT SERVICE\TrustedInstaller and its SID is:
S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464
You can see the SID for any service, even for ones that do not exist, by running the sc showsid command, as shown in Figure 1.
Figure 1 sc showsid shows the SID for any service, including those that do not exist yet
Figure 1 sc showsid shows the SID for any service, including those that do not exist yet
This SID begins with S-1-5-80. Notice that the first sub-authority here is 80, which stands for SECURITY_SERVICE_ID_BASE_RID, meaning this SID is issued by the NT SERVICE sub-authority to a service. The same is true for any service. The remaining sub-authorities and the RIDs are based on the service name itself. This enables a developer to grant permissions to his service without actually having to build and install the service first as the name is deterministic and will not vary from machine to machine.
In case you can’t find the TrustedInstaller service in the services manager, its display name is "Windows Modules Installer."
Help and Support Accounts Removed The Support_xxxxxx and HelpAssistant accounts are both removed on clean installations of Windows Vista, although they are retained when upgrading from a previous version of Windows. The Support_xxxxxx account was used to run scripts from the support center. Some OEMs who provided their own help content may also have provided their own support accounts. It is unclear what will happen to OEM accounts, but more than likely the OEMs will simply stop creating them. Strictly speaking, they are no longer necessary. In fact, from a security perspective, it was not a great idea to allow users to execute scripts from the help center as another user anyway, so it would be best if those accounts disappeared. Windows Vista has a new mechanism to accomplish this task.
The HelpAssistant account was used during remote assistance. As with the help center, the remote assistance feature has been re-engineered to avoid the need for the HelpAssistant account and consequently it has been removed.
New Network Location SIDs Windows NT®-based operating systems have always had some network location-based SIDs, such as NETWORK and INTERACTIVE, denoting users logging on from the network and interactively. There is also a REMOTE INTERACTIVE LOGON SID that is assigned to users logging on via Terminal Services. (Note that Terminal Services users will actually have both REMOTE INTERACTIVE LOGON and INTERACTIVE LOGON in their tokens.) In Windows Vista, two more are added: DIALUP and INTERNET. The exact rationale for adding an account denoting a logon via dial-up is a bit unclear, particularly when more and more users will not go online if the only network available is a phone line, but it is there now. INTERNET is obviously meant to indicate any user logged on from beyond the local area network. NETWORK, however, still designates any user logging on from the network, including the Internet.
OWNER RIGHTS and Owner Rights There is now a SID for OWNER RIGHTS, which applies to whoever happens to own a file at the time it is accessed. It is primarily used to restrict what the owner can do with the file. There are two notable changes to how owner rights work as compared to Windows XP. First, if you are the owner of the object, but there is an ACE on the object that applies to you, the rights in the ACE will supersede the fact that you are the owner. This is a major change and will significantly impact certain aspects of system administration as we are used to the owner having implicit rights. Second, the OWNER RIGHTS SID can be used to further restrict what the owner can do with an object.
Let’s assume we have a folder, owned by the user Jesper, with an ACL as shown in Figure 2. The user, Jesper, only has Read permission on the folder, even though he is the owner. If he tries to copy a file into it, the copy will fail because Jesper does not have permission to write to the folder. This is not entirely intuitive from the error messages, however. If you attempt to copy a file into a folder you own but don’t have write permissions for using Windows Explorer®, here is what happens: first, Explorer says you need to elevate permissions to copy the file and asks you to elevate, but the file copy fails because you do not have rights to copy anything into this folder. You get an error message that says "You need permission to perform this action" and a button each for "Try again" (as if that might help) and "Cancel". This is in spite of the fact that you are the owner.
Figure 2 Only Local System and one other user have access to this folder
Figure 2 Only Local System and one other user have access to this folder
If Jesper tries to change the ACL on the file, he will get prompted to elevate his token to do so. Since he is the owner of the file, he can do this. The owner retains implicit rights to read and change the ACL (READ_CONTROL and WRITE_DAC) unless there is an ACE for OWNER RIGHTS that specifies otherwise.
To understand the effect of the OWNER RIGHTS SID, let’s add that to the ACL above. We now have the permissions shown in Figure 3.
Figure 3 Adding OWNER RIGHTS permissions to the folder changes Jesper’s permissions
Figure 3 Adding OWNER RIGHTS permissions to the folder changes Jesper’s permissions
With these permissions, if the Jesper account attempts to copy something into the folder, this act is immediately successful because Jesper is the owner and has the appropriate rights. However, if Jesper tries to change the ACL on the object, that action will fail! The ACE for OWNER RIGHTS specifies that the owner shall have only Modify privilege, not the ability to modify the discretionary access control list (DACL). Thus, OWNER RIGHTS is used primarily to remove WRITE_DAC, the ability to modify the security descriptor, from the owner.
If an administrator changes the owner of the object, the OWNER RIGHTS permissions are not automatically transferred to the new owner. In this case the OWNER RIGHTS ACE is disabled by marking it as inherit-only but not applying it to either containers or objects—in other words, not applying it to anything at all. This is done to ensure that administrators do not get completely locked out of the object. To get the OWNER RIGHTS ACE to take effect again, the Administrator has to go in and manually re-enable the ACE. To do so, you mark it as applying to this folder, subfolders, and files, as desired.
There are several interesting scenarios in which the OWNER RIGHTS SID can be useful, such as when the administrator wants users to be able to create files and folders on a file server, but does not want them to be able to change ACLs on those folders. Another likely situation occurs when users were members of a group at some point and created some objects but, perhaps for business reasons, they were later removed from this group. At this point, they should not be able to modify the settings on those objects.
OWNER RIGHTS is used fairly extensively in service hardening. When a service creates a transient object at run time the creator of the object is the primary SID of the service process, typically LocalSystem, NetworkService, or LocalService, and not the SID for the service itself. That means that any other service running in the same process context can modify the object, which is almost certainly not desirable. By setting an OWNER RIGHTS SID on such objects, the OS can keep other services from accessing them.

Default ACLs
The default ACLs in Windows XP were actually reasonably good. Apart from some minor issues, such as permitting users to put files in the root of the boot volume, they were generally sensible. However, some OEMs apparently decided they knew better what constituted reasonable security. The screen in Figure 4 shows a picture of the ACL on the Windows directory on a computer running Windows XP Media Center Edition from a major OEM. The OEM essentially disabled file system security.
Figure 4 An OEM-configured ACL
Figure 4 An OEM-configured ACL
Microsoft did some tweaking to ACLs in Windows Vista. First, if you are accustomed to Windows XP, you know that all OS files are owned by the Administrators group and administrators have full control over those files. As a member of that group, you thus had unfettered access to those files. That’s not the case in Windows Vista.
Trusted Installer In Windows Vista, most of the OS files are owned by the TrustedInstaller SID, and only that SID has full control over them. This is part of the system integrity work that went into Windows Vista, and is meant specifically to prevent a process that is running as an administrator or Local System from automatically replacing the files. In order to delete an operating system file, you thus need to take ownership of the file and then add an ACE on it that lets you delete it. This provides a thin layer of protection against a process that is running as LocalSystem and has a System integrity label; a process that has lower integrity is not supposed to be able to elevate itself to change ownership. Some services, for instance, can run with medium integrity, even though they are running as Local System. Such services cannot replace system files so an exploit that takes over one of them can’t replace operating system files, making it a bit harder to install a rootkit or other malware on the system. It also becomes more difficult for system administrators who are offended by the mere presence of some system binary to remove that binary.
Deny ACEs You will find that many objects in the file system have Deny ACEs for Everyone, which has caused quite a bit of consternation for many administrators. If you turn on the "Show hidden files option," you’ll see the familiar Documents and Settings directory. But if you click on it, you will get an Access Denied error. To understand what is going on with Documents and Settings, look at the directory listing in Figure 5.
Figure 5 Documents and Settings is a junction point, not a directory
Figure 5 Documents and Settings is a junction point, not a directory
Documents and Settings is, in fact, not a directory at all—it is a junction point! Recall that junction points are similar to symbolic links that simply redirect the access to somewhere else. In this case, the junction goes to a directory called C:\Users. Microsoft has actually modified the file system namespace significantly in Windows Vista, and the user data is now moved to C:\Users. Other elements beneath the old "C:\Documents and Settings\<Username>" namespace have also moved. For example, "C:\Documents and Settings\<Username>\Application Data" has moved to C:\Users\<username>\appdata\roaming. You can see the changes very clearly if you drop to a command line and use the dir /a command as I did in Figure 5. The reason the namespace has changed so drastically is to make it more intuitive to users and to get a cleaner separation between documents and data. Rather than storing all data files underneath the My Documents folder, developers can now create their own folders under the user’s profile, and the user will see them there. Application data for all users now goes into a hidden folder called %systemroot%\ProgramData instead of under Documents and Settings\All Users\Application Data.
Microsoft did not remove the "C:\Documents and Settings" namespace because older applications may be hardcoded to use that name rather than the preferred environment variables, such as %USERPROFILE%. Those applications would break if "C:\Documents and Settings" were to disappear. Instead, they are now represented as junction points or symlinks, for backward compatibility. Applications that hardcode those paths may still break, depending on how they access the data in them, but those applications are already broken on Windows versions in languages other than English. This is really key. When an update to Windows, such as Windows XP SP2 or Windows Vista, breaks third-party programs, it is almost always because the developers of those programs made invalid assumptions or used Windows in a way they were not supposed to.
If you try to open a file, for example, by typing "C:\Documents and Settings\<Username>\My Documents\foo.txt", it would work, assuming you have a file in that place called foo.txt. However, if you try to browse to "C:\Documents and Settings\<Username>\My Documents", you get the "Access Denied" error message. To understand what is happening, look at the ACL in Figure 6.
Figure 6 There is a deny ACE on Documents and Settings
Figure 6 There is a deny ACE on Documents and Settings
Look at the first ACE in the list. It is a Deny ACE for Everyone to list the folder contents. Programs can traverse the junction points and open documents with absolute paths because Everyone has the Bypass Traverse Checking privilege (also known as SeChangeNotifyPrivilege). Attempts by a user or process to enumerate the directories they represent will fail because of the deny ACE. That is why you can’t actually see what is inside C:\Documents and Settings, nor can you delete the "directory." The main point of putting that Deny ACE there is to prevent users from deleting the junction and breaking older applications. It also serves to remind developers not to code applications to use the old namespace and instead to start using environment variables or registry strings to insulate application from any future changes and language differences.
Note that all these junction points are hidden by default, so the vast majority of users will never see them. To prevent those who do from deleting them, Microsoft put a Deny ACE in for "List Folder."
Bypass Traverse Checking The reason users can access files they have rights to inside folders (or junction points) they don’t have rights to is that everyone has the Bypass Traverse Checking privilege. Bypass Traverse Checking, or SeChangeNotifyPrivilege, is actually the most basic privilege in Windows and is granted to a process that has all other privileges removed unless the process specifically requests to have that privilege removed too. This is what happens when you launch a process using the runas /trustlevel:0x10000 < line in Windows Vista. The program specified in <command> will run with a restricted token and all privileges except SeChangeNotifyPrivilege are stripped from the process token.
As a point of interest, trustlevel 0x20000 gives you a token with the normal set of SIDs but stripped privileges. 0x40000 gives you a completely normal token.

Default Permissions
The default permissions on the file system in Windows Vista have changed a little from Windows XP. If you look at the ACL on %systemdrive% (normally the C: drive—the boot volume), on Windows XP or Windows Server® 2003, you see this (or something very similar on early versions of Windows XP):
D:AR
(A;OICI;FA;;;BA)
(A;OICIIO;FA;;;CO)
(A;;0x1200a9;;;WD)
(A;OICI;FA;;;SY)
(A;OICI;0x1200a9;;;BU)
(A;CI;0x100004;;;BU)
(A;CIIO;0x100002;;;BU)
Here is the same ACL on the same directory on Windows Vista:
D:PAI
(A;;FA;;;BA)
(A;OICIIO;GA;;;BA)
(A;;FA;;;SY)
(A;OICIIO;GA;;;SY)
(A;OICI;0x1200a9;;;BU)
(A;OICIIO;SDGXGWGR;;;AU)
(A;;LC;;;AU)
There are a number of differences worth noticing. First, there are now two ACEs for BA (BUILTIN\Administrators) instead of just one. However, the net effect is the same. In Windows Vista, one ACE is not inherited and grants full access to the root, and one ACE is an IO (Inherit-Only) ACE, inherited by containers and objects, and grants GA (Generic All, or full control). The same holds true in the replacement of the one ACE for SY (LocalSystem) with two in Windows Vista. In Windows XP, the single ACE granted full access and was inherited by objects and containers. Again, there is no net change here. The main reason why the ACL was changed was to clarify and break out the privileges so that the ACL is easier to manage, and even potentially to restore.
More interestingly, the ACE for CO (Creator/Owner) is gone. That means that if a user creates an object in the root of the file system, there are no special permissions accrued to the creator any longer.
You can also see that the ACE for WD (Everyone) has been removed. Many people who were interested in security, although they may not have completely understood the implications of their actions, were unduly concerned about that ACE. Microsoft tried in vain for years to explain that Everyone was functionally identical to built-in Users, but it appears they finally gave up and removed that ACE altogether. Since there is an identical ACE for BU (BUILTIN\Users) that is also inherited by both containers and objects, the net effect is that nothing has changed.
In addition, two of the ACEs for BU (built-in Users) have been replaced with ACEs for AU (Authenticated Users). The reason is that the Guest account is a member of built-in Users (by virtue of the fact that INTERACTIVE is a member of built-in Users), but Guest is not a member of Authenticated Users. To allow the Guest account to read and execute files, the 0x1200a9 (effectively Read and Execute) ACE remains granted to BU. However, the ACEs that grant permissions to create files and folders are granted to Authenticated Users instead. This is a departure from Windows XP. In Windows XP, a Guest could create files in the root. In Windows Vista, a Guest can’t create such files. Keep in mind, though, that this is all moot unless the Guest account is enabled and guests are somehow able to reach the root of the boot volume. By default, the Guest account is disabled.
Leaving the best for last, there are a couple of very interesting and seemingly troublesome ACEs in the two lists above. In Windows XP, you have an ACE inherited by containers, specifying 0x100004 for built-in Users. That ACE grants Users the right to create subfolders, and sub-subfolders, and so on, since it is inherited by containers. There’s also an inherit-only ACE, inherited by sub-folders for 0x100002. That ACE grants users the right to create files and subfolders in folders they create under the root. In other words, these two ACEs allow users, including Guests, to create files and folders under the root, as I mentioned before.
In Windows Vista, the corresponding ACEs are an inherit-only ACE, inherited by both containers and files, granting GR (Generic Read), GX (Generic Execute), and GW (Generic Write) along with SD (Read Security Descriptor), and an ACE that applies only to the root itself that grants LC privilege. LC is actually a short-cut term that belongs on ACEs in Active Directory®. In Active Directory it means that a user can list child objects. However, the hexadecimal value of LC is 0x4. For a directory, 0x4 means FILE_ ADD_SUBDIRECTORY, which becomes functionally equivalent to 0x100004, since we already have 0x100000 (the ability to use the object for synchronization) from the 0x1200a9 ACE. In other words, it provides exactly the same effect as in Windows XP—users can create subdirectories under the root.
Where are the hex values from? And, what are hex values in the first place? As you have noticed by now, access control is full of hexadecimal (base16) numbers, like 0x1200a9. These are actually bitmask representations of bits in an access mask that are set to "on," meaning that they are used in the particular ACE. When you use a tool, such as icacls, sc, or secedit to list an ACL, the bitmasks are represented by much friendlier text strings if there is a 1:1 match.
Therefore, to determine what LC means all you have to do is go to the MSDN® Web site, find the string LC and look in the Access right value column to find ADS_RIGHT_ACTRL_DS_LIST. If you then open up the Iads.h header file and look for that string, you will find that it corresponds to 0x4. For non-Active Directory strings (those not prefaced with "ADS_RIGHT"), you will generally find the hex value in AccCtrl.h instead. Once you have the hex value, it is an easy job to look it up in the access mask in WinNt.h or AccCtrl.h to see what it really means.
If you need some help with this, you may want to get a copy of the book Protect Your Windows Network (by Jesper Johansson and Steve Riley, Addison-Wesley, 2005). Chapter 17 goes into depth on how to analyze Security Description Definition Language (SDDL) strings and ACEs.
The permissions granted to those sub-directories are governed solely by the (A;OICIIO;SDGXGWGR;;;AU) ACE in Windows Vista, which is the biggest difference between Windows Vista and Windows XP. Rather than granting full control to the creator of subdirectories, as in Windows XP, Windows Vista grants modify privileges to authenticated users.
The net result of this new ACL is that the creator of an object no longer has any special rights, and that things are a little clearer. Perhaps the biggest change is that Authenticated Users have Modify privileges even on subfolders that are created by administrators, which is very different from Windows XP. In Windows XP, Users and Authenticated Users have no rights to objects created by administrators under the root. On the whole, though, while these ACEs may look troublesome, the net effect is not all that different from Windows XP.
To summarize, in Windows Vista everyone, including the Guest user, can read and execute files in the root. Only authenticated users can create new files and folders, and when users do, they get modify permissions on those files and folders. In other words, the permissions are marginally tighter on Windows Vista than on Windows XP, although it is worth noting that the Guest account is disabled by default.

Changes to Tokens
When a user who is a member of the Administrators group in Windows XP logs on, his token contains the Administrators group SID, and he can do anything that the Administrators group can do. In Windows Vista, on the other hand, due to User Account Control this is no longer the case. The Administrators SID is still present in the token, but is set to Deny only, as illustrated in the screenshot from Process Explorer in Figure 7.
Figure 7 Under UAC, the Administrators SID is used only for denying access unless you elevate
Figure 7 Under UAC, the Administrators SID is used only for denying access unless you elevate
When performing access control, such an entry in the token is used only to deny access—in other words, to match DENY ACEs. Any allow ACEs for that SID are ignored. That means that you are not truly an administrator all the time, even if you log onto the system as one.

Integrity Levels
Windows now supports the labeling of processes and objects with integrity levels. These integrity levels are actually represented as ACEs as well, but not in the DACL. Instead, they are a part of the system access control list (SACL), with a few special flags. For example, the flag NW is used to denote blocking of a process at a lower integrity level from writing to an object at a higher integrity level (SDDL_NO_WRITE_UP). Mark Russinovich covers this at length in his article "Inside Windows Vista User Account Control" in this issue of TechNet Magazine.

Wrap Up
While there is no single, earth-shattering, modification to access control in Windows Vista, as there was in Windows 2000, there are a lot of little changes. Individually they may not seem like much, but taken together they actually mean you need to rethink a lot of what you do when you manage your system. Furthermore, these changes support a number of other initiatives, notably UAC and service hardening. Some administrators may get very frustrated when they first start using Windows Vista. I have already seen comments about "tyrannical operating systems" that restrict the ability to delete parts of the operating system that, for one reason or another, seem offensive. However, there are solid reasons for all the changes and, most likely, if you spend some time analyzing what was done, you’ll understand why.

Jesper Johansson is a security architect for a large e-commerce company, responsible for application security strategy across the range of properties and services. He has worked in security for 20 years and is the author of many articles and two books on security. When he is not working on information security, he teaches scuba diving.


 Security: Managing Hardware Restrictions via Group Policy
Security Jeremy Moskowitz

Managing Hardware Restrictions via Group Policy
At a Glance:
  • Restricting hardware installations
  • Restricting specific devices
  • Restricting classes of devices

You know it’s true: those USB thumb-disk keys and removable media doo-dads make your personal life easier, but your professional life harder. You want a way to control which
hardware devices can be installed and which can’t. Fortunately, with Group Policy in Windows Vista™ and the next version of Windows Server®, code-named "Longhorn," you have the option to allow USB mice but disallow USB disk-on-keys, permit CD-ROM readers, but not DVD-writers, or allow Bluetooth but not PCMCIA.
Two sections in Group Policy can help you secure your hardware: Computer Configuration | Administrative Templates | System | Removable Storage Access (see Figure 1), and Computer Configuration | Administrative Templates | System | Device Installation | Device Installation Restriction (see Figure 2).
Figure 1 Predefined hardware restrictions in Group Policy
Figure 1 Predefined hardware restrictions in Group Policy
Figure 2 Customize the kinds of hardware you want to restrict
Figure 2 Customize the kinds of hardware you want to restrict
The first set (Removable Storage Access) is fairly self-explanatory: if you enable a policy setting for that kind of removable storage (CD/DVD, floppy disk, and so on), then you can restrict reading and/or writing to that whole device type, if desired. But it doesn’t quite have the superpowers Device Installation Restrictions has.
In Removable Storage Access, there are policy setting groups named Custom Classes: Deny read access and Custom Classes: Deny write access. This sounds good, but the Removable Storage Access policy doesn’t actually prevent the drivers from being installed—the driver for the class is already installed when the hardware is detected. What the policy does is prevent the device from being read or written to. In the next section, when I explore the Device Installation Restrictions policy settings, I’ll lock down the use of the whole driver itself.

Getting a Handle on Classes and IDs
First things first: you need to know what you want to restrict. You can think big or you can think small. That is, you can restrict a specific "class" of devices or get super-specific and restrict a single hardware type. Or you can do the converse and allow only specific device classes, like USB mice. Here’s the trick, though: to really be effective you’re going to need to track down the hardware you want to restrict.
So, if you want to say "No joystick drivers can be installed" and "Only USB mice can be installed," you need to get hold of a joystick and a USB mouse. The alternative is to use the Internet to track down either the Hardware ID, Compatible ID, or Device Class. However, it’s much easier if you have one of the actual devices in front of you. That way, you can introduce it to your machine and see for yourself what the Hardware ID, Compatible ID, or Device Class is. Once you know that, you’ll know exactly how to squash it (or leave it available).
In the following example, I’ll squash a specific sound card family: a Creative AutoPCI ES1371/ES1373. If you want to squash something else (like specific USB devices, USB ports, and so on), just follow along and substitute the device you want.
Fire up Device Manager on a machine that already has the hardware items installed. When you find the device, right-click it and select Properties, then the Details tab. By default you’ll see a "Device description." While interesting, it’s not that useful. Select the Property dropdown and choose "Hardware Ids" as in Figure 3.
Figure 3 The Details tab of the device
Figure 3 The Details tab of the device
The Hardware Ids page shows you from top to bottom the most-specific to least-specific device ID. If you look closely at the topmost item in the Hardware Ids value list, you’ll see this sound card is specifically a Rev 2 of the ES1371 sound board. That’s pretty darned specific. As you go down the list, the description becomes less specific to encompass the whole family.
Moreover, you can change the Property to Compatible Ids. These also describe the hardware and are considered less specific than what you find in Hardware Ids. You might choose to use the information in Compatible Ids to try to corral more hardware that’s similar into your don’t-use list—because it’s less specific and might actually net more results. Of course, the tradeoff is that you might restrict something you didn’t want to restrict.
And, finally, the least-specific category can be found by selecting Device Class from the Property dropdown. In my case, the sound card shows up as simply Media. But a number of items can be considered Media, so again, the less specific you go the more cautious you should be.
Once you’ve decided which value to use, right-click it, select Copy, and paste it into Notepad for safekeeping. Copying it directly as it’s presented is important because in the next steps, the value must be entered exactly. All uppercase and lowercase characters in the value must be transferred precisely.
If you want to be a command-line commando instead of using Device Manager to capture the Hardware Ids or Device Classes, check out the Devcon command-line utility at support.microsoft.com/kb/311272. And note that Microsoft has a number of identifiers for common classes that may be helpful if you don’t have physical access to the device; see the information at go.microsoft.com/fwlink/?LinkId=52665.

Hardware Access Control via Group Policy
While we’ll explore all the policy settings located in Computer Configuration | Administrative Templates | System | Device Installation | Device Installation Restriction (shown in Figure 2), there is really only one we’ll need to complete this initial example.
First create a Group Policy Object (GPO) and link it to an OU (or domain, and so on) that contains the machines running Windows Vista that you want to control. Now edit the GPO and drill down into Computer Configuration |Administrative Templates | System | Device Installation | Device Installation Restriction | Prevent installation of devices that match any of these device IDs. Select Enabled in the policy setting, click Show (also in the policy setting), and select Add in the "Show Contents" dialog. Then in the "Add Item" dialog box, paste in the device information you saved before, as shown in Figure 4.
Figure 4 Paste the device ID to capture the description exactly
Figure 4 Paste the device ID to capture the description exactly
Now here’s the catch. If a machine already has the device installed, it doesn’t magically uninstall and restrict access to it. So, if you’re going to restrict hardware, you’ll want to do this early in your Windows Vista deployment. However, it should be noted that Windows Vista will recheck whenever a device is then removed and reinstalled. Items like USB thumb drives (which get removed and reinserted later) thus are excellent candidates for this process. Since Windows Vista only rechecks when the device is reintroduced, the device is restricted at that time (even if the device driver was initially loaded on the machine). The more difficult problem concerns devices that ship with a machine and don’t get removed and reintroduced. And for those devices, there’s no immediately obvious solution.
When you turn on a machine that has never seen the hardware device before, Windows will try to install the driver, providing status information as it progresses. If you’ve set up a policy restricting such devices, you’ll see a result as in Figure 5.
Figure 5 A device installation being prevented
Figure 5 A device installation being prevented

More Hardware Restrictions
In the example above, we squashed just one device. If you wanted to, you could go the opposite route, restricting all hardware by default and then allowing some. Again, you can see a list of these policy settings in Figure 2, which shows the Computer Configuration | Administrative Templates | Device Installation | Device Installation Restrictions branch of Group Policy. You can choose from several available settings.
First, there’s "Allow administrators to override Device Installation Restrictions." By default, local administrators on Windows Vista must honor the restrictions that are put in place. If you enable this setting, local administrators can override the restriction and install whatever hardware they want.
Next is "Allow installation of devices using drivers that match these setup classes." By entering device descriptions in this policy setting, you’re expressly allowing those hardware devices to be installed on the system. Note that this policy setting honors only setup classes, not device IDs (like those used in the example).
To achieve the opposite effect, you can set "Prevent installation of devices using drivers that match these device setup classes."
The two settings "Display a custom message when installation is prevented by policy (balloon text) and (balloon title)" help you customize the message, as in Figure 5.
As mentioned earlier, the least-specific way to describe hardware is based on hardware class. It should be noted that the policy setting "Allow installation of devices that match any of these device IDs" does not honor Class ID descriptions. To use Class ID descriptions, use either "Allow installation of devices using drivers that match these device setup classes" or "Prevent installation of devices using drivers that match these device setup classes." This latter policy is best used with the setting "Prevent installation of devices not described by other policy settings." By preventing everything (by default) and then using this setting you can specify precisely which devices you want to allow.
In the example, I used the policy "Prevent installation of devices that match any of these device IDs" to restrict a specific type of hardware based on device IDs. If you wanted to implement restrictions using Device Classes, you would have to leverage other specific policy settings such as "Allow installation of devices using drivers that match these device setup classes" or "Prevent installation of devices using drivers that match these device setup classes."
"Prevent installation of removable devices" is a quick, generic way to restrict any hardware device that describes itself as removable, including USB devices. This setting is rather general, so it’s best not to use it too often. Instead, use the techniques described earlier to get moderately restrictive Device IDs and lock them down specifically.
Finally, "Prevent installation of devices not described by other policy settings" is the catchall policy setting that basically restricts all hardware unless you’ve specifically dictated that something can install. This policy in conjunction with the various "Allow" policies (such as "Allow installation of devices that match any of these device IDs") makes a really powerful tool for allowing only the hardware you want in your environment.

Conclusion
Group Policy in Windows Vista has a number of new superpowers, which are extremely useful for allowing only the hardware you want in your environment. Just implement your policy settings early in your deployment, so the hardware you don’t want on your network never finds a way to connect.
Interview with Michael Dennis, Lead Program Manager for Group Policy at Microsoft
I recently had the opportunity to interview Michael Dennis, who has steered the Group Policy ship at Microsoft since its inception. Michael is leaving the Group Policy team to pursue other opportunities within Microsoft. I sat down with Michael to reflect on the last nine years of Group Policy, where it’s been, and where it’s going.

Jeremy Moskowitz Michael, I think lots of people would like to know what you consider your best achievements during your time running the Group Policy team at Microsoft.

Michael Dennis The biggest achievements go back some time, when we focused on developing what was to be known as Group Policy. We already had System Policy in Windows NT® 4.0, so we looked at that and its problems. Since this was during the period of Active Directory® development, we looked at where we needed to better address the manageability of clients and servers.
The idea that Group Policy was to be built in a hierarchy and that this idea had never been done before was a big deal to us. So, we concentrated on core infrastructure, client processes, and integration with Active Directory.
The byproduct of our best achievement was also our worst achievement. That’s because the GUI that we shipped in Windows 2000 was problematic. People needed a PhD in Group Policy to use it effectively because administrators needed to know how the whole thing worked. I wish we could have created the Group Policy Management Console (GPMC) and Resultant Set of Policy (RSoP) and delivered it back then (it was in the specs).

JM What items do you wish could have been included in the Group Policy experience?

MD The good news is that the things I’ve wanted since the Windows 2000 release are here now in Windows Vista—things like RSoP, the GPMC, the increased settings, and so on. I wish we could have done those things a whole lot sooner.
Additionally, I wish that the Group Policy infrastructure could be more easily extended by partners. Our server-side/client-side extension model requires a good deal of work by developers. However, it could be argued that our ADM/ADMX template structure does provide an easily extensible framework. But, it would be even better if that part of the system enabled people to extend more types of settings.
I also wish that the GPMC reporting was more extensible for partners and third-party tool developers. It’s an area in which third-party tool vendors have been pretty vocal.

JM What are some things people don’t know about the Group Policy team?

MD Sometimes it’s not clear to people where the Group Policy team fits into the overall picture. The idea is that we build the infrastructure, the transport, and the server and client-side pieces. But in Windows Vista alone we partnered with about 120 different teams at Microsoft to get the new settings in place for this release.
Readers should note that Group Policy is not to blame for system slowdown issues at boot or logon. It’s the Group Policy payload that’s to blame if things are slow. If you tell Group Policy to do something that’s heavyweight, it’s going to just do it. For instance, if you tell it to install Microsoft Office on a per-machine basis, great. But just know that it will do what you asked for; it will install all of Office before you get a logon prompt. Is that a slowdown? You betcha, but as an admin that deployed it, it’s exactly what you wanted the system to do.

JM What’s your favorite thing to show off using Group Policy?

MD These days, I like to show off some of the new settings that made it into Windows Vista. The removable devices settings (to restrict things like USB sticks, and so forth) are settings people had been clamoring for. There are about 2,400 settings available in Windows Vista, which brings a significant level of control to admins. I like asking customers what they want to control and then showing them how to do it.

JM Why did you change from ADM to ADMX files?

MD Technically, we didn’t need to do that to get to the new central store feature in Windows Vista. The big push for converting to ADMX was to allow us to support multiple languages appropriately.
Previously, in multilanguage environments you would often run into a situation in which the contents of the ADM files inside a GPO would be inadvertently written by another language. Historically, we borrowed the ADM format from Windows NT 4.0, which had borrowed it from Windows 98, which had borrowed it from Windows 95. If XML had been around then, it would have been a good candidate for our file format.
But, now that we have XML, it has become easier to support multiple languages, and it presents future opportunities to make registry and settings enhancements with our now schematized language.

JM What was the biggest internal challenge you had to overcome while working on the GP team?

MD The biggest ongoing problem the team faces is trying to get other components of Windows to policy-enable their features.
Team X might respond &quot;We just built this great new feature. Why would anyone want to turn it off?&quot; And we can understand that. But we worked through a lot of those issues.
There are also technical challenges regarding enabling some things by policy, for instance, the new Windows Firewall with Advanced Security (WFAS). WFAS was tough to do. It’s not easy or straightforward to policy-enable it correctly. The interface that the WFAS team created for Windows Vista is superb, but doing it right has been tough.
In versions of Windows before Windows Vista, the product teams themselves didn’t always think about policy-enabling their components. But, during Windows Vista development, a fair number of teams asked us how to do it. That was huge!
JM What’s next for you?

MD I’m moving to the &quot;Mobile Information Worker&quot; team, which is responsible for Smart Phones, Pocket PCs, and so on. My role will be to extend some of the management technologies in Windows Server System to Windows Mobile® devices.
I will try to take my same vision and passion for manageability and apply it in this new space. Meanwhile, I’m leaving the Group Policy team in an outstanding position to move things forward without me.

JM Anything else you’d like to tell our readers?

MD All through the development of Group Policy, one important step was to get in front of customers and really understand what they’re trying to do. If customers have a well-structured opinion about scenarios they would like to see Group Policy cover and they have a business case for doing something, they need to communicate that back to us.
We have a good feedback mechanism that’s available to everyone at WindowsServerFeedback.com. Look for the Group Policy button.
If your folks can say &quot;here’s my problem, here’s my business case, and I need the system to be able to do this and here’s why&quot; that kind of information is very, very valuable to us. Those who make decisions about Group Policy going forward read every entry that comes through that source.
Again, if you want to have an impact in Group Policy moving forward, tell us about what you need. But please don’t just tell us &quot;We need a policy setting that does X&quot; without telling us why. The &quot;how&quot; is our job to figure out. What the Group Policy team really needs to know is the &quot;why.&quot;
JM Thanks for taking the time to tell us about your experiences on the Group Policy team at Microsoft. All the best!
MD Thank you, Jeremy.

Jeremy Moskowitz, MCSE and MVP in Group Policy, runs GPanswers.com, a community forum on Group Policy. He runs a series of Group Policy intensive training workshops. His latest book is Group Policy: Management, Troubleshooting and Security (Sybex, 2007). Contact Jeremy at www.GPanswers.com.


 Security: 4 Security Technologies Every IT Organization Must Have
Security Matt Clapham and Todd Thompson

4 Security Technologies Every IT Organization Must Have
At a Glance:
  • Risk management dashboard
  • Anti-malware
  • Network anomaly detection

When it comes to IT security, most enterprises really have roughly the same issues to deal with. Microsoft is no exception. We spent two years on the Risk Management and Compliance team in
Microsoft® Managed Solutions (MMS). (See "Microsoft Gives Energizer a Recharge for Its IT Division" for more information about MMS.)
The Risk Management and Compliance team is charged with defining, monitoring, and correcting the risk posture of all MMS environments (for both customer-facing services and infrastructure coordination). Early on, our manager, Arjuna Shunn, recognized that we needed a technology solution that provided the desired controls and monitoring in a centralized, cohesive fashion. The technologies we’ll discuss here are a direct result of our early ideas, coupled with two years of experience using various Microsoft and third-party products in our operations.
First off, we needed security technologies that would cover the three primary control types—preventive, detective, and corrective—as well as provide auditing and reporting. We saw this collection of tools breaking down into four categories: risk management dashboard, anti-malware, network anomaly detection, and desired configuration management. We have tried to include at least one representative of each in our risk management operations. And we’ve found that by taking advantage of technologies from each of the four areas, the IT security team can achieve a reasonable balance between cost and effectiveness.
Our two primary risk management operations—security incident response and compliance management—have benefitted greatly from this approach, but we still have a way to go in achieving the coordination we ultimately desire amongst the tools. A cohesive set of technologies can offer so much more in the way of operational efficiency, but sadly the industry doesn’t yet have that integrated system.
Fortunately, all is not lost for IT security teams; it’s simply a matter of time before the four systems start working together and interoperating for a greater effect. Once these systems all work together, they’ll not only allow for active monitoring of system security posture, but they’ll also come in handy during audits or other routine IT operations. In this article, we describe the ideal function of each system, interjecting some examples from our runtime usage.

Risk Management Dashboard
In our opinion, a risk management dashboard (RMD) is absolutely essential. It is the single most important technology to the operation of an IT security team. Confidentiality, integrity, availability, and accountability (CIA2) risks in an enterprise are often monitored by disparate systems and processes with no single interface for data aggregation, correlation, and risk remediation. Additionally, regulatory requirements specify increasingly difficult levels of enterprise data transparency, and there is no streamlined system to readily track policy from creation to enterprise execution. This is evidenced by common enterprise difficulties in data acquisition, correlation, assessment, remediation, and compliance. (While not a complete RMD solution as we outline here, System Center Operations Manager 2007, as shown in Figure 1, does provide a single interface for monitoring multiple resources and gathering related alerts.)
Figure 1 System Center Operations Manager 2007 provides a single interface for viewing alerts and managing resources from across the network
Figure 1 System Center Operations Manager 2007 provides a single interface for viewing alerts and managing resources from across the network
Data acquisition is hampered by an inability to aggregate and normalize data from disparate sources. Data aggregation in and of itself is challenging, as it requires breaking out of the all too common siloed approach to gathering and reporting data. Even where data aggregation is accomplished, normalization continues to pose an even bigger challenge because it is extremely difficult to establish the common framework needed to support the normalization of data. Without this normalization, it’s impossible to compare security and health-related events coming from different systems in a meaningful way.
To perform the needed automation, the risk management dashboard must have access to data feeds from sources other than the security technologies described here. A lot of non-security data can be used for determining overall risk posture. Information like router logs, asset tracking, patch status, currently logged on users, performance reporting, and change management data can all provide relevant information to the incident investigator. Thus, the overall system needs access to all of this data. We’re aware that even the most Microsoft-centric enterprise infrastructures include non-Microsoft technologies, so the RMD needs to accept feeds from non-Microsoft technologies via some common interface.
If data can be acquired and normalized, the next step is to correlate it. The goal is to correlate a sequence of events—such as a network anomaly event, an antivirus reporting event, and a desired configuration variance event—into an actionable piece of risk-related data. This requires intensive manual work in order to build the correlation logic that will result in meaningful risk-based alerting. Based on the technologies that are currently available, this correlation logic is, at best, difficult to achieve.
Assessing the data also requires intensive manual work. In the case where correlation occurs, an analyst must still look at the correlated data to determine its efficacy. The efficacy of the correlated data is only as strong as the rules upon which it is based. This leads to further human analysis of correlated data to assess the risk to the IT environment. A clear and codified risk management framework could help here to reduce the amount of manual intervention required to reach a triage level. Without this framework, developing a practical set of correlation rules in a given implementation is difficult.
Assuming a system has reached the point of assessing risk, the next step is automated remediation. Today, this is only really available in the enterprise, and even then it is only done for a limited set of technologies, such as patch management or antivirus. Automated remediation that is spearheaded by the RMD system will provide the IT admin with a tremendous ability to maintain an acceptable level of IT risk. When multiple risks are identified simultaneously, the correlation logic should be able to help prioritize the incident response based on asset classification data.
Finally, providing evidence of compliance with various regulatory requirements is a giant challenge for IT departments and, as we’ve mentioned, this system should support such functionality. A centralized risk management system tied into policy could be a great asset in producing reports and evidence of compliance. But the policy needs to be more than just the wheres and whys. To facilitate automated remediation, the policy needs to be translated into a set of standards that the dashboard can monitor, enforce, and provide feedback on.
So we can sum up the ideal risk management dashboard as a way to provide a unified interface for enterprise health assessment, regulatory and policy compliance, and risk management processes. This is achieved by combining information from disparate security and health-related products and sources into one cohesive risk-related display. A good RMD solution needs to do the following:
  • Aggregate, normalize, and correlate data from disparate sources
  • Provide automated information gathering and risk assessment
  • Map regulatory requirements to policies and support auditing and reporting
  • Provide a unified framework that can be modified to fit an enterprise’s needs
The dashboard should allow data to be organized and displayed with meaning, showing, for example, top incidents by type or source system, pending incidents, resolved incidents, and so on. It should also let you drill into each report line item for more detail. When looking at an event, the user should have easy access to any and all related data. This will improve decisions and allow them to be made faster.
We should point out that the RMD is also useful to administrators not on the security team. Since the dashboard encompasses a holistic view of the environment, the RMD can act as a central point for all staff to view current status. The dashboard may, for example, alert the messaging team about a denial of service attack at the SMTP gateway. While this is a security incident to the risk management team, the messaging team will see it as an availability incident. Though the messaging team may not be responsible for fielding and resolving such an incident, they will at least want to be aware of incidents like this that affect the assets the team manages.

Anti-Malware Technologies
A comprehensive anti-malware system is important for protecting your infrastructure against unforeseen threats hiding in code and user actions. Currently, there are generally two separate types of tools to protect against malware: antivirus and anti-spyware. (Windows® Defender, for example, shown in Figure 2, falls into the latter category.) Both effectively prevent, detect, and correct different types of infection. However, it’s only a matter of time before these two types of protection are unified into a single solution and there will be just one anti-malware stack on a system.
Figure 2 Windows Defender helps protect the client against spyware
Figure 2 Windows Defender helps protect the client against spyware
A thorough anti-malware solution needs to monitor in real-time and periodically scan. It should centrally report known malware (including viruses, spyware, and rootkits) and unknown malware based on typical risky behaviors. Robust anti-malware technology watches all the classic entry points (including the file system, registry, shell, browser, e-mail, and connected applications) via tight integration with the OS and apps.
Additionally, an anti-malware solution needs to cover more than just host security. It needs to watch common messaging and collaboration services where infected files often pass through, such as SharePoint® and instant messaging. It also needs to provide automated prevention by stopping operations (known and suspected) as well as carefully scanning user data to remove things like macro viruses that are hiding in user documents and have not yet infected the system.
It goes without saying that anti-malware is useless without updates. The system must keep its signature and removal systems updated to stay ahead of the latest threats. If an emerging threat appears, the vendor should get additional protections in place before the next zero-day threat breaks. An easy-to-manage anti-malware solution is also centrally configurable and updatable.
Of course, this protection can’t come at the cost of performance. If performance suffers, productivity will suffer. Users may even try to disable the anti-malware solution, leading to no protection at all.
Finally, don’t overlook the importance of auxiliary technologies to assist the anti-malware system. Firewalls, limiting user privilege, and other strategies also improve protection against malicious code and user actions.

Network Anomaly Detection
While anti-malware keeps an eye on systems, network anomaly detection (NAD) monitors the common pathways, watching for well-known indicators of suspicious behavior and reporting this information to the RMD for remediation. (A firewall, for example, as shown in Figure 3, would be included in this category.) Suspicious behaviors could be well-known attack traffic (such as a worm or denial of service) or data that fits a certain pattern (such as U.S. Social Security numbers) being sent via e-mail.
Figure 3 A firewall is an important part of a network anomaly detection solution
Figure 3 A firewall is an important part of a network anomaly detection solution
Despite the best efforts in IT management, any large enterprise network will inevitably encounter an occasional malware incident. NAD can provide an early warning system that can help accelerate remediation. Furthermore, the NAD data-monitoring capabilities, and the ability to identify and stop sensitive information from being leaked, are handy tools in protecting information in an environment concerned about data leaks and regulatory compliance.
As with anti-malware technologies, NAD must constantly adapt to the latest set of threats and sensitive data types or its value is greatly diminished. Additionally, a good NAD system should understand enough about the actual anomalies to minimize the number of false positives being reported. Otherwise, administrators may start to ignore the reports coming from NAD, assuming that each is just another false alarm.
After a bit of tuning or training, the NAD system should be aware of and monitor for typical traffic usage patterns. This is important since new types of malware and other attacks may reveal themselves with a change in usage patterns. Networking equipment plays a significant role in the overall NAD system, as the solution must process data from routers, switches, and firewalls. The NAD alerts can then be processed by the correlation engine in the RMD.
One interesting possibility here is for the network anomaly detectors to be built into the host anti-malware software or firewall, casting a net of protection where all the included computers help watch for and potentially stop attacks before they spread.

Desired Configuration Management
One of the biggest challenges IT departments face in large enterprises is keeping systems configured appropriately. There are many motivations for wanting to maintain system configurations—ease of management, simplifying scalability, ensuring compliance, locking down against various forms of intrusion, and promoting productivity, to name a few. Many of these reasons factor into security.
Desired configuration management is a largely untapped area in most enterprises due to its complexity and startup costs. But studies show that in the long-term, maintaining systems leads to cost savings and improved reliability. A desired configuration monitoring (DCM) solution can help.
A good DCM system should automatically scan the network to assure that new systems are deployed as desired and also verify that established systems remain in compliance. Whether it’s making sure the latest patch is deployed or minimizing the number of users who have domain privilege, a complete DCM solution must configure systems, analyze them, and report how close each configuration is to the ideal. The corrections can be simple (such as patching new systems on the network as they are deployed) or forceful (such as enforcing e-mail client settings for users). The key is to tie them back to the organization’s policies and regulatory stance. (DCM can also assist in malware infection identification and removal, since simple types will be readily spotted in scan results.)
DCM is one of the primary data reporters to the RMD’s correlation engine, and DCM provides important detail about how variant from normal the host in question is. The timeliness of its data can make the difference between a one- or five-alarm security incident so an asset needs to be scanned in a frequency proportional to its value; for instance, a low-sensitivity asset may only be scanned monthly, while a moderate-sensitivity asset is scanned weekly, and a high-sensitivity asset is checked at least once daily.
A DCM setup is also a fundamental part of a good network access protection (NAP) mechanism. This is so the system can verify that all connected systems are configured appropriately and block new or unknown systems until validated. In addition, DCM should look for vulnerabilities of configuration (such as weak access control lists on a share) so admins can take appropriate action.
Don’t assume that DCM only applies to hosts like clients or servers. Networking devices and the core directory itself are candidates for DCM inclusion. If a reasonably well-understood network design is available, it should be trivial for the ideal DCM system to enforce standards for associated devices. Imagine the possibilities! Instead of tweaking router configurations manually, the DCM can handle the implementation. Or say a set of standard Group Policy settings are associated with a particular set of servers or clients. The DCM should monitor them and send an alert if the domain settings change.
The data collected by the DCM should be robust enough to be used in an IT audit. A good DCM must have hooks into change management and regulatory compliance controls so that audit concerns can be addressed in a timely, almost continuous fashion. For example, one of our routine control checks is to verify that the local administrator membership on MMS servers hasn’t changed. Enforcement of this rule is what DCM is made for!
Even if your IT department isn’t ready for a self-correcting DCM system, a variation known as desired configuration monitoring can still be deployed and offers great results. This, too, provides reports and alerts about configuration problems, but the same economies of scale aren’t necessarily achieved since the remediation is largely manual. Importantly, however, the notification and data that the RMD needs will be available for correlation.
One word of caution, though. DCM, in either form that I’ve just described, has to be scoped to just the minimal important configuration items coupled with the standard asset collection data. Otherwise, it can impinge on the flexibility the IT team may need. If the DCM configuration guides become dated, DCM will quickly be considered an operational tax rather than a useful tool. So keeping abreast of the latest thinking in how to configure assets optimally is important. Further, we suggest that the DCM system include regular updates to its configuration cookbooks according to the best practices for the asset or application in question.

Conclusion
Whether you build it in-house or buy it from a reputable vendor, the dashboard is essential, acting as your team’s primary tool for incident response. Anti-malware is also essential, helping protect against the threats that multiply daily. Network anomaly detection is on the verge of changing from just malware signatures and host intrusion detection to include data leakage discovery—and that last function can help prevent the next well-publicized network breach. Desired configuration management, while still new, will soon be a mainstay for monitoring and maintaining configurations. Regardless of who provides these tools, you must have at least one for each of these four categories!
From what we’ve seen so far, no single vendor (Microsoft included) offers a single holistic solution that addresses each of the four spaces. It is up to you find the selection of products that will suit your specific needs. We just want this article to provide insight as to what you need to consider, what you should be looking to achieve, and what the ideal solution will do.

Matt Clapham is a Security Engineer in the Infrastructure and Security group of the Microsoft IT division. Prior to that he worked for two years on the Microsoft Managed Solutions Risk Management and Compliance team.
Todd Thompson is a Security Engineer in the Infrastructure and Security group of the Microsoft IT division. Prior to that he worked for two years on the Microsoft Managed Solutions Risk Management and Compliance team.


 Security: A Powerful New Tool for Certificate Management
Security Kevin Dallmann

A Powerful New Tool for Certificate Management
At a Glance:
  • ILM-CM architecture
  • Administration and templates
  • Creating a workflow

It’s a calm day at work when suddenly you get a call from your help desk support team—a certificate has expired on one of your production systems. Now the system is down, and your company is losing productivity (and money) until you renew the certificate.
If you are responsible for managing a Public Key Infrastructure (PKI) environment, I’m sure you’ve been surprised by a certificate that expired unexpectedly. The calm day—well, that’s a dream now.
When Microsoft added PKI services in Windows® 2000 and Windows Server® 2003, it was a great and inexpensive way for companies to implement their own internal PKI environment. Unfortunately, the Microsoft® PKI services lacked the ability to manage the lifecycle of the certificates that were generated. However, Microsoft recently acquired a certificate management product and then released Identity Lifecycle Manager (ILM), which combined certificate management with the identity provisioning and control features of Microsoft® Identity Integration Server (MIIS). This article will discuss what ILM can do to help manage certificates and smart cards for your organization.

ILM-CM Architecture
The core of the ILM Certificate Management (ILM-CM) architecture is the ILM-CM server and its related components (see Figure 1). The ILM-CM server can be installed on a single server set up to interface with one or multiple Certification Authorities (CAs). ILM-CM requires SQL Server™, which stores certificate information, policies, and other related data used to manage your certificate environment. To manage users and security permissions, ILM-CM server also requires Active Directory®. See Figure 2 for the required components and versions.
Figure 2 Supporting ILM-CM infrastructure (Close Figure 2)

Components | Versions
Active Directory | Windows Server 2003
Database Server | SQL Server 2000 SP3 or higher or SQL Server 2005
Certification Authority | Windows Server 2003 Enterprise Edition or Data Center Edition
SMTP | SMTP Server
Figure 1 ILM-CM architecture
Figure 1 ILM-CM architecture
Once the ILM-CM environment is completely installed, all certificate requests will communicate with the ILM-CM server. The ILM-CM server is responsible for storing all certificate-related information into the SQL Server database, which can be used for further certificate reporting, alerting, and maintaining a workflow environment.
The ILM-CM software architecture essentially consists of three high-level parts: the ILM-CM server, CA plug-ins, and the client-side components. The server software can be installed and run on a CA or on a server that is used primarily for ILM-CM. The ILM-CM server then communicates with the CAs, the SQL Server database, and Active Directory. The server also provides a Web portal that certificate managers use to configure certificate policies and workflows, as well as for certificate subscribers to request and renew software certificates.
In order for the CA to communicate with the ILM-CM server, ILM-CM policy and exit modules must be installed and configured on every CA you want to manage. These two modules are used to record certificate information into the database. When a certificate is issued by a CA, the exit module is responsible for sending that information to the ILM-CM server, which in turn records the certificate information into the database.
If you plan to manage smart cards in your environment, you need to install the ILM-CM smart card client software. This software is required on any client computer that must interact with the ILM-CM server.

ILM-CM Installation
Installing the ILM-CM server is actually quite straightforward—a wizard walks you through the process. But before you actually run the wizard, you will need to take care of a few preinstall functions.
The first thing ILM-CM requires is Active Directory and an ILM-CM schema extension. The schema extension adds some additional Microsoft .NET Framework security attributes that ILM-CM needs in order to implement the profile templates.
You also need to install the .NET Framework 2.0, and the components mentioned earlier—SQL Server, CAs, and SMTP server—must also be in place. If ILM-CM is going to be installed on a separate server from the CA, then you must install the ILM-CM modules on the CAs by running the ILM-CM setup wizard on the CAs. Once the installation is complete, you should be able to connect the ILM-CM portal by pointing your browser to http://hostname/CLM.
To enable certificate expiration/renewal notification, you need to configure the ILM-CM service on the ILM-CM server. Start by creating an appropriate account in Active Directory. Go into the ILM-CM services and add that account as the logon account. Then add that user to the local administrators and the IIS_WPG group within the ILM-CM server, as well as to the "Act as part of Operating System, Generate security Audits, and Replace a process level token" using group policies. After the ILM-CM service is set up, the ILM-CM server can scan the SQL Server database for expired certificates and provide e-mail notification to the certificate owners or managers.

ILM-CM Administration
ILM-CM is managed through a Web interface, which is divided into functional areas related to user, certificate, and smart card management tasks. When connected to the ILM-CM portal with the appropriate administrative privileges, it displays a number of administrative tasks that let you manage the ILM-CM environment (see Figure 3). The Common Tasks section provides administration options, including enrolling users for a new set of certificates or a smart card. You can also manage and approve requests.
Figure 3 ILM-CM management portal tasks
Figure 3 ILM-CM management portal tasks
If you need to locate users or certificates, you use the Manage Users and Certificates tasks area. These tasks give you the capability to find, recover, revoke, or renew certificates. You can also find a revocation list.
If your organization uses smart cards, the Manage User Smart Cards portion is handy. If, for example, a user has locked his card, the certificate manager can unlock the card here. You can also search and view smart cards in the local card reader.
The Requests area of the interface allows certificate managers to review and approve user certificate requests. For example, you could view all certificates contained in a pending state request. The Administration area lets you create and manage profile templates. Finally, the Reports area is, as you’d expect, used to develop and create reports related to users and certificates.
When authenticating to the ILM-CM portal, if your account doesn’t have administrative privileges, you are presented with a subscriber page that offers self-service management functions for certificate users (see Figure 4). From this portal, users can view and manage their certificates and smart cards based on their particular policy configuration. Examples of common tasks include requesting certificates or a smart card, reviewing existing certificates, and changing smart card PINs.
Figure 4 Subscriber portal page for user self-administration
Figure 4 Subscriber portal page for user self-administration
Providing a high-quality, delegated workflow process for issuing, renewing, replacing, revoking, and replacing certificates or smart cards can be a challenge in any organization. With ILM-CM you now have the capability to delegate these tasks to provide a higher assurance of security. Let’s say you have a user who has forgotten his smart card PIN. Using the delegate workflow model, the user could call the help desk support line and the support staff would ask him a few verification questions. If the questions were answered correctly, the support staff could unblock the smart card for the user. Another example of delegated workflow would be recovering a user’s Encrypted File System (EFS) certificate in case of accidental deletion or the loss of a laptop.

Profile Templates
A profile template is the fundamental component that enables a full workflow management process for ILM-CM. A profile template is considered to be a single administrative object that contains one or more certificate templates. Profile templates are created and configured to manage how the workflow process should operate in your certificate environment. The key aspect of a profile template is that it can contain multiple certificate templates that can be managed as a single item, which means users can be managed by one template that can track the certificate process through its lifecycle.
Profile templates can be configured to store certificates on a computer (software-based) or on a smart card (hardware-based). You can create these templates by duplicating a sample from the ILM-CM administrator portal. Within the profile template, you can define several different management policy components (see Figure 5).
Figure 5 A profile template
Figure 5 A profile template
Many of the policy components are applicable to both software and smart card profiles (see Figure 6). Some of these are worthy of additional comment. During the certificate enrollment process, you can use the enroll policy component to define certain criteria regarding how you’d like the enrollment process to flow. For example, you could set up a data collection, which means the user would need to enter information such as department codes, e-mail address, and manager. You could also create definitions that automatically print out an official document once the user has enrolled a certificate.
Figure 6 Software profile policies (Close Figure 6)

Component | Description
Profile details | Provides the general details of the profile template. This is where you can add one or more certificate templates to the profile template.
Duplicate policy | Defines the workflow entities of an existing certificate.
Enroll policy | Defines the enrollment process workflow.
Online update policy | Similar to the Renew Policy except it can update expiring certificates, certificate content, templates, and smart card applets.
Recover on behalf policy | Recovers a user’s private key or certificates.
Renew policy | Defines the renew workflow when a certificate expires.
Reinstate policy | Defines the process for reinstating a certificate.
Recover policy | Defines the workflow for recovering a user certificate stored on a computer was deleted, rebuilt, or stolen.
Revoke policy | Defines the workflow for revoking all certificates within a profile.
The online update policy can be very useful to your organization. It is similar to the renew policy except it can update certificate content, certificate templates, applets on smart cards, and also update the certificate itself when it is about to expire. To fully use this policy, you must enable the ILM-CM service and the web.config file to allow access to a multi-valued attribute in Active Directory. You will also need to install the online update service on the client computer.
The Recover on behalf policy can be handy if your company uses EFS encryption. Suppose someone accidentally deletes his encryption certificate. You could use this policy component to set up a workflow in which the help desk security team requests the user’s private key. The user could then retrieve his private key by receiving an e-mail with a secret password that was generated by the ILM-CM server. Finally, he’d go to a secret Web link on the ILM-CM server to retrieve the certificate with his associated private keys. The Recover on behalf policy is also particularly useful when an employee leaves the organization, but his data needs to be recovered for archival, regulatory, or other purposes.
To provide a more secure renewal process, the renew policy lets you set up and e-mail the one-time password secret key users need to renew their certificates. If you revoke a certificate and then want to reinstate it and remove it from the Certificate Revocation List (CRL), the reinstate policy can define that workflow process.
Two unique policy components associated only with software certificate policies and not smart cards are the recover policy and the revoke policy. If a user certificate stored on a computer is deleted or the computer itself is rebuilt or stolen, the recover policy could define the process for restoring the certificate or keys if archived on the CA. The revoke policy lets the administrator set a static revocation reason or allow the person performing the revocation request to designate the reason at the time of the revocation.
There are five additional management policies that are specific to smart card profile templates, as shown in Figure 7.
Figure 7 Smart card profile policies (Close Figure 7)

Component | Description
Replace policy | Defines the profile in the event that a user’s smart card is lost or stolen.
Disable policy | Defines the process of disabling certificates on a smart card prior to their expiration.
Retire policy | Defines the process for revoking all certificates on a smart card.
Unblock policy | Defines who can unblock a smart card’s user PIN.
Temporary cards policy | Defines a short-term replace smart card. The user receives new signing certificates but would be able to decrypt their data by getting the existing profile encryption certificates.
You can define several different operations for the retire policy, like erasing user data on the smart card, blocking the user and administrative PINs, and resetting the administrative PIN. The unblock policy is typically used if a user has forgotten his PIN or a new card has been shipped with a PIN assigned by the ILM-CM. The user then requests to have the smart card unblocked.
As with any administrative product, reporting is a very useful feature. The ability to capture a snapshot of your certificate or smart card environment is very important to any organization. ILM-CM comes with several built-in reports that include smart card inventories, request summaries, certificate usage and expiration, and a number of others. As with other reporting systems, if you need additional reports, you can write a custom query since all the data is stored in a SQL Server database.

Developing a Workflow
Now let’s look at how ILM-CM can help define a productive workflow process. Say you have several system administrators who are responsible for managing and maintaining SSL certificates for their systems. The first question to ask is: What are the key aspects of the process?
Depending upon the type of system, the process may require different methods for creating the certificate request file. So the first task is to develop an intranet page that has detailed instructions on how to create the certificate request for all the systems.
Once the administrator creates the request file, he can submit it to the ILM-CM user portal for certificate approval. Using the ILM-CM workflow process, the administrator can define several approvers that need to verify and approve a certificate request. After a certificate is approved, the user can retrieve the certificate from the ILM-CM. Since the ILM-CM places the certificate information into a SQL Server database, administrators are able to retrieve historical information.
One year later, when the certificate approaches its expiration period, the ILM-CM will send an e-mail notification to the requester informing him that the certificate is about to expire and the he must renew. Putting this workflow process in place will help prevent those occasions when certificates expire unexpectedly and ruin your day.

Summary
If your company is using a Microsoft PKI environment, ILM-CM can help manage it. ILM-CM allows organizations to improve security authentication processes and reduce the costs and complexity of digital certificates and smart card management. ILM-CM will also be the foundation to develop certificate and smart card workflow processes that so many companies lack today.
Microsoft has also implemented external API support for ILM-CM. If your organization uses custom applications, you may be able to interface those applications to take advantage of the ILM-CM API support.
For more information about ILM-CM, see microsoft.com/technet/clm. A quick start guide is available as well (go.microsoft.com/fwlink/?LinkId=87336).

Kevin Dallmann is a Senior Systems Engineer consultant for Accenture and is primarily responsible for supporting Active Directory and PKI environments for large enterprise environments. Kevin holds the MCSE and MCT certifications and he also teaches Microsoft courses.


 From the Editor: Security Issues
From The Editor
Security Issues
Joshua Trupin

Have you noticed how security concerns have become a bit more manageable lately? Sure, we’d like to take all the credit for it ourselves here at TechNet Magazine, but there are a few other factors that come into play. The two biggest ones are awareness and robustness.
Awareness is simply being tuned into potential threats and social engineering tricks plus staying on top of regular patches and updates that protect installed software. Robustness is the other side of the coin, the idea that software can be built to be more secure and to minimize its attack surface by turning exposed features off by default.
Oh, and there’s one more factor—reading TechNet Magazine on a regular basis. Can’t forget that! You’re holding our already-almost-famous Security issue, and it contains no fewer than seven articles that will help you become a more fearsome security analyst/practitioner for your company. Mark Russinovich leads off with a look at UAC internals, while Steve Riley dives into the Windows Firewall, and Jesper Johansson explores ACL changes in Windows Vista. We’ve also got Jeremy Moskowitz talking about Group Policy and hardware lockdowns, Michael Murgolo contributing script elevation PowerToys, and much more. This issue that you’re holding now could seriously be the greatest magazine ever published by anyone anywhere.
While you’re maintaining your state of alertness, you should get to know the newest security offering from Microsoft. Microsoft Forefront represents the "robustness;" factor; it’s a line of business security products that provides protection in three areas: client operating systems, application servers, and the network edge. It includes security tools for Exchange Server and SharePoint, as well as incorporating ISA Server and Intelligent Application Gateway for network traffic. Microsoft System Center embodies the &quot;awareness&quot; piece of the puzzle, as it lets you gather knowledge about your systems, streamline operations and management, generate reporting, and enhance service delivery. It includes the next generation of configuration management and operations monitoring technologies, among other tools.
To find out more about Forefront and System Center, visit the Microsoft Infrastructure site at Microsoft.com/infrastructure. And to get the top solutions for your security puzzles, stay aware and robust with TechNet Magazine.
—Joshua Trupin

Thank you to the following Microsoft technical experts: Conrad Bayer, David Cross, Michael Dennis, Shon Eizenhoefer, Jason Garms, Russ Humphries, Jesper Johansson, John Lambert, Eric Perlin, Mark Russinovich, Jon Schwartz, David Solomon, Greg Stemp, John Stephens, Kevin Sullivan, Jim Truher, and Buck Woody.


 Toolbox: New Products for IT Pros
Toolbox
New Products for IT Pros
Greg Steen

Create Data-Driven Gadgets
PowerGadgets
www.powergadgets.com
As the saying goes, "a picture is worth a thousand words." After using PowerGadgets, a data-visualization tool for Windows PowerShell™, I couldn’t agree more. The PowerGadgets utility lets you easily create your own customized visualizations of data, or gadgets as they’re called. While you may be familiar with the gadgets in the Windows Vista™ Sidebar, don’t assume PowerGadgets is limited to Windows Vista. You can use PowerGadgets in Windows® XP, Windows Server® 2003 and even Windows Server, code-named &quot;Longhorn.&quot; The gadgets you create are customized charts, gauges, and maps that can display data derived from Windows PowerShell, an OLE DB data provider, a text file, or a Web service.
You can instantiate a gadget via the Windows PowerShell command prompt or a script, by double-clicking a saved Gadget file, or by using the PowerGadgets Creator tool. PowerGadgets gives you three cmdlets that you can pipe data to: out-chart (which plots series data as one of more than 60 chart types), out-gauge (which displays single data points as either a radial gauge, linear gauge, or digital panel), and out-map (which lets you display data on a geographical map or other vector image).
PowerGadgets helps you turn data into eye-popping charts, gauges, and maps
PowerGadgets helps you turn data into eye-popping charts, gauges, and maps
The PowerGadgets Creator tool provides a GUI approach to defining the appearance, axes, data source, display type, and other attributes. All of this can also be done from your PowerGadgets-enabled Windows PowerShell command prompt. If you are using the Windows Vista Sidebar, adding a new visualization is as easy clicking the plus sign at the top or adding the -sidebar parameter to your command-line instantiation of the gadget.
So what could you really use these tools for? Hundreds of options come to mind. Since the tools can query Web services, you could monitor your HR department’s data, getting automatic notification on your desktop when a new employee is hired. Using the Windows PowerShell scripts, you could access Windows Management Instrumentation (WMI) and get processor utilization averages for all your Web servers in the production environment from a single management host.
If you need to look at historical data, simply import a CSV file and dump it out to a map graphic to see, for example, which remote office is using the most bandwidth. And if the bigwigs upstairs need some reassurance that everything is status quo on the Ops team, you can set up a script that will automatically e-mail an eye-popping chart of bandwidth and uptime statistics every morning.
Price: Starts at $299 for one Creator Tool license, or $599 for one Creator Tool license plus 10 client licenses.

Monitor the Environment
RoomAlert 11E
www.roomalert.com
A good host-monitoring solution is critical to your infrastructure, but that’s not the only type of monitoring you need. The physical environment surrounding that infrastructure is also essential. You should be monitoring for airflow, temperatures, humidity, flooding, smoke, and power issues. If you host your infrastructure at a co-location facility, this is taken care of by the facility. But if you have your own datacenters, cages, and server closets, take a look at AVTech’s RoomAlert 11E.
RoomAlert 11E monitors your environment
RoomAlert 11E monitors your environment
Out of the box, the product includes one temperature/humidity sensor, one digital temperature sensor, and one external power sensor along with the actual hardware device. The unit can accommodate up to eight switch-type sensors and three digital temperature/humidity sensors or expansion boxes. The three digital sensors can be placed up to about 100 feet from the device, while the switch sensors can be hundreds of feet from the device depending on the monitor used.
The device is a self-contained unit with a built-in Web-accessible administration interface. It has no external system requirements other than a Windows machine to install the device discovery software on. Simply plug in the sensors, connect the device to your network, run the device discovery tool, and configure your alerts through the Web-based interface. It’s a good idea to also update to the latest firmware before getting started.
The most important aspect of the installation is planning which elements of your environment you need to monitor and deciding the best placement for the sensors and RoomAlert device. Remember that if you are monitoring a power circuit, your RoomAlert 11E should be on an alternate circuit or UPS. Otherwise, you will be defeating the purpose of the monitor.
AVTech also has a wireless version, the RoomAlert 26W, which offers more freedom as to where you place your central monitoring station in relation to your sensors. It also relieves you of running cables between your cabinets and sensors.
You might want to watch additional environmental factors besides the ones you can monitor with the included sensors, and the AVTech product Web site offers a number of other sensors you can plug into the 11E. You can purchase sensors to track temperature, humidity, and power as well as to check for area and spot flooding, smoke, motion, airflow, and room entry.
Price: RoomAlert 11E starts at $495. Sensors run from $25 to $400.

Book Review
Inside SQL Server 2005 Tools
www.awprofessional.com
SQL Server™ 2005 offers numerous new features and tools— so many that it can seem a bit overwhelming. Several members of the SQL Server team at Microsoft have written a good book to get you quickly up to speed on all the new features and tools. More than just a primer, though, this book also serves as a handy reference for someone who already feels fairly comfortable with SQL Server 2005.
Inside SQL Server 2005 Tools (Addison-Wesley Professional, 2006) covers the entire toolset of SQL Server 2005, from the SQL Server Surface Area Configuration Tool to the SQL Server Management Objects (SMO) .NET API that replaces the old SQL-DMO. It starts out with a brief history of the SQL Server product line, followed by a breakdown of the components of the SQL Server 2005 release. It then gives a quick overview of each of the tools available for the release, categorized by operational usage: Installation and Upgrade Tools; Configuration Tools; Management and Administration Tools; Monitoring and Operations Tools; Database, Schema, and Report Design Tools; Development Tools; Query Tuning and Optimization Tools; Maintenance Tools; and finally Programming Object Models. Each tool is then examined in detail.
The book covers a lot of ground, so I’ll only touch on some of the high spots. The sections on installation and configuration will be extremely handy if you’re just getting started with SQL Server 2005. The book does a good job of highlighting the issues you may encounter when trying to upgrade your database and how to use the Upgrade Advisor tool to generate a report of possible conflicts you’ll need to address before starting the upgrade process. It provides a step-by-step guide through the installation process and a description of common configuration scenarios. Especially useful is the part on how to use the Surface Area Configuration Tool to lock down your installation to only essential services and protocols.
In addition, there is good information on SQL Management Studio, the greatly enhanced replacement tool for Query Analyzer, Enterprise Manager, and Analysis Manager. The book provides an in-depth tutorial on the tool’s GUI and details the new UI functionality. For example, you’ll see just how easy it has become to script multiple objects to a new query window. And I quite like the section that covers how to use the SQL Profiler, Activity Monitor, and Microsoft Operations Manager (MOM) to find bottlenecks, note usage patterns, and get alerts on any issues with your database instance.
Anyone working with SQL Server 2005—or thinking about upgrading—should give this book a close read.
Price: $59.99 List. $53.99 Direct.

Web-Based Management
myLittleAdmin for SQL Server 2005
mylittleadmin.com
I like having at my disposal Web-based administration of SQL Server 2005 instances. If you are a Web hosting provider, this type of tool can be an essential offering for your customers. One solution worth considering is myLittleAdmin for SQL Server 2005, from myLittleTools.
A Microsoft® .NET Framework-based Web app, myLittleAdmin is easy to install and configure. It has a skinnable interface so you can adapt it to the look of your existing tools, as well as support for multiple languages for global customers.
myLittleAdmin features a skinnable interface
myLittleAdmin features a skinnable interface
The Web-based UI supports most database operations, including creating new databases, managing existing databases and their contents, and working with snapshots and schemas. Editing the properties of existing database objects is simple and myLittleAdmin has a nice editable data grid for modifying individual rows in your tables. The tree view interface is very similar to the tree view found in SQL Server Management Studio, so the application requires little learning. The only hitch is that some familiar right-clicks won’t pull up the expected context menu.
You can also use myLittleAdmin to edit the logins, server roles, and credentials of your SQL instance. It even lets you create and edit backup devices and linked servers—useful tasks to be able to perform from a remote location.
myLittleAdmin also lets you perform tasks like ad-hoc querying, attaching and detaching databases, backing up and restoring, importing CSV data, and shrinking databases. You can even browse to the error log and activity monitor to perform troubleshooting.
Price: Starts at $590 for a single server license. As part of your Web hosting toolset for customers, starts at $990 for a single server license.

Greg Steen is a technology professional, entrepreneur, and enthusiast. He is always on the hunt for new tools and methods to help make operations and development easier for IT professionals.


 SQL Q&amp;A: 64-Bit Installations, Allocating Cluster Memory, and More
SQL Q&A
64-Bit Installations, Allocating Cluster Memory, and More
Edited by Nancy Michell

BOL Performance
Q Whenever I open SQL Server™ Books Online (BOL) on my desktop system it seems really slow, even though I have a fast machine. This doesn’t happen on other systems I use. What could be causing the delay?
A The holdup probably has to do with how the option for loading help content is set. Books Online has three options for displaying such content. The first is to try online first and then to use local help, the second tries locally first and then online, and the third only checks online help. This selection is made when you use Books Online for the first time, but you can change it.
Open Books Online, and then click the Tools item in the menu bar. Open the Options item and then point to Help | Online. Select one of the first two options to load help locally.
While you’re in Books Online, it never hurts to check the version to ensure you’ve got the latest and greatest release. Look in the title bar at the top of the screen. If the date is earlier than February 2007 or there’s no date at all, then you’re out of date and you should get the latest copy at microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx. Books Online is updated several times a year at this site.

32-Bit and 64-Bit Installations
Q I’m confused about which types and versions of SQL Server I can install on x86, x64/EMT64, and IA64 servers. I’ve been told SQL Server 2005 has different types of installations than SQL Server 2000. Is this true?
A SQL Server 2000 comes in two types of binary installations (and various editions): 32-bit and 64-bit. You can install it on x86 and on x64/EMT64 where it will run as a 32-bit application. The SQL Server 2000 64-bit version runs on the IA64 platform.
SQL Server 2005 comes in three types of binary installations (and various editions). You can install it on x86 or x64/EMT64 as a 32-bit application, on x64/EMT64 as a 64-bit application if you’re running an x64/EMT64 Windows operating system, and on IA64 as a 64-bit application.

Finding SQL Server Information
Q Is there an easy way to find SQL Server-related information? I often find myself searching in a number of places and would like a better option.
A The Microsoft Web sites definitely have a lot of information on SQL Server, and there’s a great new resource that the SQL Server User Education team put together to help you find it. It’s a customized Windows Live™ search, that scopes results to SQL Server Books Online (see Figure 1). Check it out at search.live.com/macros/sql_server_user_education/booksonline, and don’t forget to send your feedback to the team from there.

Allocating Cluster Memory
Q For my active three-way cluster (a fourth node is idle), is it best to set SQL Server max server memory to one-third the total memory, or is it OK to max out the SQL Server memory and then during failover, let the failing instances fight for memory?
It seems better to plan ahead for the failing instances since, for example, two of the four servers could go down. In such a case, I could allocate my five SQL Server instances and one Analysis Services instance to each and still have two other servers to fail over to.
Figure 1 SQL Server Books Online search in Windows Live
Figure 1 SQL Server Books Online search in Windows Live
But, let’s say SQL Server has all the RAM on a server, and a new instance of SQL Server starts. What happens to the original SQL Server instance’s memory? It seems like I should plan for the worst case scenario—that only one node stays up and all instances of SQL Server end up running on that node.
A It is generally agreed that it’s best to set a max server memory value to something less than the total memory available in a machine. However, it’s doubtful that one-third the total memory value would be the best configuration in your situation.
You’re concerned that three of the four servers in your cluster might go down at the same time and that the three SQL Server instances would end up living on the fourth node. However, this scenario is unlikely.
In the majority of cases, you’re better off configuring each instance to use most of the memory available on each node. Let’s say that each node has 32GB of RAM. Setting max server memory to something like 28GB for each instance would be reasonable.
Now, in the event of a node failure, the instance running on that node would fail over to the passive node and could potentially gain access to 28GB of memory. The other two instances would remain unaffected; they keep running on the other two nodes within the cluster.
You indicated a four-node failover cluster with five SQL Server instances and one Analysis Services instance. If you’re running SQL Server 2000 with address windowing extensions (AWE), you’re going to have to set some carefully selected memory caps for your relational engine instances as they won’t give up memory they’ve acquired. It’s a different story with the more flexible situation of SQL Server 2005 and 64-bit instances that have access to a large address space with or without AWE; even when you do use AWE in this situation, it’s dynamic and can release memory when requested. So, the answer to the question of what happens to the original SQL Server instance and the memory it has acquired in a failover situation in which a new instance is starting up on the box is that it depends on whether you’re running SQL Server 2000 or SQL Server 2005 and whether you’re using AWE.
Planning for the worst case scenario is a good idea in principle, but in practical terms, unless you’ve really over-engineered the system, it’s unlikely you’re going to survive three of four nodes going down in a cluster running five SQL Server relational engine instances and one Analysis Services instance. The remaining node won’t have enough CPU resources to service the original instances at a comparable performance level. Since that’s the case, you’ll generally be better off engineering the solution such that optimal performance is maintained with the loss of one node but might require a bit of manual intervention with the loss of more than one. This would likely deliver a good combination of high availability (HA) support while allowing you to get decent utilization of expensive resources.
Finally, with SQL Server 2005 the end user can actually scale out the cluster to eight nodes. In SQL Server 2000 a four-node cluster was the maximum possible.

Mirroring Limits
Q In reading up on SQL Server 2005 database mirroring, I found a limitation that database mirroring can support a maximum of only 10 databases per server instance. My requirements are to have two separate SQL Server instances with separate storage, automatic failover between the two, and data redundancy.
My plan was to use peer-to-peer (P2P) SQL Server 2005 transaction replication combined with Microsoft® Cluster Server (MSCS), where I would have a cluster IP that’s sourced to one of the two nodes, so all insert, update, delete, and read traffic goes to a single node in the cluster. I’d treat the secondary node as passive but it would have the transactions replicated to it. In the event of a failure, MSCS would fail that IP over to the other node and since it’s configured to be P2P and bidirectional, there would be no manual process to begin publishing transactions to the other node (once it’s back up). I would use the majority node set (MNS) configuration within MSCS to mitigate the need for a shared disk resource for the quorum.
The mirroring option is still on the table. We’ve dropped the number from 1000 to 100 databases per SQL Server cluster. Still, should I put that type of resource load on the systems?
A For information or guidance around SQL Server mirroring, check out the BOL or the SQL Server Tech Center at microsoft.com/technet/prodtechnol/sql, and msdn2.microsoft.com/sql.
Your question prompted a lot of discussion. After sifting through the banter, here are the best responses regarding your scenario:
Response number one is that there is no enforced limit to the number of databases that can be mirrored in a given instance. I assume you are referring to an article that mentions that a best practice is to mirror no more than 10 databases per instance, but that’s simply an approximation and no limit is enforced anywhere in particular; it all depends on resources available on a given system.
Mirroring could be an option, but 1,000 databases is most definitely going to be pushing it unless you really have a really high-powered server. If you don’t want to use shared storage and want to use built-in SQL Server technologies, you can try mirroring, log shipping, or replication. The pros and cons of each vary.
Response number two is that if you have a large number of databases without using shared storage and you want a disaster recovery solution provided by Microsoft, you should investigate log shipping using a set of custom small helper programs to ease administration overhead. A program can back up and restore each database in order and would thus keep you from having to run multiple log shipping agents. Note that this has some chance of data loss. There is no built-in solution that won’t require either shared storage or a DBMS to ensure no data loss.
Of course, there’s the issue of how MSCS is going to detect and fail over. MNS configurations in a cluster don’t typically remove the need for shared storage altogether, they simply remove the necessity of having a dedicated shared LUN for the quorum. The only way the plan could work would be if the cluster is configured to manage nothing but the IPs and network names. SQL Server can’t be clustered without shared storage, so you couldn’t cluster the SQL service, which means the cluster wouldn’t be able to detect and monitor SQL Server services in a typical configuration.
You could cluster the SQL Server service by adding it as a generic service to be monitored, but then the problem arises on failover: given that the service would be clustered, MSCS would try to bring the service online on the passive node on failover, but some SQL service would already be running there. Of course, you could use it to simply cluster the IP and network names, and then manually fail them over when needed. You could do the same thing using Network Load Balancing (NLB), which is done elsewhere. Take a look at the paper at microsoft.com/technet/prodtechnol/sql/2000/deploy/hasog04.mspx for more information.
Given the number of databases you’re trying to support, a log shipping solution might work out better for you. Of course, you would need to automate the process using a Data Transformation Services/SQL Server Integration Services (DTS/SSIS) package, otherwise it would probably take too long to back up manually, move, and apply the active logs during a failure.

Thanks to the following Microsoft IT pros for their technical expertise: Boris Baryshnikov, Chad Boyd, Alan Doby, Patrick Gallucci; Cindy Gross, Chuck Ladd, Pat Martin, Vipul Shah, Nelson Taggart, Kartik Tamhane, Ken Tanner, Chuck Timon, George Walters, Kevin Warren, and especially Buck Woody.


 Utility Spotlight: Script Elevation PowerToys for Windows Vista
Utility Spotlight
Script Elevation PowerToys for Windows Vista
Michael Murgolo
Download the code for this article: Utility2007_06.exe (159KB)

Among the many features Windows Vista introduced to address security concerns, User Account Control (UAC) is one of the most significant. With User Account Control, even users who are administrators run most applications with standard privilege, but have "elevation potential" for specific administrative tasks and
application functions. After using Windows Vista™ for many months, elevating a task or application as necessary has become second nature. However, I also encountered a number of shortcomings when trying to elevate some types of tasks in Windows Vista, and that became frustrating.
So in the spirit of the old Windows® PowerToys, I’ve created a few Script Elevation PowerToys to overcome these limitations. You can find all of the PowerToys I’m about to discuss in the code download at technetmagazine .com/code07.aspx. And you can read about how UAC works in the November 2006 article "Achieve the Non-Admin Dream with User Account Control" by Alex Heaton (see the "Additional Resources" sidebar).

Elevate Command PowerToy
The first annoyance was that there was no method to elevate an application from the command line or from the Run dialog box. So after asking around within Microsoft, I came across a sample script from John Stephens (a Software Design Engineer at Microsoft) that provided the information I needed. It turns out that if you pass the verb "runas" to either the ShellExecute API or to its COM equivalent, the ShellExecute method of Shell.Application, the application launched will prompt for elevation (see the sidebar for details). This allowed me to create the first Elevation PowerToy—the Elevate Command PowerToy.
This tool (which consists of the files ElevateCommand.inf, elevate.cmd, and elevate.vbs) adds an elevate command to your system. This lets you launch applications that prompt for elevation from the command line, a script, or the Run dialog. For example, the following command opens Win.ini with Notepad (after prompting for elevation):
elevate notepad c:\Windows\Win.ini
When using the elevate command with Windows Script Host (WSH), Windows PowerShell™ or other scripts, you need to specify the script host executable (such as wscript, cscript, or powershell) as the application. To run a vbs, for example, you’d use this:
elevate wscript “C:\windows\system32\
slmgr.vbs” –dli
The help text explains this. Use elevate with -? or with no parameters to see the help text.

Run as Administrator for Scripts
The next irritant was that there was no "Run as Administrator" context menu option (when you right-click on the file in Explorer) for most Windows script types. The one exception was for command-shell scripts (those with .bat and .cmd file extensions). So I set out to investigate this. Many of the context menu options for file types are controlled through command keys for the "object" type in the HKEY_CLASSES_ROOT section of the Registry (see Verbs and File Associations in the sidebar for details). It turns out that if that command key is named runas, the command invoked will prompt for elevation. This allowed me to create the following PowerToys:
  • Elevate HTML Application PowerToy (ElevateHTA.inf)
  • Elevate Windows PowerShell Script PowerToy (ElevatePowerShellScript.inf)
  • Elevate WSH Script PowerToy (ElevateWSHScript.inf, elevate.cmd, elevate.vbs)
These PowerToys add a Run as Administrator Explorer context menu entry (as shown in Figure 1) for HTAs, Windows PowerShell, and Windows Script Host file types respectively. ElevateWSHScript.inf also adds a Run as Administrator with Command Prompt menu entry. (Please read the note in ElevatePowerShellScript.inf before installing it.)
Figure 1 Run as Administrator context menu options
Figure 1 Run as Administrator context menu options

Elevating Other Files Types
The runas command technique can be applied to just about any file type. For example, the Windows Installer in Windows Vista was designed to "do the right thing" when elevation was required for installing a package. However, some poorly authored packages (where, for example, custom actions are not marked appropriately) will not install correctly with UAC turned on unless they are installed using msiexec.exe from an elevated command prompt.
To allow this to be done directly from Explorer, I created ElevateMSI.inf. This tool clones the default actions for Windows Installer packages (.msi) and patches (.msp) to add an Install as Administrator context menu option for packages and Apply Patch as Administrator for patches.

CMD and PowerShell Prompt Here as Administrator
One of the most popular Windows PowerToys is the venerable Command (or CMD) Prompt Here. With this PowerToy installed, you can right-click on a folder or drive in Windows Explorer and select CMD Prompt Here from the context menu. This opens a command prompt with the selected folder as the current directory.
Because this is so handy, I use this PowerToy many times a day. As I was trying to learn and use Windows PowerShell, I found myself wishing for the same functionality. So I created the PowerShell Prompt Here PowerToy (see "An Old PowerToy Is New Again" in the sidebar).
But even that was not quite sufficient: many times I wanted that shell prompt to be open with elevated privileges. This led to the final two PowerToys: "CMD Prompt Here as Administrator" (CmdHereAsAdmin.inf) and "PowerShell Prompt Here as Administrator" (PowerShellHereAsAdmin.inf, elevate.cmd, elevate .vbs) as shown in Figure 2. Both PowerToys work the same way as their non-elevated counterparts (which are included in the code download for your convenience).
Figure 2 Prompts with elevated privilege
Figure 2 Prompts with elevated privilege

Installation and Implementation
To install these PowerToys, right-click on an INF file, select Install, and approve the elevation. To uninstall, use the Programs and Features selection on the Control Panel.
In case you dig into the INF files and wonder why three PowerToys install elevate.cmd and elevate.vbs into different locations, I’ll explain. Most of the PowerToys are implemented by adding a runas subkey to HKEY_CLASSES_ROOT\objecttype\Shell key for the object type in the Registry.
However, for some PowerToys there were object types I wanted to have two context menu entries cause elevation ("CMD Prompt Here as Administrator" and "PowerShell Prompt Here as Administrator" for Drive and Directory object types; "Run as Administrator" and "Run as Administrator with Command Prompt" for all WSH object types.) Since there can only be one runas key for each object type, I had to implement the second action by calling the elevate command. But since I wanted each INF to be installable and uninstallable independently, I had to put the associated copies elevate.cmd and elevate.vbs in different places. (You can’t increment file usage counters from a raw INF file. Yes, MSI installers would be better, but I wanted installers that could be created and modified with a text editor.) One side effect of this is that only the context menu entries implemented using the runas key will display a shield in the menu.

Summary
I hope you find these tools useful and that they improve your experience with UAC. Perhaps they will inspire you to create PowerToys of your own. (For those who use other scripting languages like Perl or Python on Windows Vista, it should be easy to create an "Elevate Script" PowerToy for those languages as well.) As with all PowerToys, these are unsupported, "use at your own risk" tools. In any event, have fun elevating!
Additional Resource
  • Achieve the Non-Admin Dream with User Account Control
  • User Account Control Overview
  • Elevate through ShellExecute
  • ShellExecute Method
  • Verbs and File Associations
  • An Old PowerToy Is New Again

Michael Murgolo is a Senior Infrastructure Consultant for Microsoft Consulting Services. He focuses on operating systems, deployment, network services, Active Directory, systems management, automation, and patch management. He is a subject matter expert in the area of desktop deployment and migration.


 The Cable Guy: The Secure Socket Tunneling Protocol
The Cable Guy
The Secure Socket Tunneling Protocol
Joseph Davies
This column is based on a prerelease version of Windows Server code-named "Longhorn." All information herein is subject to change.

Virtual private network (VPN) support in Windows XP and Windows Server 2003 allows you to connect to your private intranet across the Internet, just as if your computer was plugged into a local Ethernet port. However, the VPN protocols in Windows XP and Windows Server 2003 don’t work for some firewall configurations
and for some indirect configurations—such as when your computer is behind a Network Address Translator (NAT) or Web proxy server—in which the traffic for VPN connections is being blocked. To resolve these difficulties, Windows Server® 2008 (now in beta testing) includes support for the new Secure Socket Tunneling Protocol (SSTP).

VPN Access Problems
In Windows® XP and Windows Server 2003, the VPN protocols that enable remote access connections to an intranet across the Internet are the Point-to-Point Tunneling Protocol (PPTP) and the Layer Two Tunneling Protocol with Internet Protocol security (L2TP/IPsec). They provide the encapsulation of the packets sent between a remote access client and the intranet to which it is connected.
PPTP-based VPN traffic consists of a TCP connection to TCP port 1723 on the VPN server to perform tunnel maintenance, and Generic Routing Encapsulation (GRE)-encapsulated packets for VPN data. But PPTP traffic can have problems with firewalls, NATs, and Web proxies. To prevent problems, firewalls must be configured to allow both the TCP connection and the GRE-encapsulated data. Although GRE is a standard method of encapsulating IP packets, many Internet service providers (ISPs) drop these packets, resulting in lost data. In addition, the connections found in hotels and coffee shops are typically configured for normal Web and e-mail traffic and may not allow PPTP traffic. Moreover, if your computer is behind a NAT, the NAT must be able to translate the GRE traffic. If it can’t, you’ll be able to establish the TCP connection but you won’t be able to send or receive any GRE-encapsulated data. Lastly, PPTP traffic cannot flow through a Web proxy.
The other VPN protocol at work in Windows XP and Windows Server 2003, L2TP/IPsec, uses Internet Key Exchange (IKE) to negotiate the IPsec Encapsulating Security Payload (ESP) protection of the VPN traffic, and it too can have problems with firewalls, NATs, and Web proxies.
In this setup, firewalls need to be configured to allow both the IKE traffic and ESP-encapsulated data. If your VPN client computer is behind a NAT, both the VPN client and the VPN server must support IPsec NAT-Traversal (NAT-T). Note, however, that the VPN server can’t be located behind a NAT, and that L2TP/IPsec traffic can’t flow through a Web proxy.

The New VPN Solution
As you can see, there are a number of issues around VPN protocol operation in Windows XP and Windows Server 2003. The good news is that SSTP in Windows Server 2008 solves these VPN connectivity problems by using HTTP over secure sockets layer (SSL). SSL is also known as Transport Layer Security (TLS). HTTP over SSL on TCP port 443 is the protocol that has been used on the Web for some time for collecting credit card numbers and other private data. Whenever you connect to a Web address that begins with https:, you are using HTTP over SSL.
Using HTTP over SSL solves many VPN protocol connectivity problems—firewalls, NATs, and Web proxies typically allow this type of traffic because it’s so widespread.
SSTP uses an HTTP-over-SSL session between VPN clients and servers to exchange encapsulated IPv4 or IPv6 packets. Note that an HTTP-over-SSL-based remote access VPN connection is different from the connection made by an application that uses HTTP over SSL. For example, Outlook® Web Access (OWA) lets you access your Microsoft Exchange e-mail at your enterprise over the Internet. OWA uses an HTTP over SSL-encrypted session, but this is not the same as a remote access connection. Although you can view your e-mail with OWA, you can’t reach the location of an intranet URL that is embedded within an Exchange e-mail message.
(SSTP does not support authenticated Web proxy configurations, in which the proxy requires some form of authentication during the HTTP Connect request.)
An HTTP-over-SSL implementation in Windows can substantially lower the cost of maintaining your remote access solution. For example, HTTP over SSL results in fewer help desk support issues and eliminates issues related to VPN servers being placed behind NATs. And, since SSTP works just about everywhere, users are happier and more productive.
Because SSTP is built into Windows, you don’t have to be concerned with third-party VPN client software to install and manage on client computers, or with extra software to install on the VPN server. Additionally, SSTP can provide better load balancing of VPN connections through available SSL load balancers.
New SSTP Features
  • SSTP has integrated support for Network Access Protection (NAP), which can be used to better protect network assets by enforcing compliance with system health requirements. For more information about NAP, see microsoft.com/nap.
  • Also, SSTP supports native IPv6 traffic sent inside the SSTP tunnel and IPv6-based SSTP connections across the IPv6 Internet.
  • Furthermore, SSTP establishes a single HTTP over SSL session from the SSTP client to the SSTP server. Other third-party SSL-based VPN solutions use two HTTP over SSL sessions. Using a single HTTP over SSL session provides lower network utilization and better load balancing.
  • Finally, SSTP is fully integrated into the VPN client components of Windows Server 2008 and Routing and Remote Access in Windows Server 2008. SSTP is another VPN protocol and can use all of the same authentication protocols and configuration methods—such as the Network Connections folder and Connection Manager—that are used for PPTP or L2TP/IPsec-based connections.
Unlike the PPTP and L2TP/IPsec protocols in Windows XP and Windows Server 2003, SSTP does not support site-to-site VPN connections.

SSTP in Windows
A computer running Windows Server "Longhorn" and Routing and Remote Access is an SSTP-based VPN server. You don’t have to install IIS because Routing and Remote Access listens to incoming connections on the specific Uniform Resource Identifier (URI) /sra_{BA195980-CD49-458b-9E23- C84EE0ADCD75}/.However, Routing and Remote Access and IIS can coexist on the same server.
A computer running Windows Server 2008 is an SSTP-based VPN client, capable of initiating SSTP connections to an SSTP-based VPN server. The SSTP server must have a computer certificate with the Server Authentication or All-Purpose Enhanced Key Usage (EKU) property installed. This computer certificate is used by the SSTP client to authenticate the SSTP server when the SSL session is established. The SSTP client validates the computer certificate of the SSTP server. To trust the computer certificate, the root certificate authority (CA) of the issuing CA of the SSTP server’s computer certificate must be installed on the SSTP client.
Figure 1 compares attributes of the different VPN protocols in Windows Server 2008. The sidebar "New SSTP Features" describes SSTP features.
Figure 1 Comparing the different VPN protocols (Close Figure 1)

Attributes | PPTP | L2TP/IPsec | SSTP
Encapsulation | GRE | L2TP over UDP | SSTP over TCP
Encryption | Microsoft Point-to-Point Encryption (MPPE) with RC4 | IPsec ESP with Triple Data Encryption Standard (3DES) or Advanced Encryption Standard (AES) | SSL with RC4 or AES
Tunnel maintenance protocol | PPTP | L2TP | SSTP
When user authentication occurs | Before encryption begins | After the IPsec session is established | After the SSL session is established
Certificates required to establish the VPN tunnel | None | Computer certificates on both the VPN client and VPN server | Computer certificate on the VPN server and root CA certificate on the VPN client

How SSTP Works
When a user on a computer running Windows 2008 initiates an SSTP-based VPN connection, the following occurs:
  1. The SSTP client establishes a TCP connection with the SSTP server between a dynamically-allocated TCP port on the client and TCP port 443 on the server.
  2. The SSTP client sends an SSL Client-Hello message, indicating that the client wants to create an SSL session with the SSTP server.
  3. The SSTP server sends its computer certificate to the SSTP client.
  4. The SSTP client validates the computer certificate, determines the encryption method for the SSL session, generates an SSL session key and then encrypts it with the public key of the SSTP server’s certificate.
  5. The SSTP client sends the encrypted form of the SSL session key to the SSTP server.
  6. The SSTP server decrypts the encrypted SSL session key with the private key of its computer certificate. All future communication between the SSTP client and the SSTP server is encrypted with the negotiated encryption method and SSL session key.
  7. The SSTP client sends an HTTP over SSL request message to the SSTP server.
  8. The SSTP client negotiates an SSTP tunnel with the SSTP server.
  9. The SSTP client negotiates a PPP connection with the SSTP server. This negotiation includes authenticating the user’s credentials with a PPP authentication method and configuring settings for IPv4 or IPv6 traffic.
  10. The SSTP client begins sending IPv4 or IPv6 traffic over the PPP link.
Figure 2 shows the structure of IPv4 or IPv6 packets that are sent over an SSTP-based VPN connection.
Figure 2 Structure of SSTP packets
Figure 2 Structure of SSTP packets
An IPv4 or IPv6 packet is first encapsulated with a PPP header and an SSTP header. The combination of the IPv4 or IPv6 packet, the PPP header, and the SSTP header is encrypted by the SSL session. A TCP header and an IPv4 header (for SSTP connections across the IPv4 Internet) or an IPv6 header (for SSTP connections across the IPv6 Internet) are added to complete the packet.
For more information about SSTP, see the Routing and Remote Access Blog at blogs.technet.com/rrasblog.

Joseph Davies is a technical writer with Microsoft and has been teaching and writing about Windows networking topics since 1992. He has written five books for Microsoft Press and is the author of the monthly online TechNet Cable Guy column.


 Windows PowerShell: Working with Active Directory
New information has been added to this article since publication.
Refer to the Editor's Update below.

Windows Powershell
Working with Active Directory
Don Jones

If you’ve spent any time playing with Windows PowerShell, odds are you’ve tried the Get-WMIObject cmdlet—also known by its convenient alias, gwmi. As I described in last month’s column, this cmdlet highlights what a major improvement Windows PowerShell is over previous scripting languages and command-line
shells (see technetmagazine.com/issues/2007/05/PowerShell). Gwmi enables fast, easy access to Windows® Management Instrumentation (WMI), allowing you to do an incredible number of things without having to write complex scripts.
Get-WMIObject is such a good example of what Windows PowerShell™ can do that whenever I show it to a class, students invariably extrapolate its functionality to other areas of Windows administration. One of the first questions I’m typically asked is along the lines of "Is there a Get-ADSIObject cmdlet?"

ADSI Support in Windows PowerShell
ADSI stands for Active Directory® Services Interface. Despite the name, ADSI isn’t actually specific to Active Directory. A more accurate way to read the name would be "Active (pause) Directory Services Interface," because ADSI can connect to a variety of directory services, including Windows NT®-style directories—not just Windows NT domains, mind you, but also to the local Security Accounts Manager (SAM) on standalone and member computers. With such flexibility, a Get-ADSIObject cmdlet would certainly be tremendously useful. Unfortunately, that’s a cmdlet the Windows PowerShell team wasn’t able to squeeze into its first version.
That’s not to say Windows PowerShell lacks ADSI support, though. In fact, the ADSI support in Windows PowerShell is so good that you might not even care about the lack of a Get-ADSIObject cmdlet!
It all starts with the [ADSI] type adapter. Type adapters need a little explanation. Remember that Windows PowerShell is built on the Microsoft® .NET Framework (2.0 or higher, to be specific). As a result, pretty much everything in Windows PowerShell—from WMI objects to files and folders—is represented as an object from the Framework. However, the Windows PowerShell team wasn’t comfortable just exposing raw Framework objects to Windows administrators. For example, many of the Framework objects work somewhat inconsistently, and consistency was a major design goal for Windows PowerShell. Another reason is that some Framework objects are overkill when it comes to Windows administration, and simplicity was also a major Windows PowerShell design consideration. As a result, type adapters were born.
As the name implies, a type adapter "adapts" a .NET Framework object type into a more consistent, and sometimes simpler, format. For example, suppose you create a new string variable like this:
[string]$var = “Hello”
You’ve used an instance of the System.String type which is handled by the .NET adapter. The [ADSI] type adapter is connected to the .NET Framework DirectoryServices classes, including the DirectoryEntry type.

Retrieving Objects from the Directory
Connecting to directory objects is fairly straightforward. For instance, to connect to a user named Don, in the IT organizational unit (OU) of the Contoso.com domain, you’d use something like this:
$user = [ADSI]”LDAP://cn=Don,ou=IT,dc=Contoso,dc=com”
[ Editor's Update - 5/31/2007: This sentence originally referred to the Distinguished Name (DN) as a Fully Qualified Domain Name (FQDN), which is not technically accurate. FQDN is a DNS term meant to refer to fully qualified host or domain names (such as server1.contoso.com). Distinguished Name is the proper term for a path shown in RFC 1779 or X.500 format, such as cn=Don,ou=IT,dc=Contoso,dc=com. This update has been made throughout the rest of the article.]
Working with local security accounts uses an almost identical process, except for using the WinNT provider instead of the LDAP provider:
$user = [ADSI]”WinNT://don-pc/don”
Note that both the LDAP and WinNT monikers are case-sensitive. While Windows PowerShell itself is generally case-agnostic, these ADSI resources are not—so be sure to pay attention to how you type them.
Figure 1 shows what happens if I take the resulting $user variable and pipe it to Get-Member: I get a list of the object’s properties. Unfortunately, this is not a complete list of all the user’s properties, and it includes none of the user object’s methods. The underlying System.DirectoryServices.DirectoryEntry Framework class works a bit oddly in this regard, and Windows PowerShell can only show me what the Framework class delivers.
Figure 1 Retrieving a list of an object’s properties
Figure 1 Retrieving a list of an object’s properties
Retrieving objects is primarily a matter of knowing how to construct a query string. Using the WinNT provider is quite easy. Simply specify a computer or domain name, a slash, and then an object name. This technique works just fine with Active Directory domains (which are, after all, backward-compatible with Windows NT domains). And, in fact, using the WinNT provider to retrieve objects from Active Directory can sometimes be the easiest route since the WinNT provider gives you a flat view of the domain. That means you don’t need to know what OU an object is located in because the WinNT provider doesn’t see the OUs.
Retrieving LDAP objects requires somewhat more precision. You start with the most-specific information possible, such as an object’s canonical name (cn) or the name of an OU. Then you provide the complete path to the object, beginning with its parent container and working out to the domain itself. For example, the user Don, located in the Sales OU, which is in the West OU of the Contoso.com domain, would look like this:
LDAP://cn=Don,ou=Sales,ou=West,dc=Contoso,dc=com
This format takes a little bit of practice and requires that you know where the object is located. Figure 2 summarizes the various components of a DN.
Figure 2 Distinguished Name components (Close Figure 2)

Component | Purpose | Example
cn | Canonical name of an object. Also used for non-OU containers, such as Users and Computers. | cn=Don
ou | Organizational Unit. | ou=Sales
dc | Domain name component. Each component of a DNS domain name gets its own “dc=” component. | dc=domain, dc=com

A Little Help from a Friend
Creating and deleting objects typically requires that you first connect to the object’s container, such as an OU, and then ask the container to create or delete the object. I always forget the right syntax, but fortunately the Microsoft Scripting Guys can lend a helping hand in the form of ADSI Scriptomatic.
Though originally created for VBScript, ADSI Scriptomatic is still a useful guide for Windows PowerShell since the actual ADSI syntax is the same. For example, after downloading the tool, I select the option to create a new user. I ignore all the script code that the tool generates until after the "End connect to a container" code, which looks like this:
Set objUser =
 objContainer.Create(“user”, “cn=” & strName)
objUser.Put “sAMAccountName”, strName
objUser.SetInfo
Translating to Windows PowerShell is easy. First, I connect to the container where I want the user to be created. To stay consistent with the Scriptomatic code, I’ll use the variable $objContainer to represent the OU. I’ll also create a variable, $strName, to hold the new user’s name:
$strName = “Don”
$objContainer = “LDAP//ou=Test,dc=Contoso,dc=com”
Next, I copy over the Scriptomatic code, remove all traces of any VBScript Set statements, and add $ to the variable names:
$objUser = $objContainer.Create(“user”,
  “cn=” & $strName)
$objUser.Put “sAMAccountName”, $strName
$objUser.SetInfo()
That’s all it takes—a new user has been created in the Test OU of the Contoso .com domain.

Modifying Directory Objects
Once you’ve connected to an object—such as a user or a group—you can modify it. With the WinNT provider, you’re able to directly modify many properties, like those in Figure 1. For example, to display and then change a user’s Description property, you would do this:
Write-Host $user.Description
$user.Description = “New Description”
$user.SetInfo()
The important thing to remember about this is that property changes are made to your local property cache, which is a temporary storage area that ADSI maintains on your computer. Calling the SetInfo method writes the cache back to the domain or computer that you retrieved the object from, essentially saving your changes back to the directory.
Active Directory objects don’t provide direct properties for most object attributes. Instead, you use the Get and Put methods:
Write-Host $user.Get(“Description”)
$user.Put(“Description”,”New Description”)
$user.SetInfo()
WinNT objects tend to be fairly simplistic, since Windows NT directory services didn’t store much information about objects like users and groups. Active Directory, on the other hand, stores a wealth of information and figuring out the correct attribute names can be difficult. For instance, if you want to change a user’s last name, you have to change the Sn property. Why Sn? It stands for surname.
Fortunately, Microsoft provides a good cross-reference, which is available online at msdn2.microsoft.com/ms677286.aspx. This reference shows the attribute names for each major area of the Active Directory Users & Computers console, so if you know what you want to change in the console, you can figure out the underlying attribute name. Note that a more complete console-to-attribute cross-reference is available in the book ADSI Scripting: TFM by Cade Fassett (SAPIEN Press, 2007).

What You Can’t Do
Unfortunately, ADSI support in Windows PowerShell isn’t as strong as support for other technologies, such as WMI. For example, it’s somewhat difficult to enumerate through the members of a local computer’s groups. A number of difficult situations crop up when dealing with Active Directory as well. My experience has been that basic object retrieval, creation, and deletion works well. Modifying object properties works fairly well, although some properties are inaccessible. I run into the most difficulties working with local objects and groups through the WinNT provider.
That’s not to say things can’t be done at all. Some things are just more difficult or less intuitive. Consider the following example:
$group = [ADSI]”LDAP://cn=Techs,cn=users,
  dc=contoso,dc=com”
$group.Member.Add(“cn=user1,cn=users,
  dc=contoso , dc=com”)
$group.psbase.CommitChanges()
This adds the user named User1 to the group Techs. It starts out straightforward enough. It retrieves the group by using the DN. Then, it uses the group’s Member collection—specifically, the collection’s Add method—to add the DN of the desired user. The last step, however, is not very intuitive at all. It calls on the hidden PSBase class’s CommitChanges method to save the changes.
PSBase is a special class that directly represents the base .NET Framework object. In this case, CommitChanges isn’t directly exposed in Windows PowerShell (actually, no methods are exposed by the ADSI adapter), so you have to go to the underlying class. This is not impossible, but it’s certainly not intuitive, either. It also illustrates that directory services capabilities haven’t yet been fully adapted into Windows PowerShell.
There are a number of reasons for this. First, the Windows PowerShell team added the current ADSI support to the shell somewhat late in the development cycle. As Jeffrey Snover, the architect of the shell, often says, "to ship is to choose." The team had a fixed amount of time to develop and ship the shell, and they had to make decisions as to what they had to save for the next version. Otherwise, they could have easily spent years adding features and never actually releasing a supported product.
Another reason, however, is the underlying .NET Framework. Its DirectoryServices class is pretty complex and adapting that complexity into Windows PowerShell will take a lot of time and careful planning. The Framework classes are also, in my opinion, a bit biased toward Active Directory and don’t provide stellar support for the WinNT provider—Windows PowerShell, of course, would inherit any such limitations from the Framework.
I expect Windows PowerShell to eventually have vastly expanded directory services support—support that may not even be through the layer of ADSI, but rather through base improvements in the .NET Framework. In the meantime, the ADSI support available in Windows PowerShell lets you perform the vast majority of administrative tasks, such as creating users, modifying common user properties, and so forth.
Don’t forget that many directory services tasks can be accomplished through WMI. Check out the scripts available at microsoft.com/technet/scriptcenter/scripts for some excellent examples that use WMI to provide more extensive information on a local group than ADSI itself provides.

Don Jones is the Lead Scripting Guru for SAPIEN Technologies, and an instructor for ScriptingTraining.com. Reach Don through his Web site, ScriptingAnswers.com.


 Hey, Scripting Guy!: Scripting Around the Squiggly Red Line
Hey, Scripting Guy!
Scripting Around the Squiggly Red Line
The Microsoft Scripting Guys
Download the code for this article: HeyScriptingGuy2007_06.exe (151KB)

When you’re a Microsoft Scripting Guy, you get used to people falling all over themselves in order to do things for you:
"Can I get you a fresh cup of coffee, Scripting Guy?"
"Hey, Scripting Guy! There’s only one cookie. Why don’t you take it?"
"Get up, Grandma. Let the Scripting Guy have the chair."
Yes, everyone wants to help the Scripting Guys—everyone. Well, everyone except Microsoft® Word.
That’s right, Microsoft Word. Now, in general, the Scripting Guys like Microsoft Word. And we suppose that it’s possible that Word has better things to do than cater to the Scripting Guys’ every whim. (Although we can’t imagine what could be better than that.) Still, it’s hard to deny that Microsoft Word can be a bit lazy at times. For example, take a look at Figure 1, a screenshot showing an extract from a draft of this column.
Figure 1 Document in Word showing spelling mistakes
Figure 1 Document in Word showing spelling mistakes
Notice anything peculiar? That’s right: Word has drawn squiggly lines under scripting terms like Msgbox. Why? Because Word doesn’t recognize those terms. Doesn’t recognize those terms? Come on, Word; after all, over the past few years the Scripting Guys have typed the term Msgbox several million times. Several million more times they have run spell-check and told you that Msgbox was spelled correctly. And yet still you mark Msgbox and StrReverse and LTrim as being misspelled words? What’s up with that?
Now, before you rush to the defense of Word, yes, we know that we can manually add these terms to the Microsoft Word dictionary. But, come on, we’re the Scripting Guys, for crying out loud; what do we know about manual labor? Besides, manually adding VBScript functions and Windows® Management Instrumentation (WMI) class names and Active Directory® Security Interfaces (ADSI) object attributes can be a bit tedious, to say the least. And what if we want to do this on all of our computers? What if we want to share these correct spellings with our devoted readers? What if... well, you get the idea.
The point is this: surely there must be an easier way to add scripting terms (or any terms, for that matter) to the dictionary without having to do it by hand, one word at a time.
As it turns out, there isn’t a way. See you all next month.
No, hey, we’re just kidding. Of course there’s an easier way to go about adding terms to the dictionary. And in just a moment we’ll show you how to do that. First, however, let’s take a minute to chat about dictionaries.
Speaking of which, here’s an interesting fact about dictionaries. Why do Americans spell color without a u (color, not colour)? Why do Americans spell the word as center rather than centre? We know the answer: because Noah Webster, who put together the first American dictionary, didn’t like English spelling rules and thus somewhat arbitrarily changed the spelling of many words.
Well, OK. Not enthralling. But you try coming up with an interesting fact about dictionaries!
In addition to the standard dictionary built into the application, Microsoft Word also allows you to create any number of custom dictionaries. By default, Word comes with a custom dictionary named Custom.dic, which is typically found in the Application Data\Microsoft\Proof folder within your User Profile folder (\Documents and Settings\username by default in Windows XP). If you right-click a misspelled word and select Add to Dictionary, that word will be added to Custom.dic.
As it turns out, Custom.dic is just a plain old text file. Open it up in Notepad and you’ll see a list of words similar to this:
Aaberg
Aalling
Abbas
Abercrombie
Abola
Abolrous
Abrus
And that’s how we can programmatically add scripting terms to the dictionary in Microsoft Word. All we have to do is create a text file containing those terms, then configure Word to use that file as a custom dictionary. How hard is that going to be? Considering the fact that the Scripting Guys are willing to do this ourselves, obviously not very hard at all.
But hold on: we need to take one more quick side trip before doing that. In the Microsoft Word object model, information about custom dictionaries is stored in the CustomDictionaries collection. In turn, that collection can be programmatically accessed by referencing the Word.Application object and the CustomDictionaries property. For example, Figure 2 shows a script that returns information about all the custom dictionaries associated with your copy of Microsoft Word.
Figure 2 Script that retrieves custom dictionary information (Close Figure 2)
Set objWord = CreateObject(“Word.Application”)

Set colDictionaries = objWord.CustomDictionaries

For Each objDictionary in colDictionaries
  Wscript.Echo “Name: “ & objDictionary.Name
  Wscript.Echo “Language ID: “ & objDictionary.LanguageID
  Wscript.Echo “Language-specific: “ & objDictionary.LanguageSpecific
  Wscript.Echo “Location: “ & objDictionary.Path
  Wscript.Echo “Read-only: “ & objDictionary.ReadOnly
  intType = objDictionary.Type
  Select Case intType
    Case 0 Wscript.Echo “Type: Spelling”
    Case 1 Wscript.Echo “Type: Grammar”
    Case 2 Wscript.Echo “Type: Thesaurus”
    Case 3 Wscript.Echo “Type: Hyphenation”
    Case 4 Wscript.Echo “Type: Spelling (complete)”
    Case 5 Wscript.Echo “Type: Spelling (custom)”
    Case 6 Wscript.Echo “Type: Spelling (legal)”
    Case 7 Wscript.Echo “Type: Spelling (medical)”
    Case 8 Wscript.Echo “Type: Hangual-Hanja Conversion”
    Case 9 Wscript.Echo “Type: Hangual-Hanja Conversion (custom)”
  End Select
  Wscript.Echo
Next

objWord.Quit
Run the script in Figure 2, and you’ll get back information similar to this:
Name: CUSTOM.DIC
Language ID: 0
Language-specific: False
Location: C:\Documents and Settings\kenmyer\Application Data\Microsoft\Proof
Read-only: False
Type: Spelling (custom)
Pretty slick, huh?
Of course, getting information about existing dictionaries isn’t quite the same thing as creating a new custom dictionary; it’s sort of like the difference between reading about someone who has a million dollars and being someone who has a million dollars. Therefore, let’s see if we can figure out how to create a new custom dictionary in Word.
We’re going to start out by adding all the VBScript functions to a new dictionary named Scripting.dic. We’re starting out with VBScript functions because we have to do a little work here. After that, however, we’ll show you how to add WMI classes, ADSI attributes, and Windows PowerShell™ cmdlets to your dictionary without having to do hardly any work at all. (Needless to say, when it comes to hardly doing any work at all, the Scripting Guys know what they’re talking about.)
To begin with, creating a custom dictionary in Microsoft Word is as easy as this:
Set objWord = CreateObject _
  (“Word.Application”)

Set colDictionaries = _
  objWord.CustomDictionaries
colDictionaries.Add “Scripting.dic”

objWord.Quit
As you can see, we start out by creating an instance of the Word.Application object. You might notice that we never set the Visible property to True, and thus never make Word visible onscreen. Why not? Well, simply because this script requires only a second or so to run. Because of that, we didn’t see much reason to have Word flash briefly onto the screen and then immediately disappear. But if you like flashing instances of Word (if for no other reason than to let you know that the script is actually doing something) then simply add this as the second line of code in your script:
objWord.Visible = True
After creating the Word.Application object, we next use this line of code to create an object reference to the CustomDictionaries collection:
Set colDictionaries = _
  objWord.CustomDictionaries
We then call the Add method to add the custom dictionary. Note that this file doesn’t have to exist; if Word can’t find a file named Scripting.dic, then it will simply create a new, blank file by that name. Here’s the code for adding the custom dictionary:
colDictionaries.Add “Scripting.dic”
You might have noticed as well that we didn’t specify a path when adding the new dictionary. Instead, we simply handed the file name (Scripting.dic) to the Add method. That’s fine. In that case, Scripting.dic will be created in the default folder for dictionaries and other proofing tools (for example, C:\Documents and Settings\kenmyer\Application Data\Microsoft\Proof).
What if we wanted our dictionary to reside in a different location? No problem. This command creates Scripting.dic in the C:\Scripts folder:
colDictionaries.Add _
  “C:\Scripts\Scripting.dic”
And what if we decide later on that we want to get rid of that custom dictionary? Once again, that’s no problem. In that case, we can just bind to the dictionary in question and use the Delete method to get rid of it:
Set objWord = CreateObject _
  (“Word.Application”)
Set objDictionary = _
  objWord.CustomDictionaries _
  (“C:\Scripts\Scripting.dic”)
objDictionary.Delete

objWord.Quit
Note that this removes C:\Scripts\ Scripting.dic from the CustomDictionaries collection in Word. However, it does not delete the file itself. If you motor on over to C:\Scripts, the Scripting.dic file will still be there, just the way you left it.
At this point, all we have to do is start adding terms to our custom dictionary. One way to do that is to simply find a list of, say, VBScript functions, copy them, and then paste them into the file Scripting.dic. For example, you can find a list of VBScript functions in the VBScript Language Reference on MSDN®. Copy those terms, paste them into Scripting.dic, then fire up Word. Figure 3 shows the same section of this article we showed you earlier in Figure 1. See that squiggly red line beneath Msgbox? Of course you don’t; that’s because Word now views Msgbox as a correctly spelled word.
Figure 3 Document in Word after adding a custom dictionary
Figure 3 Document in Word after adding a custom dictionary
That’s pretty handy, if we do say so ourselves, especially when you consider the fact that you can share Scripting.dic and your custom dictionary creation script with anyone you want. Do so and in no time at all their versions of Word will also view Msgbox as a correctly spelled word. The truth is, if we Scripting Guys were lazy, we could just end this month’s column right here and now and you’d still walk away with something useful. But, as the saying goes, you ain’t seen nothin’ yet.
Note: actually, we are lazy. But seeing as how we had to fill up the excess space in this column, we decided to toss in a bonus script or two.
As you probably know, both VBScript and Windows Script Host are kind of shy; they don’t really like to talk about themselves. That isn’t true of WMI, ADSI, or Windows PowerShell, however. All you have to do is ask and those technologies will tell you all about their classes, properties, methods—pretty much anything and everything you’d ever want to know.
Take ADSI, for example. Figure 4 shows a script that binds to the Active Directory schema and retrieves all the attributes of the user account object. In turn, it then writes those attributes to the file C:\Scripts\Scripting.dic.
Figure 4 Add ADSI attribute names to a custom dictionary (Close Figure 4)
Const ForWriting = 2

Set objFSO = CreateObject(“Scripting.FileSystemObject”)
Set objFile = objFSO.OpenTextFile(“C:\Scripts\Scripting.dic”, ForWriting)

Set objSchemaUser = GetObject(“LDAP://schema/user”)

For Each strAttribute in objSchemaUser.MandatoryProperties
  objFile.WriteLine strAttribute
Next

For Each strAttribute in objSchemaUser.OptionalProperties
  objFile.WriteLine strAttribute
Next

objFile.Close
See how cool that is? With just a few lines of code we’ve created a dictionary containing all the attributes of the Active Directory user object. Share this code with your fellow scripters, and none of you will ever have to worry about attribute names like streetAddress or givenName being flagged as misspelled words. And, of course, this is infinitely extensible. Want to add the properties for the computer class? Then substitute in this line of code:
Set objSchemaComputer = _
  GetObject(“LDAP://schema/computer”)
Or how about WMI classes? Figure 5 shows a script that retrieves a list of all the WMI classes found in the root\cimV2 namespace and writes that information to C:\Scripts\Scripting.dic.
Figure 5 Add WMI class names to a custom dictionary (Close Figure 5)
Const ForWriting = 2

Set objFSO = CreateObject(“Scripting.FileSystemObject”)
Set objFile = objFSO.OpenTextFile(“C:\Scripts\Scripting.dic”, ForWriting)

strComputer = “.”

Set objWMIService=GetObject(“winmgmts:\\” & strComputer & “\root\cimv2”)

For Each objClass in objWMIService.SubclassesOf()
  objFile.WriteLine objClass.Path_.Class
Next

objFile.Close
Forget our Windows PowerShell users? The Scripting Guys would never do that. Well, OK, actually we did forget you. But we did remember to come up with this one-line script, which returns all the cmdlet names and then writes them to C:\Scripts\Scripting.dic:
Get-Command | Foreach-Object `
{Add-Content c:\scripts\scripting.dic -value `
$_.Name}
The nice thing about this month’s column is that we all learned something. You learned how to create custom dictionaries in Microsoft Word and how to programmatically configure Word to use those custom dictionaries. And the Scripting Guys learned that if you want something done, well, it’s still way better to try and get someone else to do it for you. But if all else fails, you can always do it yourself.

The Microsoft Scripting Guys work for—well, are employed by—Microsoft. When not playing/coaching/watching baseball (and various other activities), they run the TechNet Script Center. Check it out at www.scriptingguys.com.


 The Desktop Files: How Not to Lose Your Data
The Desktop Files
How Not to Lose Your Data
Wes Miller

Information yearns to be free. It doesn’t matter who you entrust it to or how hard you try to lock down those zeros and ones, they will always find the hole in the stack. Every day the news has reports of both minor and significant data losses. It’s ridiculous that important data is lost
so often, but the reality is that information is lost because people simply fail to protect it.
A year ago, I outlined "Ten Security Rules to Live By". In this column, I’d like to focus specifically on steps you can take to secure your data. It’s rarely a simple task. The bigger your organization, the harder these steps are to complete. You’ll need to devote a significant amount of effort to these tasks; a large organization has the most to lose when critical data is compromised.
The truth is that data—customer or internal—should be treated in much the same way as you would handle medical waste. It should be:
  1. Handled with extreme care
  2. Stored and transported cautiously
  3. Not compromised during any step of the process
  4. Disposed of incredibly carefully
By following all of the safeguards I outline here, you will be well on your way to securing your data during its entire lifecycle.

Don’t Count on Policies or People
Many have referred to people as Layer 8 in the OSI (Open Systems Interconnection) model and in many ways, they are. Regrettably they are often the weakest link. Both your technically strongest and weakest users are always the ones poking at the edges of any infrastructure policy. The same holds true for data security. You should absolutely never rely on a policy as a key aspect of data security. People will break the policy—whether intentionally or inadvertently. You must put countermeasures in place in order to ensure that if the policy is compromised, the breach is properly logged or digital countermeasures will ensure that the data is not compromised.
The USB flash drive (UFD) is a device revered by the computing masses and much feared by many in the IT management world. The risk of data theft using UFDs is significant. But if you find yourself worrying that your data will just be walking out the door every time you see a UFD, then your data is not secure enough to begin with. CD-R media, Windows® PE boot CDs, network shares, and other small media types are all threats, and the truth is that if you are fighting piecemeal against a variety of media formats, you are probably fighting a losing battle. Don’t secure systems at the end of the pipeline where people connect to your infrastructure. Secure the data from the beginning. Of course you can’t secure everything, but the average organization can do much more than it is doing now.
Make protecting data a significant part of your work environment. Enforce the idea that everyone in your organization must treat data carefully. Only send e-mail messages and share documents that specifically say "OK to forward" and don’t disclose anything that should not be disclosed. As an IT professional, it’s your job to teach and enforce that behavior.

Limit Information Disclosure
With the prevalence of mobile computing, mobile devices need even more data security. If your organization deals primarily with Microsoft® Office documents, you should investigate Microsoft Office Information Rights Management (IRM) and Windows Rights Management Service (RMS) for your RMS-enabled Windows-based apps. With these technologies in place, users can only access data for which they have predetermined rights.
So often, e-mail marked "confidential" leaks out of the organization because someone thought the message significant enough to send on to a colleague, who then did the same. Figure 1 shows the message alerting the user to restricted content in Microsoft Outlook®, thanks to RMS.
Figure 1 Restricted permissions in e-mail
Figure 1 Restricted permissions in e-mail
Although RMS hasn’t completely alleviated the problem, it has made distributing restricted content far more difficult. A user who really wants to "liberate" RMS or other encrypted/secured data can still do so. Even if you securely encrypt your data, never forget "the analog hole"—the acquisition of sensitive data through nondigital means such as the capturing of information displayed on a monitor simply by using a camera. Even in a world with the new protected path in Windows Vista™, which guards data secured with Digital Rights Management (DRM) through to presentation on the screen, there is still a risk of data loss through analog means.
Pay attention to the actual machines where your data is stored. Should you really have a confidential customer database on a laptop or right at the front desk at your office? Such information should really be available only on a physically secured server (or desktop) located in a private area of the office, ideally stored in a tightly secured datacenter without a direct connection to the Internet. Here in Austin, Texas a laptop containing customer data was recently stolen from a local company. The laptop held patient medical data, Social Security numbers, and birthdates—all the key data points you’d need to steal someone’s identity. So why on earth was information this important stored on a poorly secured laptop? It should have been only available via a secure fat-client or Web application or on a server accessible via a Terminal Services or Citrix client. In an organization that should be following the HIPAA statute, the loss of data this significant is huge.

Password Integrity
Usually, the password is the final security barrier. Unfortunately, users left to their own devices will cycle through passwords, reuse roots of already weak passwords, limit the complexity so they can remember them more easily, and even write them down in conspicuous places.
It’s very important that you establish password integrity measures, as well as two-factor authentication—measures that require a combination of password and another mechanism, such as a smart card, that results in authentication integrity even if the password itself is compromised.
Whether or not you employ multi-factor authentication, password integrity should be enforced using the following techniques:
  • Limit the maximum duration of all user passwords, but use your judgment regarding this length of time. If the duration is too short, users will either forget their passwords or bypass security by writing them down. If it is set too long, the whole reason behind changing them at all becomes moot. Do not use the "Password Never Expires" option for any interactive account.
  • Enforce password length and complexity so that users aren’t short-circuiting your security with weak passwords like the one in Figure 2. Don’t enforce integrity to the point that a user cannot remember the password, unless you are using multi-factor authentication. Otherwise, they’ll use the sticky-note method to remember passwords.
  • Keep a password history—don’t let users recycle passwords they’ve already memorized and used for months.
  • Prevent brute-force password attacks by limiting the number of failed attempts before an account lockout.
  • Most importantly, educate your users about the significance of their credentials.
Figure 2 Poor password choice, even if you love your mother
Figure 2 Poor password choice, even if you love your mother
Password integrity and local authentication are critical but, of course, the data on the local system should still not be data you can’t afford to compromise unless it’s physically secured or encrypted. Passwords alone aren’t the solution. A user’s password is but a tool to ensure that attackers who want to compromise the direct interactive access to the system and aren’t willing to bring in tools cannot do so.

Physical Security
Critical data shouldn’t reside on a system that can be physically compromised or removed from the office. If you have systems that you are afraid might be compromised when someone boots into Windows PE and retrieves data, you have other problems; Windows PE is not the culprit. Instead, one or more of the following are true. Your systems are not properly physically secured. They’re secured, but you don’t trust the users who have access to them, your data is on a system that is not (or cannot be) physically secured, or the systems cannot be physically secured and you have not used volume encryption tools, such as the BitLocker™ feature in Windows Vista, to mitigate against physical compromise. (For more about BitLocker, see Byron Hynes’s article in this issue of TechNet Magazine.)
Think about which of your systems may be at risk. Can you physically secure them? Why not place them in a datacenter or some other area that has limited access? If that’s not possible, or if it’s a mobile system, do you use volume encryption software? If you can’t take any of these steps, either move the data to a system that can be secured or encrypt it. In the case of the stolen laptop previously mentioned, if the volume had been encrypted with a secure volume encryption tool, the data would have been almost completely safe from compromise.
Just because a system lives in a datacenter doesn’t mean it’s secure; if you’ve got a bunch of T1s out to the Internet, you’re still at risk. Internet access gets the bad guys one step closer to physical access, so carefully consider the threats posed against your systems. Consider moving them onto a separate segment of your network where you’ve at least got another level of network protection between the Internet and the systems being analyzed.

Data Risk Mitigation
Another security measure available to you is to give users access via applications or thin-client tools that isolate the data to a physically secure server. This may mean providing access via a VPN so users who are off-site can gain access. You should never let a user’s physical constraints dictate how data should be treated. Just because a user needs access, and he is in a location where broadband or other high-speed access is not available, doesn’t mean you should just move the data to a local instance on the user’s machine. If you absolutely cannot move the system and must keep it in an insecure location, again, secure the data using volume encryption.

In-System Security
You should be prepared for the possibility that, despite all your best efforts, someone will break into your system by removing the hard disk and placing it into another Windows system where the NTFS ACLs can be reset.
To prepare for this, use the volume encryption included with Windows Vista. For most other versions of Windows, there are many third-party tools available. They vary in complexity of use, as well as in their ability to perform full-volume encryption and/or encryption of individual files or directories as Encrypting File System (EFS) permits. If the volume is encrypted, the data will be protected against all but the most advanced thief.

Archival Security
Backup data must also be secured. Most people give two reasons for not backing-up their systems securely: encrypting at backup time takes too long and/or their backup software doesn’t support it.
But if you are backing up systems, and especially if you are following the best practice of taking the backups off-site, you must secure the data going into the backups. Either encrypt the data using EFS, if it’s available, or other volume encryption software (such as the BitLocker feature in Windows Vista or other third-party software), or purchase backup software that includes encryption capabilities and performs at an acceptable level. Just because data is somewhat obfuscated on a backup tape or chopped up in a disk-based backup solution doesn’t make it safe. Assume the transport mechanism itself will be compromised.

Transmission Security
You must secure any data that is transported over the wire. Only use secure protocols to access the remote system. Use encrypted versions of protocols and always assume a man-in-the-middle (MITM) attack is probable. Don’t use weakly encrypted or unencrypted protocols, and if using encryption, don’t use a weak encryption length or algorithm. You or someone in your organization needs to understand all of the communication protocols and encryption algorithms being used inter-system in your infrastructure.

Secure Deletion
We’ve all heard stories of hard disks or other storage devices bought from eBay or the local flea market that were subjected to forensic software or even ordinary undelete utilities, thus revealing dark secrets—data that should have been wiped out completely before the drives were sold.
If you have UFDs in your organization, consider forced encryption utilities. Disks that contain high-risk data should be encrypted. Despite popular belief, I don’t agree that simply encrypting volumes before disposal is a safe way to dispose of disks. Remember that medical waste metaphor I mentioned earlier? Regard the data on these systems as hazardous waste, and secure data deletion utilities as the treatment. Use a data deletion tool that implements the DoD 5220.22-M specification, like Mark Russinovich’s SDelete before releasing your disks and systems back into the wild for resale, or even before moving them around within your organization. Otherwise the next user becomes privy to all of the previous user’s data.

Auditing
Last but not least, another key component of data security is auditing, and even threat-modeling, the lifecycle of data in your organization. Understand the weak points where your data can be leaked and watch those points carefully. Windows provides several built-in auditing tools. With auditing, however, you can easily run into data overflow. Make sure that you’re watching the right areas and that you are not being overrun with data. Watch for weak points and fill them in properly with good mitigation—don’t spackle the data dam with hacks. Also ensure that your users are properly educated about how to treat data. They are the critical link at so many levels in your organization. You’ll find more guidance in the "Additional Resources" sidebar. Don’t forget to follow all the suggestions outlined here; you’ll sleep better at night if you do.
Additional Resources
"The Core Infrastructure Optimization Implementer Resource Guide—Basic to Standardized" will show you how to move your IT infrastructure from a highly manual and reactive basic level to a standardized level with more automation, enforced configuration standards, and improved operations. Download the guide at go.microsoft.com/?linkid=5795711. "Additional Infrastructure Optimization Implementer Resource Guides" can be found at microsoft.com/io. Also see the article "The 10 Immutable Laws of Security" for more security tips.

Wes Miller is a Development Manager at Pluck (www.pluck.com) in Austin, Texas. Previously, he worked at Winternals Software in Austin and at Microsoft as a Program Manager and Product Manager for Windows. Wes can be reached at technet@getwired.com.


 Field Notes: Talk to Your Developers
Field Notes
Talk to Your Developers
David Aiken

Jonathan is a developer. He builds software. He builds great software. Well, it’s great when run on his machine. But when he loads it onto another machine, something happens. Suddenly, someone’s saying the software is not so great. The administrators want it to do things and wonder why it doesn’t. Then they want to fix it and make it work. Then they complain that they cannot fix it because they cannot understand why it doesn’t work. That, they tell Jonathan, is his fault.
Now don’t get me wrong, Jonathan likes to be helpful. So helpful that he doesn’t mind taking the time to explain what the XML-encoded stack trace means or how to spot that the tracking GUID is missing and how to fix it. But for some reason administrators look at him as if he were speaking another language.
Strange, but developers see software differently from administrators. Developers work with code, traces, XML configuration files, GUIDs and assemblies. Administrators work with scripts and Microsoft® Management Console (MMC) snap-ins (at least they’d like to).
In fact, let’s take a step back. It seems to me some days that the whole software development process is broken. We spend lots and lots of resources figuring out what the end user wants. We build prototypes, conduct usability studies, interviews, and whatever else, yet when it comes to providing a simple, consistent management experience, we fall short. We fall very short.
I used to think that Xcopy, Regedit and Notepad were the best ways to install software. Now I know it’s a Microsoft Installer (MSI) that can be customized, installed, and uninstalled. I know that expecting an administrator to configure a Web service using Notepad to edit XML is probably not the brightest idea, and an MMC snap-in (or a Windows PowerShell™ script) is by far a better choice. I know that a stack trace is not helpful to a user or administrator in conveying the root cause and possible solutions to a problem, and that a well-written event to the application logs is better. I know that in order to build software that can be managed and operated by administrators, I need to treat them as users.
With an administrator as a user, I can define use cases, build prototypes, conduct usability studies, and so forth. This will enable me to provide the best possible experience for administrators. In other words, it will help them install, configure, monitor, troubleshoot, and fix my software without having to call me. If I use the management capabilities built into the operating system that they are familiar with, I can significantly lower the cost of running my application (fewer problem escalations), improve customer satisfaction (the application is down less often and they can fix problems quickly), and increase the chances they will buy more of my software and not yours (resulting in a sweet boat in the Caribbean).
OK, the boat is a dream. But getting developers to build more manageable applications isn’t merely a dream, it’s an achievable goal. And you can help too. Next time something goes wrong, don’t just forward the e-mail message and call them names under your breath. Instead, suggest that they write an event to the application log or provide a performance counter or some other indication of the problem. Even better, suggest a possible cause and resolution. Ask them to build you a Windows PowerShell script or MMC console to configure the application. The thing is, developers don’t always know you exist, let alone what your needs are. Tell them.

David Aiken is an Architect Evangelist working for Windows Server Evangelism at Microsoft. His role is to promote and evangelize the Dynamic’s System Initiative (DSI) with an emphasis on Designing Applications for Operations.


 Windows Confidential: What New Users See on the Start Menu
Windows Confidential
What New Users See on the Start Menu
Raymond Chen

In my last column, I looked at how Windows® determines which applications appear on the list of frequently used programs that you see on your Start menu. But why do new users have stuff on their Start menu when they haven’t run anything yet? (If you need to catch up, my last column is online at technetmagazine.com/issues/2007/05.)
In the initial designs for the Start menu, we planned for the list of frequently used programs to be completely empty the first time you opened the Start menu. You hadn’t run any programs yet, so nothing was frequently used—indeed nothing had been used at all! While this was perfectly logical, it also looked completely stupid.
Imagine the disappointment of people who just bought a computer. They unpack it, plug everything in, turn it on, and everything starts up smoothly. Great! Then they open the Start menu to begin using their new computer and what do they see but a big blank white space. They’re not sure of what to do next. And they’re thinking, "This computer can’t do anything! I should have bought a Mac." In usability terminology, this is called the cliff. The learning curve has become a precipice.
We thought about filling this initially blank Start menu with text. Something like "Hey, sure, this space is blank right now, but as you run programs, they will show up here, trust me." The space no longer looked stupid. Now it looked stupid and ugly.
It took a bit more experimenting, but we ultimately decided upon what you see in Windows XP. Last month you saw that the list of frequently used programs is based on a points system—the programs with the most points appear on this dynamic list. For brand new users, we’ve given some artificial points to various programs. As a result, the initial Start menu presents a sampling of fun programs to give users some idea of what they can do.
The number of artificial points is carefully chosen so that there are enough points to get the desired programs onto the list of frequently used programs, but not so many points that they overwhelm the real points earned by programs as users launch apps.
However, these artificial points were not given if the user upgraded from Windows 2000. In that case, the points that the Windows 2000 Start menu used for Intellimenus were used to seed the Windows XP point system. In that way, the Start menu for an upgraded installation of Windows XP reflected the programs that the user ran most often on Windows 2000 right off the bat.
In the initial release of Windows XP, the artificial points were assigned so that the first three of the six slots on the most frequently used programs list were chosen by Windows and the last three by the computer manufacturer. If you bought a retail, rather than preinstalled, copy of Windows XP, then Windows filled two of those three slots and left the last slot blank. That way, the very first program you ran would immediately show up on the Start menu.
These six slots underwent some twiddling in Windows XP Service Pack 1. Two of the slots were chosen by Windows, one by the United States Department of Justice, and the last three by the computer manufacturer. As before, if you bought your copy of Windows XP at retail, then two of the computer manufacturer slots were assigned by Windows and the last was left blank.
The Start menu is one of the most visible parts of the Windows user interface, and as you can see, a lot of work goes into trying to make it feel natural and intuitive.

Raymond Chen’s Web site, The Old New Thing, and identically titled book (Addison-Wesley, 2007) deal with Windows history and Win32 programming. His seat cushion can be used as a flotation device.


 Letters: Answers to Your Questions
Letters Answers to Your Questions
Getting Started with Windows PE
After reading Wes Miller’s article "Getting Started with Windows PE" in the September 2006 issue of TechNet Magazine, I created a menu with the HTML for Applications (HTA)-based wizard. I have several questions regarding getting the menu to work with Windows® PE 2.0.
—Andy

Here are your questions and Wes’s answers to each:

How do I know if the optional software components HTA and Windows Script Host (WSH) are running from my ISO file?
If you installed optional components in your ISO file according to the instructions provided by the documentation, they should work. I’ve heard of two common scenarios where they don’t: if you didn’t run peimg /prep to prep the image, or if you didn’t use the /commit parameter with ImageX to actually commit the changes to the Windows PE image when dismounting it.

Do I need to have Windows Management Instrumentation (WMI) installed? The wizard files from the article give me an Internet Explorer® error.
The wizard files should work as long as HTAs are installed; they’re very rudimentary. WMI is not only not required for them, I actually wrote them before you could add WMI to Windows PE.

How should I include OC.bat in my startnet.cmd file?
You don’t need to use OC.bat at all if you’re using Windows PE 2.0—it is required for 1.x only. Windows PE 2.0 allows you to add components without using the shimming that OC.bat did.

Can I use some of Wes’s code in my menu once I’ve got it all working?
Feel free to take any of the code samples and reuse them as you desire, but you may not resell or redistribute them as part of a sample code package. See the licensing agreement on the TechNet Magazine Web site for more details.

Where is Windows PE?
Where can I find the Windows PE Build Tools? Can I download them or do I have to buy them?
—Franklin
The Windows PE Build Tools for Windows Vista™ are part of the Windows Automated Installation Kit (WAIK). You’ll find that download at go.microsoft.com/fwlink/?LinkId=85377.
The WAIK is for the Windows Vista family of operating systems only. For deployment of Windows XP, many similar tools are available in the Business Desktop Deployment Solution Accelerator. However, licensing for Windows PE has changed with Windows Vista. Before (for Windows XP), Windows PE was available only through Software Assurance licensing (see microsoft.com/licensing/sa/benefits/winpe.mspx for more details).

File Server Resource Manager
Will the File Server Resource Manager package be made available publicly for download to use on the original release of Windows Server® 2003? Or is this package only compatible with the R2 release?
—Dan
The File Server Resource Manager is a feature of Windows Server 2003 R2. Due to dependencies in that version, there are no plans to make it available for prior releases at this time.

Inside the Kernel
After reading Mark Russinovich’s article "Inside the Windows Vista Kernel: Part 3", I have two questions. First, I notice that Process Explorer shows where exe or DLL files are randomly located on each boot session. Is it possible that malware could use the same mechanism to determine the location of code it wanted to exploit? Second, if there are 256 positions where randomization can start (if I understand the article correctly), what’s to prevent malware "brute force" probing if the target code stays static for the session.
—Joe

Mark has answers to all your questions:

Process Explorer demonstrates a chicken-and-egg situation: the malware can’t figure out where the DLLs are because it can’t figure out where the API is located that returns that information. Malware "brute force" probing is not a reliable injection method, because if the malware guesses wrong it most likely crashes the app it’s trying to infect. At the minimum, randomization will slow a virus’s spread. In the best case, it will prevent the malware from infecting a system.

Contact Us
Got something to say? Don’t be shy! We love to hear from our readers. E-mail us at tnmag@microsoft.com.