We do have SQL, but I'm not sure if it's been fully implemented yet. I'll talk to the web developer on that. Joe Heaton
________________________________ From: Jon Harris [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 06, 2008 8:28 AM To: NT System Admin Issues Subject: Re: Best practices question Are you using a SQL backend on your web sites to record the information? If so then you will have some other issues you will need to look at when the web site gets moved. Jon On Feb 6, 2008 11:17 AM, Joe Heaton <[EMAIL PROTECTED]> wrote: That was my initial thought also Michael. What he was suggesting didn't make sense to me, but I wanted to make sure I wasn't going crazy. Details of what we're doing now, as much as I know anyway, I'm still the new guy around here, and still getting my brain around all the goings on: 1) We are a state agency, whose sole purpose in life is to give money to businesses within California, in order to train their employees to make them better employees. We also help companies train people who may currently be unemployed/on welfare, etc. in order to get them back into the workforce, so that they can contribute to making California a stronger economy. There's actually a good overview on our website, www.etp.ca.gov <http://www.etp.ca.gov/> if you are interested in reading it. 2) The companies that we are helping are called contractors. When they enter into a contract with us, they do various activities through our website, and child sites off of that main site. They will enter in the information of the trainees, track that information, make changes, etc. There is also another site that they use to access the various forms that they have to fill out to jump through all the hoops. 3) Right now, all these sites are internal to the network. We currently use public IPs throughout our internal network. The contractors access the sites and services by being allowed into our network. Obviously, I'd like to get the webserver outside, into the DMZ, which won't exist until we get our new firewalls, within the next couple of weeks. So, I hope that helps a little bit, or at least makes it as clear as mud. Joe Heaton -----Original Message----- From: Micheal Espinola Jr [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 06, 2008 7:59 AM To: NT System Admin Issues Subject: Re: Best practices question 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> ~ ~ Upgrade to Next Generation Antispam/Antivirus with Ninja! ~ ~ <http://www.sunbelt-software.com/SunbeltMessagingNinja.cfm> ~ ~ Upgrade to Next Generation Antispam/Antivirus with Ninja! ~ ~ <http://www.sunbelt-software.com/SunbeltMessagingNinja.cfm> ~
