Linux front end for a MS Terminal Server?

On Fri, 2003-07-11 at 12:48, Scott H wrote:
> Another opportunity to use Linux has appeared at
> my company. If I can get some helpful
> ideas/comments, perhaps I'll be able to replace
> another MS machine! :)
>
> 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.

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

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

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.

As for creating all new passwords for users - requiring users to
frequently change their passwords is often called a security policy.
Evidently, your company has some strange notions about security...let's
hope that they don't have personal information, credit information about
anyone.

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

Craig