A Remote Installation Service (RIS) server has been configured so that it allows clients to use either a RIS boot disk or a boot PROM-enabled NIC to attach to the server and install Windows 2000 Professional off of an image file that’s stored there. At first glance, it might seem that RIS is a fairly harmless service and that a RIS Server wouldn’t really need any security settings above those used on any other server. But nothing could be further from the truth. Both piracy and security concerns mandate that you know how to secure your RIS server.

Why should I care about RIS security?
The first reason for securing a RIS Server is to prevent software piracy. This one isn’t as much of a problem now under Windows XP activation, but imagine this pre-Windows XP scenario: An employee gets a new computer loaded with Windows Me. However, he thinks it would be cool to have Windows 2000 instead. He sneaks into the office in the middle of the night and uses the RIS Server to install Windows 2000 onto his new machine. Your company’s software identification key has just been used on pirated software.

Preventing that type of theft isn’t the only reason for securing RIS. You want to ensure that you have very tight control over RIS so that you know exactly how many Windows 2000 Professional licenses have been used. Remember, each license costs your company money.

And then there’s the issue of security. If someone is able to use your RIS Server to install Windows onto an unauthorized PC, that PC’s registry will contain a lot of sensitive information about your network. The person could then take the unauthorized PC home and begin studying the registry for clues that would allow him to break into your network.

Prestaging a client
The first step to achieving overall RIS Security is to understand the importance of client prestaging. Any time you set up a computer on a domain, whether manually or by using RIS, you must create a computer account object within Active Directory as a part of the process. Normally, when clients use RIS to install an operating system, the procedure involves either:

  • Using an account with administrative privileges to do the installation.
  • Giving users who will be performing installs the authority to create computer account objects within a specific organizational unit.

However, these techniques are inherently insecure or inconvenient. After all, what’s the point of having an automated setup process if the administrator still has to go to each individual PC, log in, and begin the process? Besides, if you’ve got a bunch of PCs logged in as the Administrator while loading Windows, what’s to stop someone from breaking the installation process and exploiting the Administrator account, since it’s already logged in?

Likewise, what’s to stop a user to whom you’ve delegated account creation authority from exploiting this privilege for unethical purposes? Sure, it saves the administrator time, but is it really worth the risk?

Prestaging solves both these problems. When prestaging clients, you can create the computer account object ahead of time, and you can even tell Windows which RIS server should handle this particular installation request. Being able to designate a specific RIS Server for an individual computer is also good from a load-balancing standpoint if you’ve got a large number of computers that need Windows installed.

To prestage a client, open the Active Directory Users And Computers console on the RIS server. When the console opens, right-click on the organizational unit or the container that will hold the new computer account object, and then select New | Computer commands from the resulting shortcut menus. Windows will display the New Object – Computer dialog box, shown in Figure A.

Figure A
The New Object – Computer dialog box allows you to begin configuring the prestaging process.

As you can see in the figure, the dialog box asks for a computer name, but also asks for a pre-Windows 2000 computer name. It also includes a check box that allows pre-Windows 2000 computers to use the account. In the context of RIS, this legacy compatibility can actually act as a security mechanism in disguise. Since you’re creating a computer account object that will be used by a RIS Server, you can rest assured that the computer using the account will be running Windows 2000 (RIS Server supports only Windows 2000 Professional clients). Therefore, there’s no reason to select the check box or to enter a pre-2000 computer name. By not allowing pre-Windows 2000 computers to use the account, you reduce the chances of the computer account object being exploited by an unauthorized user.

After clicking Next to continue, you’ll see a screen that asks if the machine is a managed computer. Since security is your goal, go ahead and select the This Is A Managed Computer check box. After doing so, you’ll be asked to enter the computer’s unique ID. This could be a GUID, otherwise known as a UUID.

Finding a machine’s GUID can be a little tricky–it could be printed on a label on the side of the computer, it could be printed on the inside of the computer, or it could exist within the system’s BIOS.

The GUID follows a very specific format. It is expressed in hexadecimal numbers within specific positions, bound by brackets. Since hexadecimal is in use, a GUID consists of the letters A through F and the numbers zero through nine. An example of a valid GUID would be {92FB9741-ED42-11BE-BACD-00AA0057B223}. When entering the GUID, you must use this exact format or the process won’t work. You can see an example of this in Figure B.

Figure B
Be sure to enter the GUID in exactly this format.

After entering the GUID, you’ll see a screen asking if you’d like for any available RIS Server to handle the request, or if you’d like to use a specific RIS Server. The chances of someone setting up a rogue RIS Server on your network are pretty slim, but if you are the paranoid type, or if you have different installation images stored on different RIS Servers, you may want to use this feature. If you do designate a specific RIS Server for the operation, just make sure that you enter the RIS Server name by its fully qualified DNS host name. If you aren’t sure of a server’s fully qualified domain name, you can use the Browse option to help you select the server.

After selecting the RIS Server, click the Next button and you’ll see a summary of the options you’ve chosen. Review this summary carefully, because if you’ve made any typos the process will not work. If you discover any typographical errors, you can use the back button to correct them. Otherwise, click Finish to complete the prestaging process.

Verifying the prestaging
If you’ve prestaged a lot of computers, or if you’re having problems with RIS, you might want to run a verification process to see which clients have been prestaged. You can run a prestage verification either across the entire Active Directory or for a specific domain. Checking a specific domain is generally more efficient, but checking the prestaging for the entire Active Directory can be revealing.

I once had some trouble prestaging clients, and the clients didn’t show up when I tried to verify them, so I redid the prestaging and everything was fine. Months later, I did a prestage verification for the entire Active Directory only to find that months before, I had prestaged a bunch of clients to the wrong organizational unit.

To verify the prestaging, return to the Active Directory Users And Computers console. Now locate the RIS Server that you want to check within the Active Directory tree. Right-click on the server and select the Properties command from the resulting shortcut menu. When the server’s properties sheet appears, select the Remote Install tab and then click the Show Clients button. When you do, you’ll see the dialog box shown in Figure C.

Figure C
The Find Remote Installation Clients dialog box allows you to verify prestaging.

A few aspects of this dialog box probably need some explanation. First, you’ll notice at the top of the dialog box that there’s an option to find Remote Installation computers. You shouldn’t ever have to touch this option. Next is a drop-down list that allows you to select your search space. By default, the entire Active Directory is searched.

Beneath these options is the main search area. You can search on GUID name, but the only required element in this area is the server name. You might have noticed in Figure C that my server name was followed by an asterisk. The asterisk, which is treated as a wildcard, is not mandatory, but you should always use it as a timesaving tactic. Having an asterisk after the server name tells the search to find all prestaged clients on the specified server. If you had entered a GUID, you’d still need the asterisk to tell the search to look for all prestaged clients on this server that match this GUID.

Although the asterisk is a requirement, using it does have some strange side effects. For example, in Figure C, you might have noticed that I was using a server named Yogi. If I had servers named Yogi2, Yogi3, or Yogi_Bear, they would also be queried. The asterisk tells the query not only to query all users on the server, but also to query all servers whose names begin with the string of characters preceding the asterisk.

Another thing that you might have noticed in Figure C is that no computers are listed in the prestaging area. The reason for this is that when I created my prestaged computer, I specified that any RIS server should be able to handle the computer. Since no RIS server was specifically designated, the client won’t show up in the prestaging area, even if you simply designate an asterisk as the server name, which is legal, by the way.

Setting permissions for creating computer accounts
Earlier, I explained that you probably didn’t want users to have carte blanche permission to create computer account objects within the domain. However, users must be able to create objects to perform the installation process. The catch is that there is a big difference in granting users permissions to create computer account objects and granting users permission to create computer account objects based on prestaging.

If you want to grant users rights to create computer accounts for prestaged computers, open the Active Directory Users And Computers console. Select the Users | Groups | Computers as Containers command from the console’s View menu. You must then select the Advanced Features option from the console’s View menu.

At this point, right-click on the client computer that you intend to install and select the Properties command from the resulting shortcut menu. When you see the computer’s properties sheet, select the Security tab and click the Add button. In the resulting dialog box, select the users or groups to whom you want to give permissions to create the computer account for the prestaged client. Click OK to return to the Security tab. Now, select the users or groups that you’ve designated and then select the Read, Write, Change, and Reset Password check boxes in the Allow column of the Permissions box. Finally, click OK.

Granting users permissions to create normal computer accounts
If the whole prestaging process seems like overkill, you can grant users permissions to create normal computer accounts for computers that haven’t been prestaged. To do so, open Active Directory Users And Computers console and right-click on the domain in which you plan to create the computer accounts. Select the Delegate Control command from the resulting shortcut menu to launch the Delegation Of Control Wizard. It’s important that you perform this step at the domain level rather than at the organizational unit level. Now, just follow the wizard’s prompts to grant the Join A Computer To A Domain task to the appropriate users or groups.

Joining computers to a domain
Depending on how you’ve configured your RIS Server and which method you’ve used for setting up clients, you may have to join the computer account objects that you’ve created to a domain as a part of the installation process. To do so, go to Active Directory Users And Computers. If you need to apply this permission at the domain level, you can right-click on the domain and choose the Delegate Control option from the shortcut menu to launch the Delegation Of Control Wizard. Use the wizard to delegate the task of Joining A Computer To The Domain.

If, on the other hand, you need to delegate the permission at the organizational unit level, right-click on the OU in question and select the Properties command to access the OU’s properties sheet. Select the Group Policy tab, select the OU’s primary group policy from the list of available policies, and click the Edit button to open the Group Policy Editor.

Now you must modify the group policy in a way that will allow the designated users or groups to add computers to the domain. The required group policy setting is found in the group policy tree under Windows Settings\Security Settings\Local Policies\User Rights Assignments. The actual policy object name is Add Workstations To Domain.

Unlike many of the other staging-related tasks that I’ve explained, this part of the process only needs to be done once rather than each time you add new workstations.

Don’t take any unnecessary RISks
RIS can be a very useful tool for deploying new clients on your network, but at the same time, it can also present security risks. As long as you take a little time on the front end to set proper security in Active Directory, you can help minimize those risks. It may be a hassle at first, but in the long run, it will save you time and your organization, money.