ADS service policies at IU
On this page:
- ADS general operational policies
- ADS general service policies
- ADS user accounts
- ADS contacts
- ADS computer accounts
- ADS groups
- ADS schema extensions
- ADS naming convention
- ADS group policy naming and maintenance
- ADS departmental/school/campus OU creation
- ADS restoration
- ADS EFS recovery
- ADS BitLocker recovery information
- ADS support model
- Windows network services
- Windows Active Directory forests and domains
- Trusts between ADS and legacy Windows NT domains
- Roaming profiles and individual login scripts
- Trusted for Delegation
- ADS service level
- Log requests
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 IT Pros.
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
orDomain 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 IT Pro for any given OU should work with the faculty and staff administration, as well as the users, to determine the optimum OU functionality. IT Pros 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 IT Pro may serve as the first level, or may choose to escalate issues to the UITS Support Center. The IT Pro 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.
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 IT Pro 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).
Related documents
This is document aqeh in the Knowledge Base.
Last modified on 2023-11-10 16:37:20.