More March 2000 Windows Digest...
Project Plan in a Box
This article assumes an average or slightly above average familiarity with
Microsoft NT Terminal Server and Windows CE. This article is directed
primarily towards the IT Professional. Ensure you understand how to
create mandatory policies; there are some links to information regarding
this located below. For a quick refresh and informative information on
policies and profiles read Microsoft Knowledge Base Article Q161334.
Talk to anybody who works inside the Information Technology Department
for a fortune 500 company and your bound to here statements such as
"Discernable difference", "Thinking outside of the box", "Proactive vs.
Reactive". The pressure is continually applied on us, the IT Professionals
to deliver the companies next big technological success story. So employee
evaluations are only three months down the road and you recognize the need
to be more proactive and decide to take the initiative and do a hip shoot
project. This is where I found myself not too long ago. I began wondering
how I was going to provide access to the corporate Intranet to the 100's
of employee's who worked in our warehouses or simply didn't use a
computer enough to warrant a dedicated PC be set aside for them.
Access to our corporate Intranet is very important for all of our employee's,
there, an employee can find the latest information about the company,
review the latest HR policies, find the company phone directory, and even
read comments by the CEO. The Intranet has proven itself an important
communication medium and invaluable resource. Up until the deployment
of my project which I will detail shortly users were often sharing passwords
amongst one another so that "Joe Scmucately" could access the Intranet
from "Susie Q's" machine. This was a direct violation of our password
policy and often lead to people being fired. (I'm completely anal and
tolerate NO exception to the password policy under any circumstance
for any reason. Ever. Period.) This was rather unfortunate so I had to
ask myself the question "why?".
Q: Why were users sharing passwords?
A: Not all users have a computer and user A typically wanted to use
User B's computer to access the Intranet
Q: Why did every user not have a domain user account and a desktop?
A: Many employees only use a computer for a few minutes each week.
Typical use was checking the Intranet.
Q: Why did we not provide every employee with a desktop or PC to access
the Intranet?
A: For somebody who is only going to use it a few minutes a week the Total
Cost of Ownership was to high.
Q: What might lower the TCO and allow for such transient use of a
system to access the Intranet?
A: Thin Clients AKA (Bricks) connecting to a Terminal Server
So the solution to high employee turn over do to violations of the password
policy could be addressed, while providing access to all employees of the
company to the Intranet by the deployment of Thin-Clients. The idea of
deploying bricks had several concerns associated with it relating to security
of the Enterprise. It was evident that these bricks would essentially need to
function as Kiosks to the Intranet.
Below find a make shift list of equipment needed to do 20 such Kiosks:
(20) Compaq T1000 Thin Clients
(1) Compaq Proliant 2500R (Duel Ppro 200mhz & 384 - 512 megs Ram)
(21) 15" SVGA Monitors
Licenses as determined by your licensing agreement with Microsoft.
Existing WAN with connection to the location containing the Terminal
Server. (Frame Relay Network works well)
(Assuming all hardware has arrived and your ready to begin the c
onfigurations)
§ Install NT TSE on the Compaq Proliant 2500R (Disk array configuration
to be determined by you of course I recommend Raid 1 on (2) 9 gig
ScsiUW2 drives.)
§ Update Internet Explorer to IE 4.01 and install SP1 for IE. (Note: Do
not update to 5.0!!! Doing so may leave your network vulnerable as you
will read later on)
§ Apply whichever service packs are approved for your corporation (I used
Service Pack 5 for Terminal Server, which can be found at
http://www.microsoft.com/ntserver/terminalserver/downloads/recommended/tsesp5/
(Note you cannot use normal NT service packs with Terminal Server you
MUST use the Terminal Server Edition of the service pack)
§ Upon a successful installation of NT TSE configure TCP/IP services.
Ensure NOT to enable DNS by either unbinding DNS under your bindings
tab or by leaving DNS Server IP addresses empty. (This is step one in
ensuring that the Kiosks cannot be used to access the Internet. It's also
important to note that this configuration will REQUIRE a static IP address.
Not that you would use DHCP for any server in your Enterprise anyway)
§ Install the NT Resource Kit AKA "NT Crackers Kit."
Assuming you have a little bit of experience setting up Terminal Servers you
should have Terminal Server loaded at this point with IE 4.01 SP1 and the
Terminal Server Edition of SP5.
Download and Install the Zero-Administration-Kit (ZAK) from
http://www.microsoft.com/windows/zak/zakreqs.htm on a separate
workstation. Copy all *.adm files (these are templates to be used by policy
editor) to the %bootdisk%\%system%\inf (i.e. c:\winnt\inf) on the NT TS.
For a discussion about profiles and policies read the documentation that
accompanies the ZAK. You can read some good information on the ZAK
for NT TSE at
http://www.microsoft.com/TechNet/winnt/termsrv/technote/tszak.asp
§ Using Poledit.exe (from the NT Resource Kit see
http://www.microsoft.com/ntserver/nts/downloads/recommended/ntkit/default.asp
open a new set of templates. You can open the templates from the ZAK
by going to Options then selecting "policy templates" and "adding" the new
templates you copied over to the list that is current presented.
§ Now create a mandatory policy for whichever user account will be used
by the Kiosks to log into the Terminal Server and access the Intranet
through IE 4.01 SP1. For demonstration purposes assume that the
username will be "sv-intranet-kiosk".
Since the Kiosks will utilize the auto-logon feature you will have to have an
account that can be used by the system to login a user to access the Terminal
Server and launch IE to view the Intranet. I will provide some guidelines for
creating the account later. At this point it's just important to create a Mandatory
User Policy for the account that will be being used.
§ Restrict the User Account using the Policy Editor as much as possible. This
will include removing the ability for the user account to make any changes to
the system and only allowing them to run one application. That application that
the account will be allowed to run is
"%bootdisk%\progra~1\micros~1\plus!\Iexplore.exe" or whatever your path
is to Internet Explorer. Once you have restricted nearly everything that the
user account can do save the mandatory user policy to the Ntconfig.pol.
§ Create the User Account on the PDC that will be used by the Kiosks to
access the Terminal Server and ultimately the Intranet. Restrict the user account
in User Manager so that the account can only be used to login to one machine.
Specify the name of the Terminal Server as the machine that can be logged into
using the account.
At this point you should have an account assigned a mandatory policy that
can only be used to login into the Terminal Server you've setup. The account
should only be allowed to run one application and all privileges for the account
should be restricted to the best of their ability using the ADM files from ZAK
TSE. You can test this by logging in as the newly created account directly
from the TS onto your network (make sure you have logon local privileges
enabled.) if everything is successful so far you should just get a black desktop.
You should still be able to logout using CTRL+ALT+DEL "logout" function.
By logging the user account in to the Terminal Server (TS) you have also
created a profile for that account on the Terminal Server.
§ Logon to the Terminal Server as a local administrator and follow my first
installment of securing Windows NT through the registry. It is included in this
digest and represents part 1 of future installments.
The next step we will perform is not generally known by even some of the
more seasoned advanced NT administrators. The ideal result will be a
Thin-Client that when powered on will auto login to the Terminal Server
and automatically invoke the command "Iexplore -k http://<Intranet>".
The -K flag sets Internet Explorer into a Kiosk mode, where ALL tool bars
are removed from the Interface so that a user can't type UNC names into the
address bar and browse your network for example. A user could type
\\<PDC>\<share> or something similar into the address bar and do to IE's
integration into the desktop environment will be able to browse the requested
resource. You can also pull up Network Neighborhood and a number of
different resources through the browser unless you invoke it using the -k
option. Do to the fact that there is going to be "NO" user based authentication
required for a user to access the Intranet we must secure the Terminal Server
in such a way that a user can do nothing but what we intending, that of course
if browse the Intranet. You can't very well have this gaping whole in your
security architecture which would allow for access to resources set for
EVERYONE READ or EVERYONE CHANGE etc.
I followed the above outlined steps and was very pleased with the
results initially. My first test performed later on in this process using the
Thin-Clients looked very good. The Thin-Client performed just as
expected and within seconds I was presented with the main HTML file
on my thin-client screen for our Intranet. The issue we will be patching
arises when a user right clicks a link and chooses to "open in another
window". This spawns a separate instance of Internet Explorer, which i
s not initiated with the -k option. Subsequently allowing users to enter
UNC names and mess around with IE just as if it was a fully functional
browser. The patch we will install is only available directly from Microsoft
(it is not made public or published publicly until now) as they explained to
me "this is a work-around that we keep in-house". I don't know why
they wouldn't make it very public but anyhow I'll just do it for them. The
patch adds the ability for certain registry keys to be created and values
set that will cause IE to function in such a way that right clicking the mouse
to bring up the menu that displays the option to "save target as", "open in
new window", etc, will not function. When a user right clicks inside of IE,
regardless of where they right click no options are available to them. This
patch will affect ALL users or just the ONE user depending on where you
choose to set the registry values mentioned in the following steps.
· You can download the patch from the following URL
http://www.happyhacker.org/2188.exe
· You'll have to reboot your server once the patch has been applied.
In addition to the hotfix, you will also want to apply the following
registry settings for the restriction that you want.
NOTE: You will probably need to create the Restrictions key below
as I found that it was not in my registry by default. Make sure to make
a full back up of your server (registry included, rdisk /s)
· Login to the Terminal Server as a Domain Admin and execute the
patch. This being completed add the following Registry Keys
[KHEY_LOCAL_MACHINE\Software\Policies\Microsoft\InternetExplorer\Restrictions]
"NoBrowswerClose"=dword:00000001
"NoBrowserContextMenu"=dword:00000001
"NoBrowserOptions"=dword:00000001
"NoBrowserOptions"=dword:00000001
"NoBrowserSaveAs"=dword:00000001
"NoFavorites"=dword:00000001
"NoFileOpen"=dword:00000001
"NoOpeninNewWnd"=dword:00000001
"NoSelectDownloadDir"=dword:00000001
"NoFileNew"=dword:00000001
Setting each of the above entries to the number 1 (in hex or decimal),
will enable the restriction and 0 will disable. According to MS these are
all available restrictions that are known at this time.
Because of the wide array of Thin-Clients available for purchase on
the market I will not go into great detail in the configuration of the clients.
The goal when configuring the thin-clients is to point them to the Terminal
Server and provide them with the Login and Password necessary to
login to the network and into the Terminal Server. There should be a
setting or tab where you can specify which application the Kiosk should
run when it makes it connection. That is where you will enter
"C:\Progra~1\Micros~1\Plus!\Iexplore -k http://<Intranet>" Insert your
own path in a default installation this will typically work. You will setup
the Thin-Client to use RDP as the access protocol for the Terminal
Server. If you are using Citrix Winframe/Metaframe for some reason
than you would select ICA accordingly. For this instance though RDP
is used.
· Configure your Thin-Clients in accordance to the instructions provided
with them. As a rule I found the Compaq T1000 Thin-Client
exceptionally simple to configure. If you choose the Compaq T1000
Thin-Client and would like further assistance in its configuration just drop
me a line and I will forward to you a template set of step by step instructions
I produced for the non-technical person to configure the T1000.
· Place the T1000 on the network (I set mine up to use DHCP) and power
it on, providing all your network settings are correct and the configuration
on the Thin-Client is correct it should connect to the Terminal Server.
I setup the Thin-Client to automatically launch the <INTRANET RDP>
profile (not to be confused with NT Profiles) that I configured on the
Thin-Client upon its boot. That way I press the button and it's all hands
off until the Intranet shows up. If everything went well you now have a
Thin-Client that can be located in a semi-public area (break room,
warehouse, front office, etc) that when powered on auto logs into the
network and displays your companies INTRANET. It is relatively
secure and should be a pretty big win for your department.
Technical Disclaimer: I produced the above instructions by memory; I do
believe I covered most everything necessary on a technical level to get this
functioning properly. That's not to say I accidentally left something out but
I know I covered all major considerations and issues I encountered. If you
have problems use a little ingenuity I'm not here to do ALL the work for you :P
The end result???
Well performance evaluations came and went and I was honored with a
comment to something of the effect of "Continually exceed expectations,
delivering sound and solid innovative technology solutions for <company name>"
So I tooted my own horn, I thought the whole idea was pretty slick,
required only two weeks to complete (I did a lot of leg work) and
was an overwhelming success. Total cost of the hardware was approx:
$16,000.00 plus two weeks of my time. So at a initial investment of
about $19,000.00 you can provide 20 Kiosks servicing well over a 100
users access to your corporate Intranet. When you break this into a cost
per user it's a pretty cost effective solution.
More Happy Hacker Windows Digest,
March 2000--->>
