Admin Guide for the IT SU Domain Administration Best Practices

 

This document is intended for Windows administrators in the IT SU domain. The Admin Guide for SWI is required reading prior to this document, and this document should be considered supplementary to the policies listed there. The SU domain is a general domain intended for departments which have no sponsored domain to join. The SU domain is shared among many departments. ITSS has provided this domain and manages it. This policy document seeks to set a standard set of guidelines to minimize potential areas of conflict or disorganization, while maximizing the degree of flexibility within a department’s OU environment.

 

Network Architecture

 

The SU Domain has a straightforward top-level OU structure. The OU model follows a political/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. Below is a diagram of the SU domain.

Group policy loopback mode is enabled at the domain level via the “SU Domain Policy.”

 

Administrative Roles

Domain Administration
Support for domain administration is handled by a group of Windows administrators in ITSS. You can contact this group at itssdomain@lists.stanford.edu or enter help requests via the Remedy system.

 

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.

 

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 itssdomain@lists.stanford.edu mailing list will be used for discussion of such changes. Changes which reach consensus on the mailing list, will be submitted in the Change Management system (under the SU domain) for documentation, approval, and implementation. All administrators are required to subscribe to Change Management domain named SU at the routine level.

 

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). A group policy setting which restricts the group membership of that group to the authorized members is required. This will help prevent security lapses, and circumvention of the authorization policy noted above.

 

 

Domain Policy

Creation of OUs

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

 

Non-WIN domain accounts

Local accounts should use the UPN suffix of the domain in which they are created. For example, the account’s UPN should be newuser@IT.WIN.stanford.edu. This will prevent any potential collision in the namespace of the central accounts. Be forewarned, new local user accounts begin with a default of WIN.Stanford.edu so you will have to manually change 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 might 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”.

 

Security Groups

Group names shall avoid acronyms when possible. This will help minimize group name collisions, while also making group names more recognizable.

 

Administrative Practices

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.

 

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). A group policy setting which restricts the group membership of that group to the authorized members is required. This will help prevent security lapses, and circumvention of the authorization policy noted above.

 

Communication

All administrators should be involved in the communication process regarding potential domain-wide changes. The itssdomain@lists.stanford.edu mailing list will be used for discussion of such changes. Changes which reach consensus on the mailing list, will be submitted in the Change Management system (under the SU domain) for documentation, approval, and implementation. All administrators are required to subscribe to Change Management domain named SU at the routine level.

Administrative Support and Roles

 

Domain Administration
Support for domain administration is handled by a group of Windows administrators in ITS. You can enter help requests directly to this group via the Remedy system.

 

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.

 

 

Windows administrators in other domains are welcome to discuss and implement any of the best practices illustrated here.

 

Administrative Accounts

Authorization

To be granted an administrator-level account:

·The person’s job responsibilities must require privileged access to administrative functions of IT domain or an organizational unit inside the IT domain.

·An ITSS manager must sponsor the account.

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

 

 

Administrator Logon

  Persons with administrator-level access to security objects in the IT domain shall access these rights using a user account separate from the account used for infrastructure user activities. Use of the “Run as …” command makes using two separate accounts very painless. Thise admin account shall be located in the organizational unit (OU) Admin Accounts inside the IT.WIN.STANFORD.EDU domain. The account shall be named as the users primary account, with the prefix “IT.” Admin accounts will be subject to account lockout should 5 failed login attempts be made in a 20 minute time period.

 

Admin Groups

  In cases where a group is delegated administrative rights to an OU, the admin group can be placed within the Admin Accounts OU (with membership managed by a domain admin) or within the parent OU container (with membership managed by the OU admin). In either case, a group policy setting restricting the group membership of that group to the authorized members is required. This will help prevent security lapses, and circumvention of the authorization policy noted above.

 

 

Domain Security Group Policy Objects

Definition

  Group Policy shall be applied to the IT domain with the intention of providing security and enforcing the Stanford University acceptable use policy. Specific settings of this Group Policy will be detailed in

 

Communication

  Since any change to these policies will affect every machine in the domain, all of the administrators must be involved in the decision process. itdomain@lists.stanford.edu shall be the preferred method of initial contact.

 

Machine Configuration Group Policy Objects

Definition

  Group Policy shall be applied to individual organizational units (OUs) for the purpose of providing desktop management. Group Policy is cumulative, allowing more general settings in one GPO to be refined by settings in another GPO processed later in the GPO chain

 

Loopback

  Since users reside in the WIN.STANFORD.EDU domain, loopback processing will be required to control user’s settings when they log on to a machine in the IT domain. It is strongly recommended to use “Append” loopback mode so that WIN and IT policies are applied to user settings.

 

Granularity

  Policies can be applied only to the entire domain or to organizational units. To provide more granularity, GPOs also have permissions settings. By controlling the access to “Apply Group Policy” right, groups of users or computers in the domain can have a custom collection of settings.

 

Access Control Groups

Definition

which may have application onwhich need access to in the domain container

 

Naming Conventions

Groups

  Group names shall avoid acronyms when possible. Ideally, the naming of global or domain local groups and any linked local groups shall contain the same group name. For example, a global group “CoreFin Users” shall be linked to local groups “CoreFin User Resources.”

OUs

  OU names shall avoid acronyms when possible.

Accounts

  As noted above, administrative accounts have a naming convention. Test accounts shall be prefixed with “test” and end in the user’s sunetid. For example, one might 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”. The display name, full name, user logon name, and user logon name (pre-Windows 2000) shall all be set identically.

 

Portal

Creating computer accounts

  Because there is a bug in creating computer accounts when adding the machine to the domain, one shall create the computer account prior to adding the machine to the domain via the administrative web portal.

Access to WIN domain user properties

  Access to user properties shall be available via the administrative web portal. If you find batch commands you are unavailable to perform, please contact the enterprise administrators at wintree@lindy.stanford.edu. Activities via this web portal will be limited to those admin accounts which have been delegated authority to make changes to ITSS member user accounts.

??

 

Other Procedures

Last modified by barkills at 5/4/2001 9:00 AM3/22/2001 2:41 PM

©2000 Trustees of the Leland Stanford Junior University