Designing Security for a Backup and Recovery Strategy

We ve probably all heard horror stories about companies (or individuals) that failed to back up their data and suffered the consequences. For many individuals, the loss of data is an inconvenience, although rarely a serious one. For companies whose businesses depend on the data stored on network computers, the consequences can be severe. Still, many companies, particularly smaller ones, have inadequate backup and recovery strategies. Backing server files up to tape and storing the tape in the desk drawer hardly constitutes a secure backup and recovery strategy, yet that s just what takes place in many companies.

Backing up and restoring data is your failsafe option ”when all else fails, you rely on backups to restore your systems and network to their operational states. The task of backing up data can enhance security in an organization. If you think of security in broad terms such as ensuring authorized users have access to needed data and protecting network data and services, you can easily see that the very act of backing up and restoring a system is a fundamental security task. In this section, we ll look at designing a secure strategy for backup and recovery. You ll find these kinds of questions on the exam and you ll certainly want to use this information on the job.

Securing the Backup and Restore Process

How many companies do you know of that perform regular backups and then store the media onsite? How many companies do you know of that perform regular backups but never test them? It s surprising how many companies do some, but not all, of the right tasks , leaving themselves exposed to potentially devastating data losses. The downtime for systems, loss of productivity for users, and the cost of recovering lost data (or worse , losing it entirely and being forced to recreate documents and information) is enormous when compared with relatively small time, effort, and cost of establishing a sound backup and recovery plan.

In this section, we ll look at the backup and restore process. We ll take a look at best practices and how to best secure the backup and restore process to ensure your systems. Backups and restores are essential elements in a security process since they represent the failsafe option ”after data is lost, after a virus has hit, after an operating system has been disabled ”that s when you need to be absolutely sure your data is secure via reliable backup and restore strategies. It s not a matter of if something will happen, it s a matter of how quickly and effectively you can respond when something does happen.

Currently, 60 to 70 percent of a company s data storage management efforts are associated with backup and recovery functions, according to Phil Goodwin, a senior program director at the Meta Group , an IT industry research and consulting firm. Most companies today use tape backup systems for both current backup and archival backups. A growing trend is the use of offsite storage locations. With the use of encryption and high-speed connections, a firm s data can be safely backed up to an offsite storage facility. This provides another layer of protection because the data is stored at a physically separate location and provides the ability to access the stored data at any time. The downside is that it is still not practical for a company with massive amounts of data to use this type of solution, and it introduces another security risk that must be managed.

Another growing trend is the use of disk-based systems. As the price of disk drives has come down, some companies have found using mirrored sets is a good solution. A mirrored disk contains an exact copy of the live disk at any given time. If one drive fails, the other can be placed in service immediately and often transparently . Disk clustering is another option that allows data to be stored across multiple drives. The downside of both these solutions is that the drives reside onsite. If there s a fire in the computer room or a theft of computers, the data is gone unless it has also been backed up. This sometimes entails using tape backup as a secondary recovery method.

Disk-based backups are becoming more common as declining disk costs drives the growth of disk-based backup appliances. A separate disk-based backup appliance can store network data and, because it is typically located away from servers on the network, can provide some additional security from the servers. However, if it is located onsite, it is still vulnerable to sitewide problems such as flooding or fire and it might be vulnerable to attack as well. It requires that disk data be transmitted across the network, so it might also require the use of additional security and data encryption, which could have a negative impact on network performance.

Some companies use co-location to have their data stored both on their site and mirrored at another site. This is often done for load-balancing purposes for Internet-accessible resources such as e-commerce sites that have servers around the country or globe in order to improve response times. In these configurations, data is replicated among these sites, often on a real-time basis. If one site fails due to site or connectivity issues, the other sites automatically pick up the slack . Once the failed site comes back online, the data is replicated to that site and it comes back into service.

The solution you select for your company will depend on a number of variables , including your company s size , relative importance of computers, data and the network in your business, your budget, and your company s risks relative to the costs of data loss. A solid backup and recovery plan is your best insurance against downtime and catastrophic data loss for the enterprise.

Remember, too, that disaster planning is part of the larger business continuity planning activity and should be incorporated into the corporate planning process. When IT disaster planning is viewed as a stand-alone departmental project, there might be serious gaps in the plan that could be addressed by a companywide disaster recovery planning process.

Table 9.8 outlines practices that will help ensure your data is safe regardless of any problem that might occur.

Table 9.8: Safeguarding Your Systems



Best practices

Follow best practices for security, backups, and restores. Secure computers in access controlled locations.

Specify what you want the computer to do if it stops unexpectedly.

In Control Panel under System on the Advanced tab, you can specify what you want the system to do during startup or recovery. Figure 9.44 shows these options found by clicking the Settings button in the Startup and Recovery section on the Advanced tab of System Properties in Control Panel.


Perform regular backups and follow best practices for backups to ensure security of data and backup media.

Create Automated System Recovery (ASR) backup set.

Use the ASR Wizard to create a backup of the system state and other critical configuration and system files.

Keep the installation CD accessible but safe from a malicious user .

You ll need the installation CD to recovery from a system failure using Recovery Console or the ASR set. Make sure the installation CD is accessible but secured. For example, leaving it in your desk drawer is not a good idea, but locking it in bank vault isn t a great idea either. Find a balance between accessibility and security.

Install the Recovery Console for x-86-based systems.

You might want to install the Recovery Console for x-86-based systems to assist with system failure recovery.

Review and test backup and recovery plans.

As you ll see in this section, good safeguards include creating backup and recovery plans and testing those plans on a regular, periodic basis to ensure each element of the plan works as expected.

Reduce single points of failure.

Finding and reducing single points of failure, especially related to disk devices, can reduce the likelihood of failure and improve recovery time after a failure.

click to expand
Figure 9.44: Startup and Recovery Options for Local Computer via Control Panel

Designing a Secure Backup Process

A secure backup process includes planning the backup process, storing backup media, and assigning (and monitoring) backup and restore rights. The process of backing up files is an opportunity for a malicious user to make a copy of important data files and take them to a computer on which he or she has administrative rights and restore the data to his or her own computer. Therefore, the process of planning and implementing the backup process requires consideration of the security aspects along with everything else.

Planning the backup process requires that you think about where computers are located, where users store their data, and how often data should be backed up. Are servers located in one room, or across the state, country, or world? Are servers locally administered, or are servers administered remotely? How often does critical data change, and how often should you back up data files and system state data? Where are backup devices located and what s the best method for backing data up to these devices? Who s in charge of backing up the data? How will you know if it s been completed successfully? These and many other questions should be asked and answered during the planning phase to ensure that the data remains safe. A good security plan, while delineating possible attacks and desired defense methods , should also include how to recover after an attack or system device failure.

As a quick refresher, you probably remember that backups can be full, incremental, differential, copy, daily, or normal. Each is briefly described here:

  • Copy Copies files but does not mark them as having been backed up.

  • Daily Copies all selected files that have been modified on the day of the daily backup.

  • Differential Copies all files that have been created or changed since the last normal or incremental backup was performed. Files are not marked as having been backed up.

  • Incremental Copies all files that have been created or changed since the last normal or incremental backup was performed. Files are marked as having been backed up.

  • Normal Copies all files you select and marks each as having been backed up.

Backing up files using incremental or differential backup methods can be faster, but requires the use of backup sets to fully restore a system. For example, if a system crashed, you would need the last normal backup set as well as every incremental (or differential) set created since the last normal backup was created. If you perform a normal backup every Sunday night and a system crashes on Saturday afternoon, you would need last Sunday s normal backup along with the incremental (or differential) backup from Monday, Tuesday, Wednesday, Thursday, and Friday. Although you save time each night during your backup process, you ll spend more time recovering. Conversely, if you perform a normal backup on a more frequent (or even daily) basis, you ll spend more time in the backup process but your recovery process will be fairly short. You ll need to review your company s situation to determine the best solution for you.

Another critical element of designing a secure backup process is giving thought to who should perform the backups. In highly secure environments, only members of the Administrators group should be given backup and restore rights. In medium- or low-risk environments, backup and restore rights can be assigned to different individuals. If one person has permission to back up but not the permissions to restore, the likelihood of malicious users gaining unauthorized access to data is reduced. While a malicious user could take the backups and restore them to a machine to which he or she has administrative rights, it is less dangerous than giving that person backup and restore permissions. Trusted staff can perform backups and restores and they should be fully trained in such procedures to ensure that they can perform their tasks unaided, if needed.

Finally, backup media must be secured. Using multiple sets allows for backups to be stored offsite. This can help in terms of safeguarding the media from fire or flooding, but makes the media less accessible in case there is the need to restore. For example, if you decide to store your media in a bank vault, you are out of luck if you need to restore from backup media in the middle of the night or on a Sunday when the bank is closed. As an alternative, you can use data storage companies ”both offline and online. These carry their own risks, including placing your valuable data in someone else s hands. Some companies compromise and keep the latest backup onsite, and the second or third most recent backup in an offsite location. This way, if you need to restore, the worst case is that you ll have to restore from a backup that is a few days old that you retrieve from your offsite location. You must assess the pros and cons of such a plan and decide which is the best blend of security and convenience for your company given its unique risk profile.

Best Practices for Backups

A number of practices, when properly implemented, can create a secure method of backing up data. Table 9.9 summarizes these best practices.

Table 9.9: Best Practices for Backups

Backup Best Practice


Develop backup and restore plans and test them.

Without a plan, it will be difficult to know if your all data is safe. Planning on when, where, and how backups are performed and data stored will help you recover more quickly if disaster does strike.

Train personnel on backup and restore procedures.

Depending on security needs, you can train staff (users who are not Administrators) to perform backups and restores. For minimum and medium security situations, train one person (or group) to perform backups and train a separate person (or group) to perform restores. Grant privileges for either backup or restore to separate these tasks to maintain some security. For high-security networks, only assign these permissions and tasks to members of the Administrator group. Train those with backup or restore rights thoroughly so these tasks are performed correctly.

Back up all data on system and boot volumes and the system state.

Backing up all data and the system state at the same time provides an accurate snap shot of the system, making restoring from backup easier in the event of a disk failure. The system state is not backed up along with disk data unless specifically selected. If the computer on which the backups are performed is a DC, the system state data will include the Active Directory database, SYSVOL directory. For all servers, system state data includes certificates. For servers and member computers, system state data includes the Registry, system files, boot files, and files under Windows File Protection.

Create an Automated System Recovery (ASR) backup set.

Always create an Automated System Recovery (ASR) backup set whenever there are any changes to the system, including changes to the operating system, applications, hardware, drivers, or the application of patches and service packs . Having a current ASR can make recovering from a system failure much easier and faster.

Create a backup log.

Always opt to create a backup log, and then print and file the log. This will make it easier to find specific files later if the drive or system fails. The backup log is also helpful when restoring systems, especially if there are any problems during the recovery process such as failure of a backup medium.

Retain copies.

Some companies rotate between two backup sets, the one used yesterday and the one that will be used today. While this might be less confusing and more economical, it does not provide solid backup. Three sets should be the minimum, with one set stored offsite at a secure location.

Perform test restores.

Many companies do a great job backing up but never test their restore functions. The worst time to find out that your backups aren t working properly is when you re trying to restore after a disk failure. Periodically test your backups by restoring data with those backups. A test restore can also uncover hardware or software problems that might not appear when you simply verify the backup.

Use the default volume shadow copy backup.

A volume shadow copy is a duplicate copy of the original disk contents taken at the time the copy (backup) began . If you disable this feature, files that are open or are being used by the system will be skipped during the backup process, leaving you with an incomplete backup.

Secure devices and media.

Both the storage device (tape drive, etc.) and the storage media (tapes, disks, etc.) should be secured. If someone gains access to backup devices and/or media, he or she could simply use the device and the backups on a computer on which he or she has administrative privileges.

Back up the server cluster effectively.

In the event of an application data or quorum loss, individual node or complete cluster failure, you should ensure you have:

Performed ASR backup on each node in the cluster.

Backed up the cluster disks from each node.

Backed up each individual application running on the nodes.

Creating an Automated System Recovery Backup Set

To safeguard against catastrophic failure, you should create an Automated System Recovery backup set , and update the ASR every time a significant change occurs on the system. Significant changes include adding or removing applications or software, installing/removing or modifying drivers or hardware, or replacing components . You can use the Automated System Recovery Wizard, which will create two-part backups you can use to recover you system after other attempts have failed or after you ve replaced a disk drive. ASR backs up the system state, including disk volumes, Active Directory, and other critical components. It also creates a startup disk that provides information about disk configuration, and how to perform the restore. We ll step through this process in Exercise 9.09.

Exercise 9.09: Creating an Automatic System Recovery Backup Set
start example

In this exercise, you ll create an ASR backup set for your system. To perform this task, you must be a member of the Administrator group or Backup Operators group on the local computer, or you must have been delegated the proper authority. You will need a blank 1.44MB floppy disk, as well as media to hold your data files.

  1. Click Start All Programs Accessories System Tools Backup .

  2. Click Next on the Welcome screen of the Backup or Restore Wizard .

  3. You can choose to either Back up files and settings or Restore files and settings . Back up files and settings is selected by default. Click Next to continue.

  4. In the What to Back Up screen, you can select to back up All information on this computer or Let me choose what to back up . If you select Let me choose what to back up , the next screen will allow you to select which items you want from a list of all items on the computer. For this exercise, choose the default, All information on this computer .

  5. The next screen is Backup Type, Destination, and Name . In this screen, you can select your backup type, choose the destination to which files should be saved, and give a unique name to the backup for easy identification later. Once you ve specified these parameters, click Next .

  6. The final screen of the Backup or Restore Wizard verifies the backup settings you ve selected. If you want to modify these settings, click Back . If you want to access Advanced settings, click Advanced . Advanced settings include:

    • The ability to select Normal, Incremental, Differential, Copy, or Daily types of backups.

    • Whether to back up files that have migrated to Remote Storage.

    • Whether to use verification, compression, or disable volume shadow copy (discussed earlier).

    • Whether to overwrite data or append data and whether to restrict access to the data.

    • Whether you want to schedule the backup to occur now or at another time.

  7. To begin backups, click Finish . If you do not want to start the backup, you can either select Cancel or click Advanced to schedule the backup for another time.

  8. The backup file will be saved with the .BKF extension in the location you specified.

end example

This backup will only back up files necessary to restore your system to a functional state; you ll need to back up data files separately. After you create the ASR set, perform a data backup and keep the ASR set and the backup media together and labeled as a set. To use the backup media, you ll need to use the floppy disk created as part of the ASR set. You cannot use a floppy belonging to an ASR set created at a different time. You must also have your Setup CD available at the time you perform Automated System Recovery (the recovery, not the backup).

If your system does not have a floppy disk, you can copy the asr.sif and asrpnp.sif files from the % systemroot %\repair directory to another computer, but you must then copy those files onto a floppy disk. Before you can restore a computer using ASR, you must install a floppy drive.

Exam Warning  

You won t be specifically tested on the elements of best practices ”you won t see questions asking which element is or is not a best practice. Instead, you ll see questions in which the correct answer relies on best practices and the wrong answers do not. This can be subtle, so when looking for correct answers on the exam, consider whether the answer falls into best practices. If not, you know the answer is probably incorrect.

Disaster Recovery Best Practices

Disaster recovery includes creating backups, creating recovery options, and using repair and recovery tools. There are several practices that, if implemented, can significantly improve your disaster recovery preparedness and security. We all know that disks crash, viruses infect , and data corruption occurs due to intentional and unintentional acts. Trying to anticipate problems and planning for them is always the first step in any disaster recovery process. Table 9.10 summarizes these best practices.

Table 9.10: Disaster Recovery Best Practices

Best Practice


Create a plan for performing regular backup operations.

Although we already covered best practices for backups, it bears repeating here. If you do backups occasionally, you ll lose significantly more time and data than if you perform regular backups. Depending on the nature of your company and its data, you might find that backups every few hours or twice a day are required to avoid significant data loss. For many businesses, daily backups are a good balance between the need to secure data and the actual process of performing the backups.

Keep the installation CD where you can quickly and easily find it.

In some cases, you can recover a system by using the installation CD and the Recovery Console or Automated System Recovery. We ll discuss each of these later in this chapter. However, some people mistakenly think that securing the installation CD off-site or in an access-controlled location to which they do not have free access is a good idea. Always make sure the installation CD is readily available, although keeping it in a secure location onsite is certainly advisable.

Use Emergency Management Services, if applicable .

This is a new feature in Windows Server 2003. With Emergency Management Services, you can remotely manage a server in emergency situations that would normally require local access to keyboard, mouse, and monitor, such as when the network is unavailable or the server is not working properly. There are specific hardware requirements for Emergency Management Services, and it can be used only for Windows Server 2003 computers. We ll discuss this later in the chapter.

Install (and secure) the Recovery Console as a startup option.

If you are running a computer based on the Intel x-86 chip, you can install the Recovery Console in the event you are unable to restart Windows. You cannot install the Recovery Console on an Itanium-based computer. We ll look at this in this later in this section.

Specify startup and recovery options.

You can configure the computer to take specific actions if the computer stops unexpectedly. For example, you can configure it so that your computer restarts automatically and generates a log file. We ll look at this later in this section as well.

start sidebar
Head of the Class
In-Band and Out-of- Band Management

In the next section, as well as in other discussions of server management, you might hear or read about in-band management and out-of-band management. Let s take a look at these briefly.

In-band refers to two computers that can connect using normal network services. It relies on a standard network such as the LAN or the Internet. You can use standard management tools such as Remote Desktop or Telnet to manage the computer because it is online and working properly. You are able to communicate in a normal fashion with this remote computer via the established connection. This is called in-band management or an in-band connection .

In-band connections are available only when the computer is fully initialized and functioning properly. The typical in-band remote management hardware device is the network adapter, although an Integrated Services Digital Network (ISDN) or analog modem can be used as the in-band remote management hardware device. Some of the tools available in Windows Server 2003 to manage in-band connections are the MMC, Systems Management Server, Telnet, Terminal Services Remote Desktop for Administration, and the Windows Management Instrumentation (WMI). There are also numerous non-Microsoft in-band management tools available on the market.

Out-of-band refers to a connection that can be made when a remote computer is not working properly. When you are unable to manage the server via an in-band connection, the ideal alternative is to be able to manage the server through a reliable alternate connection called an out-of-band connection. An out-of-band connection does not rely on network drivers to function properly as an in-band connection does. Using special hardware or firmware, you can manage a remote server that is disabled or not functioning using an out-of-band connection.

Out-of-band connections can be useful if:

  • The computer is turned off.

  • The server is not functioning properly because of a Stop message event,.

  • The BIOS power-on self test (POST) test is running.

  • The server is low on resources.

  • The network stack is malfunctioning.

  • An operating system component has failed (including failure of the Recovery Console, discussed later in this section).

  • The server is not yet fully initialized.

    As you can see, having a reliable out-of-band method of managing a remote server can be very useful in many different scenarios.

    For out-of-band connections, the hardware device is most commonly the serial port for several reasons. First, most x-86 servers have at least one serial port. Second, serial ports are simple, reliable ports that provide a flexible solution since serial port communication standards are well established and supported across all operating systems.

    Now that you understand the in-band and out-of-band management systems for Windows Server 2003, let s take a look at Emergency Management Services, which relies on out-of-band connections.

end sidebar

Securing Emergency Management Services

Emergency Management Services is a new feature in Windows Server 2003, and provides native support for server operation and management that can be performed remotely without a local keyboard, mouse, or monitor. It can be used on x-86 and Itanium-based systems.

Emergency Management Services uses a terminal text mode rather than a graphical user interface (GUI). This provides the ability to manage computers that are not fully functional or not fully initialized. It also provides interoperability with other platforms, including UNIX. Emergency Management Services are typically available during all phases of computer startup, including when the computer is turned on, when firmware is initializing, when the operating system is loading, and when other elements (GUI, for example) are loading or when any of these elements runs into problems.

There are three key features in Emergency Management Services that we ll discuss here:

  • Console redirection

  • Special Administration Console (SAC) environment

  • !Special Administration Console (!SAC) environment

Console Redirection

Console redirection is the process whereby a computer receives keyboard input from a remote computer and responds with output to the remote computer s monitor using an in-band or out-of-band connection. A computer can be controlled by both in-band and out-of-band connections at the same time. Emergency Management Services output is available using a terminal emulator. If a computer is configured with Emergency Management Services, the following computer services will redirect their output to the out-of-band management port and to the video card, if one is present:

  • Setup loader

  • Text-mode Setup

  • Recovery Console

  • Remote Installation Services

  • Stop error messages

  • Loader

Console redirection uses a text display mode for compatibility. Character mode (rather than a graphical user interface) is more compatible with serial ports and slower connections. Character mode is what you use when you open a command prompt in Windows Server 2003 by clicking Start Run cmd . In addition to hardware compatibility, character mode is also a more flexible option across software platforms. Character mode is a basic mode and is supported by Windows as well as by non-Microsoft operating systems, including UNIX.

There are essentially three ways console redirection can occur under Windows Server 2003. The computer for which console redirection is desired can have specialized firmware or hardware install that support console redirection, or it can use Windows components such as Ntldr via Emergency Management Services.

Firmware Console Redirection

System firmware that supports console redirection can be used with Windows Server 2003 and with Emergency Management Services. For x-86-based systems, the Basic Input Output System (BIOS) can support console redirection. On Itanium-based systems, the extensible firmware interface (EFI) supports console redirection. The EFI on Itanium-based systems supports console redirection by default, but you might need a firmware upgrade for x-86-based systems before console redirection can be implemented. Once available, console redirection can be used in four specific ways, summarized in Table 9.11.

Table 9.11: Firmware Console Redirection

Management Task


Remotely view startup process.

You can monitor the progress of the Power On Self Test (POST), disk error messages, and other messages displayed by the firmware during the startup process. A computer using firmware console redirection typically can complete the POST process without an attached keyboard, mouse, or monitor.

Remotely view and edit firmware settings.

You can remotely access the configuration program via the firmware to make changes such as changing the boot order or disabling an integrated hardware device. Without this firmware functionality, you would have to make these changes at the local computer.

Remotely view and respond to Pre-Boot eXecution Environment (PXE) prompts.

If the firmware supports the PXE standard, you can remotely view and respond to the F12 network boot prompt.

Remotely view and respond to the boot from CD prompt.

With the firmware console redirection capability, you can remotely respond to the prompt Press Any Key to Boot From CD when starting the server from the Windows Server operating system CD.

Service Processor Console Redirection

A server that contains specialized hardware can also support console redirection. This component is called a service processor and supports a range of activities, including console redirection. Since a service processor is a hardware component, you should consult the service processor documentation to understand the features of the particular hardware component installed. Service processors are typically integrated into the motherboard or into a PCI adapter. Since Emergency Management Services requires that the Windows loader or kernel be at least somewhat functional, a service processor that can respond when the remote computer is completely unresponsive might be useful in some scenarios. In cases where the Windows loader or kernel is completely disabled, a service processor can still respond because it operates independently of the computer s processor(s) and the operating system. Service processors contain their own firmware and can respond with console redirection and other functions even when the operating system is disabled. Most service processors use the serial port or RJ-45 Ethernet port for out-of-band connections. If the out-of-band connection used is a serial port, you can only use one tool at a time. This means that you can either use the service processor or the Emergency Management Services, but not both at the same time.

Windows Console Redirection

Windows contains services that support console redirection as well. The Ntldr component of Windows supports console redirection and can be used with Emergency Management Services. If Emergency Management Services is enabled when Windows Server 2003 initializes, the operating system takes over the responsibility for console redirection from the firmware. The ability to redirect console output is built into several Windows components, summarized in Table 9.12.

Table 9.12: Windows Components that Support Console Redirection

Windows Component


Windows loader for x-86-based systems ( Ntldr )

When Ntldr is running, you can remotely view or select the Recovery Console. On x-86- based systems with a multiboot option, you can select which operating system to boot.

Windows kernel ( Ntoskrnl.exe )

The kernel is the core of the Windows operating system. Code that runs as part of the kernel can directly access hardware devices and system data. As a result, the Windows kernel can redirect console output so you can remotely view normal system operations or view Stop message text when a problem occurs.

Recovery console

The Recovery Console is a command-line utility that allows you to perform advanced troubleshooting and maintenance, such as disabling a device or driver you suspect is causing problems during the boot process.

Command prompt ( cmd.exe )

A character mode user interface for running commands and applications.

Text-mode Setup (including the CD-ROM Setup loader)

Early in the Windows installation process, the system is in text mode when files are being copied from the distribution source to the local hard drive. at 9600 baud for x-86-based computers

Starts the x-86-based Remote Installation Services (RIS) process. The file is downloaded and run by the RIS client to initiate operating system installation. Special versions of the program that use 9600 baud are required to support Emergency Management Services console redirection.

Special Administration Console Environment

The Special Administration Console (SAC) is the primary Emergency Management Services command-line environment. As a kernel mode component, SAC provides out-of-band management functionality when Windows runs in GUI mode. You can use SAC to manage the server during normal operations, in safe mode, and in the GUI phase of Windows Server 2003 startup. Once you ve enabled Emergency Management Services, SAC is always available as long as the kernel is functional. Using SAC during an operating system upgrade or installation, though, might cause the upgrade or installation to become unstable or fail.

SAC is not secured by password and logon requirements. As such, physical access to computers running Emergency Management Services must be restricted. We ll discuss securing Emergency Management Services in a moment.

SAC provides a number of commands that you can use to perform remote management tasks, including:

  • Restarting or shutting down the computer.

  • Viewing a list of processes that are currently active.

  • Ending processes.

  • Setting or viewing the IP address of the computer.

  • Generating a STOP error to create a memory dump file.

  • Starting and accessing command prompts.

!Special Administration Console Environment

The !Special Administration Console (!SAC) is an abbreviated version of the SAC. !SAC accepts input from and directs output to an out-of-band connection. !SAC is a separate function from SAC and from the command prompt ( cmd.exe ). You cannot access !SAC directly as you can with SAC. Instead, if a particular point of failure occurs, Emergency Management Services transitions from SAC to !SAC automatically. For example, if the graphics driver fails or you are attempting to start in safe mode via SAC and safe mode fails to start, the Emergency Management Services will automatically revert to !SAC. Since SAC runs during normal mode, safe mode, and the GUI phase of startup, if errors or failures occur in any of these operating modes, !SAC is invoked. !SAC has a more limited set of functionality than does SAC. !SAC can:

  • Remotely view STOP message text.

  • Restart the computer.

  • View an abbreviated log of loaded drivers and some kernel events.

  • Obtain computer identification information.

Enabling Emergency Management Services

If you want to have the capability to manage a computer remotely, you would install Emergency Management Services onto that remote computer. Before you begin a CD-based Windows Server 2003 operating system setup, you must enable the computer s firmware to support console redirection (discussed in a moment). Emergency Management Services configures itself during a bootable CD installation by reading the Serial Port Console Redirection (SPCR) table. If Emergency Management Services is enabled, you are prompted at the end of text-mode Setup to allow setup to automatically configure your system without user input. You must choose this option. Otherwise, the next part of the setup, known as the GUI-mode Setup, completes only if you provide input through a local monitor and keyboard. If the computer s firmware does not support the SPCR table, you must fully automate setup.

To enable Emergency Management Services after Windows Server 2003 has been installed, you must edit the Boot.ini file to enable Windows loader console redirection and Special Administration Console. The Boot.ini file controls the system startup and is located on the system partition root. The Boot.ini file can be edited via the Bootcfg.exe command-line utility.

Headless Servers

A headless server is a computer than is configured to run without a local keyboard, mouse, or display device (typically a monitor). Emergency Management Services, with support of hardware or firmware console redirection, makes it possible to configure headless servers running Windows Server 2003. Since a computer running Emergency Management Services can use both in-band and out-of-band connections, you can manage a headless server without any local input or output devices.

Terminal Concentrators

Terminal concentrators provide remote access to multiple servers via out-of-band connections. The servers connect to serial ports on the terminal concentrators via null modem cables. A null modem cable crosses the Clear to Send (CTS) and Ready to Send (RTS) signals, emulating the process of modems communicating with one another. This type of cable is often used for direct connections on serial ports between two devices in a local connection configuration. The remote management computer establishes a connection to the terminal concentrator via its network port. Most often, you ll use Telnet or a Web interface to manage servers connected via a terminal concentrator. This provides the ability to manage several remote servers via the terminal concentrator, and allows multiple administrators to simultaneous view or manage servers remotely.

Many terminal concentrators come with built-in security functions, such as enabling the use of passwords and/or encryption. Some support Secure Shell (SSH), a secure command-line utility that is comparable to the nonsecure Telnet function. SSH provides strong in-band security, including authentication, encryption, and protection against some network-level attacks. SSH is independent of the operating system and is therefore suitable for use in a mixed operating system environment. However, not all terminal concentrators provide built-in security functions, so you ll need to consult with the vendor s documentation to see what, if any, security is provided. If the terminal concentrator provides no support for authentication and encryption, you have several options for securing out-of-band traffic, including:

  • Use a router to secure the network traffic.

  • Use SSH (if supported) rather than Telnet.

  • Use a secondary management network that you can access via direct-dial remote access or via a VPN connection.

Uninterruptible Power Supplies

Emergency Management Services works with intelligent uninterruptible power supplies (UPS) if firmware-based console redirection is supported. Many companies use the UPS capability to maintain consistent power to critical computers during times of electrical instability or failure. Electrical service can become unstable during lightning storms, for example, or during peak load times when power cycles and lights dim in response to heavy loads. A UPS can provide power in the event of a total power failure, although for most companies it is typically used for the orderly shutdown of computers rather than as a method of keeping computers running after power is off.

Some UPS units, known as intelligent UPSs , provide the ability to remotely cycle the power on a computer. By itself, this capability is limited, but it can be used in conjunction with Emergency Management Services. For Emergency Management Services systems with firmware console redirection enabled, an intelligent UPS system can extend Emergency Management Services by responding to commands sent to it. To use an intelligent UPS with Emergency Management Services, the UPS must be able to passively monitor traffic on the serial port and respond to key sequences related to UPS functions.

Securing the Remote Management Process

Although remote management is outside the scope of this chapter, it s important to understand that remote management can create a security risk. Before managing computers remotely, especially using out-of-band tools, it s important to develop a remote management plan that will ensure you use the most appropriate (and secure) remote management tools and configurations for your organization. The plan should include server configuration, server location, and server roles, as well as availability requirements and designated administrators for servers you plan to manage remotely. Addressing these elements will ensure you do not inadvertently create a security hole via remote management capabilities.

Out-of-Band Security

We ve seen how Emergency Management Services works when the computer is in various stages of startup, setup, and operation. These capabilities are an important part of disaster planning and recovery. Remote server management creates its own unique set of challenges related to security. When you manage servers remotely, information that would not normally cross the network is sent as part of the remote management function. This information might include server identification, configuration information, or other sensitive data, including usernames and passwords. If someone is sniffing or eavesdropping on the network, you must be sure this remote management data is secure. Moreover, when using out-of-band connections via serial ports, null modem connections between servers and management computers (or terminal concentrators) provide no logical security at all.

A secure remote management strategy includes setting up the following constraints:

  • Servers that allow administrative commands only from an authenticated computer.

  • Servers that accept administrative commands only from an authenticated administrator.

  • Confidential information such as usernames, passwords, and server information cannot be intercepted, read, or changed.

  • Log files are viewed by using a secure method.

While configuring security for remote management is outside the scope of this chapter, you should consider strong authentication and encryption of data, and consider implementing IPSec for traffic between the remote management server and the remote server to secure sensitive data such as server identification information and passwords as they traverse the network. It s also very important to limit physical access to both remote management servers and the remote servers. A headless remote server provides some element of security if it does not employ the use of a keyboard, mouse, or monitor. However, because the connection is typically by serial port (or sometimes a commonly used RJ-45 Ethernet connection), the physical connections should be secured and the best way to do that is to put the servers in access-controlled areas. In addition to secure areas, keeping cable lengths short prevents them from being extended outside the secured area to another computer. Finally, using terminal concentrators or intelligent UPSs to consolidate access to servers and keeping these components in access-secured areas also helps.

For logical security, ensure that you properly assign rights and permissions for computers that will be used to remotely manage other servers. Best practices suggest providing the fewest permissions to the fewest people in order to adequately perform the necessary tasks.

Best Practices for Securing Emergency Management Services

Table 9.13 summarizes best practices related to securing Emergency Management Services and out-of-band connections. Typically, in-band connections are secured via normal network security, so our focus is on out-of-band connections.

Table 9.13: Securing Emergency Management Services Out-of-Band Connections



Limit physical access to the server(s).

Place servers running Emergency Management Services in access-controlled locations.

User a terminal concentrator with security features.

If you use a terminal concentrator for accessing servers via out-of-band connections, choose one that provides security when you connect through the network.

Use service processors with well-designed security.

If you decide to use service processors in your implementation, select ones that have well-designed security. Service processors provide additional access, which creates a security risk. Ensure the service processors you use have strong security that secures the access to the server via the service processor.

If needed, set up a second network for remote management.

In some cases, it might make sense to set up a separate remote management network for all management traffic, including Emergency Management Services traffic. A separate network used with a router or firewall can add a layer of security. Only allow secure management workstations and authenticated users. Do not allow any connections to the Internet.

Exam Warning  

Emergency Management Services is a new feature in Windows Server 2003, so expect to see at least a question or two that involves using this feature. Using Emergency Management Services or the Recovery Console introduces security risks that must be addressed, so expect to see questions along that line in the exam.

Securing the Recovery Console

If safe mode and other startup options fail, you can use the Recovery Console to enable and disable services, format drives, read and write data, and perform other administrative tasks. You must use the built-in Administrator account to use the Recovery Console. There are two ways to start the Recovery Console ”from the Setup CD or from the Recovery Console boot.ini option. You cannot install the Recovery Console on an Itanium-based computer. If you install the Recovery Console on a computer, it will be an available option during the boot sequence. If you have a dual-boot or multiboot machine, you ll need to choose which installation you want to log in to, and you will need to password for the built-in Administrator account for that installation. You can invoke the Recovery Console via the Setup command-line tool, winnt32.exe , using the /cmdcons switch ( winnt32 /cmdcons ). You cannot run Winnt32.exe on an Itanium-based computer, and therefore the /cmdcons command that invokes the Recovery Console is unavailable.

The Recovery Console provides commands that you can use to do simple operations such as changing or viewing directories, as well as more complex operations such as repairing the boot sector. Typing help at the Recovery Console command prompt accesses available Help commands.

Since installing the Recovery Console essentially provides an alternate means of logging on to a computer, it creates a security risk because it bypasses many of the built-in security mechanisms in Windows Server 2003. It s important to assess and understand the security risks involved with the installation of the Recovery Console before installing it. Ideally, the computer should be in an access-controlled area to prevent unauthorized access. Basic security is enforced by requiring the use of the built-in Administrator account username (if different than the default) and password. If you enter the incorrect password three times, Recovery Console will close and the computer will restart. Recovery Console also prevents access to Program Files, Document and Settings, and other installations of the operating system. If you have alternate installations of the operating system, they will be displayed in the initial Recovery Console screen and you can select the installation that you want to work on. Otherwise, by default, you cannot access data files and other installations through Recovery Console.

There are two Group Policy options that can be used in conjunction with the Recovery Console. If you have installed the Recovery Console option, you can enable or disable these two policies:

  • Recovery console Allow automatic administrative logon.

  • Recover console Allow floppy copy and access to all drives and all folders.

These are accessed via the Group Policy snap-in or the Security Configuration and Analysis snap-in for the Local Computer in the MMC. After loading the snap-in, select the following path by expanding nodes in the left pane: Local Computer Policy Computer Configuration Windows Settings Security Settings Local Policies Security Options

The Recovery console: Allow automatic administrative logon option determines if a password for the local built-in Administrator account must be given before access to the system is granted. Clearly, if you enable this, you allow anyone to access the system via the Recovery Console. While there might be appropriate uses for this in your organization, it is important to understand that this creates a very easy way to access a system. Even if the computer is in an access-controlled location, you should not enable this unless you have a compelling reason to do so. It is disabled by default and this option is not available unless you have installed the Recovery Console. If you have not, the policy shows in Security Options but both the Enable and Disable functions are disabled (grayed out).

The Recovery console: Allow floppy copy and access to all drivers and all folders option enables the Recovery Console SET command, which allows you to set the Recovery Console environment variables listed in Table 9.14.

Table 9.14: Recovery Console Environment Variables

Environment Variables



Enables wildcard (*) support for some commands that support wildcards, such as the DEL command.


Allow access to all files and folders on the computer.


Allow files to be copies to removable media including floppy disk.


Do not prompt when overwriting an existing file.

As you can see, the environment variables you can set using the Recovery console: Allow floppy copy and access to all drives and all folders policy reads like a hacker s wish list. This option is disabled by default. Even if you have opted to Allow automatic administrative logon (bypassing the need for a password), the Administrator (or other user) would still be limited in his or her access to the system. By default, Recovery Console limits access to Program Files, and Documents and Settings, among others. However, when you enable the Allow floppy copy and access to all drives and all folders policy, you enable access to all files, all folders, allow the use of wildcards, and allow files to be copied to removable media.

Clearly, the security risk of enabling these policies must be evaluated against whatever organizational need you believe justifies enabling them. If you believe the risk outweighs the benefits, you should not enable these options. If you believe the benefit outweighs the risk and you re confident that you understand your organization s risk profile, then you can elect to enable these via the Security Policy options.

Specifying Startup Options for Computers

You can specify what actions a computer should take if it does stop unexpectedly. This is set in the computer s System properties in Control Panel. Exercise 9.10 steps you through the process of specifying startup and recovery options on the local computer.

Exercise 9.10: Configuring System for Startup and Recovery Options
start example

In this exercise, we ll step through configuring startup recovery options for the local computer.

  1. Click Start Control Panel System .

  2. In the System Properties dialog, click the Advanced tab.

  3. In the Startup and Recovery section, click Settings .

  4. In the System startup section, select Time to display recovery options when needed . Set the time, in seconds, to the length of time you want recovery options to be displayed.

  5. In the System failure section, notice that Write an event to the system log is selected but disabled, as shown in Figure 9.45. This is selected by default for Windows Server 2003 and cannot be de-selected. This option is available in Windows XP and can be enabled or disabled.

    click to expand
    Figure 9.45: Startup and Recovery Options

  6. In the System failure section, you can also select Send an administrative alert and Automatically restart , which are selected by default. Selecting Send an administrative alert causes the system to send an alert to the system administrator when a Stop error occurs. Windows uses the net send command to send the alert over the network to the system administrator. If Automatically restart is selected, the computer will restart after sending the alert.

  7. In the Write debugging information, you can select None , Small memory dump (64K) , Kernel memory dump , or Complete memory dump . Complete memory dump is selected by default. A small memory dump will provide basic information about an unexpected stop. A kernel memory dump only records kernel memory information. It is larger than a small memory dump and will take a bit more time but is faster than a complete memory dump. A complete memory dump is not available on computers with more than 2GB of RAM. If you select this option, you must have a paging file on the boot volume that is the size of the physical system RAM plus 11MB.

  8. You can specify the name and location of the dump file, which defaults to %systemroot%\memory.dmp . In addition, by default, the check box is selected to Overwrite any existing file . If you choose not to overwrite the existing file, you should occasionally delete old files so you do not take up disk space with unneeded dump files.

  9. After confirming the desired settings, click OK to accept changes or Cancel to exit. Click OK or Cancel to exit the System Properties dialog.

end example

Since a dump file contains the contents of memory at a particular point in time, it might contain sensitive data. Dump files should be secured in the same manner you secure other sensitive data, including with EFS on the local drive and with IPSec when transmitting the data across the network.

MCSE Designing Security for a Windows Server 2003 Network. Exam 70-298
MCSE Designing Security for a Windows Server 2003 Network: Exam 70-298
ISBN: 1932266550
EAN: 2147483647
Year: 2003
Pages: 122 © 2008-2017.
If you may any questions please contact us: