Administrative Guidelines for Andrew Windows
Carnegie Mellon University
A Computing Services Publication
July 11, 2016
Introduction
This document is a guideline for administering computers within the Andrew Windows
service and includes the following sections.
I. Overview: Andrew Windows and Microsoft Active Directory
II. Required and Recommended Administrative Guidelines
1. Non-Kerberos Clients
2. Object Naming Conventions
3. Service Packs and Patches
4. Security Hot-Fixes
5. Backups
6. IIS
III. Andrew Windows Service Policies
1. Member Server’s Operating System Versions
2. Creation of Departmental Domains
3. External Trusts Relations
4. Active Directory Schema Changes
5. Organizational Unit (OU) Accounts
6. Object Creation
7. Blocking Inheritance
8. Mandatory Group Policy Over-rides
9. Non-Kerberos (NTLMv2) Authentication
10. Passwords
11. Security
12. Domain Security Policies
13. DNS
14. Core Software GPO
15. Printing
IV. Andrew Window Infrastructure
1. Domain Controllers
2. Andrew User accounts
3. Single Sign-on
V. Future Goals
1. Software Distribution and Support
2. Central File Services
3. AFS
4. Group Integration
5. Roaming Profiles
I. Overview: Andrew Windows and Microsoft Active Directory.
This document is a guideline for administering computers within the Andrew Windows
Service. Readers should have a general knowledge of Windows 2000 and Active
Directory terminology.
The Andrew Windows Service provides a reliable, stable and secure environment for
Windows based computing at Carnegie Mellon University using the framework of the
Microsoft Windows 2000 Active Directory. Placing workstations and servers into this
environment will minimize the level of support that will be required from departmental
administrators. Active Directory was designed as an enterprise solution. It is intended to
be a centrally managed system that is based upon existing standards (e.g. LDAP,
Kerberos, DNS). Therefore, in designing the Andrew Windows Service, Computing
Services had to balance desires of individual departments versus the impacts to the entire
campus. At times, these guidelines may seem restrictive. However, since reliability and
stability are essential requirements of the Andrew Windows Service, these design
decisions were made for the best interest of the entire campus community. Questions or
suggested changes to this guide should be directed to Computing Services via
advisor@andrew.cmu.edu.
In order to become familiar with Active Directory, Computing Services recommends that
Departmental Computing Administrators who plan to administer machines in the Andrew
Windows environment complete a course similar to MS Course 2154: Implementing and
Administering Microsoft Windows 2000 Directory Services, from a Certificated Microsoft
trainer.
I.
Required and Recommended Administrative Guidelines
The following sections detail the recommendations and requirements for Andrew
Windows.
1. Non-Kerberos Clients
We strongly encourage users to migrate to clients that provide full support for
Kerberos. Currently these clients include Windows 2000, Windows XP and
Macintosh OS X. Computing Service will focus the majority of our support on
these Kerberos compatible OS versions.
Core technologies utilized by Windows Active Directory architectures such as
Kerberos and Group Policies are only supported in newer Windows Operating
Systems such as Windows 2000 or Windows XP. Older clients such as Windows
98, Windows ME, Windows NT and Macintosh OS 9 do not support these core
technologies. Computing Services acknowledges that many of these clients
currently exist on campus and will attempt to support these operating systems for
a period of time.
2. Object Naming Conventions
Objects created within Organizational Units (OUs) must follow these conventions
in order to minimize the potential for conflicts:

Printers
Computing Services recommends that all printer object names be prepended with the Organizational Unit (OU) descriptor. For example, a
printer named “pine” in the Chemistry department would be named
“mcs.chemistry pine”.

Computers
It is suggested that the Computer object’s name match the top-level
hostname registered in NetReg. Departments should also consider adding
a unique departmental identifier to the computer so that it can be easily
identified as a departmental object.

Security Groups
All Security Groups object names should be pre-pended with the
Organizational Unit (OU) descriptor. For example, a Security Group
object named “students” in the Chemistry department would be named
“mcs.chemistry students”.

Organizational Units
There are no name requirements for Organizational Units (OUs) created
within a department’s Organizational Unit (OU).

Group Policy Objects (GPO’s)
Due to restrictions in the ability to delegate Group Policy Objects (GPO’s)
creation within a domain to an Organizational Unit (OU), Departmental
Administrators will not be capable of creating a GPO directly. Each
departmental Organizational Unit (OU) will have a GPO created for it,
with full control being delegated to the OU Administrator account. Once
this is done, the Organizational Unit (OU) Administrator can edit the
GPO.
Computing Services will create all GPO’s with a pre-pended
Organizational Unit (OU) descriptor in its name. For example, a Security
Groups object named “Departmental Share” in the Chemistry department
would be named “mcs.chemistry Departmental Share”. Requests for
additional GPO’s should be sent via email to advisor@andrew.cmu.edu.

Universal Groups
Due to restrictions in the ability to delegate authority to Organizational
Unit (OU) Administrators at the appropriate level, Departmental
Administrators will not be able to create universal groups. Large numbers
of universal groups, or universal groups with large populations, could have
a negative impact on performance within the Active Directory forest.
Computing Services will consider creating universal groups for
departments, on a case-by-case basis. Requests for universal groups,
including a detailed reason for their need, should be sent to
advisor@andrew.cmu.edu.
3. Service Packs and Patches
Domain Member Servers and Workstations should be kept at the same Service
Pack level as AD.CMU.EDU Domain Controllers. Service Packs provide
security patches and often improve the stability of the operating system by fixing
bugs. Workstations will not be forced to upgrade Service Packs or to apply
patches, but it is recommended that they stay up to date with patches. New
systems that are added to the Andrew Windows will be required to install the
latest supported OS versions and the current Service Pack.
4. Security Hot-Fixes
Member Servers and Workstations should have the latest Microsoft Hot Fixes
applied at least once every two weeks. Security Hot Fixes are important because
they reduce exposure to vulnerabilities, which could have impacts on the entire
Domain. Systems found to be excessively vulnerable to attack because of poor
security practices may be removed from the campus network.
5. Backups
To minimize the effects of data loss, administrators should safeguard their data by
periodically backing up their files systems. Computing Services runs a costrecovery backup service via Computer Operations. Contact
dk08@andrew.cmu.edu for more information.
6. IIS
Departments will have the ability to run Microsoft Internet Information Service
(IIS) on Member Servers within the Andrew Windows Domain. Due to the
widely publicized vulnerabilities in IIS, it is recommended that Administrators
apply caution in implementing IIS. This includes installing all security patches
for the Microsoft Internet Information Service. Clear-text authentication for IIS
services should not be permitted. The Andrew Webiso service will be available in
late Fall 2002. This should allow IIS servers to utilize Andrew usernames and
passwords for authentication.
II. Andrew Windows Service Policies
The following sections detail the Andrew Windows Service Policies
1. Member Server’s Operating System Versions
Andrew Window’s Member Servers must be running Windows 2000 Server SP2
or higher.
2. Creation of Departmental Domains
Computing Services will not permit the creation of additional Departmental
Domains within the existing Andrew.AD.CMU.EDU Forest. Although Active
Directory (AD) provides the ability to create multiple domains within a Forest,
there is a known security design flaw in the trusting relationships among
Domainsi ii and therefore a compromised Domain Controller could jeopardize the
campus infrastructure. So, for the moment additional domains will not be
supported. Future releases of the Campus AD structure may provide for this
ability.
3. External Trusts Relations
There are no plans to establish trusts between Andrew Windows and other
external entities. Currently, the Andrew Windows Domain has a trust established
with Andrew.cmu.edu to establish Kerberos credentials with the existing
Kerberos Distribution Centers. If users have a need to establish additional trusts,
please send the request to advisor@andrew.cmu.edu. However, due to the security
ramifications of the change, external trusts will not be made without careful
consideration to enterprise impacts.
4. Active Directory Schema Changes
There are no plans to extend the existing Active Directory Schema. Active
Directory Schema changes are set at the Forest level and hence affect the entire
Active Directory Infrastructure. If users have a need to modify the schema,
please send the request to advisor@andrew.cmu.edu. However, due to the global
nature of the change, schema change request will not be made without careful
consideration to enterprise impacts. Note - some common requests for Active
Directory Schema modifications might already be found in the Campus LDAP
directory.
5. Organizational Unit (OU) Accounts
Departmental Administrators will NOT be able to directly create User Accounts
within the Andrew Windows Domain. The Active Directory design allows for a
single user account namespace per Domain and the namespace is reserved for
Andrew User accounts. Account creation will be handled via the existing Andrew
account creation process. Administrators who want to establish accounts for
individuals that do not currently have Andrew accounts should pursue this
through the “sponsored accounts” or “courtesy appointment” process. If this does
not meet your departmental account needs, please send email to
advisor@andrew.cmu.edu to discuss alternatives.
Organizational Unit (OU) Administrators Accounts are created by Computing
Services for the delegation of control of OU’s to departments. Since these
accounts have advanced privileges, they should be treated with proper security
precautions (e.g. strong passwords, frequent password changes, used sparingly,
etc.).
6. Object Creation
Organizational Unit (OU) Administrators will be granted privileges to create
printers, groups, and computers objects within their respective Organizational
Unit OU. Because of the potential performance issues associated with having
excessively large numbers of objects within a domain, it is expected that
administrators will be judicious in their creation of objects, and will delete
unnecessary and outdated objects.
7. Blocking Inheritance
OU Administrators will have the ability to block Group Policy Object (GPO)
inheritance from parent Domains and Organizational Units (OUs). Blocking
inheritance prevents parent policies from being applied to departmental OU’s.
8. Mandatory Group Policy Over-rides
In some instances, it may be necessary for Computing Services to manually override blocks for certain Group Policies pertaining to security settings, or other
University Policies (e.g. auditing). Proposed changes to mandatory over-rides
will be discussed with OU Administrators prior to implementation. Application
software will not be present in Mandatory GPO’s and hence will never be forced
upon departments.
9. Non-Kerberos (NTLMv2) Authentication
Windows 2000 provides a variety of authentication schemes with varying levels
of security. Kerberos is a secure and reliable authentication protocol and will be
encouraged throughout Andrew Windows. In order to provide access to nonkerberos clients, the NTLMv2 protocol is also currently supported. In order to
ensure security for the Domain, less secure authentication schemes (NTLMv1,
LanMan, clear text) will not be permitted within Andrew Windows. As clients
migrate to Kerberos, the NTLMv2 authentication will also be removed from the
Andrew Windows domain.
10. Passwords
Passwords must be consistent with Andrew Account policies. Accounts that fail
to abide by password policies and show vulnerabilities may be disabled with
appropriate notice.
11. Security
In order to provide a reliable Andrew Windows Service for the entire campus,
departments will be expected to follow good security practices (password and
account security, physical security, etc.). Repetitive failures to secure resources,
may lead to actions against Administrators including potential removal from the
Domain.
12. Domain Security Policies
Microsoft Active Directory security policy (e.g. password length, password
change policy, etc.) is set at the Domain level. Therefore, OU Administrators
cannot adjust these policies. Computing Services will set these security policies
for the entire Andrew Domain. If users have a need to establish customized
security policies, please send the request to advisor@andrew.cmu.edu. Changes to
security policies will be announced via the established notification process.
13. DNS
As existing Computing Service Network guidelines state, DNS servers may not be
run on Carnegie Mellon’s network. Therefore, do not attempt to run a Windows
DNS server as part of the Andrew Windows Service.
14. Core Software GPO
A Group Policy Object (GPO) entitled “Andrew Core” is currently configured to
distribute a number of key applications (e.g. KerbFTP, CMULogin, KLPRMon,
KWeb, NiftyTelnet, etc.) to all of the machines in the Andrew Windows Domain.
Overtime, it may become necessary to remove packages or versions of software
from these GPO’s. Proposed changes to the Andrew Core GPO will be advertised
to the Organizational Unit (OU) Administrators two weeks prior to any changes to
the Group Policy Object. As detailed above, departments that would like to limit
these changes can prevent this by blocking inheritance of parent GPO’s.
15. Printing
OU Administrators will have full access to create printer objects within their
Organizational Unit. Computing Services has tested Windows Spoolers under the
Andrew Windows environment and it appears to work reliably. However, due to
the complications of supporting remote printing, Computing Services will not
provide support for departmental spoolers.
III. Andrew Window Infrastructure
1. Domain Controllers
Computing Services will maintain at least two domain controllers for every
domain in the Andrew Windows Infrastructure. The Domain Controllers will be
housed in a physically secure and environmentally controlled location.
2. Andrew User accounts
Andrew Users accounts are dynamically created within the andrew.ad.cmu.edu
domain. These accounts are managed by Computing Services. To authenticate
using these accounts, the user must login from an Andrew Window 2000 or
Windows XP domain computer and use an Andrew Password.
Users on non-Andrew Windows computers (e.g. Windows 98, Windows ME,
Windows NT and Macintosh computers) will also be able to authenticate using
their Active Directory password for these accounts. A web interface tool is
provided to allow non-Kerberos users to reset their AD password. This tool is
provided for non-kerberos clients for a limited period of time while the migration
to modern clients takes place.
3. Single Sign-on
Upon joining the Andrew.AD.CMU.EDU domain, the Andrew Core GPO installs
a new CMU Login GINA (Graphical Identification aNd Authentication). This
GINA has been customized to obtain all of the essential Kerberos tickets
necessary to function in the Andrew environment. Therefore, after login, an
Andrew User should have access to their typical Kerberos applications (KerbFTP,
NiftyTelnet, CorpTime, Mulberry) without having to reenter their password.
IV. Future Goals
1. Software Distribution and Support
Computing Services uses GPO’s and Microsoft Software Installer (MSI) files to
distribute software to cluster machines. This technique can apply to Departmental
Organizational Units. However, at this time, many vendors do not distribute
software in MSI format. Computing Services has been custom building MSI
packages to support cluster operations since the fall semester of 2000. The
current MSI packages were designed and tested only for cluster operations. We
will attempt to make these MSI packages available to departments within the
bounds of our licensing agreements. We will not customize or debug these
packages for environments outside of our standard cluster operations. We will
also attempt to provide MSI’s from commercial vendors when it is appropriate.
It is expected that as vendors ship software in MSI format, we will be able to
expand our services in this area. We may consider developing custom MSI’s as a
fee-for-service.
2. Central File Services
Computing Services is currently planning to provide a Central Windows File
Service. The File Service will be hosted in a secure operational facility and
maintained by Computing Services Desktop Support Group (DSP). File space will
be available via DSP for-fee-service.
3. AFS
Computing Services is continuing to work on integrating a stable AFS client into
Andrew Windows, providing integration with the existing Andrew File System.
4. Group Integration
Computing Services is investigating the possibility of adding groups to the
Campus LDAP Directory. Andrew Windows will attempt to make these groups
available and accessible.
5. Roaming Profiles
Windows 2000 provides the ability to host Roaming User Profiles. Computing
Services is not prepared to offer these services at this time. However, Folder
Redirection at the Organizational Unit level can be handled via Group Policies
using Loop-back processing. In the future, Computing Services will investigate
the possibility of deploying true Roaming Profiles.
i
http://www.ciac.org/ciac/bulletins/m-036.shtml
ii
http://www.aelita.com/library/whitepapers/AD_SIDH/Protecting_Active_Directory_from_Domain_Trust_
Vulnerability.pdf