Re: AD across multiple campuses

[Scott Weyandt <scott.weyandt () MORANTECHNOLOGY COM>]

It is a fact that true security boundaries exist only between forests.  So,
if you need to isolate the 35 institutions such that "Authenticated Users"
at Institute A are not able to access anything that's not explicitly ACLed
in Institute B, then separate forests are necessary. However, 35 forests is
a lot of management overhead and 100 locations and 100K seats is NOT an
issue from a scale perspective for a forest.  Accordingly, individual
forests should only be recommended (or implemented) where you want to
eliminate all access between domains except for where access is explicitly
provided via ACLs.  In most cases this isn't required.

As far as the original post about the network numbering. You can definitely
do domain controller replication over the Internet. The best way to do it is
with IPSec tunnels (directly between DCs even,
http://technet.microsoft.com/en-us/library/bb727063.aspx). You shouldn't
need to configure the AD (or network) topology such that every client needs
to be able to talk to every DC. A lot of organizations simply can't do this.

It's fine to run AD traffic over mixed use links. In fact, our lead MS
Architect, Brian Desmond is speaking about this at DEC in a few weeks. Brian
is also the author of O'Reilly's latest version of Active Directory
(http://oreilly.com/catalog/9780596520595/?CMP=AFC-ak_book&ATT=Active+Direct
ory).  Obviously he knows a lot more about this than I do, so if you have
any additional questions about this send me a personal email and I will give
you his contact information.  He's always happy to answer questions and can
frequently found on the new Microsoft Higher Ed listserv:
http://www.windows-hied.org/

Thanks.

*****************************************************************
Scott Weyandt, PhD
Director, Security and Infrastructure Planning
Moran Technology Consulting
877-214-2980 (Voice & Fax)
Website:  www.MoranTechnology.com
*****************************************************************


-----Original Message-----
From: The EDUCAUSE Security Constituent Group Listserv
[mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of John Ladwig
Sent: Friday, February 20, 2009 3:24 PM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: Re: [SECURITY] AD across multiple campuses

As I recall, MS AD engineers recommended to our large (100 location, 35
institution, ~100k-node) system that we *not* attempt a single forest, as
interforest boundaries are the only place where security can be applied.

The recommendation they whiteboarded was for a coordinated user namespace,
and tie per-institution forests together using a systemwide LDAP.

We've not attempted to build that, yet, and MS large-scale advise may have
changed in the last...  16 months.

Also, in our system, we are pretty federal; each institution has
responsibility for its own IT, and then there's another Systemwide IT
function for enterprise apps, and the wide-area network.  

Suggestions made for us should be compared carefully to your local
environment.

   -jml

> > > Jeff Kell <jeff-kell () UTC EDU> 2009-02-20 15:17 >>>
We are again revisiting a "single forest" integration of AD across
multiple campuses in the system, and the inevitable pros/cons and issues
are starting to roll in.  I'm interested in any information / pointers /
feedback / suggestions from other sites that have done or tried this
approach.  Specifically with regard to routing/addressing and overall
security (not just the AD components)...

Each campus is essentially a separate network entity now, no private
links / leased lines / hocus-pocus.  We have our individual internet[2]
providers.

Most sites are using RFC-1918 addresses internally, to varying degrees,
some are required to (lack of public IPs).  The RFC-1918 space currently
overlaps.

Each site will have it's own domain (tree?) but there is a desire for
cross-site replication and redundancy of domain controllers.

The current "desire" from the design group (I'm certainly no AD guru,
I'm network/security) states that each user on each campus must have a
globally unique IP address, such that "any" user at "any" campus can
authenticate to "any" of the domain controllers.  Some us will have to
renumber our 1918 space, but it is doable.  Private links (either
leased, site-to-site VPN, or MPLS-provider private vlans) have been
proposed to route the AD client/domain traffic within the system. 

Having survived Blaster, Slammer, Nachi, Conficker (so far), and other
network nightmares exploiting Microsoft infrastructure in the past, I'm
very concerned about having one big flat system-wide routed domain. 

Restricting the "private" links to "only" AD-related traffic seems
troublesome as well (firewalls, policy routing, etc), but perhaps not
insurmountable.  There is a great deal of existing inter-campus traffic
(operating through traditional NAT/firewalls) for centralized SAP/R3,
video traffic, distance learning, distributed printing, and other
cases.  Much of this is freely intermixed on networks that would also
have AD clients/servers. 

Is all of this really necessary to provide the desired result?  Is
anyone doing this over "the public internet" ?

Can DC-to-DC replication happen across NAT, without all this other
infrastructure/exposure?

Can client-to DC authentication happen across NAT?

Is there some way to keep the existing site network/routing autonomy?

Jeff Kell
University of Tennessee at Chattanooga