Cool. Another awesome tool from joeware.net ! :)
From: "joe" <[EMAIL PROTECTED]>
Reply-To: [email protected]
To: <[email protected]>
Subject: RE: [ActiveDir] DMZ domains and IPSec - looking for explanation re
resource access and authentication
Date: Thu, 8 Dec 2005 11:16:02 -0500
Exactly, you would run lg from the member and use -r dmzDC and it tells LG
to query the dmzDC for the SID and dumps that into the group. Again I
haven't tested it in that scenerio it should work. Certainly it works when
there is NO trust channel at all as it has been used on tens if not
hundreds
of thousands of machines that way.
joe
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick
Sent: Thursday, December 08, 2005 9:52 AM
To: [email protected]
Subject: RE: [ActiveDir] DMZ domains and IPSec - looking for explanation re
resource access and authentication
"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.";
That would surprise me since it's likely that the network path would not
allow the member server to talk directly to the internal domain and would
have a hard time getting resolution. Unless your tool would allow the
mapping to occur from the dc the machine authenticated against and it knew
what to do with it from there.
Be interesting to know for sure though.
>From: "joe" <[EMAIL PROTECTED]>
>Reply-To: [email protected]
>To: <[email protected]>
>Subject: RE: [ActiveDir] DMZ domains and IPSec - looking for
>explanation re resource access and authentication
>Date: Thu, 8 Dec 2005 09:08:41 -0500
>
>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: [email protected]
>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.
>**********************************************************************
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
