I think I would need more details to discern the most appropriate setup, but typically you don't setup a trust relationship with your DMZ. The point of your DMZ is that you *don't* trust it.
YMMV On Feb 6, 2008 10:47 AM, Joe Heaton <[EMAIL PROTECTED]> wrote: > > Our business involves customers (called contractors, as they sign contracts > with us) accessing a couple of applications. The contractors come in, enter > information, and have the ability to track this information, so that they > can make any changes they need to make. We're making some changes to our > infrastructure, and I wanted to get some opinions about the "right" way of > allowing outside customers access to our system. We don't have a DMZ at the > moment, but we will be going to that soon, as soon as I get our new > firewalls in. One of our developers here, who also has some networking > experience has suggested that we setup another domain in the DMZ, and create > trust relationships with the internal domain. The contracts typically last > about 2 years, and the active contracts change on a monthly basis. My > concern would be knowing when contractors left, and need to be removed from > AD within the DMZ domain. > > My thoughts were to simply install the public webserver in the DMZ, and > configure rights, etc. for the contractors to come into that server, and > access the databases within the network. Isn't that the "normal" model? > > Haven't dealt with this all that much, so I'm going to hit Google once this > is posted. Any tips/advice would be appreciated, as always. > > Joe Heaton > AISA > Employment Training Panel > 1100 J Street, 4th Floor > Sacramento, CA 95814 > (916) 327-5276 > [EMAIL PROTECTED] > > > > > > > > > > > > > > > -- ME2 ~ Upgrade to Next Generation Antispam/Antivirus with Ninja! ~ ~ <http://www.sunbelt-software.com/SunbeltMessagingNinja.cfm> ~
