And the funny thing it is one of the very first tools I published for public use....
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick Sent: Thursday, December 08, 2005 12:39 PM To: [email protected] Subject: RE: [ActiveDir] DMZ domains and IPSec - looking for explanation re resource access and authentication 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/ 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/
