Re: DMZ NT4 TO Internal 2000 AD One-Way Trust via Firewall

From: Brian Daniel (bdaniel1_at_cinci.rr.com)
Date: 05/10/04 

Date: Mon, 10 May 2004 14:05:50 -0400

Al,

Thanks for the rant/feedback. While I take exception to some of your
propaganda...err... warnings :-) .. I do appreciate your commentary and am
curious for some explanation of the comments I've added below:

Lastly, your take has spurned further conversations to re-look at our
design... so understand that my sometimes-sarcastic slant is strictly based
on being confident in some of your statements.

Others are welcomed to chime in. I want to be sure we are making the right
decision in the spectrum of security - not the overkill "fear the world and
don't trust your firewalls" one or the senseless un-secure ones.

Regards,

Brian

"Al Mulnick" wrote in message
> My take is that you're skirting the real issue. You're taking an
> unnecessary risk for the convenience of a few that really have no business
> with direct access (in most companies developers are NEVER allowed to
touch
> production. They're strictly isolated to prevent "tinkering" and such.)

As you know, every situation is different for every company depending on
application, type of access, support infrastructure, etc. Our goal is to
separate roles/responsibilities (SOX) that fit into our enterprise-wide
Identity management framework to provide trackable changes per server, and
leverage an effectivity security policy to ensure that password complexities
and regular changes are enforced. Who is getting to the boxes and why is
outside the scope of my question.

> That said, I think the proposed is likely going to work. If not, you'll
> quickly see the port access attempts in the logs and can fix.

Great. Thanks.

> You can't do PPTP with NT4.0. You'll need Windows 2000 or higher. If
that's
> your PDCe, then you could use it with shared secret (it's just a VPN so
you
> just need to configure the GPO and a shared secret for them to build the
> tunnel.)

Thanks for the clarification. It definitely doesn't seem to be a popular or
well-supported solution (at least from what research I've tried to locate).

> That said, I will reiterate that I think it's a bad idea to do this.
You're
> basically, from your post, wanting to throw technology at a layer-8
problem.

An AD 2003 separate forest is less technology to throw than opening up 3
portsfrom the DMZ PDC to the Internal PDCe? I'm not following.

> That never really works in the long term. Since you have "All support is
> currently a mess of local and domain users, no security policy, etc.
> Workgroup isn't a popular choice given the number of servers and
differences
> between."
> I'd say that you need to properly define your policies and then make your
> environment support the policy. You haven't yet done that, yet you want
to
> throw technology at it. Why? Doesn't that seem backwards to you?
Awkward
> at least?

We have in fact defined the policy - which in short is to provide one
user/one account Identity Managment vision - thus the project to clean it
up. My question is whether or not the administrative overhead of managing a
workgroup/separate forest for 12 boxes only accessed via web ports AND the
increased risk for internal name lookups OUTWEIGHS the benefit of leveraging
our already established internal name infrastructure.

> Why do you need to keep NT4 out there? Why do you not use two separate
> forests as in best practices? Why?

Our NT4.0 boxes acting as DCs have application dependancies (local to the
DMZ, not publicly accessible) that aren't going away within the stated
timeframe for the project. Regardless - the DMZ is only accessible publicly
to non-DC web servers in the DMZ on 80 and 443 - none of which are directed
to domain controllers. So we're still only as good as the security of our
web servers (all 2000+), correct?

I'd challenge that a true (not M$) LDAP metadirectory greatly outperforms a
full functioning 2003 AD forest that requires domain policy management, DNS
infrastructure, enhanced hardware requirements, etc simply to manage the
user authentication for 12 resources. Sounds like overkill in our current
"fear-based networking" climate.

> NT4 is not a security focused OS. To overrun and own that, would not be
> terribly difficult.

Enlighten me as to how a DMZ segment that is only accessible on 2000+ server
web ports (all running the latest version of IE) is any less secure by
having NT4.0 as a domain controller in the same segment. What further
benefit would we gain by running an isolated NT domain (no trust) vs. a 2003
forest in your example above?

> And once you did, you could camp in your DMZ for many
> moons. You also have free reign internal whenever you feel like it, since
> the checkpoint trusts the DMZ host(s).

Incorrect. the only open inbound NETBIOS ports are to the PDC Emulator.
Access to no other internal resources is possible.

> You also have a LOT of information
> since lmhosts is there,

It would contain one entry and an IP...?

>and browser into the network is functional.

to only to 1 host???

> Shouldn't be too difficult to get in and trapse about undetected depending
> on other security measures.

>
> Al
>
>
> "Brian" <bdaniel1@cinci.rr.com> wrote in message
> news:ca27c203.0405070900.37fac451@posting.google.com...
> > I've read a few different threads on similar (but not quite the same)
> > scenerios, so here goes.
> >
> > 1. We have a 12-resource (mostly 2000 web servers) NT 4.0 domain in
> > our Checkpoint firewall-protected DMZ subnet. All support is
> > currently a mess of local and domain users, no security policy, etc.
> > Workgroup isn't a popular choice given the number of servers and
> > differences between.
> >
> > 2. Therefore, we are looking to setup a one-way trust to our internal
> > 2000 AD for support user authentication only. I've read that the
> > ports necessary for an NT 4.0 -> 2000 trust are the same as an NT ->
> > NT (no LDAP, LDAPS, GC ports necessary), as long as you are pointing
> > to NT4 PDC -> 2000 PDCEmulater. Question - is this correct??
> >
> > The list of ports I have is:
> >
> > From-To Client Port(s) Server Port Service
> > DMZPDC-IntPDC 1024-65535/TCP 135/TCP RPC
> > DMZPDC-IntPDC 137/UDP 137/UDP NetBIOS Name
> > *AllDMZServers-IntPDC 138/UDP 138/UDP
> > Netlogon/Browsing
> > DMZPDC-IntPDC 1024-65535/TCP 139/TCP NetBIOS
> > **DMZPDC-IntWINS 1024-65535/TCP 42/TCP WINS
> > Replication
> >
> > *per article 179442
> > **optional - read below
> >
> > 3. I've read both sides of the option regarding name resolution. In
> > our environment, I'm leaning NOT to run WINS Replication across the
> > firewall (use lmhosts instead), since the outside boxes only have to
> > know the name of the internal domain and the PDC emulator, but I'd
> > appreciate anyone's insight on whether or not the risk/benefit is
> > worth the admin overhead of managing 10 different lmhosts files and
> > the potential for single POF? I've never been a fan of hosts or
> > lmhosts, but it may make the most sense from a security perspective.
> >
> > 4. I've also read about leveraging PPTP for the trust as well - but
> > have had no luck finding documentation other than the port number.
> > Anyone have any insight?
> >
> > Your assistance in verifying my information is MUCH appreciated.
> >
> > Regards,
> >
> > Brian Daniel
>
>

Relevant Pages

  • Re: DMZ - Question
    ... Many times you will go as far as to have a web facing DMZ ... security requirements these systems will likely be on their own VLAN at ... architecture to prevent any web facing servers connecting into the ... Mainframe on the LAN, and a Mail server that need access to another ...
    (Security-Basics)
  • Re: Deploying a DMZ Internationally
    ... Subject: Deploying a DMZ Internationally ... that there is almost always a lack of corporate security policies in place ... In addition to VLANS you should work on defining security domain boundaries. ... > involved with moving servers to these DMZs and the warfare that will ...
    (Security-Basics)
  • Re: PIX network config advice
    ... servers are really at once the code hits the box. ... the DMZ, and it works well. ... Thanks for the advice, like I mentioned all my servers are configured from a DHCP entry, so it's simply just assigning the new non-routables from there and then adding the map to the public IP on the PIX. ... I'll certainly test it in my lab, I think I'll go with it - any extra security is a good thing:D ...
    (comp.dcom.sys.cisco)
  • Re: Joining Servers to a Domain
    ... You can certanly stop policies and scripts from running on specific servers, so that really shouldn't be the determining factor. ... I would be asking questions as to what security benefits they would expect to see, though there are certanly some security and management benefits. ... Usually people will have a seperate forest for the DMZ and use either a trust or federated services to provide access to an internal resource. ...
    (microsoft.public.windows.server.active_directory)
  • Re: hisecweb.inf hardening
    ... You can use the Local Security Policy MMC snap-in to setup the ... hisecweb.inf security template. ... How do I secure Stand alone servers such as public web ...
    (microsoft.public.windows.server.security)