Chris Sanders

Network security has gotten to a point where it can no longer be an afterthought. Every application you implement, every device you install, and every user you create must be done so with the utmost security in mind. In a world where technology is integrated into every facet of our lives we must do everything we can from a technical standpoint to ensure the integrity of the technology we rely on. Waiting for a problem to happen and then responding to it is something that can’t continue to happen if we hope to persist in securing our networks. If we ever hope to achieve a consistent level of network security it must be thought of as a proactive concept rather than a reactive one.

With these thoughts in mind, over the course of the next few weeks I am going to be releasing a series of brief articles here regarding proactive security. These are measures that you can take in order to possibly prevent future security issues on your network. This will cover a broad scope of both technical solutions as well as company policies that you can implement in order to achieve a more proactive state of though in regards to network security.

I have several of these articles already lined up for publishing. As always however, I love to hear of things you are doing on your network that would fit into the category of proactive security. If you have anything you would like to see on this site please send it to me at chris@chrissanders.org. You will be given full credit on the site for your contribution as well as a link back to your website if you have one.

I have just co-written and article with Mitch Tulloch for O’Reillys WindowsDevCenter.com website on the implementation of mandatory roaming profiles and their best practices. You can view this article by clicking here or you can see it directly from the front page of http://www.windowsdevcenter.com.

One of the things I have come to notice in my dealings with making images is that the Microsoft Sysprep utility is sometimes not as flexible as you need it to be. In my case for example, I like to run fully automated installations. However, I want the person pushing the image to be prompted to enter a computer name during the mini-setup process. This is so that after the image has been pushed, you don’t have to deal with renaming the computer and then joining it to the domain.

The current problem is that when you do a fully automated installation you can either specify a computer name or allow sysprep to generate one automatically. Neither of these options provide the solution I am wanting. What I have determined to be the best route is to go ahead and specify a computer name with the scheme that I plan on using. For instance, “GCHS-LAB-”, where the dash would typically followed by a number which specifies each individual computer in the lab.

The trick to this is to open the sysprep file back up after you have finished creating it with setup manager and finding the field that specifies the computer name to be used. When you find this area, simply put a asterisk at the end of the computer name. This will effectively make the name specified to use for the image “GCHS-LAB-*”. The thing you may recognize about this character is that it is not supported for use in a computer name. This being the case, the mini-setup will give an error about this when it is running. From here you can simply click ok, give the computer the name you want it to have, and click next and the mini-setup will complete.

There has been some recent discussion as to how to use Ghost to clone a machine running Windows Vista. I have tested this myself and found that doing a straight up ghost image push without any switches will not work. However, if you add the -fpsd switch to ghost.exe when pulling and pushing your image it will work like a charm. The -fpsd switch actually preserves the signature bytes on the hard disk rather than clearing them out. The clearing of these signature bytes is what causes Vista to go haywire when you try to clone it. I would imagine Symantec will clear this up in the v1.2 release of the Ghost Solution Suite. If you do have problems with this whatever you do don’t contact Symantec technical support. Windows Vista is not by any means supported by them yet.

If you are having problems getting a client computer to connect back to the Ghost Console, one of the first things you will want to do is to go to the client and look at the debug window. To do this, perform the following steps:

1. Login to a computer that has the Ghost Console Client installed
2. Hold down the Ctrl key
3. Slowly move your mouse cursor to the upper left hand side of the screen
4. This will cause a new ghost icon to be displayed in the system tray. Right click this and choose “Show Debug

This will bring up a DOS style screen that shows the communication between the client and the console server. Given this information, you can move on to your next step in the troubleshooting process.

User profile management can be a complete nightmare for a network administrator. There are literally dozens of ways to manage profiles based on the needs of your particular organization or department. One of the most complicated scenarios to properly administer is a typical lab environment in which you do not want user profiles to be modified at all. Through the use of mandatory profiles this type of profile administration becomes much easier.
For this example we will examine a typical University Campus. This small campus has one hundred computers spread across various labs. These are all Windows XP machines connected to a Windows 2003 domain. These computers are used by students to do research, type papers, and perform various other coursework. Along with these computers there are a total of 2000 students who each have their own unique user account. Our goal is to present each and every student user with the same profile settings, and disregard all profile changes when a user logs out so that they are presented with the same profile as everyone else when they log back in.

Step 1: Setting up the Base Profile
The first thing you will want to do is setup a model profile on a workstation (preferably an identical one to the workstations in the lab) that will serve as the profile that everyone sees when they log into a computer. Here you will want to make sure you have configured all desktop settings, shortcut icons, and installed printers correctly as to how they will appear on all other workstations.

Step 2: Copying the Profile to a Server
Once you have your profile setup how you want it, the next step is to copy the profile to a server. It is important that you set the permissions on the folder holding the profile so that all users accessing it will have complete read and write access to it. Once setup the workstations will pull each user profile from this location. In order to properly copy this profile to a server you will complete the following steps:

1. Login as a user other than the one you used to make your model profile
2. Right click “My Computer” and click “Properties”
3. Click the “Advanced” tab
4. Click “Profiles”
5. Select your model profile and click the “Copy to” button
6. Browse to the location you want to store the profile at
7. Click “Change” under “Permitted to Use” near the bottom of the window and add the “Authenticated Users” group
8. Click “OK”
9. Exit out of any dialog boxes that may remain open.

Step 3: Making the Profile Mandatory
The next step in creating your profile is the actual process of making it mandatory and therefore unchangeable.

1. Browse to the location of your saved profile on the server and locate the NTUSER.dat file (make sure hidden files are set to be visible)
2. Rename this file to NTUSER.man

Step 4: Configuring the User Accounts

1. Open Active Directory Users and Computers and browse to the location of the user or group of users you wish to assign a mandatory profile to
2. Right click the user or group of users and click “Properties”
3. Click on the “Profile” tab
4. In the “Profile Path” box type the UNC path to the folder where the mandatory profile is located
5. Click “OK”Exit Active Directory Users and Computers

With those steps completed you have successfully setup mandatory profiles for your student population. You may now reap the benefits of having a central location to store all of your user profiles so that they can be modified with ease. This also provides a great layer of additional security for your network. Mandatory profiles can also be extended upon greatly with the use of Group Policy, which is something that I would highly recommend looking into.

In my experience with Ghost I often run across an error stating that an internal inconsistency has been found when trying to a do a basic hard drive clone. The problem normally occurs at the beginning of the hard drive clone when Ghost begins to check the hard drive directory structure. Another symptom of this problem can be found in the Ghosterr.txt file generated. In this file you will notice that in most cases when recieving this error, Ghost reports the computer has having less RAM than it actually has. The most common scenerio is the error file showing only 16MB of RAM on a computer that has 128MB or more.

My primary solution to fixing this has always been to run the good ol’ KillDisk utility on it. The downside to this is that a KillDisk can take anywhere from 20-30 minutes on a 40 GB hard drive. After doing some more researching I found that ghost generates this error due to a problem with the way the program caches certain things. Symantec reccomends using the -ws- and -wd- switches when executing the ghost program to resolve this issue, which I have found, works like a charm.

Example:
Ghost.exe -ws- -wd-

Also, Symantec mentioned that this error can also occur often when doing disk clones from images that have an unusually large number of files and directories. This issue has to do with the standard Ghost version of PC-DOS running out of memory when indexing everything. The solution proposed for this by them is to use MS-DOS files instead.

I have been focusing a lot of my efforts at the office lately to implementing our new IAS/Certificate based wireless security strategy. In doing this, one task I needed to complete was to set the Dial-In properties of the wireless client computers via the Dial-In tab in the Active Directory Users and Computers MMC snap-in. Needless to say, I was quite shocked when I went to make these changes, and I didn’t even have a Dial-In tab. After quite a bit of googling I found the problem lied in the version of the Windows Server 2003 Adminpak that I was running. There was apparently a new release of the Adminpak for Windows 2003 Server SP1 and without the new version, a few tabs will be missing. The Adminpak is MUST HAVE resource for anybody who manages a Windows Server 2003 network. You can download the Adminpak here.

Typically printer installation is done in the enterprise via login scripts that are based on usernames. This works fine in most cases, however, I recently began looking into a better way to do this.

The problem with installing printers based on usernames is that on a given day a teacher or student can log into as many as three or four different computers in various locations throughout a school. With this being the situation, we could for instance map the printer “GCHS-MATHLAB” to a student active directory account, but then when the student walks into the business lab, he will still be printing to the math lab. The obvious reaction to this would be to setup a script that installs all avaliable printers in the building for the student, however this creates an unneccesary security risk, and would allow students to print into room they are not located in which could cause trouble.

My first instinct for a solution was to install printers based on the active directory organizational unit by pushing a machine startup script. This would work perfectly as our active directory is for the most part organized by a computers physical location in a school. A machine startup script which can be found in the group policy editor under Computer ConfigurationWindows SettingsScriptsStartup is different from a login script as it is run on the target machine before a user even logs into a computer. After creating a GPO with my printer installation script set as a startup script I linked the GPO to a test OU where I began my testing. Unfortunatly, this setup didn’t seem to want to work. When the computers in the OU would boot up I would recieve a message stating the access was denied to add the printer. I knew that the problem was not with permissions accessing the script, because the error it gave me was actually on the 5th line of the script, so I know it was getting appropriate access to the file. The line it gave me the error on was the actual line that connected to and installed the printer. Sure enough, the “domain computers” group was added to the specific printers ACL, so that wasn’t the issue either. I had eventually determined that the issue with installing the printer this way was by design in windows as printers are typically managed in a user based context rather than a machine based one.

After a week or so of more research, I was about to give up when I stumbled upon some Microsoft documentation regarding something called Loopback Processing. In using loopback processing, you define settings for the User Configuration context of the group policy editor. After you finish setting these policies, browse to Computer ConfigurationAdministrative TemplatesSystemGroup Policy and select the policy called “User Group Policy Loopback Processing Mode”. Once you enable this policy you have two options to choose from. The first option is the “Merge” mode, which processes all user configuration policies as if they were machine policies AFTER whatever machine configuration policies that already exist are applied. The “Replace” mode however, does not process existing machine configuration policies, and only executes the user configuration policies. With this knowledge in hand I configured my printer installation script as a login script for group policy user configration, enabled user loopback processing merge mode, and sure enough, it worked like a charm.

A week or so removed from the discovery of loopback processing mode, I have found several other uses for it. I am actually considering changing site based drive mappings from being mapped via user defined scripts to being mapped via a group policy invoked script in order to avoid issues with teachers and faculty who roam among various schools in the district. I am also currently expiramenting with extending Mandatory user profiles via user loopback processing, so be sure to check back for my findings on that.

For more information regarding loopback processing, see the related Microsoft KB# 231287