Administrative Guide for Stanford Windows Infrastructure

This document is for Windows computing professionals who are learning about the Stanford Windows Infrastructure and how it relates to the rest of Stanford University's computing infrastructure. A good overview of the latter can be found in the Stanford University IT Environment document.

This Guide describes the basic architecture of Windows infrastructure services and the role of a Windows administrator within this infrastructure. More detailed information about the Stanford Windows Infrastructure is referenced throughout via links on the documentation page of the Stanford Windows Website. Note that, in addition to this Guide, Windows system administrators are expected to review the Policy Guide for the Stanford Windows Infrastructure.

The administrator should read through the document once before using the following hyperlinks to jump through the document. Some concepts and definitions are introduced sequentially, and will make more sense when read sequentially.

Network architecture
Authentication
Domain controllers
DNS
Off-campus access
Directory
User Accounts

Distributed computing
Recommended security
Working with other OS
User education
Administrative troubleshooting

Administrative Support and Roles
Domain Controller Administration Support
Windows Directory Administration Support
Domain Administration Support
Account Administration Support
OU Administration Support
Server Support
Local and Other Support

Infrastructure Overview

The Campus Windows Infrastructure

The Stanford Windows Infrastructure is built on Microsoft's Active Directory and the Windows Server 2003 operating system. Administrators unfamiliar with Windows Server 2003 and Active Directory should consult other sources for training. The book "Inside Active Directory" by Kouti and Seitsonen is particularly good.

The Windows Infrastructure is implemented as a single forest with a single tree with two tiers of domains, arranged similarly to the Windows NT 4.0 "Single Master" domain model. The structure of the tree stresses the importance of organizational units, and uses domains to provide a common structure for similar departments (usually within the same school).

This focus on the organizational unit maximizes each department's ability to control its environment and to make local decisions that work for it within the larger Windows infrastructure. Basically, how organizations within the Stanford community decide to implement their Windows resources is largely up to them. Local administration at the department level is handled by local administrators. ITS just provides the top-level WIN domain and maintains the infrastructure's services.

Any given Windows workstation has two potential homes in this model. If the workstation belongs to an organization that already has a domain, the workstation will be part of an organizational unit within that domain. If the workstation belongs to no organization (which is highly unlikely), or belongs to an organization that is not part of an existing domain, the workstation can join the "general purpose" SU domain that has been formed specifically to house organizations, organizational units, or individual workstations that do not have a domain. The SU domain is provided and maintained by ITSS. More detailed information about SU domain policies can be found in the Administrative Handbook for the SU domain.

All Windows computers are members of a child domain, and will never be a member of the root WIN domain. This arrangement helps to ensure a separation of authority, while also maximizing the security of the most critical shared resource: SUNet accounts and any personal information associated with them.

For more information about the Stanford Windows Infrastructure domain model, take a look at the domain organization document.

Domain Controllers

Domain controllers hold account and group information. There are at least two domain controllers for each domain in the Stanford Windows Infrastructure. In addition, two dedicated infrastructure domain controllers serve as "global catalog servers", which hold the subset of searchable information of all directory objects. A global catalog server is involved in almost every login.

The network designed for the domain controllers is pictured below. Each pair of domain controllers is co-located -- one in Sweet Hall, one in Forsythe Hall -- with a pair of Gigabit fiber connections for directory replication and other domain traffic. The domain controllers are on an isolated subnet and have 2 dedicated routers, which can help provide packet-level filtering to prevent denial of service attacks, and other security issues. There is a DNS cache local to each server room, so network or even DNS outages have minimal effect. This network is connected directly to the Stanford network backbone, so multiple paths are always available. The domain controllers are backed up three times daily.

All the domain controllers are hosted, managed, and monitored by ITSS. There is always at least one person on-call who can respond to your domain controller's needs 24 hours a day, seven days a week, 365 days a year. The domain controllers are maintained in a climate controlled, replicated environment that is physically secure, with an emergency power backup system that renders it immune from blackouts that might otherwise disable an office power supply.

All the domain controllers in the infrastructure are supported by ITS Windows Systems and 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. This requirement is to ensure the security of the SUNet accounts and any personal information associated with them.

Authentication options

Stanford University offers a multitude of computing services to the Stanford community. To access many of these services people must enter their SUNet ID username and password. The SUNet ID establishes their affiliation with Stanford and their right to use its computing services. This process of identification and authentication is managed by the Kerberos authentication service.

Windows 2000 users can take advantage of Stanford's Kerberos authentication system. Because the Stanford Windows Infrastructure is connected to the existing Kerberos authentication realm (via a Kerberos realm trust), it permits a SUNet account to let people access services in the domain tree (such as Windows file and web services) as well as services in the Kerberos realm (such as POP mail, the Stanford Directory, Stanford.You, etc.). This integration is achieved by linking the Windows account in the WIN domain to the SUNet account in the kerberos realm. Account creation, and the details regarding the Windows SUNet account is discussed further in the directory section below. Further information about Kerberos authentication with an existing Kerberos realm can be read in the MS Window 2000 Kerberos Interoperability whitepaper.

Authentication flow

At login, users present their identification credentials. These credentials consist of 3 pieces of information: username, password, and realm. The user in the Stanford Windows Infrastructure will supply these credentials: SUNetID, SUNet password, and stanford.edu. Its also possible to combine the username and realm information on the username field; SUNetID@stanford.edu is a valid username. This fully qualified username is called the UPN, or user principal name. After presenting credentials, the login (TGT) request is sent directly to the stanford.edu KDCs (the workstation knows exactly where these KDCs are, because it has a local config (registry key) which tells it). After obtaining a stanford.edu TGT, the Global Catalog servers need to be contacted (which are known because the workstation boot process has located them via a DNS query) to locate a valid Windows credential which will allow them to log in on the Windows workstation (the non-Windows TGT doesnt have any rights to the local workstation). So the next step is to obtain a referral from stanford.edu. The referral is passed to the WIN KDC, which identifies sunetid@stanford.edu as the altSecurityIdentities attribute of sunetid@win.stanford.edu, and therefore issues a WIN TGT for sunetid@win.stanford.edu. The WIN TGT contains a list of all WIN domain security groups of which the user is a member, and all universal security groups of which the user is a member. Then, group policy objects load (with any GPO resident login scripts), roaming profiles load, and finally user specific login scripts load. Should any of these processes need access to a resource in a local domain, then a local domain TGT is requested. This first requires a referral from the stanford.edu KDCs. When the local domain TGT is issued, it contains a list of all the local domain security groups of which the user is a member. Should the user later wish to connect to a resource in a domain in the Stanford Windows Infrastructure for which he doesnt have a TGT, a referral and TGT will be requested at the time of the connection attempt to the resource.

Prior to Windows' native kerberos support, a Stanford-written application called PC-Leland was required to acquire and manage kerberos tickets for Windows users. Unfortunately this is still true. Many network services are written so they can only access the PC-Leland kerberos ticket cache, and are not familiar with the Windows kerberos ticket cache. Another issue is that many of the Stanford network services only accept kerberos version 4 tickets, while Windows only uses kerberos version 5. Because of these issues, PC-Leland is still used to bridge this gap. If PC-Leland is configured in single sign-on mode, it also grabs the credentials presented at login. Separate from the Windows authentication process, in parallel, it also obtains a TGT for sunetid@stanford.edu (version 5) as well as a TGT for sunetid@ir.stanford.edu (version 4). By configuring PC-Leland to run in single sign-on mode, you can eliminate the need to sign into both your workstation and PC-Leland and nearly achieve a single sign-on functionality to Stanford computing resources. One important thing to note is that PC-Leland does not automatically renew TGTs, whereas Windows does automatically renew them. So over time a user may need to login to PC-Leland again.

As noted above, Kerberos authentication is the preferred authentication method in the Windows infrastructure. However, many Windows services are not Kerberos aware at this time. Older Windows authentication methods include NTLMv2, NTLMv1, LanMan, and Basic (cleartext) authentication. For security reasons, clear text authentication will not be allowed; clear text authentication is prohibited on all domain controllers and IIS web servers in the Windows infrastructure. LanMan and NTLMv1 have serious security issues, so they also will not be allowed. Aside from Kerberos, only NTLMv2 authentication will be allowed.

In order to interact with the Windows Infrastructure, clients such as the Macintosh Windows File and Print client will need to update their client to support the NTLMv2 authentication method. Windows NT clients will need to install the Directory Services client. Additionally, these Windows clients will need to make a configuration setting to use NTLMv2 as detailed at How to join your computer to the Stanford Windows Infrastructure. Microsoft has released a special Macintosh authentication client (called a UAM) that supports NTLMv2. This UAM will need to be installed to allow Macintosh versions lower than 10.3 to interact with the Windows Infrastructure.

DNS

All campus Windows workstations should have a valid NetDB entry, with a corresponding hostname.stanford.edu DNS address, regardless of their domain within the Windows infrastructure. The recommended Windows 2000 client network settings are here. Details about NetDB and its integration with the campus DNS system can be found at http://www.stanford.edu/group/networking/netdb/help/html/helpnetdb.html.

A fully qualified domain name (FQDN) consists of a hostname and DNS domain name, including top-level DNS domain. For example, hostname.Stanford.edu is a fully qualified DNS domain name: "hostname" is the hostname, "Stanford" is the second-level DNS domain, and "edu" is the top-level DNS domain. Windows Active Directory domains require a FQDN to support LDAP, Kerberos, PKI certificates, and other new technologies which are now integrated with the operating system. Specifically, domain controllers must have a FQDN within the FQDN of the Windows domain. A Windows domain cannot use Stanford.edu as its FQDN, because there would be a collision with existing infrastructure services, such as kerberos services. Because of this requirement, the Stanford Windows Infrastructure has a DNS subdomain "win.stanford.edu" for domain controllers. So, for example, the FQDN of a domain controller in the ITSS Windows domain would be hostname.it.win.stanford.edu. Only domain controllers have this requirement for a longer FQDN.

Domain controllers need to register roughly a dozen special DNS records called SRV records. These records support name resolution for authentication and directory services. Without these records, login and most domain services would be impossible. Because of the existing lack of NetDB support for SRV records, the Stanford Windows Infrastructure is running its own delegated DNS server. When NetDB support is made for SRV records, there are plans to eliminate this DNS server and statically register all needed records on the primary campus DNS servers. Only domain controllers use this delegated DNS server, and only domain controllers need to use the lengthy x.y.win.stanford.edu names. All workstations should keep stanford.edu as their primary DNS domain suffix, if it is currently configured that way. For more details see the DNS & Windows 2000 on Stanford campus document.

Off campus access

Stanford community members using Windows who are traveling or are off-campus can access Windows network services remotely via the University's high-speed modem pool as well as via Stanford DSL. The ports used for NetBIOS over TCP/IP are currently blocked at the entrance to Stanford, meaning that you will need to configure the client for VPN if you are connected to another ISP. Firewalls at ISPs or other network providers are out of Stanfords control and may cause further restrictions.

Workstations with a non-stanford.edu FQDN (e.g. via an ISP), can join the Stanford Windows Infrastructure. Non-domain controllers (i.e. workstations and member servers) can have any FQDN and be a member of a Windows Active Directory domain. For example, foo.microsoft.edu can belong to the it.win.stanford.edu domain. However, only Stanford affiliated users who are performing official Stanford business on that computer can join a non-stanford.edu computer to the Stanford Windows Infrastructure.

User Accounts

All user accounts are placed somewhere beneath the Accounts OU container, as described below. The Registry supports a feature called the Workgroup Registry. This is a list of groups from 3 sources: Stanford, departments, and individuals. All Stanford-based security groups are placed within the Organizations OU container. All department-based security groups are placed within the Workgroups OU container. All individual-based security groups are placed in the Personal Groups OU container. This placement simplifies the directory replication process, while also providing a simple and consistent organizational structure.

When a new SUNet account is sponsored, a Windows account with a temporary random password is created within 60 minutes of the sponsored SUNet account appearing in the registry by the harvester process. This account can be used immediately thereafter, as long as the user logs in using the sunetid@stanford.edu form of logon. The SUNet password can then be changed in StanfordYou and is immediately set on the Windows account via a special process called kadmind. Once this has happened, a user can login with the sunetid@win.stanford.edu form of logon. Kadmind is a special kerberos process which sets passwords on all the SUNet accounts whether they are in the kerberos 4 realm (ir.Stanford.edu), kerberos 5 realm (Stanford.edu) or Windows realm (win.Stanford.edu). The harvester process runs independent of the kadmind process, and is dependent on the kadmind process to set a SUNet password that the user knows. Both these processes are represented in the diagram in the Directory section above. The Windows account is created within the users respective department OU under the Accounts OU. If the department affiliation for the SUNet account isnt available at the time of account creation or the affiliation is a new department which Active Directory isnt familiar with, then the account will be created in the Unaffiliated OU, beneath the Accounts OU. At a later time, if the affiliation of the person is updated, the account in the Unaffiliated OU will be automatically moved as necessary. During account creation, the other associated person data is also set by the harvester process.

Any particular user is placed in the OU which corresponds to the affiliation listed in their official record. In some cases, the affiliation data may not be up-to-date. The Active Directory is a subscriber of this information, so no change can be made directly in Active Directory. However, once the affiliation data has been corrected in the official system of record, the user account will be automatically moved to the appropriate OU.

The structure under the Accounts OU deserves extended discussion, because of the importance it plays. The OU structure is based on the official organizational structure Stanford has identified. Because that structure is so big, it is impossible to put in a picture. For example, there are 1665 different department affiliations that any user might have, and these affiliations are in a hierarchy which reaches 7 levels deep in some places. You can review a static version of the full hierarchical structure in an MS Excel document, along with the special department code by going to orginfo.stanford.edu.

The ACLs which govern access to user accounts are also of special interest, because they enable a department admin to access their user accounts, as well as protect personal data from other users. The Accounts OU has an ACL which is inherited by all OUs beneath it. This ACL looks like:

Accounts OU ACL
Windows Infrastructure Group	:	Full Control	This object and all child objects
SELF	:	Read All Extended Rights	This object and all child objects
Authenticated Users	:	Read	Organizational Unit objects
Department Admins	:	"Read SunetID"	User objects

When a department indicates that they would like access to their OU, an inherited ACL is set on their department OU. The following example uses the Psychology department:

Psychology OU ACL
Psychology Account Admins	:	Read All Properties	User objects
Psychology Account Admins	:	Write "User-Logon"	User objects
Psychology Account Admins	:	Write "User-Parameters"	User objects
Psychology Account Admins	:	Write "scriptPath"	User objects
Psychology Account Admins	:	Create Group Objects	This object and all child objects
Psychology Account Admins	:	Full Control	Group Objects

User-Logon is a sets of user properties that includes multiple properties. User-parameters is a user property which includes all the terminal service settings.

Departments that use Exchange will require an additional access control entry to enable access to the Public-Information property set.

This set of ACLs correspond to the attributes that a departmental administrator will need access to modify. "Windows-centric" attributes -- user attributes that correspond to Windows configuration settings, such as home directory location, profile location, and terminal service settings -- are not held in the SUNet Registry/Directory, so they are only present in Active Directory. Each department has the opportunity to have access to manage the Windows-centric attributes on the user accounts in their departments account OU. The department simply needs to notify the Windows Infrastructure Group that theyd like this ability, and designate who their Windows account administrators are. The user data for these attributes can be changed using the Microsoft utility Active Directory Users and Computers or via other standard Windows interfaces, like ADSI, which can easily perform batch operations. Any particular departments account administrator will only have the authority to make changes to the users in that departments account OU. Again, non-Windows-centric attributes wont be writable by account administrators.

Because these departmental administrators will also need the ability to read the personal information of their departments accounts, every administrator will need to sign a policy statement that they will respect the personal information of users. This policy is described in detail in the Policy Guide for the Stanford Windows Infrastructure. Only the Windows Infrastructure Group can add administrators to the Departmental Account Admin group noted above.

The departmental administrator has the ability to create group objects inside their accounts OU. These groups should only be used for the application of Group policy (explained below) or in situations where groups must reside in the WIN domain to be effective - for example, global groups for use during a Windows NT 4.0 to Windows Infrastructure migration. A predetermined prefix or suffix must be used on every group name to prevent possible name collisions with other department's groups.

Group policy or group policy objects (known as GPOs) are directory objects used to apply common configuration settings on computers and user objects. For example, a Windows administrator can assign a particular software installation to a set of computers or users. GPOs are associated with directory containers, and are thus applied indirectly to all user or computer objects within that container. There are currently three types of containers in Active Directory that can have GPOs applied to them: sites (we have a single site at Stanford); domains; and OUs. Most user or computer objects are contained by at least one of each type of container. GPOs cannot be applied directly to user or computer objects. GPOs do have security ACLs, and a Windows administrator can use these ACLs to limit which computer or user objects can read and apply a GPO applied to a container. Group policies are applied in a particular order. Please read the GPO Processing order document to understand this order.

One group policy setting you may find particularly useful is known as the group policy loopback feature. This configuration allows an administrator to apply a user policy based on the directory container for the computer they are logging into. OU administrators can apply this setting to their OU, if they have any user settings they would like to set based on the computer. This setting is especially useful in computer lab settings or on Terminal Servers, where all the users should have a mandatory interface or set of configuration options.

Directory architecture (i.e. the OU structure) in child domains is left to the department which sponsored the domain, and the architecture model employed will vary from domain to domain. In general, departments will be given a top level OU, and they may design an OU structure under this to fit their needs. Domain administrators are expected to draft a document which describes their domains directory architecture and any policies which govern it. A document which contains OU design recommendations will help guide departments through the process of designing their directory architecture.

Distributed Windows Computing

For many groups, working in a distributed computing environment is not new, because they have taken advantage of the Leland Systems environment. But most groups do not have any significant number of workstations configured to be in that environment, so they are not familiar with the security implications. For example, most Windows workstations that are not in the Stanford Windows Infrastructure are standalone workstations which, because of their default configuration, do not need to take many additional steps to protect local resources from prying eyes or malicious intent. But when a Windows workstation joins the Stanford Windows Infrastructure, the default configuration allows any user to login to that workstation, shutdown that workstation, or gain read access to shared files on that workstation. This is one of many issues people must learn to deal with. Departmental administrators should take steps to educate their users about these risks, and help them to minimize their exposure.

Recommended security

Local administrators must take steps to establish and restrict access on workstations in their purview in order to prevent security problems. Windows workstations that can be physically accessed by people other than the primary user are of particular concern. Microsoft has written an excellent document that explains and documents the default security configuration of Windows 2000 workstations. Local administrators will want to examine the membership of the local Users group in particular, because many default rights and file permissions are assigned to it. For example, a security group called "Authenticated Users", which includes every account in the Stanford Windows Infrastructure, is a default member of the local Users group; we recommend that you remove "Authenticated Users" and specifically add only those accounts or groups that should have a basic level of access. This task can be done for all workstations in an OU via a group policy configuration, scripted by using the secdefs tool, or via the manual employment of the user management tools. We also recommend that local administrators implement the NTFS file system on their workstations for the file security and auditing it offers. A local administrator will want to pay special attention to local directories where particularly sensitive data may be stored, such as a mail directory. Configuring local workstations to increase their authentication level is also strongly encouraged. A document called Securing a Windows 2000 Server may help local workstation administrators do this.

As described in the Mandatory group policies document, security in the Stanford Windows Infrastructure is taken seriously. Noteworthy among these policies is a restrictive password filter, and the prevention of cleartext authentication. The Stanford Computer Security Office is closely involved with the domain tree, and receives all the security events occurring on the domain controllers for auditing purposes. Instructions on how to handle security incidents is covered in the Policy Guide for the Stanford Windows Infrastructure.

Working with other Operating Systems

Non-Windows 2000/XP/2003/Vista/2008 computers are limited in their ability to participate in the Stanford Windows Infrastructure. These limitations derive from the inherent capabilities of each operating system and would be difficult to cover in detail. Note that most operating systems do not have the ability to perform authentication in a way that Windows can accept: this largely determines which clients can interact. Of those client operating systems which can interact, there are other advanced features like group policies, software distribution, and distributed file sharing which are not possible. Windows NT has an Active Directory client, which allows interaction with the Active Directory on a basic level, but do not provide all of these advanced features. Windows NT-based operating systems and Mac OS X 10.3 have the ability to authenticate (via NTLMv2) at the domain level and access shared files. Other Macintosh clients can connect to Windows servers running the Macintosh File and Print Service, but require a special Windows client called a UAM. Microsoft has released Windows 2000 Services for Unix, which may allow your department to provide closer integration. The campus-wide distributed AFS filesystem provided by the Leland Systems is accessible via a Windows client in the Stanford Windows Infrastructure. This space consists of twenty AFS servers, geographically distributed across campus, and one Terabyte of available disk space, which is backed up nightly. You can read more about AFS at http://consult.stanford.edu/afsinfo/, and find the appropriate AFS client software at http://www.stanford.edu/dept/itss/ess/pc/pc.html. SAMBA 3.0 can also perform NTLMv2 authentication, so can be used with central Windows Infrastructure accounts

Common user problems

As a local administrator, it is up to you to educate your users on a regular basis so as to avoid common problems. The majority of issues you deal with will probably concern failed logins and security in the distributed Windows environment. For example, remembering to specify the correct domain during login (or the full UPN on the user field) is something most people will not be familiar with, because they're accustomed to a single domain environment, where there is only one domain to choose from. For example, have them try logging into another Windows workstation (this should tell them their computer has an issue). Have them try using PC-Leland to login with exactly the same credentials to the KDC (if it fails, then the password they are using is wrong). Make sure they know that password changes must be done via PC-Leland or the Stanford.You web page; neither Windows' built-in "change password" function, nor you as their local administrator, have the ability to make this change. Establish which security group (other than "Everyone") the members of your department should always use for access to local shared folders; document the process step-by-step, so users can follow it easily.

Administrative troubleshooting

Troubleshooting problems in a distributed computing environment requires cooperation between administrators in all areas. Being able to contact the appropriate administrator in a timely manner requires both a central contact list of other administrators and a commitment by all administrators to help address distributed issues. The next section of this document will address the various roles of central administrators and provide links to a contact list. This list will help you find the appropriate administrator of resources in other parts of the Stanford Windows Infrastructure.

Two areas of Windows administration in a distributed computing environment are especially complex. The first, resolving group membership, is difficult because security groups can be nested multiple times while also crossing domain boundaries. These issues can be made simpler to address by taking advantage of resource kit tools. Global.exe, local.exe, findgrp.exe. and showmbrs.exe are all tools that help enumerate group membership in slightly different ways.

The second, tracing which group policy objects have been applied in order to resolve policies settings, can also be difficult. Gpresult.exe, another resource kit utility, will list all GPOs applied; it also conveniently lists all groups for which the current user is a member. Microsoft has written a whitepaper called Troubleshooting Group Policy in Windows 2000 that you will also find helpful.

Administrative Support and Roles

The Stanford Windows Infrastructure is composed of many different computing, administrative and consulting services. This section provides a brief description of these services and specific contact information for each. More detail can be found in the Roles and Responsibilities document at http://windows.stanford.edu/docs/rolesandresp.xls. In general, people who experience problems with a particular service should speak to their local Windows administrator first. If the issue cant be resolved, then the local administrator should raise the issue to the appropriate support group.

Domain Controller Administration Support

The ITSS Windows group installs and maintains the domain controllers that support the Windows infrastructure. The administration of user accounts, or other tasks specific to a particular campus group, cannot be handled by this group. Urgent problems related to domain controllers or infrastructure services should be reported via the HelpSU page under "Billable Services" "Windows Systems Administration". Please mark the request 'Urgent' if a problem requires immediate attention and the admin on-call will be paged. For general discussion, this group can be contacted via email.

Windows Directory Administration Support

Support of the directory services is also handled by the ITS Windows group. This group manages the flow of information from the SUNet Registry/Directory to the Windows AD. The Windows Infrastructure group also manages the replication of directory information within the Active Directory, and makes any enterprise level changes to the directory, such as schema modifications or adjusting personal data attributes to reflect proper privacy settings when necessary.

The Windows Infrastructure group communicates all enterprise-wide changes to domain administrators via the Stanford Change Management System. The CMS serves as the primary vehicle for the notification, coordination, authorization, and archiving of notable changes. The WIN domain in the Change Management domain will facilitate this communication. For more information about the system, administrators should go to http://www.stanford.edu/services/changemgt/. Additionally, changes which can affect users will be sent to the mailing list windows-info for notification.

In order to support and maintain the infrastructure's domain controllers and directory services, the Windows Infrastructure group have administrator privileges on all domain controllers. On the other hand, the Windows Infrastructure group assumes a "hands-off" approach to domain administration within domains. Only when faced with an enterprise-wide emergency, where no adequate alternative exists and every attempt has been made to contact appropriate support personnel and relevant managers first, will the Windows Infrastructure Group take action at the domain level.

If you suspect that some password replication has failed, or that a newly created account is not showing up, contact the Windows Infrastructure group. Urgent problems related to infrastructure services should be reported via the HelpSU page under "Billable Services" "Windows Systems Administration". Please mark the request 'Urgent' if a problem requires immediate attention and the admin on-call will be paged.

Domain Administration Support

Support for Windows domain administration is provided by the school or organization that owns that domain. Domain administrators are required to maintain a contact list for administrators within their domain on the Windows Administrator Contact List web page. This page can be employed by users as well as other Windows administrators as an easy means of contact and support. Domain administration within the IT domain and in the general SU domain are done by ITS; work requests can be entered into the HelpSU page.

Administrative privileges over a domain are first delegated to a pre-created administrative group account. The manager of whichever group had requested that domain will be the person responsible for designating which administrators will be added to this administrative group account. Separately, a manager at each departmental level will designate administrators who have account operator access to the Windows user accounts for people in their department. Domain administrators are required to maintain a contact list for all administrators within their domain and post this information on the Windows Administrator Contact List web page.

Domain administrators are responsible for communicating domain-wide changes to the OU administrators in their domain via the Stanford Change Management System. Every Windows domain has a corresponding domain in the Change Management System to facilitate this practice. Domain administrators must also keep themselves up to date with changes in the enterprise as a whole by subscribing to the WIN domain in the Change Management System. In addition to this use of the CMS, domain administrators are responsible for setting up a mailing list to help facilitate general discussion among administrators within their domain. Information on how to request a mailing list can be obtained by browsing to lists.stanford.edu. Mailing lists on lists.Stanford.edu are free to Stanford affiliates.

Domain administrators are encouraged to document their domain architecture (i.e. OUs, policies, etc.), as well as their administrative policies. Domain administrators should also develop and document naming policies for local accounts. Examples of such documention are the Admin Guide for the SU domain and the Admin Guide for the IT domain. The Stanford Windows Website would be happy to host your domains administrative guide.

Account Administration Support

A manager at each departmental level will designate which administrators have "account operator" access to the Windows user accounts for people in their department. These account operators will have privileges that let them make changes to a subset of attributes for the accounts in their OU. This subset of attributes includes Windows-centric information like home directory location, profile location, terminal server settings and other kinds of user data that is not replicated from the SUNet Registry/Directory. Replicated user data such as account name (SUNet ID), department, and affiliation -- and any future extensions of other personal data replicated to the Active Directory -- are in non-writable form and hence unavailable to account operators. The authoritative Stanford registry (accessible via Stanford.You) is the only place where these non-writable attributes can be changed, and there only by the user.

OU Administration Support

Administrative control of top-level OUs are first delegated to a pre-created administrative group account by the domain administrator. The manager of the group that had requested the OU will be the person responsible for designating which administrators will be added to this administrative group account. OU administrators are required to keep domain administrators informed about which administrators are active in their OU so that domain administrators can maintain an up to date record on the Windows Administrator Contact List web page.

OU administrators must keep themselves informed about domain-wide changes via the Stanford Change Management System. Every Windows domain has a corresponding domain in the Change Management System to facilitate this practice. OU administrators must also keep themselves informed about enterprise-wide changes by subscribing to the WIN domain in the Change Management System. In addition to using the Change Management System, we recommend that OU administrators join a domain-centric mailing list to help facilitate general discussion among other administrators within their domain.

Server Support

Windows servers are usually supported at the departmental level. However, the Windows Systems Group offers Windows server support for clients on an FTE-based cost model.

Local and Other Support

Other Windows services are supported at a departmental level. To contact Windows administrators in other departments, refer to the public listing of departmental Windows administrators page. People who have problems logging in should contact their local administrator. He or she will investigate the issue and, if unable to resolve it, will contact the directory support team.

The ITS Computing Resource Center provides general workstation support and domain administration services, on a fee-based service: go to ITS: Contract Support Services to learn more about group support services.

The ITS Windows Systems Group provides a certain amount of technical assistance to Windows administrators in the infrastructure. The Windows Systems Group website hosts information useful to Stanford Windows administrators, such as security alerts, news, and relevant documentation.

Note that, in addition to this Guide, Windows system administrators are expected to review the Policy Guide for the Stanford Windows Infrastructure.

Last modified Wednesday, 04-Feb-2009

STANFORD UNIVERSITY

INFORMATION TECHNOLOGY SERVICES

About this Service

Documentation

Service List

Contacts

Related Services

Tools