Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

This seems really basic, but I couldn't find an answer already ... we are looking to deploy a website to an IIS server, and a database to a separate server. We aren't sure how to best secure this for access by internal users and internet.

The IIS Server is not connected to the domain, and neither is the database at the moment. Should it be? Also, if we use SQL Server authentication instead of Windows Authentication, should we just hard-code the user/password into our internal apps?

share|improve this question

I guess it comes down to if you trust your domain administrators and the domain. If you suspect the domain administrators are corrupt and the most likely hackers to attack your system, you might not want to join the domain, otherwise, joining the domain should have security benefits, such as participating in group policy.

When SQL and IIS are on different boxes, often the best you can get is sql authentication because setting up delegation is tricky and many server admins don't know how to do it. If you can figure it out, windows authentication is preferable.

If you can't avoid using passwords, encrypt passwords when you can.

share|improve this answer

There's a few questions here:

  1. Q. Should web/db server for a public facing site be connected directly to your internal network?

    HELL NO!!

    It's 2011, I would even question why your hosting the website on the same premises as your internal users. unless your premises are actually in a datacentre & then you'd want to make sure the internet facing boxes are in a DMZ or a totally seperate network. Cost is no excuse, there are many VPS's out there that can probably do better for cheaper then what your doing internally.

    2. Q. How to best secure this for access by internal users and internet?
    A. Assuming your internal users are your sysadmins, only give your sysadmins access in through rdp, block all other traffic in/out of your internal network & the public facing boxes. If their needs are more complex, consider setting up a non point-to-point vpn for them.

    3. Q. If we use SQL Server authentication instead of Windows Authentication, should we just hard-code the user/password into our internal apps?
    A. This is really an application design option. Avoid storing connection strings in clear text with hardcoded passwords! Yes, the best way to avoid it is to use windows authentication. Assuming your using something like there are ways of encrypting the web.config even if the application doesn't support encryption.
share|improve this answer
We'd love to put everything in a Data Center, but it is WAY too costly given our internal users' usage. The problem isn't the cost of hosting in the Data Center (which is < $2000/month), but the cost of connecting our internal users to the data center. Internal bandwidth requirements are ~80Mb/s right now, vs. <2Mb for external users. A 100Mb connection from our location (which is in a low density area of a small city) to a data center would be well in excess of $20,000/month. It's ridiculous. Even a 1.5Mb T1 is close to $1000/month. – Beep beep Jan 9 '11 at 4:17
BTW - our internal users are data entry clerks, customer service reps, reporting applications, etc ... accessing via a web client. – Beep beep Jan 9 '11 at 4:18
if external users are only a small percentage of traffic & it's not a public site, then maybe you can convince them to a VPN to use your system ;-) You have to weight up what the risks are if you DO get hacked, what are you exposed to by leaving it public? – Nick Kavadias Jan 9 '11 at 7:15

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.