What are the ADS service policies at IU?
On this page:
- ADS general operational policies
- ADS general service policies
- ADS user accounts
- ADS computer accounts
- ADS schema extensions
- ADS naming convention
- ADS group policy naming and maintenance
- ADS departmental/school/campus OU creation
- ADS restoration
- ADS EFS recovery
- ADS support model
- Windows 2003/2000 network services
- Windows 2003/2000 forests and domains
- Trusts between ADS and legacy Windows NT domains
- Roaming profiles and individual logon scripts
- Trusted for Delegation
- ADS service level
ADS general operational policies
ADS provides a wide range of authentication services on all Indiana University campuses except IPFW. 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 the policies set forth on the University Information Policy Office (UIPO) page at:
http://informationpolicy.iu.edu/policies/ADS user accounts
Every student, faculty member, and staff member on all eight IU campuses is eligible for an ADS account. UIPO creates user accounts that are unique for each of the 130,000 users across all eight campuses. Users who have IUPUI or IU Bloomington domain accounts have ADS accounts generated for them automatically, and the passphrases are synchronized with their Network ID passphrases.
To ensure that unique usernames exist for each student, faculty
member, and staff member, no user accounts may be created in ADS
except for those generated by UIPO. 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 UIPO account generation process. UIPO staff will handle
the creation of all ADS user, resource, and/or service accounts.
Direct requests to
valid@indiana.edu or
actadmin@iupui.edu , or submit them
online at:
ADS computer accounts
To minimize the number of unused computer objects within the Active Directory, the following will occur:
- Any computer account inside the
Computerscontainer 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
Computerscontainer, UITS will compile a report of all accounts that have remained inactive for more than 90 days. OU administrators may contact LSP Services to get access to the list.
ADS schema extensions
The ADS schema will not be modified unless the proposed extension meets these criteria:
- It has a demonstrated benefit to the university as a whole.
- It is supportable and scalable for the enterprise.
- It will have a minimal impact on service delivery.
- It has been thoroughly tested in a non-production domain.
- It does not compromise the privacy of personal data.
- It is in harmony with IU's published Appropriate Use policy.
- It uses properly registered Object Identifiers (OIDs) and naming prefixes (e.g., "iuEdu-").
Requests to extend the ADS schema should be made via email 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, group policy objects (GPOs) and Distributed File System (DFS) roots is strictly enforced. This is necessary to maintain a unique namespace in ADS, since WINS legacy support requires a flat namespace for interoperability across all eight campuses. In addition, a naming convention simplifies administrative tasks. Before you add a computer, group, OU, or GPO to ADS, please review At IU, what naming conventions does UITS recommend for 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.
Unused and unlinked GPOs must be removed from the system. LSPs who want to keep an unlinked GPO for historical reference should export the GPO to a file and then delete it from ADS. Any policy left unlinked is subject to deletion after a warning has been sent to the GPO's owner.
ADS departmental/school/campus OU creation
OUs at IU (e.g., 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 support provider (LSP) for any given OU should work with the faculty and staff administration, and the users, to determine the optimum OU functionality. LSPs 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 2000, XP, 2003, and Vista, 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. Also, UIPO can help departmental representatives decrypt departmental or user documents only after verifying their authority, based on the Guidelines for Handling Electronic Institutional and Personal Information, available at
http://informationpolicy.iu.edu/resources/safedata/guidelines.shtmlSend all requests to decrypt files to UIPO at
uipo@iu.edu .
ADS support model
ADS follows the IU distributed support model for computing services. The LSP may serve as the first level, or may choose to escalate issues to the UITS Support Center. The LSP or Support Center may escalate issues to LSP Services, which may in turn escalate issues to the service owner (UITS Messaging Systems) for final resolution.
Windows 2000/2003 network services
Windows 2000 and Windows 2003 network services, such as DHCP, DNS, and WINS, that are improperly configured 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 2000/2003 forests and domains
The IU Active Directory is a single-forest, single-domain model that does not trust other Windows 2000 or Windows 2003 forests. IU schools, departments, and affiliated units shall not install, upgrade to, or participate in a Windows 2000 or 2003 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. It is against policy for IU units to bring up Active Directory forests.
UIPO and Messaging Systems 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 as determined by UIPO or Messaging Systems.
Note: On a Windows 2000, XP, 2003, or Vista computer that is a member of ADS, the "Authenticated Users" built-in group includes accounts from ADS, plus user accounts from any domain that holds a two-way trust with ADS. Therefore, you should 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 (and to limit network traffic), roaming profiles and login scripts assigned to individual users are not supported within the ADS domain. The Windows 2003 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 LSP 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 the UITS Messaging Systems team and UIPO.
ADS service level
The ADS architecture was designed to provide continuous service delivery free from interruption or impact by maintenance or hardware failure. In the event of a service interruption or modification, Messaging Systems will implement the notification and resolution procedures set forth by UITS Change Management. For more information, see Change Management's Guidelines, Procedures, and General Information page at:
http://www.indiana.edu/~change/Last modified on October 13, 2009.







