---

Administrative Guide for the SU Domain

Domain OU Structure

The SU Domain has a straightforward top-level OU structure. The OU model follows a departmental/functional-based design with a top-level OU for every department or group which seeks to join the Stanford Windows Infrastructure. Below the top-level OU any OU design is welcome, but a set of OUs "Groups", "Workstations", and "Servers" is a popular choice.

ITS CRC maintains a top-level OU for supporting a number of client departments in the Stanford Windows Infrastructure

Domain Trusts

The domain only has trust relationships with the other domains in the production forest

Domain Policy and Administrative Practices

Being an administrator in the SU domain carries certain expectations. This policy and protocol section further expands on the official policy statements in the Admin Guide for SWI to delineate those policies specific to the SU domain.

Administrator accounts

Administrative Accounts are those accounts with any privileged right to the SU domain or to an OU within the SU domain. An administrative account need not be a “domain admin”, but is any account with one or more domain or OU rights delegated to it.

To be granted an administrator-level account:

• The person’s job responsibilities must require privileged access to administrative functions of the SU domain or an organizational unit inside the SU domain.
• A manager within the department owning the relevant top-level OU must sponsor the account.

The account shall only be granted those permissions necessary to perform assigned tasks.

All administrators should be involved in the communication process regarding potential domain-wide changes. The windows-admins@lists.stanford.edu mailing list will be used for discussion of such changes. Changes will be submitted in the Change Management system for documentation, approval, and implementation.

Admin accounts will be subject to account lockout should 5 failed login attempts be made in a 20 minute time period.

In cases where a group is delegated administrative rights to an OU, the admin group will be placed within the Admin Accounts OU (with membership managed by a domain admin).

Service/Task Accounts

Any delegated administrator can create service or task log on accounts. Accounts for service or scheduled task logon should be named such that the service or scheduled task that the account is used for can be inferred from the account name.

• These accounts may or may not be subject to password expiration
• These accounts should have access rights limited to those necessary for the software to run
• These accounts should be restricted to only log on to a limited set of machines, if possible.

Service/Task accounts shall never be used for interactive logon

Shared Accounts

No accounts shall be shared by multiple people for regular use

Object Creation/Naming policies

Group Policy Objects (GPOs)

New Group Policy Objects are created by the domain administrators. New GPOs can be requested at any time using HelpSU

Organizational Units (OUs)

OU names shall avoid acronyms when possible. New top-level OUs are created by the domain administrators. Creation of OUs at lower levels can occur without consultation.

SU Domain User accounts

It is recommended that the number of accounts created for people in the SU domain be kept to a minimum. SU Domain accounts should be primarily used for privileged access, service or task logon, and for testing purposes

Local accounts must use the UPN suffix of the domain in which they are created. For example, the account’s UPN should be newuser@su.win.stanford.edu. This will prevent any potential collision in the namespace of the central SUNet-integrated accounts. Be forewarned, new local user accounts may begin with a default of win.stanford.edu and will have to be manually changed for this setting on every local account creation. The display name, full name, user logon name, and user logon name (pre-Windows 2000) of all accounts shall be set to an identical value.

Test accounts shall be prefixed with “test” and end in the user’s SUNetID. For example, one user may have several test accounts with the names “test1sunetid”, “test2sunetid”, “test3sunetid”. Temporary accounts for visitors shall be prefixed with “temp.”. For example, a visitor account for Raman might be named “tempraman”.

Access Control Groups

Access Control Groups are used to provide security control to shared files or resources. It is highly recommended that all groups created in SU for controlling access be created as Domain-Local groups. Due to the configuration of the Stanford Windows Infrastructure, group types cannot be changed to global or domain local after they are created. Groups requiring access to domain-wide resources will be created and managed by domain administrators in the Admin Accounts container.

Group names shall avoid acronyms when possible. This will help minimize group name collisions, while also making group names more recognizable. Where this is not possible the description field of the group should decode the acronym. You may also wish to use a prefix or suffix in the names of all groups to readily identify your groups and prevent name conflicts.

Administrative Support and Roles

Domain Administration

Support for domain administration is handled by a group of Windows administrators in ITS. You can make requests via HelpSU. Using the Billable Services, Windows Systems Administration category will route to the Windows Systems Team.

Local Support

Support of other Windows services is done at a local level. To contact Windows administrators in other departments, you can access the public listing of departmental Windows administrators. When a user can’t login he/she should contact a local administrator. This local administrator should investigate the issue, and if unable to resolve it, contact the domain administrators.