Procedure
Effective Date
January 13, 2014
Chapter Name
Networking
Chapter Number
6.5.P.1
Date of Last Revision
January 13, 2014
Title
Active Directory Schema Modifications
1.0 Purpose
When the set of classes and attributes in the base Active Directory (AD) schema do not meet our needs, it is possible
to extend the schema by modifying or adding classes and attributes. However doing so must be reviewed in detail
and merits weighed against various risk factors as schema changes are global and affect an entire Active Directory
forest. Also, schema changes are permanent and cannot be reversed. Thus the schema should only be extended when
it is deemed absolutely necessary by DoIT.
This procedure establishes the process for request, evaluation, testing, and deployment of Active Directory schema
modifications.
2.0 Governing Policy
Number/Document Name
6.5 Active Directory Delegation
Effective Date
October 19, 2011
3.0 Procedure
Submit requests to modify the Active Directory schema using the DoIT Request for Service (RFS) process. All
requests must include the following:
•
A complete definition of the requested schema change. Include LDIF file in the request if it is available.
•
A proposal for how the data in any new attributes or objects will be managed:
o What system serves as the source of data?
o How is the data to be maintained?
o How will data be transferred to AD, if AD is not the source?
o For requests that rely on external data, the request must define who will be responsible for
maintaining that data.
Proposed schema changes will be evaluated for the following:
1.
Data sensitivity and privacy: Would any of the data be considered sensitive or private? Data privacy
issues may be re-directed to DoIT Security for review.
2.
Appropriateness: Is Windows Active Directory the proper place for this data?
3.
Correct ACLs: Are the default ownership and security ACLs appropriate?
4.
Schema Conflict: Does the proposed change conflict with existing schema or potentially conflict with
future schema? Does the proposed schema follow standards for naming and OID assignment?
5.
Compatibility: Could the schema change interfere with existing production services?
6.
Compliance: Could the desired use violate Eastern Michigan University policies?
A proposed schema change that raises an issue based on these criteria would be examined further to mitigate issues.
IT Procedure
Form Version 3.0
Page 1 of 2
Testing requirements
All schema updates will be tested in a development/test environment before being deployed into production.
Prior to the start of testing, the requester will need to develop a test plan for confirming the functionality of the
schema updates and applications. Depending on potential impact, DoIT will also develop a test plan for confirming
compatibility. Once a test plan is in place, the schema will go to development.
The development environment will have a subset of objects and will not have the full range of interoperability with
campus infrastructure. This environment will be used to determine functionality of the changes and to develop any
procedures needed for production rollout and support. Once the functionality test plans and basic compatibility tests
are complete and a documented production rollout plan is approved, the schema will go to user acceptance testing
phase on the test domain.
Deployment of schema updates
All updates to the user acceptance testing and production environments require notification of the Windows
Infrastructure clients. These changes are only made during the regularly scheduled maintenance times. Schema
changes are considered major changes because they cannot be completely rolled back and change management
requests must schedule lead time accordingly. All schema changes will be documented.
4.0 Responsibility for Implementation
The Director of Network and Systems services is responsibility for the implementation of this procedure.
5.0 Definitions
Term
Active Directory (AD) schema
Class
Object
ACL
LDIF
OID
6.0 Revision History
Description
Policy Committee
Approved by CIO
IT Procedure
Definition
Contains formal definitions of every object class that can be created in an Active
Directory forest. The schema also contains formal definitions of every attribute
that can exist in an Active Directory object.
A formal description of a discrete, identifiable type of object stored in the
directory service.
A unit of data storage in the directory service.
Access Control List ..
LDAP Data Interchange Format – A file format used to make changes to an
LDAP.
Object Identifier.
Approval Date
January 9, 2014
January 13, 2014
Page 2 of 2