Administrative Guidelines for Andrew Windows


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Administrative Guidelines for Andrew Windows

  1. 1. Administrative Guidelines for Andrew Windows Carnegie Mellon University A Computing Services Publication May 20, 2010 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
  2. 2. 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
  3. 3. 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 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
  4. 4. 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 pre- pended 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
  5. 5. • 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 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 cost- recovery backup service via Computer Operations. Contact 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
  6. 6. 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 to establish Kerberos credentials with the existing Kerberos Distribution Centers. If users have a need to establish additional trusts, please send the request to 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,
  7. 7. please send the request to 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 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 over- ride blocks for certain Group Policies pertaining to security settings, or other
  8. 8. 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 non- kerberos 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 Changes to security policies will be announced via the established notification process.
  9. 9. 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 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.
  10. 10. 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
  11. 11. 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.
  12. 12. i ii df