January 18, 2002
It is the design and goal of the Windows 2000 project that every campus Microsoft Windows NT domain be able to become a part of the central forest. This gives the University an economy of scale that is not possible with multiple forest implementations, as well as the considerable benefits of unified, integrated services and user groups.
As such, it is the Windows 2000 project team’s charter to build a common infrastructure that best suits the needs of the entire campus. However if an individual group has unique requirements that cannot be met without compromising the central Windows 2000 forest for the entire campus, it may be appropriate for them to implement their own forest.
Specifically, a local school or department may need an independent forest for one of the following four reasons:
1.
Policy differences
Some schools may run into regulatory or policy issues that run counter to the policies implemented on the central Forest. If this is the case a separate Forest would be needed.
2.
Complete independence
A campus group that currently has complete autonomy in regards to their IT Infrastructure may wish to keep that autonomy.
3.
Instant changes to the infrastructure
If a campus group needed to make immediate changes to Domain Controllers or the Schema this could be accomplished faster in a separate forest. Changes can definitely be made to DC’s and Schema in the central Forest but adequate testing needs to be done to ensure the integrity of the entire Forest. Of course testing would most likely be done in an independent Forest so the speed of a change may not be much different.
4.
Single network points of failure risk too great
Most schools have a single pipe out to the campus network from their building locations. With all DC’s (domain controllers) being housed in Sweet/Forsythe, a campus network outage could prevent access to authenticate against the central DC’s.
However, implementing an independent Forest comes at considerable cost—not only financially, but also in terms of lost functionality, time to implement, increased security risk, and ongoing maintenance. These costs are:
1)
Systems administration support
An independent forest would need considerably more extensive systems administrator support than as a domain or OUwithin the Stanford Windows Infrastructure. The independent forest administrators would need to design an effective network, document the forest infrastructure, forecast capacity requirements, develop a disaster recovery plan, host and support domain controllers, manage directory synchronization, manage forest security policy, and work closely with ITSS Windows, Kerberos, and Directory personnel to ensure continued integration. None of these tasks would be necessary if the campus group joined the Stanford Windows 2000 Forest Infrastructure as a child domain or OU (Organizational Unit). In the Central Forest accounts are created automatically via the Harvester and passwords are kept in sync.
2)
Hardware
Purchase and maintenance of multiple Domain controllers, including backups of the Domain Controllers, would be necessary to create an independent Forest
3)
Domain name system
The campus group would need to maintain their own non-authoritative DNS servers.
4)
Directory services
If a group with an independent forest wished to synchronize user account data from the existing Stanford Directory/Registry, it will need to find effective ways to ensure the existing privacy controls, and will be duplicating the ITSS effort. After duplicating this effort, it will need to maintain privacy settings, and work closely with the Stanford Directory/Registry team.
a.
Account space
An independent forest would most likely have accounts outside the existing
SUNet ID database. This would mean that direct single sign-on integration with
existing services such as pop mail and webauth wouldn’t work.
Designing an independent forest to use the SUNet database would require duplication
of the ITSS project team’s effort in synchronizing accounts, as well as
establishing a Kerberos realm trust with Stanford.edu. ITSS can assist in this
process on a fee based time and material basis. After duplicating this effort,
local departments will need to maintain these accounts, and work closely with
the ITSS Directory and Kerberos teams. Using the SUNet account space obviously
places a reliance on the existing SUNet account creation mechanism. The campus
group may not wish to rely on the SUNet account creation process.
b. Passwords
In the central forest passwords are automatically synchronized between Active
Directory and the Sunet Directory.
Should an independent forest use the SUNet account space, there are
sensitive issues surrounding where passwords are stored. The domain controllers
would effectively be SUNet KDCs (Kerberos Domain Controllers). In addition, the campus group may be
interested in synchronizing passwords to other systems such as their Unix or
Netware directories. This is something which would need to be examined against
existing policies and practices, because of the extension of the security risk.
The campus group would need to work with the Security office and work within
the security policies of Stanford University.
5)
Schema
management
Anyone who implements an independent forest would have to devise their own methods and
policies for schema management. If the campus group makes different schema
decisions than the campus forest, integration between the two forests could become
impossible.
6)
Windows resource sharing
In the central forest sharing resources across departments is as simple as granting rights to any other user in the central forest. If a separate forest wished to share resources with other departments, trust would need to be manually established and the directories in both forests will need to allow directory browsing for accounts in the other forest. This browsing configuration could hold implications down the road with respect to privacy controls on person data. Additionally, more extensive user education will be required to document the alternate account space that the independent forest implements, so that users can easily share files across forests.
When considering creating an independend forest over joining the central forest, it is necessary to consider the benefits that come with joining the central forest. Not only does membership in the central forest provide local groups with the benefits integration with many of Stanford’s other systems, but also it leaves them with considerable autonomy in their local domain.
The benefits listed below come in two types—those services and features that will only be available to members of the central forest, and those services and features that local IT groups will still have the autonomy to provide even as members of the central forest. As local groups evaluate whether to join the central forest or not, they should be aware of the functionality that they will gain as part of the central forest. They should also weigh any unique requirements they might have that won’t be met by the central forest in the context of all the functionality and local autonomy that they will be gaining.
The following captures
some of the near- and long-term benefits of the Windows 2000 infrastructure.
Items marked with an asterisk (*) are available only to those who join the
central forest. Items marked with a cross (†) are services and features that
local groups within the Windows 2000 central forest will still have the
autonomy to offer/implement.
·
Integration with Existing Services*
In keeping with its mission ITSS is designing a Windows 2000
central forest that will interoperate with other pieces of Stanford’s IT
systems. Services such as authentication, directory, and name resolution are
all integrated with the existing Stanford infrastructure. This makes it simpler
for any Stanford user to join their computer to the infrastructure (given the
computer is supportable), login, and take advantage of Windows functionality.
· Single Sign On*
Login once, and PC-Leland makes sure the University's Windows and non-Windows based services know who you are. This lets users access their University email, connect to websites that have webauth protection, and use other Stanford services without having to login again.
·
Increased Security*
Windows 2000 uses Kerberos for authentication. Kerberos protects your password. In addition there will be the ability to use and implement best practices and Security templates across the Windows infrastructure to make it more secure. The Windows Systems Group also has a set of scripts, which it runs on domain controllers to help evaluate security. The campus Security Office & this group will be closely monitoring for potential break-ins.
· Central Account Management*
Single Sign On account creation/deletion and password reset will be managed through the SUNet account creation process. All Single Sign On accounts will to be created in this manner. Password synchronization across all Single Sign On resources will be handled centrally.
· Automated Group Membership*
All groups that exist or are created in the Campus Registry will automatically become Windows 2000 security groups. Changes to a person’s departmental affiliation are automatically reflected in the Windows Infrastructure.
· Group Policy Objects †
Local Administrators can create policies for users or computers, which automatically configure common settings for security, software, user interface, and document management.
· Software Distribution †
This feature allows local administrators to publish applications automatically to your users desktops.
·
Automated Document Synchronization †
This lets you point any local directory on your
computer at a remote server. People who regularly use more than one computer
find this feature useful because it makes their files easily accessible, no
matter which computer they're working on. It also makes it easier for your
department to backup your files (because they are on a server, not your computer).
· Granularity of Control †
Delegate administration locally to support account management tasks.
· Managed Infrastructure*
No Domain Controllers or duplicated Infrastructure for client departments to purchase and manage (unless a child Domain is required then Domain Controllers must be purchased). DNS, Directory replication, and Domain Controllers are managed and backed up by ITSS. The cost savings in asset costs as well as reduced support personnel overhead can be significant.
· Migration Assistance*
ITSS will work with you to help ensure a successful migration. Many administrative tools, procedures and templates have already been created to assist you in moving your current Domain/Workgroup into the Windows Infrastructure. ITSS will share knowledge and experience from their own rollout project.
· Simple Distributed Resource sharing across all of Stanford *
Share Windows files, printers, or applications securely with any other person in the Stanford Windows Infrastructure. Local Administrators define who has access to the resources they share. Resource sharing is possible currently, but one must setup an account local to the local domain or machine (meaning they have another userid and password) or the local administrator must create a domain trust--both of which are not elegant solutions
· Login to machines across campus*
With a centralized infrastructure users will be able to use their account to login to any machine participating in the infrastructure. Practically speaking, many Administrators will restrict the login rights locally, but public workstations such as those in the libraries, labs, and elsewhere would benefit from this service.
· Infrastructure services*
There are a number
of other services being evaluated by ITSS -- such as the planned Microsoft
Exchange 2000 email service, monitoring tools and security (such as
distribution of Security templates) -- that work as part of the Windows 2000
Infrastructure and so can only be offered to people who join the Stanford
Windows Infrastructure.
* = A benefit of joining the Central Windows Forest
† = A service members of the Central Forest can still offer to their local users autonomously