ADS service policies at IU

On this page:

Note:
For help with Active Directory, contact your local UITS support person.

ADS general operational policies

ADS provides a wide range of authentication services on all Indiana University campuses. Furthermore, Exchange requires that users have an entry in the IU Active Directory tree. UITS restricts departments or individuals from setting up local Active Directory trees outside of the IU ADS domain. In the past, creating additional Active Directory trees has invariably led to naming integrity problems, user confusion and frustration, and unnecessary departmental overhead. The use of organizational units (OUs) within the ADS domain has proven to meet the organizational requirements of IU departments and organizations. UITS creates OUs for all IU departments and organizations that request them.

ADS general service policies

ADS service policies are bound by those at Information and IT policies.

ADS user accounts

Every student, faculty member, and staff member on all eight IU campuses is eligible for an ADS account. UITS creates a unique user account for each user on every IU campus.

To ensure that unique usernames exist for each student, faculty member, and staff member, no user accounts may be created in ADS except those generated by UITS; any ADS user accounts created outside this process may be deleted or disabled without notice. Requests for sponsored and departmental accounts also go through the UITS account generation process. Tier 2 Accounts and Student Information Systems (ASIS) facilitates the creation of all ADS user, resource, and/or service accounts. For requests, contact Tier 2.

ADS contacts

To minimize the conflict with Identity managed contacts and the Cross Domain sync objects in Entra ID, departments are not to create their own Mail Contact objects. If a mail contact is required for an Entra ID managed Distribution Group, invite them as a Guest in a Microsoft Team or Planner, so that a guest account is created; if that is not viable for the account type, contact Tier 2.

If a mail contact is created in Active Directory, outside of the managed space, it may be deleted without warning.

ADS computer accounts

To minimize the number of unused computer objects within the Active Directory:

  • Any computer account inside the Computers container that has remained inactive for more than 90 days will be automatically disabled. A computer account that has been disabled for more than 90 days will be automatically removed.
  • For computer accounts outside the Computers container, UITS will compile a report of all accounts that have remained inactive for more than 90 days. OU administrators may You do not have sufficient permission to view this document. (requires authentication) to get access to the list.
  • For computer accounts outside the Computers container, the domain admins will periodically remove any devices that have not accessed the domain in more than 180 days. These device cleanups will be represented at UITS Change Management, and a list of affected devices will be shared with local UITS support people.

ADS groups

Groups should adhere to the following practices:

  • When using groups to assign permissions, follow the principle of least privilege.
  • Group membership should not contain Domain Users or Domain Computers.
  • Use group nesting where appropriate and supported.
  • Avoid circular nested groups.
  • Follow standard naming convention; see ADS naming convention.

ADS schema extensions

The ADS schema will not be modified unless the proposed extension meets these criteria:

  • Has a demonstrated benefit to the university as a whole
  • Is supportable and scalable for the enterprise
  • Will have a minimal impact on service delivery
  • Has been thoroughly tested in a non-production domain
  • Does not compromise the privacy of personal data
  • Is in harmony with IU's published Appropriate Use policy
  • Uses properly registered Object Identifiers (OIDs) and naming prefixes (for example, "iuEdu-")

Direct requests to extend the ADS schema to ads-admin@iu.edu. Representatives from various UITS divisions will be called upon as required to review ADS schema extension requests.

ADS naming convention

A naming convention for all computers, groups, OUs, grouppolicy objects (GPOs), and Distributed File System (DFS) roots is strictly enforced. This not only simplifies administrative tasks, but also is necessary to maintain a unique namespace in ADS. Before you add a computer, group, OU, or GPO to ADS, see Recommended naming conventions for IU Windows computers and groups.

ADS group policy naming and maintenance

Group policy objects (GPOs) must be named following the same naming conventions as computers, groups, and OUs. Any GPO left with the default GPO name of New Group Policy Object is subject to deletion after a warning has been sent to the GPO's owner.

Any GPO left with the default GPO name of New Group Policy Object is subject to deletion.

ADS departmental/school/campus OU creation

OUs at IU (for example, departments, schools, affiliated agencies) may apply to have an OU container created for managing their resources within ADS. OUs will be placed within the appropriate campus OU, depending on their physical location. Any cross-campus entity that has a presence on multiple campuses may apply for an OU outside of its campus, or on multiple campuses.

The local UITS support person for any given OU should work with the faculty and staff administration, as well as the users, to determine the optimum OU functionality. Local UITS support people should take care in securing, managing, delegating, and creating sub-OUs, GPOs, and other resources, because they will be held responsible for proper functioning of these aspects of their OU.

ADS restoration

ADS resources, structures, and data will not be restored except in the event of catastrophic failure of the directory structure. OUs, computers, GPOs, and other directory constructs should be maintained with great care, and should be carefully documented so that errors or omissions at the OU or sub-OU level can be mitigated and rectified.

ADS EFS recovery

In Windows, users can encrypt their files on local workstations, and decrypt their files with their own decryption keys. UIPO maintains a "master recovery key" so it can address requests to decrypt documents made by users who have forgotten keys. UIPO can help departmental representatives decrypt departmental or user documents only after verifying the representatives' authority, based on the Guidelines for protecting sensitive data.

Send all requests to decrypt files to UIPO at uipo@iu.edu.

ADS BitLocker recovery information

In Windows, users can encrypt hard drives using BitLocker.

System administrators can choose to escrow the BitLocker recovery information to Active Directory, and can also request retrieval of the BitLocker recovery information if necessary; see Escrow BitLocker recovery information in Active Directory at IU.

ADS support model

ADS follows the IU distributed support model for computing services. The local UITS support person may serve as the first level, or may choose to escalate issues to the UITS Support Center. The local UITS support person or Support Center may escalate issues to Tier 2 Support, which may in turn escalate issues to the service owner, Enterprise Microsoft Administration (EMA), in UITS Enterprise Systems for final resolution.

Windows network services

If improperly configured, Windows network services (such as DHCP and DNS) can cause service interruptions for other departments. Operating one of these services without first consulting UITS may result in temporary disconnection from the network.

Windows Active Directory forests and domains

The IU Active Directory is a single-forest, single-domain model that does not trust other Active Directory forests. IU schools, departments, and affiliated units shall not install, upgrade to, or participate in a Windows Active Directory child domain within the ADS forest.

Trusts between ADS and legacy Windows NT domains

Microsoft has discontinued support for Windows NT, and therefore new trusts to NT domains will not be created. Two-way trusts between IU schools, departments, and affiliated units will not be established, and it is against policy for IU units to bring up Active Directory forests.

UIPO and EMA must approve any two-way trusts with non-affiliate partners of IU. If a security compromise occurs because of a two-way trust relationship with a partner, the trust will be immediately terminated. Any terminated two-way trust shall be re-evaluated if the partner chooses to upgrade its NT domain, or at any time UIPO or EMA determines such a re-evaluation is appropriate.

Note:
On a Windows computer that is a member of ADS, the "Authenticated Users" built-in group includes not only accounts from ADS but also user accounts from any domain that holds a two-way trust with ADS. You should therefore use the "Authenticated Users" group with discretion. If you want to limit a resource to only users that are affiliated with IU, the best practice is to use the "Domain Users" built-in group.

Roaming profiles and individual login scripts

Because they are very difficult to support within a large domain (as well as to limit network traffic), roaming profiles, login scripts, and personal virtual desktops assigned to individual users are not supported within the ADS domain. The Windows Active Directory provides other advanced features, such as group policies and folder redirection, to define the user environment.

Trusted for Delegation

Trusting a computer object for delegation is a sensitive security option. Use of this right will be considered on a case-by-case basis. In the rare case where the "Trusted for Delegation" right is necessary, an local UITS support person may submit a request to have this right granted to a server. The request must include the name of the machine, its IP address, and a detailed description of why this right is necessary. Each request will undergo a review process, and must be approved by UIPO and the EMA team.

ADS service level

The ADS architecture was designed to provide continuous service delivery free from interruption or impact from maintenance or hardware failure. In the event of a service interruption or modification, EMA will implement the notification and resolution procedures set forth by UITS Change Management. For more, see UITS Change Management .

Log requests

To request logs or activity reports from this system, contact the Support Center.

If the request for information involves someone other than the requester, or if the log information will be used in support or defense of an investigation, the request must be sent to the University Information Security Office (UISO) via it-incident@iu.edu. UISO staff will then determine the context of the request, as well as the authorization required; for more, see Privacy of Electronic Information and Information Technology Resources (IT-07).

This is document aqeh in the Knowledge Base.
Last modified on 2024-04-15 17:56:59.