Thank you very much for your reply!  I'm not sure
I understand all of it, so let me try to take
issue with some of what you say, and please set
me straight where I'm off base.  Below are my
comments...

> From: Craig White <craigwhite@azapple.com>

> > Here's the situation:  we used to have a W2K
> box
> > in our DMZ (I'll call it xterm) which
> accepted
> > TSAC web connections to it (TSAC is a
> web-based
> > terminal services client).  Once the user
> > authenticated to the local box's SAM (SAM is
> the
> > user/password database for a standalone box -
> we
> > didn't want to have our AD domain stuff out
> > there), another terminal service client
> session
> > is started for them (not web-based) to a MS
> > terminal server inside, on our LAN.  In this
> way
> > we could protect the internal MS boxen from
> > direct connections from the Internet.  Of
> course,
> > eventually, xterm got hacked, and now we
> don't
> > want to rebuild it with backed up SAM db
> because
> > someone might have all this info, and we
> don't
> > REALLY want to create all new passwords and
> get
> > them to the users, and then have it all
> happen
> > again.  So I suggest this, and please tell me
> if
> > it could work:
> > 
> > External user connects to a hardened Linux
> box in
> > the DMZ, via SSH. They are authenticated to
> our
> > RADIUS server (can Linux authenticate to
> radius? 
> > MS can't).  A script is run to then connect
> the
> > user with rdesktop to the MS terminal server
> > inside.  
> > 
> > Does this sound possible?  Has anyone done
> > anything like this?  
> > 
> -----
> This setup isn't any more logical than the
> first setup.
> 
> If the intent is to have Terminal Service
> clients access from public
> internet - why not just forward the stuff
> through the firewall directly
> to the terminal server and FULLY IMPLEMENT ALL
> WINDOWS SECURITY SYSTEMS
> on the terminal server. 

The idea is we'd like to create more layers than
that.  And we don't feel real comfortable with
Windows servers serving up sessions directly to
the Internet, even it "ALL WINDOWS SECURITY
SYSTEMS" were "FULLY IMPLEMENTED".  Capital
letters don't a secure OS make!  :)

> Security through obscurity doesn't work.
> Security via Rube Goldberg
> technological axioms likewise isn't security.

We're not using obscurity, we're trying to
require any would-be cracker to hack through
multiple, disparate security layers before
getting to anything we care about. That's what we
think has saved us in this case, in fact.  The
box I'm calling xterm was hacked, but nothing
internally was compromised. (The cracker may have
a copy of the SAM db from this box, but that
isn't our AD info)

> I would bet money that Windows can authenticate
> via Radius but that
> isn't the point.

Agreed.  My security guy says it can't be done,
but that's not the issue here. You may be right. 

> Not wanting to have AD information out there???
> That's exactly what you
> did when you created this so-called DMZ and
> allowed this computer in
> this so-called DMZ onto the internal LAN. A DMZ
> would not allow a
> computer to connect to the internal LAN for any
> reason.

Apparently there are different ideas on exactly
what constitutes a DMZ?  In this case, we have
xterm behind a firewall which controls all
traffic to the box, either from the Internet, or
from the LAN, like this:

LAN--FIREWALL--INTERNET
       \     
       XTERM

> As for creating all new passwords for users -
> requiring users to
> frequently change their passwords is often
> called a security policy.

I don't understand your point here.  For the
record, we do require password changes.

> Evidently, your company has some strange
> notions about security...let's
> hope that they don't have personal information,
> credit information about
> anyone.

strange notions?  like what? 

> My suggestion...hire somebody to create a
> security policy first...then
> have them plan the remote access.

Unfotunately, we don't have budget for that, so
we're doing the best we can, and this is one of
the avenues.  I appreciate your feedback!

Thanks,

Scott



.

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com