[isalist] Re: New Articles on Tales
- From: Steve Moffat <steve@xxxxxxxxxx>
- To: ISA Mailing List <isalist@xxxxxxxxxxxxx>
- Date: Mon, 17 Aug 2009 09:35:02 -0300
http://www.ISAserver.org
-------------------------------------------------------
Ahh, you've put on your tinfoil hat again.....
-----Original Message-----
From: isalist-bounce@xxxxxxxxxxxxx [mailto:isalist-bounce@xxxxxxxxxxxxx] On
Behalf Of Thor (Hammer of God)
Sent: Monday, August 17, 2009 12:44 AM
To: ISA Mailing List
Subject: [isalist] Re: New Articles on Tales
http://www.ISAserver.org
-------------------------------------------------------
After seeing the mental whitewash that you are capable of, I'm grateful my
"cranium protection" is intact. You've clearly illustrated the consequences of
attempting logic without it. :)
t
-----Original Message-----
From: isalist-bounce@xxxxxxxxxxxxx [mailto:isalist-bounce@xxxxxxxxxxxxx] On
Behalf Of Jim Harrison
Sent: Sunday, August 16, 2009 8:29 PM
To: ISA Mailing List
Subject: [isalist] Re: New Articles on Tales
http://www.ISAserver.org
-------------------------------------------------------
My argument was never about how DM benefits Exch Edge itself, but how it
potentially benefits *ANY* server deployment.
It's you who are unfortunately unable to release that chew-bone. This behavior
smacks very strongly of thin metal cranium protection.
:-)
-----Original Message-----
From: isalist-bounce@xxxxxxxxxxxxx [mailto:isalist-bounce@xxxxxxxxxxxxx] On
Behalf Of Thor (Hammer of God)
Sent: Sunday, August 16, 2009 8:21 PM
To: ISA Mailing List
Subject: [isalist] Re: New Articles on Tales
http://www.ISAserver.org
-------------------------------------------------------
Well, I know you too well to think that you'll actually come around to agreeing
with me after a public exchange like we've had, but at least I've peeled away
the "people who think installing Edge (or anything) as a WG instead of a DM are
a 'tinfoil hat crowd'. If anything, THAT statement was the absolute, and I'm
still puzzled why you continue to bring that point up. So far, you are the
only one who has mentioned absolutes.. No one said that anything was an
absolute. No one said "do it the way it's always been done," or "do it this
way or not at all." Well, except you.
I'll no longer try to point out the fallacy of your "logic" here, but I will
mention the following for the benefit of those who are actually trying to make
the appropriate decision for themselves.
First and foremost, you have been unable to list a single point of how a DM
member for Exchange Edge increases security. Pulling in TMG into it and it's
security model is specious. Trying to make the point that "well, if you say
ANY server is better with TMG, the Edge MUST ALSO be better with TMG" is silly.
Thinking that you can somehow manage DMZ resources if they are domain members
but can't if they are WG members is simply incorrect.
You going from "tin hat if you don't" to not being able to list a single
security benefit from doing so is quite a gap. WG/DM does not dictate one's
ability to patch, so that (yet again) straw man argument is dead.
But, that being said, and like I've said all along, do whatever fits your needs
with risk and threat being weighed properly, and I'm glad you've ended your
post by agreeing with me on that. I wish you would have started it that way
rather that positioning those concerned with security as wearer of tinfoil hats.
Hans, here's my suggestion, and it depends on the topology itself.
If your deployment looks like this:
Internet --> Edge Role/TMG ---> LAN
Then make it a domain member. But it's not really an "edge" asset, you're just
running Ex Edge role on it. If it is a "true" or "close enough" edge topology
like this:
Internet --> Edge Role/TMG ---> DMZ ---> ISAorTMG ---> LAN
Then make the "external/edge" Edge Role/TMG box a WG, and the "internal" or
"dmz facing" TMG box a domain member. Now, that being said, if you really have
a substantial number of edge resources out there that, by sheer number,
actually do create a security issue if you can't figure out how to patch and
maintain them as WG members, then feel free to create a separate edge forest
and go nuts. Just don't have authentication boundaries cross through your DMZ.
t
-----Original Message-----
From: isalist-bounce@xxxxxxxxxxxxx [mailto:isalist-bounce@xxxxxxxxxxxxx] On
Behalf Of Jim Harrison
Sent: Sunday, August 16, 2009 6:01 PM
To: ISA Mailing List
Subject: [isalist] Re: New Articles on Tales
http://www.ISAserver.org
-------------------------------------------------------
[Thor #1] - "the local ADAM instance contains recipient email address
information, not account name information" - given that very few deployments
actually force the users to choose an email address that differs from their
domain account, this point is very nearly moot. The replication is a pull model
using a domain account (one your personal pet peeves). Regarding the number of
protocols allowed between the edge host and the domain, this (as you're known
to suggest) is mitigated through the judicious use of IPsec.
[Thor #2] - "*ANYTHING" deployed concurrently with TMG would offer those
advantages" - true, but we're not discussing "anything", are we? The point
(studiously ignored, it seems) is if the fear is that a domain member at the
edge poses a greater threat than a WG, much of the network attack surface
argument is mitigated by collocating with TMG (more so even than using ISA).
[Thor #3] - I'm not arguing that Exch Edge in and of itself benefits from
domain membership. I'm arguing that ANY server deployed as a DM benefits from
the centralized management and monitoring that comes with being a DM. Since we
agree that it benefits ANY server, we agree by extension that it benefits Exch
Edge.
[Thor #4] - The question posed by Han concerns the combined Edge/TMG deployment
and the apparently conflicting "best practices" offered by the two teams. My
point in this is that if deploying Edge as a DM creates a conflict in the
security model, then if you deploy edge on TMG, you logically extend that
conflict to the TMG server as well. At this stage of the threat modeling, you
have a decision to make. You balance the pros/cons of Edge as a DM against TMG
as a DM and decide if they present a conflict. If so, separate them or accept
the reduction in your perceived security model. It's just that simple.
We do agree that extending your AD authentication into the DMZ (assuming one
exists at all) is generally less secure than not doing so, but to offer this as
an absolute blocker fails to address the FACT that business needs will dictate
the final solution and this is the crux of the biscuit I have been offering -
there are NO ABSOLUTES. Your threat model dictates how you deploy. If you have
none or you choose to "do what has always been done", or worse yet; apply a
single "do it this way or not at all" mentality, then you have failed; and that
most epically.
Your continued assertion that management is orthogonal to security ignores the
demonstrated fact that the harder it is to manage a server or system, the more
likely it is to be compromised. When an organization spends $$$ on their
centralized management and monitoring system (whether from MS or not), the
value of that system and the security it offers (whether real or inferred) is
degraded proportionally by the number of servers that have to be handled
separately from that process.
In short, the choice to make a DM or WG of the Exch Edge collocated with TMG is
a choice you have to make with regard to your own business needs and threat
model. The choices boil down to three:
1. EE/TMG as DM
2. EE/TMG as WG
3. separate EE from TMG and re-evaluate the WG/DM question for each
individually.
In addition to separating the threat model for one from the other, you will
lose the ability to centrally-manage your EE servers via the TMG console. This
may be a small or significant issue, depending on your own requirements.
Jim
-----Original Message-----
From: isalist-bounce@xxxxxxxxxxxxx [mailto:isalist-bounce@xxxxxxxxxxxxx] On
Behalf Of Thor (Hammer of God)
Sent: Sunday, August 16, 2009 1:47 PM
To: ISA Mailing List
Subject: [isalist] Re: New Articles on Tales
http://www.ISAserver.org
-------------------------------------------------------
In line:
-----Original Message-----
From: isalist-bounce@xxxxxxxxxxxxx [mailto:isalist-bounce@xxxxxxxxxxxxx] On
Behalf Of Jim Harrison
Sent: Sunday, August 16, 2009 12:49 PM
To: ISA Mailing List
Subject: [isalist] Re: New Articles on Tales
http://www.ISAserver.org
-------------------------------------------------------
Answer to Han, take 2:
It's actually not a contradiction at all (and adding it to the Q&A makes sense).
There are perfectly good reasons (tinfoil hat crowd excepted <VBG>) for
choosing either WG or DM deployment for either TMG or Exch Edge.
The decision to choose one or the other has to be taken in the context of your
own deployment, the business needs and the threat model you apply to them. Do
various people feel strongly about placing DM at the edge of the network? - you
betcha and that's not about to change anytime soon.
1. Exch Edge role *alone* as a DM offers a potentially larger network attack
surface because the Windows firewall (as good as it is) is still not as
"application intelligent" as TMG. The counter-argument that deploying it as a
WG reduces the extended attack surface (you didn't think "attack surface" was
limited to the computer under evaluation, did you?) to your AD is true, but in
this specific case, this point is offset by the fact that you're replicating
accounts to the local ADAM (LDS, for WS08) instance. Thus, a compromised Exch
Edge deployment still offers visibility into your user accounts, making auth
attacks that much easier to mount (depending on your password policies, of
course).
[Thor] - the local ADAM instance contains recipient email address information,
not account name information. Only if one had the email addresses the same as
the account names would this be an issue, which would exist in either case as
an individual would know account information based on organization emails.
DM/WG, Adam or not, does not impact the decision from a security standpoint.
Edge ADAM replication is based on LDP, not "full" AD authentication... If one
made the edge server a domain member, it would require far more protocols to be
opened to authentication servers, particularly if the goal is to simply
management, as outbound rules would have to be created as well, including
outbound auth, which *greatly* reduces security. This exists "outside" of the
Edge Role services.
[/Thor]
2. Exch Edge deployed concurrent with TMG offers the advantages of a much
smaller attack surface with the centralized management of all TMG-concurrent
Exch Edge servers. While it's true that any compromised edge-deployed DM offers
visibility into the AD structure, a TMG-concurrent Exch Edge deployment is less
threatened than an Exch Edge deployment by itself.
[Thor] *ANYTHING" deployed concurrently with TMG would offer those advantages.
This would be the case with or without domain membership, and is not bound to
server role. This example simply reduces the inherent risks of having the edge
server be a domain member when TMG is deployed concurrently, but does nothing
to substantiate any perceived benefits of the server being a domain member.
The same could be said for a web server, IIS box, or Quake server.
[/Thor]
3. Tom did an excellent job of thinking through the major issues with deploying
ISA as a DM in his article at isaserver.org
(http://www.isaserver.org/tutorials/Debunking-Myth-that-ISA-Firewall-Should-Not-Domain-Member.html).
This should be part of your considerations when evaluating Exch Edge
deployments as well; especially tose that include TMG.
[Thor] "At no time shall my fingers leave my hand..." SQL server, when
deployed as domain member, has many benefits not offered by WG. But one cannot
simply say that Exchange Edge inherits the same type of benefits in the same
manner simply by also being a DM. Different services, different goals.
ISA/TMG being a domain member, and the benefits therein, have nothing to do
with Edge, as Edge doesn't do the same thing as TMG.
[/Thor]
If deploying Exch Edge on a DM causes a fault in your security model, then it's
also possible (maybe even likely) that deploying TMG as a DM has a similar
effect; especially when deploying them together on the same machine. This is a
perfect example is where the business needs and the threat model come together
to force decisions that contradict "best practices".
[Thor] Again, I disagree. TMG as a domain member allows for domain-based
authentication of rules to users and groups in multiple authentication/protocol
models. Edge does not benefit from membership choices. I really want to drive
this point home:
The TMG services themselves -- the role of the server itself -- offers
increased security options and methods when the server is a domain member.
Edge does not. There is nothing about the Edge services themselves that are
affected by the domain membership. DM or WG, you still have to provide an
account to LDAP for local adam if you choose to do so. Authentication
mechanism to hub transports are not affected, and rules need to be created on
your intra-edge box to support these mechanisms, irrespective of DM or WG. Can
you more easily *manage* the box? Sure - at the price of reduced security.
With or without ADAM, with or with TMG, there is nothing about deploying an
Exchange Edge server as a DM that increases the security of the role itself.
There are *several* security risks that ARE introduced by making it a DM such
as:
-Required authentication and management traffic into/out of the internal
network.
-Cached domain credentials on the server itself -- even if not cached, the
machine's account allows for leverage of exploitation on internal assets even
if a vulnerability requires authentication. Measures can be taken to reduce
these risks, but they MUST be taken if a DM, not so if a WG.
-Domain credentials/tokens will very likely be in memory and can be leveraged
by an attacker, particularly if someone is logged on to the console of the box,
or if services are running under domain credentials.
-any user anywhere in the forest, or trusted entities, will be an
"authenticated user."
In summary, making an Exchange Edge server (or any other edge asset) a domain
member, where doing so doesn't explicitly increase the security posture and/or
features of the core services, reduces overall security of the asset,
regardless of what bolt-on measures you put in place to mitigate those risks.
[/Thor]
t
-----Original Message-----
From: isalist-bounce@xxxxxxxxxxxxx [mailto:isalist-bounce@xxxxxxxxxxxxx] On
Behalf Of Han Valk
Sent: Saturday, August 15, 2009 11:54 PM
To: isalist@xxxxxxxxxxxxx
Subject: [isalist] Re: New Articles on Tales
http://www.ISAserver.org
-------------------------------------------------------
As far as I know Exchange Edge is to be installed on a workgroup server while
TMG does its best job when domain joined. So this is a bit of a contradiction
to me. I would love to see guidance from Microsoft on that. Maybe this can be
added to the Q&A in Understanding Email Protection on TMG.
Han.
> -----Original Message-----
> From: isalist-bounce@xxxxxxxxxxxxx [mailto:isalist-bounce@xxxxxxxxxxxxx]
> On Behalf Of Jim Harrison
> Sent: Sunday, August 16, 2009 00:35
> To: isalist@xxxxxxxxxxxxx
> Subject: [isalist] New Articles on Tales
>
> http://blogs.technet.com/isablog/archive/2009/08/15/new-tales-from-the-
> edge-articles.aspx
------------------------------------------------------
List Archives: //www.freelists.org/archives/isalist/
ISA Server Newsletter: http://www.isaserver.org/pages/newsletter.asp
ISA Server Articles and Tutorials: http://www.isaserver.org/articles_tutorials/
ISA Server Blogs: http://blogs.isaserver.org/
------------------------------------------------------
Visit TechGenix.com for more information about our other sites:
http://www.techgenix.com
------------------------------------------------------
To unsubscribe visit http://www.isaserver.org/pages/isalist.asp
Report abuse to listadmin@xxxxxxxxxxxxx
------------------------------------------------------
List Archives: //www.freelists.org/archives/isalist/
ISA Server Newsletter: http://www.isaserver.org/pages/newsletter.asp
ISA Server Articles and Tutorials: http://www.isaserver.org/articles_tutorials/
ISA Server Blogs: http://blogs.isaserver.org/
------------------------------------------------------
Visit TechGenix.com for more information about our other sites:
http://www.techgenix.com
------------------------------------------------------
To unsubscribe visit http://www.isaserver.org/pages/isalist.asp
Report abuse to listadmin@xxxxxxxxxxxxx
------------------------------------------------------
List Archives: //www.freelists.org/archives/isalist/
ISA Server Newsletter: http://www.isaserver.org/pages/newsletter.asp
ISA Server Articles and Tutorials: http://www.isaserver.org/articles_tutorials/
ISA Server Blogs: http://blogs.isaserver.org/
------------------------------------------------------
Visit TechGenix.com for more information about our other sites:
http://www.techgenix.com
------------------------------------------------------
To unsubscribe visit http://www.isaserver.org/pages/isalist.asp
Report abuse to listadmin@xxxxxxxxxxxxx
------------------------------------------------------
List Archives: //www.freelists.org/archives/isalist/
ISA Server Newsletter: http://www.isaserver.org/pages/newsletter.asp
ISA Server Articles and Tutorials: http://www.isaserver.org/articles_tutorials/
ISA Server Blogs: http://blogs.isaserver.org/
------------------------------------------------------
Visit TechGenix.com for more information about our other sites:
http://www.techgenix.com
------------------------------------------------------
To unsubscribe visit http://www.isaserver.org/pages/isalist.asp
Report abuse to listadmin@xxxxxxxxxxxxx
------------------------------------------------------
List Archives: //www.freelists.org/archives/isalist/
ISA Server Newsletter: http://www.isaserver.org/pages/newsletter.asp
ISA Server Articles and Tutorials: http://www.isaserver.org/articles_tutorials/
ISA Server Blogs: http://blogs.isaserver.org/
------------------------------------------------------
Visit TechGenix.com for more information about our other sites:
http://www.techgenix.com
------------------------------------------------------
To unsubscribe visit http://www.isaserver.org/pages/isalist.asp
Report abuse to listadmin@xxxxxxxxxxxxx
------------------------------------------------------
List Archives: //www.freelists.org/archives/isalist/
ISA Server Newsletter: http://www.isaserver.org/pages/newsletter.asp
ISA Server Articles and Tutorials: http://www.isaserver.org/articles_tutorials/
ISA Server Blogs: http://blogs.isaserver.org/
------------------------------------------------------
Visit TechGenix.com for more information about our other sites:
http://www.techgenix.com
------------------------------------------------------
To unsubscribe visit http://www.isaserver.org/pages/isalist.asp
Report abuse to listadmin@xxxxxxxxxxxxx
------------------------------------------------------
List Archives: //www.freelists.org/archives/isalist/
ISA Server Newsletter: http://www.isaserver.org/pages/newsletter.asp
ISA Server Articles and Tutorials: http://www.isaserver.org/articles_tutorials/
ISA Server Blogs: http://blogs.isaserver.org/
------------------------------------------------------
Visit TechGenix.com for more information about our other sites:
http://www.techgenix.com
------------------------------------------------------
To unsubscribe visit http://www.isaserver.org/pages/isalist.asp
Report abuse to listadmin@xxxxxxxxxxxxx
------------------------------------------------------
List Archives: //www.freelists.org/archives/isalist/
ISA Server Newsletter: http://www.isaserver.org/pages/newsletter.asp
ISA Server Articles and Tutorials: http://www.isaserver.org/articles_tutorials/
ISA Server Blogs: http://blogs.isaserver.org/
------------------------------------------------------
Visit TechGenix.com for more information about our other sites:
http://www.techgenix.com
------------------------------------------------------
To unsubscribe visit http://www.isaserver.org/pages/isalist.asp
Report abuse to listadmin@xxxxxxxxxxxxx
Other related posts:
