Active Directory Services Administration Manual

ITS Systems
October 12, 2007, Updated February 1, 2017

 

AD.UNC.EDU Directory Services are bound by the policies set forth in the ITS Policies, Procedures and Guidelines. In addition, Information Technology Services (ITS) has developed specific specifications to govern various aspects of the service.

 

Table of Contents

User Accounts

Departmental Organizational Units

Computer Accounts

Groups

Group Policies

Naming Conventions

Schema Extensions

Domain Naming system (DNS)

Distributed File System (DFS)

Domain Restoration

Disaster Recovery

Logs

Domain Support Model

Forests and Domains

Communication

User Accounts

ONYENs

The ONYEN username/password information for all active faculty and staff, and students at UNC-Chapel Hill are loaded into the AD.UNC.EDU domain. The ONYEN information is synchronized with the ONYEN database in real time. Thus, users do not change user usernames and passwords on AD.UNC.EDU, but on the ONYEN Management Page.

In addition to ONYEN synchronization, users’ directory information is also replicated from the UNC Campus Directory. Any information that is incorrect must be updated using the Campus Directory Update Tool.

ONYEN user accounts are owned and located centrally. Departmental security policies and settings cannot be applied directly to ONYEN user accounts. Instead, security policies must be applied to departmental computers and applied to user accounts using Group Policy loopback processing.

Active Directory ONYENs are deprovisioned in a monthly batch process. Accounts will be deleted if all the following criteria are met:

  • Account is at least 2 years old
  • Account has not logged on in at least 2 years
  • Account has not changed password in at least 2 years
  • Account does not have a mailbox
  • ONYEN system indicates account not active

Domain Administrator Accounts

Domain administrator accounts are special accounts used for managing the domain infrastructure. As a best practice, the number of domain administrator accounts should be kept to a minimum. Domain administrator accounts will only be available to ITS staff with a primary responsibility for managing Active Directory infrastructure and approval by the AVC for Infrastructure and Operations or ITS Active Directory Service Owner.

All administrator accounts must correspond to an ONYEN and must follow the Password Standards for System and Application Administrators. Administrator accounts never expire. Administrator accounts are subject to a special password policy with more stringent lockout requirements and a 30-day password expiration. Administrator accounts must not set the “password never expires” flag or have servicePrincipalNames (SPN).

All domain administrators will receive a daily report, by email, showing the systems their admin account has logged in from and any changes to AD objects made by their admin account. Domain administrators should review this report daily for signs of abuse.

 

Administrator Account Naming Rules
Field Char Length Example
ONYEN Up to 16 pgmurphy
Separator 1 .
Suffix 3 dom

Example:         pgmurphy.dom

 

Departmental User Accounts

Special purpose user accounts may be created in the AD.UNC.EDU domain by departmental administrators. It is critical the departmental user accounts not conflict with ONYEN accounts or potential ONYEN accounts–that is, usernames <= 8 characters. The ONYEN system has priority over all usernames with <= 8 characters. Any departmental user account conflicting with the creation of an ONYEN will be immediately deleted. Following the naming standards will ensure that no conflicts exist.

Departmental user accounts will be disabled if the following criteria are met:

  • Account is at least 1 year old
  • Account has not logged on in at least 1 year
  • Account has not changed password in at least 1 year

Departmental user accounts will be deleted if the following criteria are met:

  • Account is disabled
  • Account is at least 395 days old
  • Account has not logged on in at least 395 days
  • Account has not changed password in at least 395 days
  • Account does not have a mailbox

The following types of accounts are permitted:

                   OU Administrator Accounts

OU administrator accounts are special accounts which have been delegated special privileges on the domain that aren’t appropriate for general computer usage. These accounts should only be used when the elevated permissions are necessary.

All administrator accounts must correspond to an ONYEN and must follow the Password Standards for System and Application Administrators. Administrator accounts will be disabled if no active, matching ONYEN is found. Administrator accounts never expire. Administrator accounts are subject to a special password policy with more stringent lockout requirements and 30 day password expiration. Administrator accounts must not set the “password never expires” flag or have servicePrincipalNames (SPN). Administrator accounts should not be mail-enabled or trusted for delegation.

An administrator account will be created for the requestor of each departmental OU. This user will have the ability to create additional administrator accounts for other departmental administrators. ITS does not typically make changes, including resetting passwords, for Administrator accounts. This task should be done by other departmental administrators.

All OU administrators will receive a daily report, by email, showing the systems their admin account has logged in from and any changes to AD objects made by their admin account. OU administrators should review this report daily for signs of abuse. Managers may request rollup reports their subordinates’ admin account activity.

Administrator Account Naming Rules
Field Char Length Example
ONYEN Up to 16 pgmurphy
Separator 1 .
Suffix 3 adm

Example:         pgmurphy.adm

                 Service Accounts

Service accounts are special accounts that are used to run services or schedule tasks under their own credentials. This allows the service to be run using the minimum required credentials and allows for easier security monitoring.

Service accounts must follow the Password Standards for System and Application Administrators. Service accounts must have complex passwords with at least 15 characters. When supported, passwords should be much longer, e.g. 64-128 characters. Service account passwords do not expire, but must be changed every 1 year.   Service accounts are owned by the OU administrators for the OU where they are located. The service account owners are responsible for ensuring that the service account usage is secure and complies with all UNC-Chapel Hill policies. Service accounts should not be used to logon interactively in place of admin accounts.

Service Account Naming Rules
Field Char Length Example
OU ID Up to 5 ITS
Separator 1 _
Description Up to 11 mssqldev
Separator 1 .
Suffix 3 svc

Examples:         ITS_mssqldev.svc and its_dis-mssqldev.svc

                Test Accounts

Test accounts are special accounts used to temporarily test something.

Test accounts must follow the ONYEN password policy. Test accounts must be set to expire 30 days after creation and be deleted within 15 days after they expire. Test accounts are owned by the OU administrators for the OU where they are located. The test account owners are responsible for ensuring that the test account usage is secure and complies with all UNC-Chapel Hill policies.

Test Account Naming Rules
Field Char Length Example
OU ID Up to 5 ITS
Separator 1 _
Description Up to 11 sidhistory
Separator 1 .
Suffix 3 tst

Example:         ITS_sidhistory.tst

 

                Common Accounts

Common accounts are domain users used to auto-logon a computer, for example a kiosk. The intention is the credentials are stored in the operating system and are not know by the end user.

Common accounts must follow the Password Standards for System and Application Administrators. Common accounts must have complex passwords with at least 15 characters. When supported, passwords should be much longer, e.g. 64-128 characters. Common account passwords do not expire, but must be changed every 1 year.   Common accounts are owned by the OU administrators for the OU where they are located. The common account owners are responsible for ensuring that the common account usage is secure and complies with all UNC-Chapel Hill policies. It is recommended that common accounts are configured with LogonWorkstations restrictions to avoid misuse.

Field Char Length Example
OU ID Up to 5 ITS
Separator 1 _
Description Up to 11 kiosk
Separator 1 .
Suffix 3 com

Example:         ITS_kiosk.com

                 Guest Accounts

Guest accounts are special accounts created to give temporary access to a person who does not have an ONYEN. In most cases, users should be given access by registering them as an Affiliate in AffiliateWeb. Guest accounts were primarily used to give external collaborators access in SharePoint. Since moving to Office 365 SharePoint, external collaborators should be given access via Microsoft accounts. CREATION OF NEW GUEST ACCOUNTS IS NO LONGER PERMITTED.

Guest accounts must follow the ONYEN password policy. Guest accounts must be configured to expire 60 days after creation and must be deleted within 15 days after they expire. Guest accounts are owned by the OU administrators for the OU where they are located. The guest account owners are responsible for ensuring that the Guest account usage is secure and complies with all UNC-Chapel Hill policies.

Guest Account Naming Rules
Field Char Length Example
OU ID Up to 5 ITS
Separator 1 _
Description Up to 11 jqpublic
Separator 1 .
Suffix 3 gst

Example:         ITS_jqpublic.gst

                Other Accounts

The following account types are used for special services, such as Exchange, Office 365, and Qualys.

Type Extension
Resource Mailboxes .rmb
Shared Mailboxes .smb
Unified Groups .ug
Qualys Scanner Account .scn
VMware Admin .vmadmin
Departmental Organizational Units

Organizational units (OUs) are analogous to folders in a file system. In addition to being a container for Active Directory objects, OUs are used to create administrative boundaries for delegation and the application of Group Policy Objects. A well-organized OU architecture will simplify management by grouping objects that have common delegation and security policy needs.

Naming

A departmental organization unit (OU) will be created by ITS Windows Enterprise Infrastructure for each eligible department participating in the AD.UNC.EDU domain. To be eligible, a department must have at least one permanent IT staff member who can serve as the OU administrator. The departmental OU is intended as an administrative boundary and departmental OUs will not necessarily represent the “org chart.”

The departmental OU will contain all computers, groups, organizational units, and group policies that belong to the department. The departmental administrators will be delegated control over this OU. The departmental administrators are solely responsible for the administration of this OU and all the objects that it contains.

Each departmental OU will be given name of 5 characters or less. This name will be an abbreviation of the department that it represents. In most cases this name will be the official abbreviation used by the department, college, or unit. In the case of conflicts, the abbreviation will be awarded to the organization that has a more well-known use of the abbreviation. However, once a departmental OU name has been established, it cannot be changed.

Departmental Organization Unit Naming Rules
Field Char Length Example
OU ID Up to 5 ITS

Example:         ITS and SON

 

Organization

All departmental OUs will be created under the UNC OU which exists in the root of the domain. Departmental OUs will be organized in a quasi-org chart design based on end-user desktop support responsibilities. In short, departments that provide tech support to end-users using domain computers will have their own OU within the UNC OU. Organizations that receive their end-user support from a parent organization will be a part of the parent organization’s OU. Parent organizations are encouraged to create sub-OUs following the org chart, but this is at the parent organization’s discretion.

This organization and delegation scheme can be extended to as many levels that are necessary to fully capture the organization’s desktop support environment. Consider the following advanced example:

  • A college provides desktop support to its departments.
  • The college would create a sub-OU for its departments.
  • Each department would then have sub-OUs for each of its departments, such as administration, and several research labs.
  • Each research lab has its own desktop support staff that share duties with the college’s staff.
  • The college would delegate control over each research lab to the research lab’s desktop support staff.

Because the design of a department’s organizational unit hierarchy is critical to the efficient usage of Active Directory, ITS Systems will provide consulting to departmental administrators to help ensure that their design will help promote efficiency and security.

Computer Accounts

When a computer is joined to a domain, a computer account is created in that domain. We recommend that the departmental computers be added to the AD.UNC.EDU domain by first adding the computer name into the departmental OU using the Active Directory Users and Computers MMC. To keep the number of objects in Active Directory under control, the following procedure will be followed:

  • For computer accounts inside the Computers container: Any computer account in the Computers container will be disabled after 7 days. A disabled computer account in the Computers container that has been disabled for over 7 days will be deleted. An email will be sent daily to the creator of the computer requesting that it be moved to their departmental OU. To assist departmental administrators in retrieving computers from the Computers container, all departmental administrators will have permissions to move computers from the Computers container into their OU.

 

  • For computer accounts outside the Computers container: A report will be generated each semester containing all computer accounts that have been inactive for over 365 days. This report will be sent to the activedirectory@listserv.unc.edu After 7 days, any computer remaining inactive will be disabled. After 30 days, any computer remaining inactive and disabled will be deleted.Computers will show up as inactive if they are unable to contact the domain controllers. Computers that are off-campus are unable to contact the domain controllers unless they are connected to the UNC-Chapel Hill VPN. All users who take computers off-campus should be encouraged to use the VPN whenever possible.

 

Computer names must be unique, but there is no required naming scheme. It is suggested that computer names start with the OU name.

Groups

Security Groups

Security groups are general purpose groups used for grouping users and computers for easier management. It is important that security groups have descriptive names and descriptions that further explain their purpose, membership, and resource permissions.

In cases where groups are used to filter the application of Group Policy, the group and Group Policy should have identical names.

We encourage following the AGDLP group design practice.

Note: The underscore ‘_’ character is reserved for use as a separator in object names to simplify programmatically parsing object names. Please do not use underscores except as specified in this document. Hyphens and spaces are available to use as separators.

Security Group Naming Rules
Field Char Length Example
OU ID Up to 5 ITS
Separator 1 _
Description Up to 59 DIS-Staff

Example:         ITS_DIS-Staff

Software Groups

Software groups are special groups created to distribute software to computers via Group Policy. These are not widely used in ad.unc.edu. SCCM is the preferred tool for software deployment.

Software Group Naming Rules
Field Char Length Example
Prefix 2 SW
Separator 1 _
OU ID Up to 5 ITS
Separator 1 _
Vendor Up to 56 Symantec
Separator _
Product Antivirus
Separator _
Version 10.1.6.6010

Example:         SW_ITS_Symantec_Antivirus_10.1.6.6010

Managed Groups

Managed groups are special groups that are managed by the Identity Management System. The purpose of these groups is to provide pre-populated groupings of users based on their identity management information, such as: departmental affiliations, class, course enrollments, major, etc.

Managed groups are named based on the naming standards in Grouper and are prefixed with MSG for security groups and MDG for distribution groups.


Group Policies

Note: The underscore ‘_’ character is reserved for use as a separator in object names to simplify programmatically parsing object names. Please do not use underscores except as specified in this document. Hyphens and spaces are available to use as separators.

Security Policies

Security Group Policies are general purpose GPOs used for applying security policies and settings to users and computers. It is important that security GPOs have descriptive names and descriptions that further explain their purpose and effects.

In cases where groups are used to filter the application of Group Policy, the group and Group Policy should have identical names.

Security Group Policy Naming Rules
Field Char Length Example
OU ID Up to 5 ITS
Separator 1 _
Description Up to 59 DIS-Staff

Example:         ITS_DIS-Staff

 

Software Installation Policies

Software installation Group Policies are special Group Policies created to distribute software to computers. Group Polices are not widely used to distribute software in ad.unc.edu. SCCM is the preferred tool for software deployment.

Software Group Policy Naming Rules
Field Char Length Example
Prefix 2 SW
Separator 1 _
OU ID Up to 5 ITS
Separator 1 _
Vendor Up to 56 Symantec
Separator _
Product Antivirus
Separator _
Version 10.1.6.6010

Example:         SW_ITS_Symantec_Antivirus_10.1.6.6010

Naming Conventions

All Active Directory objects noted in this document must abide by the described naming convention for that object. A naming convention is necessary to ensure the ability to locate, utilize, and troubleshoot resources, and to avoid name collisions. Within the AD.UNC.EDU Active Directory structure, this naming convention has been established for Users, Computers, Groups, Organizational Units (OUs), Printers, and Group Policy Objects (GPOs) to reduce the difficulty in searching for resources. A naming convention for Exchange objects, such as distribution lists, public folders and resource names, is also in place. Before adding any objects to the AD.UNC.EDU domain, please carefully read the naming conventions in this document.

Any requests for exceptions to the naming conventions must be submitted in writing to ITS Systems.

Schema Extensions

The AD.UNC.EDU domain schema will only be extended when the proposed extension will demonstrably benefit the University, is supportable and scalable for the enterprise, and will have minimal impact on service delivery. Because schema extensions are not reversible, extensive testing and review of schema extensions must occur. Requests to extend the AD.UNC.EDU schema require the approval of the domain administrators.

Any custom schema extensions must be prefixed with a unique identifier to prevent naming collisions with existing and future products and must have a registered OID.

Domain Naming System (DNS)

The domain controllers also server as DNS servers in order to enable dynamic DNS. Dynamic DNS allows AD member systems to automatically create DNS records. The AD DNS servers are configured to transfer DNS to the campus BIND DNS servers. Clients should be configured to point to the campus BIND servers for DNS resolution.

Departments can request that DNS domain and reverse zones be added to AD DNS. The process varies depending on the situation. Contact ITS-SYSTEMS for more information.

Dynamic DNS records in AD are configured to be scavenged once per week. Dynamic DNS records will be automatically deleted if they haven’t been updated within 14 days.

Distributed File System (DFS)

Distributed File System namespace roots will be created upon request. Each department is limited to 1 root. DFS namespaces will be delegated to the OU admins for the department, allowing the creation of targets under the root.

Domain Restoration

ITS Systems is able to provide restoration of accidently deleted or corrupted domain objects. Objects must have been deleted within 180 days to be restored. To request an object restoration, create a Help Request for the ITS-SYSTEMS group including the details of the deleted objects.

Disaster Recovery

Being a critical infrastructure system, considerable planning has gone into disaster recovery. AD.UNC.EDU Directory Services are hosted on at least three redundant domain controllers. These domain controllers are located in two geographically separate, secure, datacenters with redundant power sources.

Active Directory is backed up nightly.

Logs

Active Directory creates extensive logs about login events and changes to objects in AD. These logs are available in Splunk for 90 days. Additional logs are maintained for audit purposes, up to 365 days, however these logs are not available for routine requests. Request for logs or reports should be made by ticket to ITS-SYSTEMS. Requests must include a valid business reason for the log request. Log requests will be granted at the discretion of the ITS Active Directory Service Owner and in accordance with university policies.

Domain Support Model

Departmental administrators are responsible for managing all aspects of their departmental OU. ITS Systems will provide consulting to departmental administrators to assist them in effectively and efficiently using the AD.UNC.EDU domain.

Forests and Domains

The AD.UNC.EDU Active Directory domain uses the single forest, single domain model. Child domains will not be permitted in the AD.UNC.EDU forest. Other Windows forests will not be trusted by the AD.UNC.EDU forest, except temporarily to accommodate migration into the AD.UNC.EDU domain.

Communication

Departmental administrators should subscribe to the activedirectory@listserv.unc.edu mailing list, as it is the primary communication method on matters concerning the AD.UNC.EDU domain.

The ITS Change Notice System will be used to communicate information impacting the service level of the AD.UNC.EDU domain and supporting systems.