The following information provides a quick summary of the major points of interest for Windows computing professionals learning about the Stanford Windows Infrastructure. For more detail, refer to the Administrative Guide to the Windows Infrastructure and the Policy Guide.
Domain model
The Stanford Windows Infrastructure consists of a single forest containing a single tree with multiple domains in two 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 two campus Electronic Communication Hub buildings, and shared domains have an additional controller located in Livermore.
DNS
Delegated DNS zones support each of the three 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, which 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.
Kerberos and accounts
The production forest has two-way trust with the stanford.edu Kerberos version 5 realm. Kerberos interoperability becomes possible by linking SUNet Kerberos principals to Windows accounts located in the root domain that have the same username and password. In the other direction, applications such as SAML can allow WIN accounts using equivalent realm configuration.
The root domain in the production forest will be empty of computers and will only hold SUNet accounts, groups from the Stanford Workgroup registry, and certain distribution groups for Exchange. These Windows accounts are placed in organizational unit contains (OUs) within the root domain. Each account is placed (and dynamically moved as needed) in an OU that matches the account's primary departmental affiliation. The OUs are in a seven-level-deep hierarchy that matches the official department hierarchy. Accounts are created and maintained dynamically by a special process that watches for changes in registry data. 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 department administrators that have some privileges on the accounts in the department's OU. Passwords should only be set in Accounts.
Personal data
Some person-related data — full name, departmental affiliation, privilege group membership — is replicated to the appropriate Windows account in the Windows Active Directory. All this data retains its privacy settings from StanfordYou, and departmental administrators have read only permissions for this replicated personal data.
Centrally managed services
The directory schema, which defines the rules and objects 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; for more information about schema changes, see the details for Help requests. Proposed additions will be tested in the test and pre-production forests 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 Change Management system to track any enterprise-wide change or change to the root domain. These administrators are also responsible for maintaining domain controllers, directory service, integration with existing Stanford computing infrastructure, infrastructure documentation, and technical leadership, as needed. Enterprise administrators assume a hands-off approach unless assistance is requested.
Departments
Domains below the root domain contain all client computers, both servers and workstations. A general domain is provided; any department on campus may join it free of charge, but administrative management of computers and Windows-specific user support must be provided by the department itself. Local administrators retain all authority over local resources.
Any school-level organization can decide to implement a separate child domain, though not recommended. 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 two domain controllers.
Extended details about implementation decisions, policies, and practices are documented in the Administrative Guide to the Windows Infrastructure.
