Educause Security Discussion mailing list archives
Re: AD across multiple campuses
From: John Ladwig <John.Ladwig () CSU MNSCU EDU>
Date: Fri, 20 Feb 2009 15:23:52 -0600
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
Current thread:
- AD across multiple campuses Jeff Kell (Feb 20)
- <Possible follow-ups>
- Re: AD across multiple campuses John Ladwig (Feb 20)
- Re: AD across multiple campuses Dexter Caldwell (Feb 20)
- Re: AD across multiple campuses Michael Sinatra (Feb 20)
- Re: AD across multiple campuses Scott Weyandt (Feb 20)
- Re: AD across multiple campuses Dexter Caldwell (Feb 22)
- Re: AD across multiple campuses John Ladwig (Feb 23)