What are the ADS service policies at IU?

Username:
Password:

On this page:

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://protect.iu.edu/cybersecurity/policies

ADS user accounts

Every student, faculty member, and staff member on all eight IU campuses is eligible for an ADS account. UITS creates user accounts that are unique for each of the 130,000 users across all eight campuses.

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 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. The Accounts Administration team facilitates 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:

https://itaccounts.iu.edu/

ADS computer accounts

To minimize the number of unused computer objects within the Active Directory, the following will occur:

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 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://protect.iu.edu/cybersecurity/data/guidelines.shtml

Send 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 IT Professional Services and Support, 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/

This is document aqeh in domain all.
Last modified on May 13, 2011.