University of Maryland Active Directory Policies
Purpose of this policy
Scope
AD Forest
Forest Schema & Data Visibility
Account and Group Synchronization
Account Creation and Password
Forest Security
Principle of Least Privilege
Active Directory DNS
Site – AD.UMD.EDU
Support for Domain/OU Administrators
Communication
Root Backup & Disaster Recovery Solution
OU Design & Delegation
Software License Compliance
Authentication
Enterprise/Domain Administrator Responsibilities
Organizational Unit Administrator Responsibilities
Joining\Leaving\Change of Role (s) within Active Directory
Naming Conventions
Compliance
1
9/29/09
Purpose:
The purpose of this policy is to provide requirements and specific recommendations for the successful
operation of the UMD Active Directory.
Scope:
This policy applies to all computer support personnel participating in UMD's Active Directory. It covers
information regarding the design and naming conventions for Active Directory, responsibilities for
computer support personnel and compliance guidelines.
AD Forest
AD.UMD.EDU domain will house all windows user accounts for the campus. This is done by
Microsoft’s account provisioning software which has data feeds from the Campus Enterprise
Directory (LDAP), PHR, and SIS. Each account will be mapped to their respective UMD
Kerberos principals. This is being done to enable authentication through the external Kerberos
realm which will allow users to use their directory ID and password for authentication to their
desktops and other services in AD. The forest is a single domain structure with 5 domain
controllers positioned throughout campus and off-site to provide redundancy in case of a
disaster. Organizational Units (OUs) will be created for departments participating in AD based
on their listing in the PHR system. OU administrators will be delegated full control within their
designated OU(s) and will be able to create and/or modify the following objects where they are
assigned privileges:
Security Groups
Computers
Printers
Scanners
Group Policy
Creation of additional OU’s
Member Servers
The domain controllers and services (hardware/software) which run and support AD.UMD.EDU
are monitored by OIT administrators on a 24x7 basis.
Forest Schema & Data Visibility
The schema is a definition of all object classes and their attributes contained within active directory. The
schema may be dynamically extended through the approval of the AD steering committee, OIT’s Change
Management Committee, and acknowledgment by the AD working group. Any proposed schema
modification will be evaluated based on potential conflicts; Data Ownership, Privacy, Security etc. Once
the steering committee and OIT’s Change Management Committee has approved changes to the schema
the working group will be notified via mailing list. Schema testing in a staged environment will occur
2
9/29/09
before and during the request for modifications. Changes will only be implemented after two weeks of
successful testing with no major issues identified. The data populated in AD reflects data in the Enterprise
Directory. The Enterprise Directory is updated by PHR and SIS on a daily refresh cycle.
Account and Group Synchronization
AD.UMD.EDU will be regularly populated by a directory synchronization process using Microsoft’s
Identity Lifecycle Manager (ILM) server that extracts data from the enterprise directory, PHR, and SIS
and populates the objects in Active Directory. ILM takes that information and creates and synchronizes
user accounts and security groups in Active Directory. Accounts will be disabled when employees is
terminated from the University. Students who graduate or leave the University will be removed from all
security groups.
Account Creation & Password
Accounts within AD.UMD.EDU are maintained centrally through the use of an automated account
management system (ILM). When a person becomes affiliated with UMD (Affiliate, Faculty, Staff,
Student, etc.) and is entered in the enterprise directory, an account will be automatically created for them
in Active Directory. Similarly, when a person is no longer affiliated with UMD, their accounts will be
disabled within Active Directory. When ILM initially creates an account in Active Directory, the
password will be set based on a randomly generate password. The password can only be changed at the
University’s password change page (password.umd.edu). When a user changes their password, the
changes will be reflected in Kerberos and Active Directory. Password synchronization between the two
environments is needed because of applications and services that need Active Directory for
authentication. All centrally created accounts will adhere to the campus password policies. OU
administrators will NOT have the ability to create accounts within their OU’s. If an
administrator needs an account for a guest or visiting scholar then they must obtain an account
through the campus Affiliate System.
Forest Security
The resources within AD.UMD.EDU are only accessible by domain members who have been specifically
granted access to the resource by their administrators. By default, all enabled domain members have user
access to resources when initially created. Administrators are encouraged to apply the appropriate ACLs
and group permissions to objects they wish to secure from other users in AD. All domain controllers and
servers maintained by OIT are routinely monitored for security vulnerabilities and critical patches are
immediately applied in accordance with OIT’s security policy. All domain controllers are firewalled using
a hardware appliance which only allows the necessary ports needed to provide services in
AD.UMD.EDU. OIT requires all OU AD administrators routinely evaluate their systems (both
workstations & servers) for vulnerabilities and patch them in a timely fashion. All servers within
AD.UMD.EDU will have a base security policy that will turn on Auditing, display the Campus
Acceptable use Policy on the screen upon login, turn on the firewall, and point the server to the campus
Windows Server Update Services (WSUS) servers. Due to the sensitive nature of data that is visible to
Domain and OU administrators, student’s employees may NOT be assigned the role of administrator.
3
9/29/09
Principle of least privilege
The principle of least privilege states that users must have access to the software, data, and devices
required to perform their daily duties, but must not have access to local or network resources that are not
required for their job tasks. Similarly any process accounts must have access necessary to run the process,
but no more. If low-privileged accounts are compromised, they will do a lot less damage to a system than
a high-privileged account. Consequently, using a non-administrator account instead of an administrator
account while completing daily tasks offers the user added protection against infection from a host of
malware, external or internal security attacks, accidental or intentional modifications to system setup and
configurations, and accidental or intentional access to confidential programs or documents.
Microsoft White Paper: Using a Least-Privileged User Account
Active Directory DNS
AD DNS services are centrally maintained by OIT. All workstations participating in active directory
should utilize the Campus DNS servers: 128.8.76.2, 128.8.74.2, 128.8.5.2. There are cases when you will
need to register your machine hostname with NTS. If that need occurs, please send email to
Hostmaster@noc.umd.edu. All servers in Active Directory should use Active Directory’s DNS servers
128.8.12.132, 128.8.12.133, 128.8.163.135, 128.8.163.136, as their primary DNS servers. You will also
need to contact the Wintel group so that we can register your server in AD’s DNS and you will need to
register your hostname with NTS (hostname@umd.edu) for reverse lookup. As secondary or tertiary
servers, the campus bind servers may be used: 128.8.5.2, 128.8.74.2, 128.8.76.2.
Site – AD.UMD.EDU
The forest currently spans three sites (PDC AV-Williams, the SDC CSS Building, and Shady Grove
Campus). Any requests for changing the site configuration will be brought before the AD steering
committee.
Support for Domain/OU Administrators
There will be several resources available to administrators for problem resolution. Administrators can
send mail to UMD-AD@umd.edu asking questions of other Active Directory administrators on campus.
This list is monitored by members of the Wintel Group. Additionally, OIT’s helpdesk system has been
modified to handle AD.UMD.EDU specific issues such as login issues using a kerberized account or
being unable to locate a user account in AD. Employees and students should continue to use their local
support infrastructure or contact the OIT helpdesk for desktop support.
Communication
Communication will occur via the appropriate mailing lists.
Root Backup & Disaster Recovery Solution
AD is currently on a nightly backup schedule.
4
9/29/09
OU Design & Delegation
Top-Level OUs will be automatically created for each department when they join AD. Administration
will be delegated to an administrative security group which will hold access controls for administrators of
the department identified by appropriate management. OU administrators have the ability to create child
objects within their OUs. It is required that everyone adheres to the naming standard described below
when creating object within AD.
Software License Compliance
It is the responsibility of the department to ensure that all of their desktops and servers are properly
licensed. Although some CALs may be offered by OIT for specific MS products, Administrators are
strongly encouraged to stay abreast of all licensing needs within their environments.
Authentication
The purpose of this section is to describe the authentication options that are available within
AD.UMD.EDU. All workstations that are a part of AD.UMD.EDU will be able to authenticate to the
forest using the external Kerberos realm or directly to AD.UMD.EDU. By default, workstations will be
configured to authenticate to the external Kerberos realm. There are circumstances when users will have
to authenticate directly to AD.UMD.EDU (remote access to files or applications that cannot take
advantage of the external Kerberos realm). Below is a description of which protocols will or not be
available.
Clear text authentication is not allowed in the AD.UMD.EDU infrastructure. Clear text authentication will
be turned off on all domain controllers. Clear text authentication is not allowed for IIS, Mac File and Print
Services, Samba, or FTP.
Kerberos Version 5 Protocol
Kerberos Version 5, also known as K5 or Kerberos v5, is the preferred authentication protocol for
Windows when operating in a domain environment. Every Windows Infrastructure domain controller is
also a Kerberos Key Distribution Center or "KDC". Microsoft has added extensions into the vendor
extension area of the Ticket structure to support the Microsoft credential system (Authorization).
Microsoft supports trust relationships with an external Kerberos source for user authentication.
AD.UMD.EDU currently has an external trust with the campus Kerberos (Heimdal) environment.
NTLMv2 Protocol
NTLMv2 stands for NT LAN Manager Authentication protocol version 2. This is a challenge-response
based protocol. In a challenge-response protocol, the client generates a response using the server
challenge and a secret value that the client and server both know (like a password) and sends it back for
validation. Security features were added to the protocol in version 2 to provide for stronger protection of
encryption keys and challenges. LM and NTLMv1 protocols are not allowed in the AD.UMD.EDU
Infrastructure.
5
9/29/09
Enterprise/Domain/OU Administrator Responsibilities:
The AD Infrastructure is composed of many different computing, administrative and consulting services.
This section provides a brief description of these services and specific contact information for each. In
general, people who experience problems with a particular service should speak to their local
administrator first. If the issue can’t be resolved, then the local administrator raises the issue to the
appropriate support group. OIT installs and maintains the servers and support machines which run Active
Directory for the UMD forest. Staff within the Wintel Group will only be elevated to the level of
Enterprise Administrators (EA) only when those rights are needed and with prior approval from the
Manager of the Wintel Group. They install, configure, and maintain the Active Directory domain
controllers for the campus Active Directory forest that support the AD.UMD.EDU infrastructure. Urgent
problems related to domain controllers or infrastructure services should be reported by calling the OIT
Helpdesk Desk at 301-405-1500. For general discussion, this group can be contacted via e-mail at servergroup@umd.edu.
The responsibilities of the Enterprise Administrators are:
•
Install and maintain the Active Directory domain controllers in the
AD.UMD.EDU forest.
•
Manage the flow of information from the Enterprise Directory to
AD.UMD.EDU. The Wintel group also manages the replication of directory
information within the Active Directory, and makes any enterprise level changes
to the AD directory, such as schema modifications.
•
Maintain Forest-wide Operations Masters: Schema Master and Domain Naming
Master
•
Diagnose all reported AD problems.
•
Provide backups for disaster recovery purposes
•
Responsible for maintain accurate time on the forest domain controllers.
•
Responsible for maintaining security of the forest root.
•
Maintain site-level security policy. The Active Directory architecture provides
the ability to apply group policy and security to all systems within a site. By
default, no policies will be made to the forest default site. Any changes will be
presented to the AD community and before implementation.
•
Manage Root-level DNS. Manage forward zones for Root Domain Controllers.
•
Maintain test forest for internal and campus testing. OIT-TSS provides a
Windows/AD test environment that mimics the production environment so that
services can be tested and questions answered before introducing them into the
6
9/29/09
production environment. Any department can participate in the test forest in a
manner appropriate to the way that they will participate in the UMD Forest.
Testing may also be required before new services or applications are introduced
into the production forest.
•
Communicate all enterprise-wide changes to the forest via AD reflector (UMDAD@umd.edu) and other technical team reflectors.
•
Have administrator privileges on all domain controllers and OUs, in order to
support and maintain the infrastructure's domain controllers and directory
services.
•
Assume a "hands-off" approach to OU administration. Only when faced with an
enterprise-wide emergency, where no adequate alternative exists and every
attempt has been made to contact appropriate support personnel and relevant
managers first, will an Enterprise administrator take action at the OU level.
•
Support staff required to have working knowledge of Active Directory.
•
Maintain a well documented infrastructure diagram of their respective
environments, including descriptions of all services provided by servers
participating in AD.
•
Maintain only the recommended list of services on the DCs (KDC, LDAP, and
DNS) nothing more.
•
Abide by Forest naming standards.
•
Maintain the appropriate level of security and patch revisions on the domain
controllers as specified by the Windows Support Team.
•
Keep current with proposed changes and upgrades to software in the Forest that
is communicated by Microsoft’s Technical Support Team.
•
Keep a current contact list available for the Windows Support Team.
•
All changes to the domain will be approved by OIT’s Change Management
Committee
•
Domain Controllers will be monitor 24x7 to ensure high availability.
•
Must have DCs and FSMO roles strategically located in multiple locations to
provide redundancy in case of a disaster.
•
DCs must be physically secured.
•
DCs should have a current hardware agreement with vendor.
7
9/29/09
•
Adhere to secure account management process using ILM
•
On-call staff will monitor and resolve all issues pertaining to the DC’s
•
Must have onsite support to resolve issues within your domain during business
hours
•
Must have disaster recovery & backup/recovery solution for the DCs.
•
Communicate and coordinate all scheduled and unscheduled outages or major
upgrades to OU administrators.
•
Must coordinate any maintenance that may affect Forest (i.e. replication, adding
services to the DCs, etc.)
•
Follow all OU administrator responsibilities below.
Organizational Unit Administrator Responsibilities:
•
Agree to the policies and guidelines for AD.UMD.EDU OU Administrators
•
Work closely with the Windows Support Team.
•
Adhere to the UMD naming standards
•
Provide their own local desktop, application & internal services support
•
Add, Delete & Maintain objects within their OU
•
Add, Delete, Maintain & Troubleshoot GPOs
•
Delegate administrative functions to authorized accounts & ensure policy
compliance
•
Maintain proper security groups and authorization policies
•
Windows Client CALs (Currently covered under the campus MEEC agreement
see: http://www.oit.umd.edu/units/slic/products/microsoft/winserver2008.html)
•
Server licensing required to be current
•
Maintain member server OS & hardware maintenance
•
Keep workstations and member servers within their OUs secure
•
Service packs & hot fixes should be kept up to date where applicable
8
9/29/09
•
Servers should never be more than 1 service pack behind the current (except
where required for business need)
•
Monitor member servers regularly
•
Apply for a new data feed for every application server which will utilize Active
Directory for authentication
•
Backup member servers & Test restore procedure.
•
Server operating system must be within the boundaries of Microsoft’s
Mainstream Lifecycle Support (See: http://support.microsoft.com/gp/lifeselect)
•
Colleges/Departments/Units are responsible for the management of local
resources and services. Examples of these resources and services include
installing and removing servers, desktops, printers, creation of file shares and
group, and access management.
•
Provide contact information for OU administrators in case of emergency
•
Responsible for maintaining security of all objects within their OU
Leaving\Change of Role (s) within Active Directory
If at any time a department decides to no longer participate in the campus Active Directory forest, the
department head will need to provide a written statement (email or memo) to the Director of Technical
Services and Support indicating that they will be leaving the Active Directory forest. If the role of an OU
administrator changes (resignation, new job responsibilities, etc.), then department head must notify the
Manager of the Wintel group immediately.
Naming Convention:
Purpose:
Provide a naming convention for all units within UMD's Active Directory that uniquely identifies
workstations, servers, users, groups, OUs, GPOs and distribution lists in the NetBIOS, DNS, and LDAP
name-spaces. The campus Active Directory will have well over 100,000 objects that provide information
and act as resources to many departments. The only possible way to ensure AD can be used effectively is
to enforce naming standards. Aside from avoiding name collisions, naming standards will allow users and
administrators to efficiently search through thousands of objects and locate their resources and data. The
naming Convention document can be found at http:\\oit.umd.edu\ad\naming convention.
Compliance:
All Colleges/Departments/Units heads and designated administrators will have to sign a Memorandum of
Understanding and the Acceptable Use Policy in order to participate in/join the campus Active Directory.
9
9/29/09
It is the responsibility of each AD administrator to maintain their AD environment as per the above
specifications and guidelines. Department heads will be notified upon repeated violations by an AD
administrator and explained the impact it has on the entire campus AD infrastructure. In cases of gross
negligence or refusal to adhere to the agreed policy, OIT will recommend to the AD Steering committee
that a department is immediately removed from the Forest.
The Memorandum of Understanding and the Acceptable Use Policy can be found at the links below:
Memorandum of Understanding:
http://www.oit.umd.edu/wintel/ad/policies/mou.php
Acceptable Use Policy for Active Directory:
http://www.oit.umd.edu/wintel/ad/policies/accept_use.php
Naming Convention:
http://www.oit.umd.edu/wintel/ad/policies/name_convention.php
10
9/29/09
By "signing this form/checking the box below", I verify I have read and understand the
information provided above, and agree to comply with its contents.
I have read and understand the information provided in this document
Signatures:
Print Name
Signature
Title
Date
Applicant_____________________________________________________________________
Dept Head____________________________________________________________________
OIT
Signature_____________________________________________________________________
11
9/29/09