Re: [ActiveDir] DMZ and Trusts

Tue, 29 Aug 2006 06:57:53 -0700

Interesting.  I stick by the original note I posted. The risks are more procedural, such as the example you mentioned about the passwords being the same.  The other issue noted is that it is really no longer a DMZ if the internal users can access it. 
 
I don't know of any other increased risks outside of those categories. The traffic originates only from one direction, and the risk may be tolerable for the requirements it meets in your case.
 
For what it's worth, I personally think that the added complexity put on the users of the service is warranted as a reminder to let the user know they are administering in a higher security zone. I think this reminder outweighs the convenience and plays a part in the reliablity and stability and is in keeping with the intended purpose of a DMZ topology.
 
My thoughts though.  I'm not a security expert, but I sometimes play one on the internet so take the opinion with that knowledge.
 
Al

 
On 8/29/06, Wyatt, David <[EMAIL PROTECTED]> wrote:
Hi Al
 
I am "pulling" the statement from a Microsoft chat transcript found here:
 
 
One of the quotes says:

Paul Rich MS (Expert):
Jim, creating a trust from your internal forest to the externally facing forest is definitely something that presents security risks. Although I'm not saying it can't be done, I wouldn't do it but then I don't have a requirement to do so. Creating trust from the DMZ/external forest to the internal forest is normally done in order to allow internal folks to administer the external forest, which is a legitimate desire. However, there are risks with creating the trust in that direction.

What I am trying to find out is what these "risks" are.  I know the transcript goes on to say about the use of passwords that could be the same for both the internal and external forests but I am more interested in any known exploits, hijacks etc that may exist.

I wouldn't configure a firewall rule with ANY---->DMZ anyway.  There would be a set of rules for external--->DMZ and internal--->DMZ.  Each would have specific rules for the services that are required.

-David

 

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Al Mulnick
Sent: 25 Aug 2006 18:01
To: [email protected]
Subject: Re: [ActiveDir] DMZ and Trusts

Where are you pulling the "not recommended" from?
 
The issues are not typically technical, but rather procedural once you get past the, "yes, but if it's a DMZ, should internal users have direct access?" questions. :)
 
One other thing to point out: the users will also have to have direct access to the application.  From a network perspective, that's often seen as an issue because the firewall is then configured for any -->DMZ host. That really does defeat the purpose of a DMZ in most cases.
 
My added $0.04 anyway.
 
-ajm

 
On 8/25/06, Wyatt, David <[EMAIL PROTECTED]> wrote:
Hello
 
Imagine the following scenario, you have an internal W2K3 forest and an external W2K3 forest on the DMZ.  Management wish to create one-way trust between the two forests so the DMZ forest trusts the internal forest for an application.
 
I have read that this is obviously possible but not recommended and cannot find out why.  Does anyone know what the exact security issues or exploits could be?  Assume we have a firewall with the rules configured to only allow trust traffic through.
 
Regards
David

****************************************************************************

This message contains confidential information and is intended only

for the individual or entity named. If you are not the named addressee

you should not disseminate, distribute or copy this e-mail.

Please notify the sender immediately by e-mail if you have received

this e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free

as information could be intercepted, corrupted, lost, destroyed, arrive

late or incomplete, or contain viruses. The sender therefore does not

accept liability for any errors or omissions in the contents of this

message which arise as a result of e-mail transmission.

If verification is required please request a hard-copy version.

This message is provided for informational purposes and should not

be construed as an invitation or offer to buy or sell any securities or

related financial instruments.

GAM operates in many jurisdictions and is

regulated or licensed in those jurisdictions as required.

****************************************************************************



Reply via email to