Сервер терминалов на windows 2000

Creating a Standard MFCF Windows Terminal Server Disk Image for
Distribution

Please be advised that this web page is intended for MFCF internal
use only. Ofcoarse, outside observation and comments are welcome however
this document is changed and updated on a regular basis as local standards
for Terminal Servers are always being revised. We thank you for your
understanding.

Table of Contents

• Introduction
• Current Versions Developed
• Nessesary Items Required for Building of Master Disk Image
• Creating the Desired System State for Cloning
  • Setup from the Windows 2000 Installation CD
  • System Modification After First Login
  • Modifications to Key Folders in the File System
  • System Security Modifications
    • System Drive (D:) and Sub-Folder Security Modifications
    • Registry Key Security Modifications
    • Network Port Security Implementations
    • Local User Groups and User Rights
  • MFCF Packages and Policies
  • Configure the Windows Time Service
  • Creating the Default User Profile
  • Some Final House Keeping
• Prepare the System for Cloning
• Copying the Master System Disk Image from the Hard Drive
• Installation of Disk Image to a Target System
• Setup of the New Terminal Server Clone

Additional Notes

• Samba (v2.2.1a) Configuration for NT Domain Membership

Introduction

Here we have recorded the hard won facts of building, cloning and distributing
a Windows 2000 Terminal Server OS based on MFCF (local) standards for software and
security.
This document begins with an outline of how to install and build the system
OS into the
desired state. Later on, this document describes how the OS may copied from
the master (development) hardware to a desired target system.

The disk image which we will eventually create will serve as a standard MFCF Windows 2000
Terminal Server installation. In having this
image, installation of such systems will be faster and uniform.
Building a typical Windows 2000 OS from its installation CD can take as
long as two hours per machine (not including applications).
During this process an installer may deviate from the desired server
design through simple mistakes and omissions.
By creating a standard disk image for terminal server type systems,
system installation is reduced to less than 15 minutes. The installer
is required to make fewer choices thus there is less oportunity for error.
The results will also
allow for easier software packaging, distribution and installation. Such
as what currently occurs with many UNIX systems managed by MFCF and IST.

Current Versions Developed

Windows 2000 Advanced Server with Terminal Services and SP2
Basic Operating System for the ACPI Processor Family
Windows 2000 Advanced Server with Terminal Services and SP2
Basic Operating System for the MPS Processor Family
Windows 2000 Standard Server with Terminal Services and SP2
Basic Operating System for the ACPI Processor Family

Nessesary Items Required for Building of Master Disk Image

• Windows 2000 Standard or Advanced Server Installation CD
• Disk Imaging Software preferably one that may be started from
  DOS, such as pqdi.
• One boot floppy disk. The DOS should be able to run the disk imaging
  software as well as have relavent drivers for the CD ROM drive. There should
  as be a compatible fdisk and format command.
• One Master Server. This system will require two separate hard drive devices,
  a floppy drive and a CD ROM drive.
• Internet access.
• To be continued…

Creating the Desired System State for Cloning

Setup from the Windows 2000 Installation CD

We begin by launching the OS installation procedure on the Windows 2000 installation CD.
Place the Windows 2000 Server Installation CD into the CD drive and reboot the server.
You will be prompted during startup if you wish to boot from the CD. Bott from the
CD. The Windows 2000 Server setup will then begin.

Disk Partitions

This image setup procedure actually requires two physical hard drives on the server
where the work is to be done. Drive Device 1 will contain the boot and system partitions
only (logical drives C: and D: respectively).
Drive Device 2 will serve as the location for recording the completed disk image prior
to it being sent to be burned on a CD ROM(s). Drive Device 2 will be formatted as a FAT32
disk since system image files must be readable in Windows 98 DOS. However do not format
or otherwise set up Drive Device 2 until the Windows 2000 OS is first installed on
Drive Device 1. There is also no need to mount Drive Device 2 into the Windows 2000
OS until it is nessesary to send the completed disk image across the network.
Most of the time Drive Device 2 will only be used in DOS mode.

The first hard drive device in the system will have two partitions containing two
logical drives.
C: drive will be 2048MB (2GB) in size and will carry the «protected»
operating system files such as boot.ini, ntldr and ntdetect.com.
A secondary function for this partition is to act as a location for an
emergency system OS (like Windows 95) if the primary OS (on D:) were to fail.
D: drive will be set to 4096MB (4GB) in size and will become
the system partition (where D:\WINNT resides). It will also
serve as the file system root for installed softare packages.
In this way we retain an established stardard in MFCF with the Windows OS on the
D: drive and the C: drive serving as the smaller boot partiton.
The D: drive will be formatted as an NTFS drive. Although traditionally
the C: drive has been a FAT partition for workstations, C: should be
an NTFS partition on Terminal Server systems. This would protect
the OS files on C: from malicious (virus) or accidental corruption.
However conversion of C:
to NTFS will be an optional issue to be done after system installation is complete.

You may note that the initial size of the system partition (D:)
is small for a Windows 2000 server.
However, what we are creating in this case is a basic Terminal Server
configuration which shall be used for system cloning. A Microsoft utility called
sysprep can be used to expand an existing system partition into the available
(unused) disk space when this system is installed on a target machine.
For the purposes of preparing a prototype server a 4GB system partition is
more than sufficient and allows us to clone a Terminal Server system onto
a hard drive as small as 6GB in size.

Installation of OS and Services
OS installation is quite straight forward and follows from the installation
wizard provided by the Windows 2000 installation CD.

• Regional Settings
  Time Format: 24hr
  Date Formats: Short as d MMM yyyy — Long as ddddd, d MMMMM yyyy
  Languages: Add all forgein languages available.
  Keyboards: Add all English (US) Dvorak and US International keyboards.
• Personalize
  Name: Please enter YOUR name here
  
  Organization: MFCF — University of Waterloo
• Enter CD Key
• Select per server licensing
  Enter 25 licenses since this is the default number of CALs that
  come with a Windows 2000 Advanced Server
• Enter the computer name
• Provide a local Administrator password

Add the following components.

• Management and Monitor — SNMP
• Networking — Simple TCP/IP
• Other Networking — Print Services for UNIX
• Terminal Services

Make sure that the following components are not selected.

• IIS
• Terminal Services Licensing
  Although all RDP clients of a Terminal Server require a permenant TSCAL
  (Terminal Server Client Access License),
  most Terminal Server systems will not be TSCAL license servers. This feature can
  also be installed and activated later if required.

Continuing with the installation wizard.

• Set Time Zone as Eastern (automatically adjust for Daylight Savings Time)
• Set date and time if not correct
• Select Application Server mode (not the default in this case)
• Select permissions compatible with Terminal Server 4.0 Users
• Network Settings — Customize
  TCP/IP: Specify a valid IP address for server setup
  DNS Server: Set for campus DNS servers 129.97.128.10 and 129.97.128.100
  Advanced — DNS: Do not register this connection with DNS
  DNS Suffix: uwaterloo.ca

The installation wizzard will now install all required components and
prepare the system. Clicking on the Finish button completes the OS installation and
reboots the machine.

System Modification After First Login
Login as Administrator using the password which was set in the installation
process. Install the following noting that a system reboot may be required
for each step.

• Install all relevent OS service packs, critical updates and
  recommended updates.
  
  For Windows 2000, these can be found on the
  Windows 2000
  Downloads page.
• Install (upgrade) to desired version of Internet Explorer. These
  can be downloaded from the
  Internet Explorer Downloads page.
  Internet Explorer is an integrated part of the OS and can not be
  managed as a packaged application.
  Internet Explorer setup may leave a special setup (Windows Update Setup Files) folder on the D:
  drive root when setup is complete, delete this folder.
• Install all service packs and fixes for Internet Explorer and
  Outlook Express.
• Create a command script called IEXPLORE.CMD which uses the start
  command to launch Internet Explorer in low process priority. Place this
  script in the Internet Explorer installation folder.
• Increase pagefile size (on D: drive) to about 1.5GB
  (2.5x 512MB (Typical TSE RAM) + 256 MB)
• Increase registry size to 128MB.
• Find the following registry key
  
  HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon
  The value Userinit must be modified such that just the executable file
  userinit.exe is specified and not the file’s absolute
  path.
  This will allow for easy login and system repair if the system drive letter
  (D:) is accidently swapped with another drive. See Microsoft’s Knowledge Base
  article
  Q249321 for more information.

Set UsrLogon.cmd and User Network Home Drive
Locate the file D:\WINNT\system32\Usrlogon.cmd. This is a command
script which runs for every user at logon time. One of its reponsibilities is
to establish a RootDrive for Terminal Server users through substituion of a
logical drive letter for the user’s home directory — the RootDrive. The existence
of a RootDrive allows for easier application configuration when making software
compatable in the Terminal Server environment. However since
a network drive is always established for the user at logon by the SYSTEM drive
substitution is not required.

Edit Usrlogon.cmd such that all lines which
begin with the command Subst must be remmed out. As well, the following
command line musted be remmed.net use %RootDrive% /D > NUL: 2>&1

NOTE: The the user’s network drive is always the P: drive. This
will be the requested RootDrive value when using any Terminal Server Compatibility
Scripts. Using P: is consistent with the drive letters given to networked user
disk space on other Windows based systems such as Polaris and WinCentre.

Format Drive Device 2
Reboot your server using the DOS floppy. Use the fdisk to create a suitably sized
partition on Drive Device 2. Make sure you tell fdisk to switch to
Drive Device 2 prior to attempting to create the partition. Do not try to create any
other partitions on Drive Device 1.
You should allow for several copies of your disk image
to be storable on Drive Device 2. In fact, unless you have another purpose for
the disk space on Drive Device 2 you should dedicate the entire disk for this
purpose. You will need to reboot the server for these changes to take effect.
Leave the boot floppy in the floppy drive to return to DOS in order to
format Drive Device 2.
Use fdisk again to determine the drive letter of the partition on
Drive Device 2 in the DOS. Use the format command to format this disk drive.

Modifications to Key Folders in the File System

From the default file structure on a newly installed system the following
folders are to be created.

• D:\Temp
  Having a communal temp folder writable by all users is useful on UNIX systems
  and will likely be handy in the Windows 2000 environment. There will always
  be times when a user will require more space during a session than he is
  normally alotted by his disk space allowance.
  Users also have a private temp folder in their profiles as
  well. The contents of which are not retained at log out.
• D:\software
  Unless unavoidable, new software will be installed in D:\software. This
  will effectively separate third party software from the vendor components
  in the D:\Program Files. Within D:\software packages can be diverted to
  other hard drives using a Windows 2000 construct called a «junction» if
  partition space becomes and issue. The use of junctions affords system
  administrators the flexibility of storing or moving packages to other
  logical drives and yet retain the original absolute path of the software
  packages. See
  Use of Junctions on the Terminal Servers
  Software Prepartion page.
  D:\software is also required since some older
  software packages can not interpret file or folder names containing spaces.
  D:\software is also consistent the naming conventions
  found on MFCF and IST UNIX and Windows NT systems.
• D:\software\mfcf_admin\bins\bin
  Although packages which are command based are not as common in the Windows
  environment as in UNIX, it is handy to have a common place to stash such
  commands so that the system path need not be modified.
  This folder folder would need to be added to the system PATH.
  NOTE: The folder D:\software\mfcf_admin should have its attributes set as hidden.
• D:\UserProfileCache
  This folder will become the new cache location for user profiles. This
  is a change from the default location for cached profiles (D:\Documents and Settings).
  The name change is require to eliminate user confusion over the proper
  location for the storage of personal files and software. On a TSE system
  it is important to separte space intensive document files and executables
  from smaller profile information. Profiles are moved from system to system
  and large profiles can grossly slow down the network.
• D:\Regional
  This folder will contain information unique to the group(s) of systems
  to which this server belongs. An example of such a group would be a load
  balanced cluster. An example of the kind of information found here would be a
  list of IP addresses permited to access the cluster via the RDP client.
• D:\Local
  This folder will house information unique to the server.
• D:\Local\local_users
  This is a network shared directory (shared as local_users) which will
  contain the home directories of special user accounts such as the local
  Administrator.
  This accomodation is required in Terminal Server systems since all user
  disk space must be the root directory of a network or substitute drive.
  This is nessesary for general software compatibility with Terminal Server
  design.
  In our case we use a network drive designated as P:.

After UserProfileCache is created, the following subfolders are copied from
D:\Documents and Settings. However do not attempt to move any user profile
folder such as Administrator.

• All Users
• Default User — hidden folder

Using regedit.exe, find the following registry key.
HKLM\Software\Mcrosoft\Windows NT\CurrentVersion\ProfileList
Delete all existing subkeys — these keys record the profile cache location for
users (like Administrator) which have previously logged in and so must be deleted
if the cache location for these user profiles are to change.
Then edit the value
ProfilesDirectory to read %SystemDrive%\UserProfileCache
The server will need to be rebooted at this point.

After the restart use regedit.exe to find the following registry key.
HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders
The value Common Documents should be changed to
D:\UserProfileCache\All Users\Documents
The server will have to be rebooted once again.

After restart, the D:\Documents and
Settings folder and its contents can now be deleted.

System Security Modifications

System Drive (D:) and Sub-Folder Security Modifications
Folder permissions in Windows 2000 are inherited from the parent folder
by default. This process follows up all the way to the permissions set
on the root of the logical drive. However, as
a rule each of the top level folders on the system drive (D:) will not inherit permissions
from the D: root. This is due to the fact that each folder’s purpose is unique.
In particular Temp and UserProfileCache must have
special permissions to allow users to add and modify files.

Here we will
specify the permissions applied to the root of the system drive (D:) and
its imediate list of subfolders.
Some of the permissions listed below may appear redundant. When the
system is installed Windows provides some greater rights to special user
groups such as TERMINAL SERVER USERS and Power Users. These rights have been
reduced to simple Read and Execute.
It is policy that non-administrative users have no rights to modify the system,
the registry or any common software. They only have the right to affect
materials which belong to them. The result is a fairly uniform permission
structure for the possible exception of the D:\Temp directory.

D:\

• Administrators — Full Control
• CREATOR OWNER — Full Control (on created items in the D: root directory)
• SYSTEM — Full Control
• Users — Read and Execute

D:\Local

• Administrators — Full Control
• CREATOR OWNER — Full Control (on created items in D:\Local)
• SYSTEM — Full Control
• Users — Read and Execute

D:\Program Files

• Administrators — Full Control
• CREATOR OWNER — Full Control (on created items in D:\Program Files)
• SYSTEM — Full Control
• TERMINAL SERVER USERS — Read and Execute
• Users — Read and Execute

D:\Regional

• Administrators — Full Control
• CREATOR OWNER — Full Control (on created items in D:\Regional)
• SYSTEM — Full Control
• Users — Read and Execute

D:\software

• Administrators — Full Control
• CREATOR OWNER — Full Control (on created items in D:\software)
• SYSTEM — Full Control
• Users — Read and Execute

D:\Temp

• Administrators — Full Control
• CREATOR OWNER — Full Control (on created items in D:\Temp)
• SYSTEM — Full Control
• Users — Special Access (*)

D:\UserProfileCache

• Administrators — Full Control
• CREATOR OWNER — Full Control (on created items in D:\UserProfileCache)
• SYSTEM — Full Control
• Users — Read and Execute (**)

D:\WINNT

• Administrators — Full Control
• CREATOR OWNER — Full Control (on created items in D:\WINNT) (***)
• SYSTEM — Full Control
• Users — Read and Execute

(*) Traverse Folder, List Folder, Create Files and Create Folders. Thus Authenticated
Users may create files and folders for themselves. These items can be modified and
deleted by the creating user and are not accessable to other users (expect the SYSTEM
and Administrators).
(**) The SYSTEM caches the user’s profile in D:\UserProfileCache not the user
however since the profile is owned by the user the CREATOR OWNER permission
gives the user Full Control of his profile folder within D:\UserProfileCache
(***) The use of CREATOR OWNER is handy on all folders since it will add the
creator’s/installer’s id to the permission list of any new file or folder. This
is a handy mechanism for determining which administrator installed what file.

Shared Folder Security Modifications
At the present time we have no security standard for permanent shares on MFCF Terminal
Servers. The file permissions associated with any shared folder are usually
sufficient to protect the contents from unauthorized access (or modification). In addition,
the default drive root shares (C$ and D$) are set for administrative access only by the
SYSTEM at start up.

Registry Security Modifications
All the registry keys come with a set of default permissions to protect them.
This situation is much like the file system after a fresh install.
However, the default security on the registry has serious holes
which are dangerous on a system used by as many as 1000 different
students per week. These holes in the security exist for
one of two reasons.

1. By design. A Terminal Server is suppost to allow users to install their own
   software for their own purposes. These are called local or personal applications.
   — as opposed to common applications. In many cases though an application must
   register components to be run by the system. Thus CLSID keys need to be created
   in the HKCR hive. HKCR is a commonly accessed area of the registry. New keys
   may also be required in the HKLM hive.
2. For software compatibility. Some Windows based applications do not create
   all required registry keys
   during the installation process. Some «re-create» these registry keys
   (as many as a hundred in some cases) when
   the application is run by the user. On an unprotected system, such as with
   Windows 95, this is an effective measure for ensuring the integrety of the
   keys upon which these applications depend. However registry errors can occur for a
   user if he does not have modification rights on these keys under Windows NT
   or Windows 2000

For us, allowing users to register their own software components is not
desirable. Registered components are run under the SYSTEM authority once
the server is rebooted. SYSTEM authority is the highest authorization
level on a Windows server and not even administrators are given it.
If such components are run at that level then they have full access to
all server resources (even personal ones). If they turn out to be viruses
or hacker traps then the system if effectively compromized.
Further, applications are not written specificly for the Terminal Server
environment. These are usually PC applications which were created under
the assumption that they would be used on a single user, single interface
console and not on a multi-user, thin-client server.
During installation, an application may make general changes which can
have an undesired effect on other users — such as unexplained icons
on everyone’s desktop.

In order to balance system stability and security with the practicle matters
of compatability we have targeted certain strategic keys that when
secured will effectively protect the registry. This coupled with a general
policy of not permitting the users to access the registry editors seems
to have prevented all forms of virus attacks, accidents and mischief.
This is by no means as good a «lock down» as the file system but it is a happy
meadian for the time being. As better registry monitoring/editing tools appear
this procedure will be refined. The keys in question are as follows.

• HKLM\Software
• HKLM\Software\Classes
• HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths
• HKLM\Software\Microsoft\Windows\CurrentVersion\Run
• HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce
• HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall
• HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\Desktop\NameSpace
• HKCR (hive root)
• HKCR\CLSID
• HKCR\Software (if present — created by Acrobat Reader or MathCad)
• HKCR\exefile\shell\open\command
• HKCR\exefile\shell\runas\command
• HKCR\comfile\shell\open\command
• HKCR\cmdfile\shell\open\command
• HKCR\batfile\shell\open\command
• HKCR\txtfile\shell\open\command

Registry key permissions in Windows 2000 are, like the file system,
inherited from the parent key
by default. This process follows up all the way to the permissions set
on the hive root (HKLM, HKCU or HKCR).
In every case above the idea is to keep the Special access permissions for
subkeys but reduce access to simple Read on the keys themselves.
Hence user can not create their own subkeys at important levels of
the registry but still retain their freer access at less sensitive levels. The
Advanced permissions editor permits this by allowing permissions to be
inherited by all subkeys and yet not applied to the key itself. You may
then create a new Read Only entry for TERMINAL SERVER USER or Power User
which does apply to the key itself. The permissions should read as
outlined below.

• Administrators — Full Control — This key and subkeys
• CREATOR OWNER — Full Control — Subkeys only
• Everyone — Read — This key and subkeys
• Power Users — Special — Subkeys only
• Power Users — Read — This key only
• SYSTEM — Full Control — This key and subkeys
• TERMINAL SERVER USER — Special — Subkeys only (*)
• TERMINAL SERVER USER — Read — This key only (**)
• Users — Read — This key and subkeys

(*) Special permission, in this case, refers to the following permission attributes.
Query Value, Set Value, Create Subkey, Enumerate Subkey, Notify, Delete,
Read Control.
(**) Read permission, in this case, refers to limited permission attributes.
Query Value, Enumerate Subkey, Notify, Read Control.

Network Port Security Implementations

Windows 2000 Standard and Advanced Servers come with what can be described as a built-in firewall
service. It is a mechanism which, amungst other things, can allow an administrator to
pick and choose what network locations (IP addresses and ports) may connect to the
server or specific ports on the server. This is particularly useful if you desire
to limit which specific terminals may connect as terminal server clients.
This feature is the IP Security Policy in the Local Security Policy admin
tool.

Network Ports of Interest for Terminal Services Client Connections

• TCP 1494 on Server
  Connection for ICA clients
• TCP 3389 on Server
  Connection for RDP clients.
• TCP 6000 on «Client» Terminal
  Connection to X terminals.
  NOTE: X terminals are actually the X protocol servers and the hosts to which they connect
  are the client machines.

Unfortunately, the interface for the IP
security tool is still quite cumbersome and non-intuitive thus development for this kind of
policy requires more trial-and-error than other parts of this build process. However here
is a basic outline of the steps involved.

1. Highlight IP Security Policies on Local Machene in the left hand window.
2. In the Action menu select Create IP Security Policy. A wizard will appear
   to guide you through the rest of the policy creation process.
3. Give the new policy a name. In our case, MFCF Standard Network Security.
   You should also fill in a brief description of the policy’s purpose.
4. Accept all the default characteristics for this new policy including
   Windows 2000 (Kerbrose V5 protocol) for default Responce Authentication.
5. At the end click on Finish to create a new blank policy.

A single policy is a list of IP Security Rules. An IP Security Rule is an IP Filter List
associated with a particular Filter Action.
IP Filter Lists themselves are a list of different network connections; each connection
consists of a source and destination IP address, a source and destination network port(s)
and a specific network protocol.
Usually, the Filter Action is either Permit or Block, accept or ignore a connection
respectively.
By associating a list of network
connections with a filter action (block or permit) an administrator can dictate what
connections a Terminal Server will accept networkwise and which it will simply ignore.
Using IP Security Rules in combination it is possible to completely block out (stelth)
a network port or series of network ports to the general internet but then allow only
specific locations (IP address or seats) to access it.

Below is an outline of how to create a universal block of all connections to TCP port
3389. By default port 3389 is the network port for RDP protocol connections from thin clients.
With this block in place, the Terminal Server will ignore all connection attempts to port 3389.

1. Highlight the new policy now found in the right hand window.
2. In the Action menu, select properties.
3. Disable the wizard option in the lower right corner of the Edit Rule Properties applet.
   The tools are easier to follow this way.
4. Click on Add to create a new IP Security Rule (IP Filter List — Filter Action combination).
5. The next applet will appear offering a list of pre-defined IP Filter Lists. Click
   on the Add key because we intend to create a new IP Filter List.
6. Again, disable the wizard in the IP Filter List applet.
7. Fill in the name field, in this case RDP Seats Blocked.
8. Click on the Add button to create an entry in the filter list.
9. Set the following.
   • Addressing Tab:
     • Source Address: Any IP address
     • Destination Address: My IP address (the IP address of the server)
   • Protocol Tab:
     • Select Protocol Type: TCP
     • Set the IP Protocol Port: From any port, To this port: 3389 (RDP default port)
   • Description:
     • Fill in a valid decription of the connection filter.
10. Click on OK to enter the new filter list entry.
11. Click OK on the IP Filter List applet.
12. Returning to the Edit Rule applet select the Filter Action tab.
13. Select Block for the Filter Action and click on the OK button.

Thus a new IP Security Rule has been created in the policy.
Ofcoarse, this universal block rule is not much good unless there is some mechanism
to allow access
to specific RDP clients on the network. That is why a second IP Security Rule
needs to be added to the policy. The creation of this new rule will follow
the same steps listed above except for the three items listed below.

1. IP Filter List name will be RDP Seats Permitted.
2. There will be more than one entry (connection) in the Filter List. One IP address
   for each seat permitted to be an RDP client.
   • Addressing Tab:
     • Source Address: A specific IP address (this address will then be entered).
     • Destination Address: My IP address (the IP address of the server)
   • Protocol Tab: (same as in the case of the Blocking Rules).
   • Description:
     • Fill in a valid decription of the connection filter.
3. Filter Action will be Permit.

Fortunately Permit Filter Action takes precidence over Block so even though
all IP addresses were blocked from port 3389 on the Terminal Server,
specificly identified IP addresses in the RDP Seats Permitted Filter List
may connect to TCP port 3389.
This provides us with the first part of our security policy with regards to
our desire to regulate the location of permitted client seats.
We can write similar Block/Permit rule combinations for ICA and x11 client
connections to a Terminal Server.

Network Ports of Interest which require special controls

• TCP/UDP 137 on Server
  Windows NetBIOS-ns (Name Service)
• TCP/UDP 138 on Server
  Windows NetBIOS-dgm (Datagram Service)
• TCP 139 and 150 on Server
  Windows NetBIOS-ssn (Session Service)
• TCP/UDP 161 and 162 on Server
  SNMP Service
• TCP 445 on Server
  Windows NT/2000 SMB.
• TCP 497 on Server
  Retrospect Backup System (when in use)
• TCP 1900 and 5000 on Server(*)
  Windows Universal Plug and Play (UPnP)

These are network ports used for system information exchange. Such exchanges are
file and printer sharing, user authentication and comunication between Windows 2000 and
Windows NT systems. Unfortunately, they also may be attacked from outside our networks
to gain system and user
information which should remain private. These ports could also be attacked in order to
break these system services (DoS attack).
We wish to make use of these ports localy however there is no need for systems off of
campus to access them.
Thus we will create IP Security Rule block/permit combinations which will be similar
to the RDP connection rules except they will cause all queries that are not from
on campus (129.97.*.* in our case) to be ignored.
Except for the case of the SNMP ports where we have chosen to be more restrictive. We
require that all queries to SNMP ports must come from our local management subnet
(MFCF-net) otherwise the connection request is ignored.

NOTE: Windows Universal Plug and Play (UPnP) is listed here due to current security
concerns involving UPnP on Windows XP systems. Windows 2000 does not come with UPnP, however
Windows.NET (with Terminal Servers) may. When .NET Terminal Servers become more common
and if UPnP is used, the UPnP ports will be restricted to on-campus connections only.

Local User Groups and User Rights
The most important purpose of this section is to provide an easy mechanism for
selecting which users may log in to a Terminal Server. To this end we create a new
local user group called Local Accounts. The membership of this group is limited to
accounts on the local system which are permitted to login to the Terminal Server.
Usually, these accounts are the local Administrator and one test user account.
Then in the Local Security Policy tool Logon Locally rights are granted to the
Local Accounts group. At this time Logon Locally rights are removed for the
Guest account and the Users group. Once the server is installed and in production
Logon Locally rights may be granted to other local (or domain) groups as desired by the
server’s administrator.
Adjust the Access this computer from the network user right similarly.

MFCF Packages and Policies

This section is still being reworked since recent system updates have rendered
some changes redundant.

Install mfcf_wintse_basics Package
To be installed (copied) into d:\software\mfcf_wintse_basics.
This pacakge currently has three components.

1. All sysdiff files from the Windows 2000 Resource Kit CD. The entire resource
   kit is really not required nor would we be permitted license-wise. sysdiff itself
   s a freely downloadable application from the Microsoft web site.
   This will give the new system the ability to easily install packaged software in
   the form of diff files.
2. All sysprep files required for preparing the new system for cloning. We will
   discuss system cloning later in this document.
3. A locally produced script called notice.cmd. This is a script designed
   to read and display the message of the day (motd) file for a system.
   It is nessesary to define an environment variable called MOTDPATH which will provide
   the system file or network path of the motd file. Our default setting will be
   D:\WinNT\system32\config\etc\motd

NOTE: The software for all components of this package will actually be placed in
d:\software\mfcf_wintse_basics\distribution and this directory will be added to the
system path.

Create a Shortcut (.LNK) Depository
Create the following folder, D:\software\mfcf_admin\bins\bin and add this path
to the PATH environment variable as an addition to the search rules. Then add the .LNK
suffix to the end of the PATHEXT environment variable string.
By adding .LNK to PATHEXT, shortcut (.LNK) files can be run from a command prompt
in the same manner as any other executable. The file that the shortcut is «linked» to will
be opened in accordance to it’s file extension. That is, a shortcut to an .EXE file will
execute.
The folder D:\software\mfcf_admin\bins\bin will serve as a depository for shortcuts
linking to executables in command based packages. This will reduce the need to constantly
add to the PATH environment variable after the installation of a command based package.
This is also a practice consistant with what is done in xhier-ed UNIX systems here at
the University of Waterloo.

Create a Local Computer Policies Console

Add MFCF Policy Changes to system.adm File

Configure the Windows Time Service

This will synchronize the Terminal Server clock with that of the local time server
here in the Math Faculty. At a command prompt enter the following command. Note that
this requires administrative privalages.

net time /setsntp:ntp.math.uwaterloo.ca.

The network name ntp.math.uwaterloo.ca
is the alias
for our local time server. It is important to use the alias name as opposed to the true
host name or IP address since the time service is movable from one server to another.
In order for the time server settings to take effect the Windows Time service must
be restarted. In the Services tool of the Administrative Tools group open the properties
of the Windows Time service. If the service is already running then stop it. Now start
the service. At the same time ensure that service start up is automatic and not manual.

Switch Off All Unnessesary Services
Windows 2000 Servers initially come online with a multitute of services installed and
running. Not all of these services are required to be active for a typical Terminal
Server to be able to do its job. Therefore, we should switch off any services which
are not required in order to save processing power and RAM.
Any of the services llisted below not only must be stopped but there «Start Up»
state must be changed from Automatic to either Manual or Disabled.

• Disable wallpaper for all Terminal Server clients.
• Disable LPT and Printer mapping for RDP clients.
  • This is in Terminal Services Configuration. Most users can not install their
    own printer drivers in any case.
• Disable Automated Updates
• Disable Background Intelligent Transfer Service
• Disable Distributed Transaction Co-ordinator
• Disable TCP/IP Print Services
• Disable Simple TCP/IP Services
  • This will stop unnessesary network services like echo, qotd and chargen
    which are only useful for system testing. Other services like Distributed
    Transaction Co-ordinator were introduced in SP3 and are not nesseary for our
    Terminal Server design.

Creating the Default User Profile

This is the most «fuzzy» stage of the server configuration. In essence, the Administrator
modifies his own desktop into a form which he feels is a good default profile
for all his users and then he copies it to the Default User folder in UserProfileCache.

things to do.

• Remove all .sco (screen saver) files from the D:\WINNT\system32 directory.
  Terminal Server users must never be allowed to use screen savers. Screen savers in
  Terminal Server do not protect the terminal screen when it is idle.
  Screen savers use server processing power continuously. All screen savers should
  run on and by the local terminal.
• Find the following registry key.
  HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders
  For this key set the following values so that these default directories reside in
  the user’s disk space and not in the profile.
  • Set AppData to %HOMEDRIVE%%HOMEPATH%Windows\WindowsAppsData
  • Set Local AppData to %HOMEDRIVE%%HOMEPATH%Windows\WindowsAppsData
  • Set My Pictures to %HOMEDRIVE%%HOMEPATH%WindowsDocs\Pictures
  • Set Personal to %HOMEDRIVE%%HOMEPATH%WindowsDocs
• Delete the following registry key. It will be regenerated at the next logon.
  HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders
• Delete all application icons from the desktop. There should only be the following
  desktop items.
  • My Computer
  • My Network Places
  • Recycle Bin
• Open a «My Computer» browser and use Folder Options… in the Tools menu
  to set the following browser defaults.
  • Set Details option in browser View menu.
  • General Tab
    • Use classic Windows desktop.
    • Use Windows classic folders.
    • Open each folder in the same window.
    • Double-click to open an item.
  • View Tab — ensure that the following values are selected and no others.
    • Display compressed files and folders with an alternate colour.
    • Do not show hidden files and folders.
    • Hide file extensions for known file types.
    • Hide protected operating system files.
    • Show pop-up description for folder and desktop items.
    • Lastly, click the «Like Current Folder» button to make these changes universal.
• Open the Display applet in the Control Panel.
  • Appearance tab
    • Create MFCF Standard colour scheme — black background and tasteful.
    • Create any other desired colour scheme.
    • Select and Apply the MFCF Standard colour scheme.
  • Effects tab — ensure that the following values are selected and no others.
    • Show icons using all possible colours.
    • Hide keyboard navigation indicators until I use the Alt key.
• Create an Internet Explorer programme group in the All Users profile and
  move all Internet Explorer and Outlook Express links into this programme group.
• Ensure there are no further Internet Explorer and Outlook Express links in your
  own profile folder and the Default User profile folder.
• Ensure all Start menu links for Internet Explorer actually run the
  IEXPLORE.CMD script (recommended above) instead of the IEXPLORE.EXE
  executable. These links should reside in the All Users profile folder.
• Run Internet Explorer and configure it using the Internet Options… in the
  Tools menu.
• Set up for usage on a LAN.
• Set the home page to the MFCF homepage.
• Turn off all Toolbars on the Windows Task Bar (bottom of Desktop).
• Use the System applet in the Control Panel to copy the Administrator’s
  profile to the D:\UserProfileCache\Default User folder. Make sure that the
  «Permitted to use» permissions are set to Everyone before saving the folder.

NOTE: All of these settings are mearly copied to a user’s personal Windows profile at the
time of his first logon. Unless enforced by a Group Policy Object or
a local system policy, a user may change any setting in his personal profile.

Some Final House Keeping

Here are a few things which should be done prior to sysprep-ing the system for cloning.

• Delete all files from D:\Temp
• Clear document entres in the Administrator’s Documents menu off of the Start button.
• In the Event Viewer, clean up the Event Logs: For each log perform the following.
  • Set maximum size to 10MB (or more if desired) from the default of 512 KB.
  • Set to «Overwrite events logs as needed»
  • Clear the the log.
• Disconnect any and all network drives for the exception of the P: drive.
• End all programmes and close all windows.
• Empty the Recycle Bin.

Prepare the System for Cloning

Using sysprep to prepare the system for cloning
Sysprep is a free Microsoft application package for cloning Windows 2000
systems. It can be downloaded from the Microsoft Web site

here. When sysprep is run it simply «strips off» the SIDs from all userids
and machine identification. The software has three key files.

• sysprep.exe — The system preparation utility.
• setupcl.exe — The system setup client (wizard) which is run when a prepared
  system is restarted
• sysprep.inf — A settings file which describes which system settings
  are to be set manualy during setup and what are the default settings.

In order to use sysprep create a directory called %SystemRoot%\sysprep
(D:\sysprep). In this
folder copy sysprep.exe, setupcl.exe and sysprep.inf.
Then run sysprep.exe from this
new directory. After confirmation, the preparation process should be «hands off»
and no further intervention on the part of the user will be needed.
Once sysprep has completed its task, it will shutdown your server. DO NOT
restart the server until a disk image has been taken. This will require
booting from a floppy — the details are in the next section.
Although the folder %SystemRoot%\sysprep is retained on a prepared system, this
folder will be deleted from %SystemRoot% once the mini-setup is completed on the
cloned system.

sysprep.inf is the optional setup wizard configuration file. If it is used this
file must be located in
the %systemdrive%\sysprep folder with sysprep.exe and
setupcl.exe.
sysprep.inf is an answer file for setupcl.exe, determining the
behavior of the
setup wizard. sysprep.inf can even fully automate
the wizard so that no user intervention is required.
In our case we have created our own version of sysprep.inf which contains
the following information.

[Unattended]
[UserInfo]
[Networking]

There is more to this file which has to do with specifying IDE and SCSI drivers
in order that this system image can be applied to many different kinds of systems.
Click here to view the entire MFCF sysprep.inf file

Copying the Master System Disk Image from the Hard Drive

With the system sysprep’ed and shutdown, the time has come to create a portable disk
image of the C: and D: drives created above. It will be this set of image files that
will be cloned onto new servers. Usually the image files are burned onto a set of CDs
to simplify the installation process — outlined later. Here is our current procedure
for creating the image.

• With a Windows 98 boot disk in the A: drive, boot the sysprep’ed server from floppy.
  Again, do not allow the server to boot from the hard drive at this point.
• Run your disk imaging software (Drive Image Pro 4.0)
  • Select Create Image.
  • Select source drive as Disk 1 only.
    • Although Disk 1 is labeled as the C: drive alone, it actually represents
      both C: and D: drives developed above. Windows 98 DOS can not read NTFS partitions
      and so does not assign our system partition a letter. Similarly the FAT partition
      on Disk 2 appears as D:. The NTFS partition on Disk 2 is also ignored.
  • Select both existing source partitions to be included in the image file
    (listed as C: and *:).
  • Name the image file. Specify a complete path for this file ending in .pqi.
    You want to store the image file on the D: drive which under these circumstances
    is the FAT partition on Drive 2.
  • Select High Compression.
  • Select Advanced Options button. Make sure that only the following options are selected.
    • Check for File System Errors.
    • Split Image File into Multiple Files
    • File Size: 580,000,000 (maximum file size for a single CD).
  • Select Finish button.
• The disk image software will now make a portable copy of the boot and system
  partitions of our sysprep’ed Terminal Server. This process can take five to
  ten minutes to complete.
• The resulting set of files are subsequently copied (burned) onto a set of CDs
  for easy distribution to other systems.

Installation of Disk Image to a Target System

Once a disk image is prepared it can be installed on a new system.
In order to install the image onto a new system you will require the
following items.

• Your disk image CDs.
• A bootable (Windows 98) floppy with fdisk.exe and CD ROM
  drivers
• A floppy containing the Power Quest Disk Image software pqdi.exe.

Below is the established procedure for installing the disk image onto the
new server hardware.

• Boot the new server from floppy.
• With the Power Quest Disk Image floppy use pqdi.exe to copy disk image
  onto hard drive #1 from CD. Any pre-existing partitions on hard drive #1 must be
  deleted.
• Select Restore Image.
• Select Image File. This will be on the CD ROM and will end in .pqi.
• Select all the Image File partitions for restoration.
• Select Disk 1 for the Destination Drive.
• Select the Delete Disk Partitions button. This is where we will purge the
  hard drive of any pre-existing partitions. Delete all partitions.
• Leave remaining unused space. DO NOT allow the disk imaging software
  to re-size any partition. The setup process to follow with take care of partition
  resizing.
• Click on the Finish button. pqdi.exe will delete the existing partitions
  on Drive 1 and install the new Terminal Server partitions.
• Once pqdi is completed, reboot to floppy again —
  DO NOT allow the server to boot from hard drive.
• From the boot floppy run fdisk /mbr to set master boot record. This is
  required otherwise the system may install itself with the assumption that the system
  drive should be C: and not D:
• Reboot the server and this time allow the server to boot from the hard drive.

Setup of the New Terminal Server Clone

Below is the setup procedure for a newly cloned Terminal Server just after its
first startup. A process called mini-setup will begin and attempt to asses and
configure the system to its new hardware environemt.
Typically, these servers become members of the MFCF NT domain if they
are considered Administrative, Research or Graduate Student (ARG) services.
Otherwise these servers are considered Undergraduate (UG) services and would
then be members of the MATH-UG NT domain.

• Follow setup process when the server starts up again. This is where
  D:\sysprep\setupcl.exe runs. In the case of cloning the Terminal Server
  we wish to specifiy the following items which are unique to each cloned system.
  • Specify Windows 2000 product key number on the CD.
  • Specify system name.
  • Specify system IP address and local gateway address.
  • Specify local Administrator password.
• The server will reboot at the end of the setup process.
• Upon reboot, logon as Administrator using the password specified in the
  above setup procedure.
• Ensure that the network card is properly setup and networking is up.
• Check and/or configure network settings.
  • Set server IP address.
  • Set DNS values.
  • Enter IP addresses of WINS servers
• Add domain controller addresses (PDC and BDCs) to the
  d:\winnt\system32\drivers\etc\lmhosts file.
• Reboot the server.
• Ensure multiprocessor driver is in use in Device Manager.
  • The original disk image was created on a single processor system. It is important to check
    that the server is running in multiprocessor mode (if the server has multiprocessors).
• Start the System applet in the Control Panel
  • Select the Network Indentification tab and access Properties
  • Set the name of the domain you wish your server to be a member — you will require
    domain administration authority to do this procedure.
• Run srvmgr.exe to set a description of the server.
• Set value DefaultDomainName in
  HKLM\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon to the name of the domain.
  This will force the logon service to offer a domain logon by default)

Samba (v2.2.x) Configuration for NT Domain Membership

These are basic instructions for setting up a samba server (version 2 or higher)
for use as a resource (file and printing) server for Windows within an NT 4 domain.
Having a samba server as a member of a domain allows for seemless access of
personal file and print resources as well as storage of personal roaming profiles
within user UNIX disk space.

• Ensure that the samba package is installed on the UNIX host.
• Edit the file, /software/samba/config/smb.conf.
• The following values must be set in the [global] section
  • security = domain
  • password server = domain PDC name
  • encrypted passwords = yes
  • workgroup = domain name
  • username map = location of username map file
  • nt acl support = no
• Edit the file, /software/samba/config/lmhosts such that it
  contains the IP addresses and names of all domain controllers in the domain.
• Start samba by executing /software/samba/export/boottime.
• On an NT system which is a member of the domain use srvmgr.exe to make
  the samba server (UNIX host) a member of the domain.
• On the samba server run smbpasswd -j domain_name to join the domain.

Some Notes Conserning Certain Samba Configuration File Entries

username map = location of username map file

In order for a user to access his personal disk space on the samba server his
username in the NT domain must exactly match his username on the UNIX samba server.
It is also MFCF policy to make sure each user has the same username for MFCF systems.
However, there are a few cases (usually accidental) where this is not the case. For those
cases it is often
not practical or possible to establish a new username in either the NT domain or UNIX
environments. For these users the username map file is used to map the NT
domain username to the corresponding UNIX username.

nt acl support = no

nt acl support is a mapping mechanism for UNIX permissions to NT access control lists.
We choose to disable this feature because since the implementation of Windows 2000 Service Pack
2 (SP2) roaming profile loading will not work from a samba share if this feature is enabled.

Some Notes Conserning Samba Client Connection Limits

By default, the SAMBA daemon running on a UNIX system (smbd) has a built in limit of
128 connections per client machine. Or more accurately, each new smbd daemon
is spawned specificly for each new machine client and has a
connection limit of 128 simultanious file and printer shares.
For a single
session, single user workstation this is more than enough. Unfortunately for
a Terminal Server with more than one user per machine client this is not
enough. A single Terminal Server can rapidly exhaust its limit of file share and
printer connections during peaks periods.

The solution is to raise the 128 connection limit. However, this change must be done
prior to the compilation of the SAMBA software. The smbd daemon connection limit
is hard written into the source code. A quick search of the web
indicates that the connection limit can be increased by modifying the following
line in the conn.c programme in the smbd section of the SAMBA source code.

#define MAX_CONNECTIONS (128)

We have changed this line to allow for 512 connections. Then the SAMBA source can
be compiled.

This page was last updated on Thursday, the 5^th day of June
in the year 2003 AD.
Contact Clayton Tucker for questions
or comments.