RE: Architecture Q - Public access domain integrated pc' s

[Richard.Bertolett () ci austin tx us]

All,
As it happens, there are some things that can be done to harden virtual
security within Active Directory, utilizing Group Policy objects.  Within
the Group Policy editor, there are configurations for user accounts policy,
but there are also administrative templates that permit the admin to harden
the user desktop shell by restricting access to permitted programs, taking
away access to internal drives, clearing the desktop, and so on.  Within
GPO, one can set directory/file permissions, registry key permissions, it
can get pretty granular.  These policies can be extended to Terminal
Services profiles as well. 

Further to this, there are some good starting points for GPO security at the
Center for Internet Security, in the form of GPO templates that can be
imported.  But they are not the whole answer, you will need to go further
than they do.  http://www.cisecurity.org./ 

If you _must_ integrate these "kiosk" computers into your AD infrastructure,
then start looking at creating an OU/child OU infrastructure to accommodate.
Then, put it into a lab, and do a vulnerability assessment, and try to break
it.  And harden it some more.  AD does not provide too much for physical
security (you should remove or disable floppy drives and CDROMs), but you
can create a fairly restricted sandbox for your public to play in.

Cheers,
Rick Bertolett
Austin Water Utility
512-972-0225


-----Original Message-----
From: Paul D. Robertson [mailto:paul () compuwar net]
Sent: Tuesday, May 18, 2004 9:20 PM
To: Jeff Boles
Cc: firewall-wizards () honor icsalabs com
Subject: Re: [fw-wiz] Architecture Q - Public access domain integrated
pc's


On Tue, 18 May 2004, Jeff Boles wrote:

> security and controlling system vulnerabilities.  We'd
> like to integrate into an AD architecture which also
> supports the core enterprise (non-public users) as
> well.  Public users would be identity-less guest
> accounts with automatic logon, with passwordless
> terminal services accounts setup on a per device
> basis, and desktop access controlled via the third
> party logon product.  The need for Active Directory
> integration is to manage these terminal server, as
> well as some non-terminal public systems (updates and
> patches) with the same management infrastructure in
> place on the enterprise network (SUS, SMS, etc.).

Someone else will have to answer the specifics- but in general terms,
using the same authentication method for untrusted systems as trusted
systems tends to be a bad trust boundary crossover.  With AD, it seems to
me that there have been significant "once you're in, you're in and once
you escalate you're in _everywhere_" type issues.  Surely it's not that
much more administrative work to have a separate forest for the public
stuff and add duplicate accounts for those things that need them?

Paul
----------------------------------------------------------------------------
-
Paul D. Robertson      "My statements in this message are personal opinions
paul () compuwar net       which may have no basis whatsoever in fact."
probertson () trusecure com Director of Risk Assessment TruSecure Corporation
_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards