The "outbound only policy" is only applies when it makes sense - nothing I say is ever put as a postulate. If you can do it, do it, if you can't don't. In regard to Exchange, as previously noted, the bi-directional properties of the rule are mitigated by the application filter, and I'm good with that. I think this is where our disconnect came last time... First, bringing in "compliance" in this discussion is non sequitur. "Compliance" has nothing to do with security or the technical aspects of the question; let's not drop red herrings into this please. I still fail to understand how one can "manage and patch" so much easier in a domain than in the DMZ as a WG member - I'd really like for you to elaborate on that... If you are referring to push configurations and remote RPC based policy, then I would have to say that with the rules necessary to create a fully functional domain-based communications path to the system, you might as well not even have a DMZ, at least in respect to that system. If one must compromise the integrity of the DMZ structure to accommodate management goals, then someone has lost sight of the purpose of a DMZ. It would take a plethora of rules to deploy a fully managed domain member in the DMZ. One must treat the DMZ as a "when it is owned" set of assets. In this case, having systems fully managed from the internal network severely limits the strength of a DMZ. I have a production Exchange Edge box in my DMZ that is not a domain member. Once you configure the box, there isn't any management one needs to do, really. Turn on auto updates and be done with it. Having rulesets in place 24/7 to allow for remote management is far more of a threat/risk than even an unpatched box would be in a "proper" DMZ. The main point is to start from a position of security, and design around that. If you find that you absolutely have to destroy the integrity of a DMZ structure by supporting domain members, well, that's something you just have to do. But to start off with "management and patching might outweigh the need for security" is back-asswards, and obviates the purpose of a DMZ in the first place. t From: isalist-bounce@xxxxxxxxxxxxx [mailto:isalist-bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison Sent: Wednesday, January 20, 2010 5:04 PM To: isalist@xxxxxxxxxxxxx Subject: [isalist] Re: [isapros] Re: Exchange Server 2010 Edge and TMG 2010 Integration I promise not to use references to thin cooking accoutrement headgear if you do... <oops; too late> Tim and I agree in principle - it's where implementation comes into play that we find ourselves reshaping our headgear. The question of domain vs. WG membership as a threat mitigation in and of itself typically ignores additional aspects of this question that an organization has to satisfy, such as compliance, management, patching, etc. Very frequently, the needs of the management outweigh the needs of the security or the traffic profile and its in these cases that you need to broaden your thoughts and do the "pro/con" checklist for yourself. Tim's arguments that a properly-defined and -managed traffic policy can do great things with mitigating this threat are absolutely correct (as I said; we agree in principle). Sadly, Tim's "outbound-only" traffic policy can't be used for Exchange SMTP connections because the Exchange team dropped such nice toys as TURN and ETRN in Exchange 2007 (shame, that). There are likely plenty of other examples where you have to adjust your traffic and deployment policies to meet the limitations of the applications and organizational requirements and you'll need to understand these before you make your final decision (or leave yourself some wiggle room afterwards).. Yes; absolutely seek opinions, options and technical thingies and weigh them all against your own requirements and limitations. You are the only one that can make the decision for your deployment and if it's based solely on "he said", then you haven't done your homework. None of the "reference folks" on this alias will intentionally steer you wrong, but neither can you base your decisions on these discussions alone. Security is not a goal; it's a repeating task. There is no "silver bullet" and the search for one can only end in unplanned cranial follicle freedom. ..we now return you to your irregularly-scheduled discussions... ..so there; thpthpthpthp :-) From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Tim Mullen Sent: Wednesday, January 20, 2010 9:37 AM To: isapros@xxxxxxxxxxxxx Subject: [isapros] Re: Exchange Server 2010 Edge and TMG 2010 Integration Jim and I recently had a rather "spirited" conversation around this. Hopefully we'll leave out things like "tin foil hat" this time :) (I had to Jim). My general though is to start with security in depth and least privilege in mind. As such, I begin the design of an Exchange Edge deployment with the mindset that I will not have them as domain members, but rather, simply stand-alone servers in a workgroup. I guess my first question would be, what makes you think it is more complex and that it requires a more difficult configuration? The role of the Exchange Edge is to accept SMTP mail for your domains, and presumably, to filter for spam and malware. This only requires SMTP to the perimeter and nothing else. If you choose to filter for recipient information, you can create an account for ADAM synchronization, however, I think you will find that the EE anti spam options are severely lacking in that respect - the logic is backwards; you can allow all main in TO someone, but not FROM someone, which totally defeats the purpose. I doubt you will use the feature at all, which means that ADAM sync is not necessary. Irrespective of that, the purpose of isolating the exchange edge box is to mitigate exposure should the server become compromised. If you DO make it domain member, then that box will have stored credentials for administrative access available to an attacker, as well as the necessary traffic rules to your DNS and domain controllers to fully compromise your entire network. My main rule in designing DMZ structures where there is anonymous access to the public for services (SMTP) is that "no credentials may live on that box which may be used on the internal network). Making that box a domain member breaks that. Now, that being said, am I to understand that you also wish to provide OWA, OA functionality via the Edge box? If so, I don't see why - access to those services requires authentication, and can further be limited to certificates, so direct publication via TMG to your Exchange front end is acceptable. The EE box should only be used for SMTP inspection. Here's how I do it: I begin with a 3 leg TMG box (UAG in my case): Internal, External, and DMZ. I publish SMTP (with the filter) to the DMZ to the Exchange Edge box. It does it's thing. I then smart-host deliver mail via another publishing rule to the internal Exchange box. Yes, double publishing, with SMTP filter on both. OWA/OA is directly published via 443 to my Exchange box. The EE box is a stand alone server with different credentials. It is managed via a one-way RDP rule. If the EE box is compromised, the ONLY path to the internal network is via the SMTP publishing rule which is protected by the SMTP filter. I have full management capabilities, there is no internal credential exposure, and there is only a single protocol inbound to my network. To me, it is FAR more complex to securely publish and manage a domain member in the DMZ than a stand alone server, and increases the risk of exposure tremendously and really has little benefit. GPO need only be applied once on a role-based server, and can easily be applied via template. That's my buck o' five. t From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jerry Young Sent: Wednesday, January 20, 2010 9:01 AM To: isapros@xxxxxxxxxxxxx Subject: [isapros] Exchange Server 2010 Edge and TMG 2010 Integration I wanted to bounce a question off of the list regarding usage scenarios for integrating TMG 2010 with an Exchange 2010 Edge Server. My goal is to also install Forefront for Exchange on the boxes, too. My question, however, comes down to thoughts on domain membership and TMG utilization. My current thought is to make the Exchange 2010 Edge Servers domain members, install TMG on both of them in an array, and then use that same TMG array to provide reverse proxy access to other resources (like OWA, OMA, OA, CWA, etc.) through publishing rules. As in the past, the Exchange Product Group doesn't want the Edge Servers to be members of the forest in which the Exchange organization is hosted. I ran across postings on the Internet that indicate this can be done but was wondering what the list has seen deployed so far to date. While I could certainly dump the Edge Servers into their own perimeter network, that would require additional complexity, planning, and configuration for my client that they would like to avoid; they accept the risks presented by having the Edge Servers be domain members with the condition that TMG is used to mitigate those risks. Thoughts? -- Cordially yours, Jerry G. Young II Microsoft Certified Systems Engineer Young Consulting & Staffing Services Company - Owner www.youngcss.com<http://www.youngcss.com>