Installing the Servers

You considered all the options, selected the proper configurations, and are now ready to install the servers, thereby introducing the next phase in securing Windows 2000 servers. Before you put the CD-ROM in the server and start booting the machine, consider the following:

■ Make sure that you have all the necessary software, the correct versions, and corresponding licenses.

■ Make sure that the servers you have are complete and diagnostically working.

■ Define an Active Directory (AD) structure, first deciding if the BizTalk environment will have its own domain, or will be part of an existing domain. Let's assume you make a special BizTalk domain, with its own AD forest.You need a server that will become the domain controller (DC), so you must install an additional server for this purpose. If your AD structure contains security vulnerabilities, you run the risk that someone who "hijacks" one server can use these vulnerabilities to gain control over other servers. Adding a server to an AD domain has many advantages over installing it as a stand-alone server.

■ Check Microsoft TechNet for possible "Known Issues" before starting the installation.

■ Check the website of the server manufacturer for known issues with the firmware and device drivers, and download the latest Windows 2000 certified versions. Note that the latest version of drivers are not always certified, so only get those that are W2K certified.

■ Make sure all the servers have access to the Internet, so you can confirm that you have applied all available updates, and because many Microsoft products need to be activated after installation.

■ Make an installation plan and protocol. The plan describes the sequence in which you want to install the servers. My suggestion is to go one by one or by cluster; finish the complete installation, do thorough testing, make a full backup, and go on to the next server. The protocol is the checklist of what you have to install and in what sequence. Do not install Windows 2000 components if the server does not need them. Be extra careful with components such as Windows Scripting Host (WSH) and Collaboration Data Objects (CDO), as these can be a recipe for disaster if your server is compromised. For example, e-mail viruses such as "ILOVEYOU" could only run on systems with these components installed.

■ Make a logbook of every server, starting with the installation.This is not the most fun part of system administration, but it might hold valuable information in case you run into problems further down the road.

■ After each step in the installation process, check the event log for possible errors. In case there are unexpected errors, be sure to fix them before continuing.

■ In case of load balancing or clustering, test to make sure everything is working properly. The setting up and configuring of a cluster with, for example, SQL Server 2000, can be tricky.Therefore, make sure you test that the active server fails over correctly.

■ Set up your BizTalk environment tier by tier. Make sure that communication between servers works correctly.

The last step in securing server configurations is the one we can call access restriction. Much can be said about securing the Windows platform, so much so that you could write a complete book about it.This chapter only touches on several of these aspects, so for more in-depth information you can read Hack Proofing Windows 2000 Server (ISBN 1-931836-49-3), also from Syngress Publishing. As you read under "Roles and Access Levels," your main targets are to:

■ Limit the users who have direct access to the server.

■ Restrict users' access to only those parts of the server they need.

■ Limit access to the lowest access rights possible.

Warning_

The sequence in which you install software can be crucial for the proper working of your system. History has shown that certain applications install different versions of DLL files over existing ones without asking, or they may ask "Replace with a newer version?" implying that you should answer "Yes." The result is often that an application that had been working without a flaw suddenly ceases to do so. This is the reason that on Windows NT 4 systems, the service packs had to be reinstalled after you installed a new piece of software.

Much like we did with the firewall, begin by disallowing access to the server altogether, and then add groups and users to the system one by one.Within Windows 2000, the security of users, groups, and computers are managed through different tools. Instead of using these separate management tools, you can group them using Microsoft Management Console (MMC) shown in Figure 8.2. To do so:

2. Within MMC, go to Console | Add/Remove Snap-in____

4. A list of available snap-ins is shown in Figure 8.3. Select an appropriate snap-in, press Add..., and choose any others you will need.

5. Now press Close, and when you get back in the Add/Remove Snap-in dialog press OK.

6. Save the console through Console | Save or Save As____This saved

MCC configuration is added to the list of Administrative Tools.

Figure 8.2 Using the Microsoft Management Console for Security Management

Figure 8.2 Using the Microsoft Management Console for Security Management

Figure 8.3 Select the Appropriate Security Management Snap-Ins

SHU* 1 WW40. H

IBtaitKHIfip Eté* «ri ï■ i

LvTííl.--

^Xl^fAM^ iJkMI JWd r^falHiL

i^- hui r.',TL.jU,

LPJ«»-: 'Irtd

BGA«*

EM*m*

UCïlfA dW 'rMri'i!

tttiç®! LL'L-Uim

4 _ ■ Hvifi ■ iiv

i*»:*

MdûUÉ r ijJ-J m Ci i

ÍMniMSri^nHi j

Vrt. -iVf Jtai. ltiJi KApftlû

Vrt. -iVf Jtai. ltiJi KApftlû

k Jitjf lúfWt. Hdlkra

It is virtually impossible to give you all the details on securing your BizTalk servers in one chapter. Nevertheless, here are some practical recommendations on configuring Windows 2000 security that you can use as pointers in establishing a more secure configuration:

■ Never use anonymous logons, not even on the IIS server. Each person who needs access to a server has to log on with his or her own account.

■ Use group policies to maintain control over the computer and user configuration of a group.

■ Remove any type of application on the production servers that can influence the BizTalk runtime environment or easily modify BizTalk files. Be careful with the WHS component!

■ Make sure that you can trace the use of the system through the event log.You can control the auditing settings in Group Policy.We recommend that you turn on as much auditing as possible during the first month of production.This first month is the life "shake down" of the system, and the event log can provide you with a wealth of information. After this initial period, you can reduce the level of editing. Be sure to analyze the event logs on a daily basis, and after analyzing them, make a backup copy.

■ Create an account for every BizTalk Server-related service.This account has some differences in user rights from that of an interactive user.These specific user rights for the service account should negate the rights of the interactive user.To do so:

1. Enable Act as part of the operating system.

2. Disable Deny logon as a service.

3. Disable Shutdown the system.

Defuse the system/domain-managed group "Everyone." Everyone is a group that roams around your system and can be granted access to parts of your server without you knowing it.The best approach is to take all the rights away from Everyone.You do this in two areas. First, eliminate any risks in accessing sites by adding Everyone explicitly to the Security list and allow them read-only access. Second, check all COM+ applications and remove Everyone from the user list of the roles (see the section "Securing XLANG Schedules" later in the chapter).

Do not use the Administrator account. Instead, make an identifiable account with administrator rights for every employee who needs administrator access. Sharing administrative accounts makes it harder to trace system-related issues.

■ Do not use REGEDIT.EXE, but rather use the administrative tools. Registry values can be reset when you install additional system software, or apply a service pack or security patch. Of course, there are times when you have no choice but to use REGEDIT. Before doing so, make certain that this is necessary and if there is no other way to accomplish the same. If you do so, enter these changes in the logbook, and make before and after copies of the Registry's subtree.

Safeguarding Installations

As mentioned earlier, it is a good practice to make backups of your system after installation. It would be even better to make a full system backup every few weeks and after every significant configuration change. Backups are a safety net in the event something goes terribly wrong, like a burned-out server.The system you put on tape never represents the exact situation at the moment the system fails. Again, here is where the logbook comes into play. Other points of attention include:

■ Never store tapes in or close to the computer room; in case of disaster, you might not be able to retrieve the tapes.

■ Always put tapes directly into the data vault after the backup.

■ Periodically test the tapes to confirm that you can restore the data from tape.

■ Periodically perform a full restore of a server.

■ Replace tape cartridges after a year to lower the risk of read/write failures due to reuse of the tapes.

Proactive Maintenance

BizTalk solutions can be very important to an organization, and their availability is expected to be high.This is only possible if the system administration focuses on preventing disruptions and problems. As we have seen, this is very different from being ready to solve problems.

The chance that a component in your server will fail increases with the age of the component. Replacing components in business-critical servers, such as the ones that make up your BizTalk infrastructure, after a fixed period makes good sense. For example, you should replace hard disks after two years. This does not mean that you should throw them away! They can still be very useful in less critical systems, or you can sell them to a refurbisher. Alternatively, you can use heuristic management tools to monitor the server components and warn you of forthcoming failures.

Another sensible task is to take a server offline once every year, open it up, and clean the inside. Dust and lint can clog the ventilation and fans, and can cause static discharges that can destroy the CPU, memory, or the entire motherboard.

Proactive maintenance is also about keeping things structured and organized; for example, being able to find your way around documentation, logbooks, and computer rooms. Computer rooms can sometimes give the impression that a bomb went off inside, with cable bundles that look more like spaghetti on a plate, seemingly starting somewhere and going nowhere. Organized and labeled cables are a good protection from the wrong cable being detached.

Was this article helpful?

0 0

Post a comment