Abbreviated Guide to the Windows Infrastructure
This document is for Windows computing professionals who are learning about the Stanford Windows Infrastructure, but would like a quick summary of the major points of interest. For the comprehensive details, please refer to the Windows Admin Guide, as well as the Windows Policy Guide.
The Stanford Windows Infrastructure consists of a single forest containing a single tree with multiple domains in 2 tiers (Root "Account" and Child "Resource"). A production forest, pre-production forest, and test forest are implemented to provide adequate environments for all activities. Each production domain has at least one domain controller located in Forsythe hall and at least one in Sweet hall.
Delegated DNS zones support each of the 3 Windows forests. Windows DNS servers support these zones. Only domain controllers register records in these zones, and all client computers continue to use the primary DNS servers. The primary DNS servers redirect all requests for records related to Windows domain services to the Windows DNS servers. Dynamic DNS is turned off on all Windows clients, and all clients should retain a hostname.stanford.edu DNS name.
The production forest trusts the existing stanford.edu kerberos version 5 realm. This provides kerberos interoperability by linking SUNet kerberos principals to Windows accounts (in the root domain) with the same username and password. The root domain in the production forest will be empty of computers, and will only hold SUNet accounts, groups from the Stanford registry, and some global groups necessary for migration or Group Policy. These Windows accounts are placed in organizational unit containers (OUs) within the root domain. Each account is placed (and dynamically moved as needed) in an OU which matches the account’s departmental affiliation. The OUs are in a 7 level deep hierarchy that matches the official department hierarchy. Accounts are created and maintained dynamically by a special process called the WinHarvester that runs once an hour. Creation occurs as soon as the source system notifies the Stanford directory of the new account’s existence or of a change to data associated with that account. Departments may opt to designate departmental administrators who have some privileges on the accounts in their department’s OU. Passwords can only be set via the existing SUNet password processes. A process separate from the WInHarvester (known as the kadmind process) synchronizes passwords to Windows.
Some person-related data is replicated to the appropriate Windows account in the Windows directory (Active Directory or AD). The data which will be replicated is full name, departmental affiliation, and privilege group membership. All this data will retain its privacy settings as set in stanford.you, and departmental administrators have only read permissions to this replicated personal data.
The directory schema, which defines the rules and objects that the directory supports, must be managed centrally. A group made of representatives from every domain in the forest will review proposed additions to eliminate any potential issues. Proposed additions will be tested in the test and pre-production forest first. Enterprise admins will implement proposed schema additions after approval.
The number of enterprise administrators is kept to a minimum, and these administrators are required to use the ITSS Change Management system to track any enterprise wide change, or change to the root domain. Enterprise administrators are responsible for maintaining domain controllers, directory service, integration with existing Stanford computing infrastructure, infrastructure documentation, and technical leadership as needed. These administrators assume a hands-off approach, unless assistance is requested.
Terminal server licensing is supported by Enterprise terminal server license servers, department administrators that use Terminal Services in Application Mode should cooperate with Enterprise Admins in managing the terminal service license pool or specify a local terminal server license server .
Clear text, LanMan, and NTLMv1 authentication are not allowed in the forest. NTLMv2 authentication is allowed, but kerberos is preferred.
Some minimum security settings are set via a site-wide group policy. Windows 9x cannot support the security requirements of the domain.
It is the client’s responsibility to ensure license compliance.
In order to obtain an administrative account that has delegated access to a department’s account OU, a departmental manager must request this access, and the administrator must agree to comply to the relevant computing policy statements. Personal data that is associated with the accounts is owned by the Registrar, and since ITSS is simply a custodian of this data, ITSS must take steps to assure that this data will be kept confidential.
Use of administrative rights is audited and reviewed by the Security Office to ensure that the University’s interests are protected.
Domains below the root domain contain all client computers, whether they are servers or workstations. A general domain is provided by ITSS for any department on campus to join. There is no charge for a department to join this domain, but administrative management of computers and any Windows-specific user support must be provided by the department. Local administrators retain all authority over local resources.
Any school-level organization can decide to implement a separate child domain. Other departments can also implement a domain if they can provide suitable technical justification as decided by the infrastructure enterprise administrators. Any organization which implements a domain must fund at least 2 domain controllers. ITSS is responsible for administrative maintenance of these domain controllers, and provides all management, including physical. These domain controllers will only run the default Active Directory services, namely a kerberos distribution center (KDC) and LDAP. File services and other client services must be located on other hosts. To keep the forest consistent, all domain administrators are required to use the ITSS Change Management system to track any domain-wide changes. Domain administrators should keep in close contact with ITSS enterprise administrators.
Extended details about implementation decisions, policies, and practices are documented in the Admin Guide for the Stanford Windows Infrastructure at http://windows.stanford.edu/Public/Infrastructure/WinAdminGuide.htm.
|
Created: March 4, 2002 by Brain Arkills Last modified: September 03, 2004 by Ross Wilper ©2004 Trustees of the Leland Stanford Junior University E-mail comments/suggestions/additions |
 |