RE: [ActiveDir] DMZ domains and IPSec - looking for explanation re resource access and authentication

[joe]

Title: DMZ domains and IPSec - looking for explanation re resource access and authentication

You would need to have the access rights of someone who can talk to the DMZ DC. The local admin doesn't have rights and the lg tool will NOT fall back to anonymous access like the GUI will do.

 

You could log on locally to the member, then do a runas /netonly to fire up a command prompt as a normal user from the DMZ Domain or internal domain and then run the command from there. The local access rights will be admin and the remote connection will be as the normal user.

 

  joe

---

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chakravarty, Sakti
Sent: Thursday, December 08, 2005 8:49 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] DMZ domains and IPSec - looking for explanation re resource access and authentication

Hi joe,

 

Thanks for the response, I thought you'd be able to shed some light on the situation.  I guess I was looking for clarification of the "handled differently" part, since the AD admins here really couldn't explain it.

 

I've had a play around with the lg tool, and I've been able to do add a user from the internal domain.  Thanks! 

 

Just a note, I could not perform that task when logged on as the local administrator of the member server, I had to log in as a Domain User.

 

Cheers

Sakti

---

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe
Sent: Friday, 9 December 2005 1:09 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] DMZ domains and IPSec - looking for explanation re resource access and authentication

I haven't perused the OS source code for this but from my experience this is how it works...

 

In order for the member server to resolve a name to a SID, it needs to be able to connect to a domain controller of the domain specified. If it can't reach the domain controller, it can't convert the name to a SID.

 

The SID to name conversion on the other hand is handled differently. The machine tries to handle it locally and if it isn't a local SID it passes it up to the DC that authenticated the computer (i.e. the DMZ DC) and lets it try to resolve it, that machine will look at its local SIDS (objectsid/sidhistory) and then if it doesn't find it there will start chasing through the trusts.

 

I have never tested that specific scenario but you should be able to add an internal domain secprin to the DMZ member server without working from the DC. It would require a tool that knows how to specify the server to use for the name to sid resolution. Let me think if such a tool exists.... oh yeah, look at lg on my website - http://www.joeware.net/win/free/tools/lg.htm.

 

There is a -r option to specify the machine you want to use for the name to sid resolution. I added that option so you could add secprins from a domain the machine wasn't a member of yet to the admins group so when you added it to the domain, the membership was already set (great for migration scenarios where you aren't a domain admin in the next domain).

 

Now that being said, I am not a fan of internal networks being accessible from the extranet or from the DMZ unless doing very specific individual server:port based reverse proxy with that single port being heavily defended on the internal host. Anything that compromises one of the DMZ domain machines can at the least most likely enumerate info from the internal domains. If someone wants to be cute, they could easily D.O.S. attack you from there as well.

 

   joe

 

 

 

---

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chakravarty, Sakti
Sent: Wednesday, December 07, 2005 10:12 PM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] DMZ domains and IPSec - looking for explanation re resource access and authentication

Hi all,

I'm looking for an explanation … this is a bit of a complicated scenario but I'll try to be succinct.  Whilst I have a fair bit of AD experience, I'm not the AD administrator at my current place of work.  The AD administrators are not forthcoming with information, hence my post here.

We have a corporate network with a Windows 2003 forest (mixed-mode) with multiple domains.  We also have a DMZ, in which there is a separate Windows 2003 forest with a single domain. 

There is an IPSec policy set up between domain controllers in the DMZ domain and domain controllers in one of the domains in the corporate forest (I'll call it the "internal domain").

There is a one-way trust, the DMZ domain trusts the internal domain.

Our aim is to provide access to resources in the DMZ domain, by using accounts in the internal domain.

My role includes managing Member Servers.  We built a server in the internal domain, added some groups from that domain into the Administrators group, then physically moved it to the DMZ.  Then, the names in the Administrators group would no longer resolve (since it is still a member of the internal domain, but physically disconnected from it).  Next, we made the server a member of the DMZ domain, and the names now resolve.  So, it seems the Member Server is talking to the DMZ DC which is querying the internal DC to resolve the name.

What we cannot do, is log onto the Member Server in the DMZ and add an account from the internal domain.  The reasoning we are given is that the IPSec policy and trust is between DCs only, and not the Member Server.  If the DMZ Domain Admin logs onto the DMZ DC, then makes a Computer Management connection to the Member Server, then groups from the internal domain can be added to the Member Server.

Can anyone explain to me why this is so?  I don't understand why resolving names is different to adding a user, it seems to me the same authentication path is followed.

Thanks in advance
Sakti

**********************************************************************
This message is intended for the addressee named and may contain
privileged information or confidential information or both. If you
are not the intended recipient please delete it and notify the sender.
**********************************************************************

**********************************************************************
This message is intended for the addressee named and may contain
privileged information or confidential information or both. If you
are not the intended recipient please delete it and notify the sender.
**********************************************************************