The AD.UNC.EDU Directory Services service is bound by the policies set forth in the ITS Policies, Standards, and Procedures. In addition, Information Technology Services (ITS) has developed specific specifications to govern various aspects of the service.
Emergency accounts aka “glass-break accounts” are accounts that are only meant to be used for system recovery or when domain administrator accounts cannot be used. These accounts include the built-in Administrator account for the domain and the Directory Services Restore Mode (DSRM) account on each domain controller.
The passwords for these accounts are kept in a password manager available to domain admins.
Any attempt to login with these accounts are logged and alerted.
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 Connect Carolina Self Service 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:
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 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 |
jqpublic |
| Separator |
1 |
|
| Suffix |
3 |
dom |
Example: jqpublic.dom
Special purpose user accounts may be created in the AD.UNC.EDU domain by departmental administrators. It is critical the departmental user accounts do 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 365 days old
- Account has not logged on in at least 365 days
- Account has not changed password in at least 365 days
- Additionally, departmental user accounts will be disabled if their maximum password age policy is less than 365 days, and the password is expired.
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 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 elevated permissions are necessary. Note that OU administrator accounts should not be used for high-risk activities, including web browsing, email, and logging in to client computers, other than the administrator’s assigned workstation. LAPS is the preferred solution for administration of client computers.
All administrator accounts must correspond to an Onyen and must follow the Passwords, Pass-phrases, and Other Authentication Methods Standard. 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. Administrator passwords must be 17 characters and expire after 91 days. Administrator account passwords will be locked out for 5 minutes after 10 failed attempts in a 5 minute period. 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.
By default, there are 3 privileged roles within each departmental OU: OU Admin, Computer Admin, and Server Admin. Where possible, departments should consider assigning these roles to different people to achieve separation of duties. Accounts for these distinct roles can be distinguished using .adm for OU admins, .cadm for computer admins, and .sadm for server admins.
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.
When OU administrators leave or change roles, their admin accounts should be deleted. When OU Administrators change departments, their admin account should be deleted, and a new admin account created for them. This will remove any permissions directly granted to the admin account.
Administrator Account Naming Rules
| Field |
Char Length |
Example |
| Onyen |
Up to 8 |
jqpublic |
| Separator |
1 |
|
| Suffix |
3-4 |
adm, cadm, sadm |
Example: jqpublic.adm, jqpublic.cadm, jqpublic.sadm
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 Passwords, Pass-phrases, and Other Authentication Methods Standard. Service accounts must have complex passwords with at least 17 characters. When supported, passwords should be much longer, e.g., 64-128 characters. Service account passwords do not expire but must be changed every 365 days. 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.
Administrators are encouraged to use group managed service accounts (gMSA) where possible and to migrate existing service accounts to gMSAs where possible. This eliminates the need to manage passwords.
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
Group managed service accounts (gMSA) are an alternative to standard service accounts which offer the advantage of having extremely complex, managed passwords, eliminating the need to manage and change passwords. While gMSAs are not compatible with all service account scenarios, they are recommended where supported.
For assistance with creating and implementing gMSAs, contact the domain admin team. gMSA names are limited to 16 characters, with the last character being a $. We’ve modified the naming standard to maximize the number of characters available for description. gMSAs cannot be synchronized to Azure AD.
Group Managed Service Account Naming Rules
| Field |
Char Length |
Example |
| OU ID |
Up to 5 |
ITS |
| Description |
Up to 13 |
mssqldev |
| Suffix |
1 |
$ |
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 accounts are not synchronized to Azure AD.
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 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 known by the end user.
Common accounts must follow the Passwords, Pass-phrases, and Other Authentication Methods Standard. Common accounts must have complex passwords with at least 17 characters. When supported, passwords should be much longer, e.g., 64-128 characters. Common account passwords do not expire but must be changed every 365 days. 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
vi. 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 using unit HR processes to affiliate them in a way that would entitle them to an Onyen. 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 accounts are not synchronized to Azure AD.
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
vii. Native Azure AD Global Administrator Accounts
Azure AD global administrator accounts are special accounts used for managing the Azure AD tenancies in the Azure cloud and only exist natively in those Azure AD tenancies. As a best practice, the number of Azure AD global administrator accounts should be kept to a minimum. Azure AD global administrator accounts will only be available to ITS staff with a primary responsibility for managing Azure AD and approval by the AVC for Infrastructure and Operations or ITS Azure service owner.
AD global administrator accounts are special accounts used for managing the Azure AD tenancies in the Azure cloud and only exist natively in those Azure AD tenancies. As a best practice, the number of Azure AD global administrator accounts should be kept to a minimum. Azure AD global administrator accounts will only be available to ITS staff with a primary responsibility for managing Azure AD and approval by the AVC for Infrastructure and Operations or ITS Azure service owner.
All administrator accounts must correspond to an Onyen and must follow the Passwords, Pass-phrases, and Other Authentication Methods Standard. Azure global administrator accounts never expire. Administrator accounts are subject to a special password policy and regular ITS Audit. Administrator passwords must be 17 characters and expire after 91 days. Use of these accounts must follow the ITS Change Management Policy.
Activity Logs for these accounts will be delivered to the domain administrators Team for reference and audit.
viii. 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 |
| O365 Unified Groups |
.ug |
| Qualys Scanner Account |
.scn |
| VMWare Admin |
.vmadmin |
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.
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 a 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
| Departmental Organization Unit Naming Rules |
|
|
| Field |
Char Name |
Example |
| OU ID |
5 |
ITS |
Example:
ITS and
SON
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 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.
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 published to the SysAdmins team. 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 or configured to use the Always On 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.
a. 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 programatically 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
b. 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 Policy Naming Rules
| Field |
Char Length |
Example |
| Prefix |
2 |
SW |
| Separator |
1 |
|
| OU ID |
Up to 5 |
ITS |
| Vendor |
|
|
| Separator |
Up to 56 |
Symantec |
| Product |
|
| Separator |
Antivirus |
| Version |
10.1.6.6010 |
Example: SW_ITS_Symantec_Antivirus_10.1.6.6010
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.
To promote cleanup, ITS Systems maintains a report of groups that have been empty for 30 consecutive days. Departmental admins should review this report periodically and delete groups if they are no longer needed.
Active Directory Group Cleanup | Splunk 9.1.2 (unc.edu)
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 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 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
Group policies will be deleted after they have been unlinked, empty, or had all settings disabled for 30 consecutive days, as tracked by this Splunk report:
Active Directory Group Policy | Splunk 9.1.2 (unc.edu)
GPOs can be restored upon request indefinitely, given the name of the GPO and the requested date.
The following procedures will be used for making changes to campus-wide security policies. This process relies on departmental participation for vetting new policies. Note: policy changes may follow an abbreviated schedule when designated as time-sensitive by the CISO.
- Approval
Proposed new group policies will be evaluated for approval by the domain administrators with input from the Technical Advisory Committee (TAC) and the SysAdmins team
- Testing
- The new policy will be made available for opt-in testing for at least 2 weeks
- Communication and discussion will be made via the SysAdmins team Active Directory channel
- Departments who participate will provide feedback via the SysAdmins team Active Directory channel and that feedback will be used to adjust the policies as appropriate
- Pilot
- The new policy will be deployed to a pilot group for at least 2 weeks
- This group will consist of all or part of more than one campus departments
- Typically, pilot departments will volunteer, but in the event of insufficient participation, departments will be chosen by the domain administrators
- Departments who participate will provide feedback via the SysAdmins team Active Directory channel and that feedback will be used to adjust the policies as appropriate
- The pilot should include at least 10% of target systems
- General Deployment
- Changes will be planned with the ITS Change Management System
- Detailed information about the new policies will be provided in the SysAdmins team Active Directory channel
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.
By default, all systems in AD are configured to escrow their BitLocker key in Active Directory and Azure Active Directory. An SCCM baseline ensures that systems have escrowed their BitLocker keys.
SCCM is used to monitor systems encryption status. It is important that all BitLocker protected systems be managed by SCCM to ensure reporting is available in the event a system is lost.
An OU administrator can obtain the BitLocker recovery password via AD Users & Computers.
Method 1 – Using password ID
- Open AD Users & Computers
- Right-click ad.unc.edu at the top of the domain and click Find BitLocker recovery password
- Enter the first 8 characters of the password ID and click Search
Method 2 – Using computer object
- Open AD Users & Computers
- Navigate to the computer object for the computer
- Open its Properties
- In the BitLocker Recovery tab, choose the most recent entry
- The recovery password is available in the Details panel
Domain admins have access to additional BitLocker key backups and escrows. If you are unable to locate a BitLocker key, contact the domain admins for assistance.
By default, all systems in AD are configured to use the Local Administrator Password Solution (LAPS). This system automatically changes the local Administrator account password every 30 days and escrows that password securely in Active Directory. LAPS can assist in the following scenarios:
- Obtaining local administrator access when the domain is unavailable.
- Temporarily granting a user local administrator access.
- Granting computer administrators access to a client computer without risking privileged administrator accounts or creating a lateral movement risk.
An OU administrator can obtain this password via AD Users & Computers.
More information is available about LAPS here:
Windows LAPS overview | Microsoft Learn
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.
The domain controllers also serve as DNS servers 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 InfoBlox IPAM. Clients should be configured to point to the campus DNS servers for DNS resolution.
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 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.
ITS Systems can provide restoration of accidentally 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.
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 hosted in two geographically separate, secure datacenters with redundant power sources. Additional domain controllers are hosted in the public cloud.
Active Directory is backed up nightly.
Active Directory is not an approved system to store regulated sensitive data, such as HIPAA, PCI, or FERPA protected data. Most data stored in Active Directory is visible to everyone with an Onyen. Passwords and other sensitive data should not be stored in plain text in any attribute.
Directory information is not synchronized into Active Directory for students who have requested, under FERPA, that their directory information not be disclosed.
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-ADMINISTRATION. 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.
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.
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.
Departmental administrators (OU Admins) should subscribe to the SysAdmins Team in Microsoft Teams which is the primary communication method on matters concerning the AD.UNC.EDU domain service.
The ITS Change Management Process and the Active Directory channel in the SysAdmins Team will be used to communicate information impacting the service level of the AD.UNC.EDU domain and supporting systems.