Admin Guide for the IT Domain
Administration Best Practices
This document is intended for
Windows administrators in the IT domain. The Admin Guide for SWI is required reading prior
to this document, and this document should be considered supplementary to the policies listed Windows administrators in other domains are welcome to discuss and implement any of the best
practices illustrated here.there.
Network Architecture
The IT Domain has a simple top-level OU structure. The OU model
follows a resource-based design with just 2 top-level OUs for workstations and servers. Below the
top-level OUs a functional/political based design is
used to support different administrative
application environments or ITSS departments as needed. Below is a
diagram of the IT domain.
ITSS’ Windows NT 4 domain, Stanford-NT, is being migrated to the IT domain, and for
this purpose domain trusts are in place between this NT4 domain and the WIN and IT domains.
Group policy loopback mode is enabled at the domain level via the “ITSS Domain Policy.” This policy also gives the
domain local group “IT\Basic Domain Rights” the right to add
workstations to the domain. By default, the “WIN\ITSS” security group is a member of the
“IT\Basic Domain Rights” group, so all ITSS users should have this basic right.
All the IT domain and OU group policies are documented
at http://windows.stanford.edu/docs/ITgpos.htm.
Domain Administrative Roles
Domain Administration
Support for domain
administration is handled
by a group of Windows administrators in the CRC
and CSS. 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.
Policy and Administrative Practices
Being an administrator in the IT 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 IT domain.
Domain Policy
Administrator accounts
Administrative
Accounts are those accounts with any privileged right to the IT domain or to an
OU within the IT 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 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.
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 IT domain) for documentation, approval, and implementation. All
administrators are required to subscribe to Change Management domain named IT
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.
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”.
Computer
account creation
All desktop class computers should be created or
located in the Desktops OU. Further division of the Desktops OU
may occur for labs or other situations as the Desktops OU admin
determines.
All server class computers should be created or
located in or
under the Servers
OU. Servers which are used only by clients internal to ITSS should be placed in
the Servers/Internal Services OU. Servers which provide access to
administrative systems with special environment needs will be placed in OUs under the Servers OU.
Access
Control Groups
Access Control Groups are used to provide security
control to shared files or resources. Access Control shall follow the Microsoft
recommended practice of placing domain accounts inside domain groups (either global or domain
local), then placing these groups inside computer local groups, and finally assigning permissions on
the resource to these computer local groups. Domain groups should be created inside the OU container in
which they will be applied. Groups which require access to domain-wide
resources shall be created and managed by domain administrators in the domain
container.
Group names shall avoid acronyms when possible.
Where this isn’t possible the description field of the group shall decode the acronym.
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.
Group
Policy
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 another published document. Since
users reside in the WIN domain, loopback processing will be required to control
user’s settings when they log on to a machine in the IT domain.
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.
To provide more granularity, GPOs also have permissions settings. By
controlling the access to the “Apply Group Policy” right, groups of users or
computers in the domain can have a custom collection of settings.
Administrative AccountsPractices
Administrator accounts
Administrative
Accounts are those accounts with any privileged right to
the IT domain or to
an OU
within the IT 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.
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
Groups canwill or within the parent OU container (with membership managed by the OU admin)In either case, aAwhich sing
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 IT domain) for
documentation, approval, and implementation. All administrators are required to subscribe to Change Management domain named IT at
the routine level.
Administrative Support and Roles
Domain
Administration
Support
for domain administration is handled by a group of Windows administrators in
the CRC and CSS. 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
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
ProceduresLast
modified by barkills at 5/2/2001 3:43 PM3/22/2001 2:41 PM
©2000 Trustees of the Leland Stanford Junior University