When should you place a server in a DMZ vs opening ports on the firewall and keeping it within the network? I'm referring to active directory servers, IIS servers, and mostly things on a windows based setup.
Some issues I've noticed with placing in the DMZ is that it's no longer on the domain, it doesn't have nameserver access to our internal servers, and a few other things that make it strange to work with.
A server placed in a DMZ can't open connection to your network because there is a firewall in the middle (by the very definition of DMZ), so your network will be protected from it, should it ever be compromised by an attacker: in this scenario, the compromised server could not be used as a starting point to launch new attacks against the rest of your network. This is instead not the case if the server is placed inside your network, and you open firewall ports to allow external users to access it using the services it provides. The same succesful external attack (f.e. against a web site) would lead to very different consequences if your server is in a well-guarded DMZ or inside your LAN.
That said, placing a server in a DMZ is really only useful if you can actually filter the traffic between it and your internal network; if it requires domain controller access for authentication, database access for back-end data and mail access for sending out messages (like an Exchange CAS), and you need to open all of those ports between it and internal servers in order for it to actually do anything useful, then there really isn't much of a point in placing it in a DMZ. Domain member servers are the worst offenders here: domain access requires so many open ports between a computer and its domain controllers that it could as well be placed in the same network as them; and a compromised domain member computer is a big security pain, because it can access lots of things in the domain.
Rule of thumb for Windows servers: if it needs to be a domain member, then placing it in a DMZ is A) a pain to get it to work correctly and B) almost useless; keep them in your LAN, but be sure to keep them fully patched, running a good antivirus and protected by a well locked down external firewall. The best approach here is using a reverse proxy, an inbound mail relay, or anything else that can act as an application gateway, and avoid exposing them directly to the Internet.
A good rule of thumb is to consider the damage that could potentially be done if the server were to be compromised via the service that you've opened. You'll want to consider two factors for each device: the risk level ("How likely is this to get compromised?" - this measure should go way up as soon as a service is internet-exposed) and the sensitivity level ("How much of a loss would it be if this system were compromised? Is there important/confidential data?").
For high risk systems, you should endeavor to keep their sensitivity as low as possible. This is the reason that you build a DMZ.
The idea of a DMZ is to isolate the high-risk systems, so that an attacker needs to penetrate an additional layer of security (another firewall) to access your highly sensitive systems. You'll likely need some connections between the DMZ and the internal network, but try to push data outward to the DMZ instead of allowing connections inbound to the internal network.
If the server get compromised when you open ports to the internal network, potentially the attacker will have access or much easier way to perform attacks toward internal systems. In today's world, most of the system that you're planning on deploying in DMZ can be tweaked and configured to perform some type of Internal/DMZ network distinguish. As a matter of fact, the only way the traffic should flow is from your INTERNAL network to DMZ, essentially, the internal servers opening connections towards servers in DMZ.
