RE: [fw-wiz] Architecture Q - Public access domain integrated pc' s

Richard.Bertolett_at_ci.austin.tx.us
Date: 05/19/04

  • Next message: Dana Nowell: "RE: [fw-wiz] Worms, Air Gaps and Responsibility"
    To: paul@compuwar.net
    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


  • Next message: Dana Nowell: "RE: [fw-wiz] Worms, Air Gaps and Responsibility"

    Relevant Pages

    • Re: hide organizational unit from view in active directory
      ... The security of a security principal isn't supposed to be in its identifier, it comes from the authenticator (password/certificate/biometric/etc). ... As for hiding the admin accounts, I have yet to have seen a good valid ... Author of O'Reilly Active Directory Third Editionwww.joeware.net ...
      (microsoft.public.windows.server.active_directory)
    • Re: hide organizational unit from view in active directory
      ... Anything else is a huge security no no. ... As for hiding the admin accounts, I have yet to have seen a good valid ... Author of O'Reilly Active Directory Third Editionwww.joeware.net ...
      (microsoft.public.windows.server.active_directory)
    • Re: hide organizational unit from view in active directory
      ... the administrators account, to obtain security through obscurity and often ... hiding the accounts from the readers). ... Anything else is a huge security no no. ... Author of O'Reilly Active Directory Third Editionwww.joeware.net ...
      (microsoft.public.windows.server.active_directory)
    • Re: Sharepoint Portal User cannot be found
      ... Are those accounts mail-enabled? ... Bill English ... When using the manage security ... > expired and is still active in active directory. ...
      (microsoft.public.sharepoint.portalserver)
    • Windows 2003 Server Group Policy Override
      ... I mistakenly set a total lock down security ... group policy to all accounts! ... This means the administrator can no longer open any administrator tasks or ... Is there anyway to remove this additional group policy or will I have to ...
      (microsoft.public.windows.server.security)