What's New!

Chat with
Hackers

How to Defend
Your Computer 

The Guides
to (mostly) 
Harmless Hacking

Happy Hacker 
Digests (old stuff) 

Hacker Links 

Hacker
Wargames 

Meet the 
Happy Hacksters 

Help for 
Beginners 

Hacker 
Bookstore 

Humor 

It Sucks 
to Be Me!

How to Commit
Computer Crime (not)! 

What Is a 
Hacker, Anyhow? 

Have a 
Great Life! 

News from the 
Hacker War Front

Carolyn's most
popular book,
in 4th edition now!

For advanced
hacker studies,
read Carolyn's
Google Groups
Subscribe to Happy Hacker
Email:
Visit this group

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--->>

 © 2013 Happy Hacker All rights reserved.