Firewall Wizards mailing list archives
RE: Architecture Q - Public access domain integrated pc' s
From: Richard.Bertolett () ci austin tx us
Date: Wed, 19 May 2004 08:31:06 -0500
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
Current thread:
- RE: Architecture Q - Public access domain integrated pc' s Richard . Bertolett (May 19)