AD Service Level Agreement

Sample CITES Service Level Agreement

This is an example of UIUC AD service level agreement (SLA). It provides a general description of the intent of the SLA and defines the customers, users, approval and review process, and the terms used in the document.

1.0 Statement of Intent

2.0 About the Service

3.0 About Service Availability

4.0 About Service Measures

1.0 Statement of Intent

This service level agreement (SLA) documents the characteristics of an Information Service that is required by a business function as they are mutually understood and agreed to by representatives of the customer groups. The purpose of the SLA is to ensure that the proper elements and commitment are in place to provide optimal data processing services for the business function. The customer groups use this SLA to facilitate their planning process. This agreement is not meant to override current procedures, but to complement them. Service levels specified within this definition/agreement are communicated on a monthly basis to the customer group representatives.

1.1 Approvals

Table A.1 shows which business groups and IS groups share ownership of the service, and the representatives that have reviewed and approved this SLA.

Table A.1 Organization Representation

1.2 Review Dates

Last Review: DATE

Next Review: scheduled date for next SLA review

1.3 Time and Percent Conventions

This SLA uses the following conventions to refer to times and percents:

• Times expressed in the format "hours:minutes" reflect a 24-hour clock in the central standard time zone.
• Times expressed as a number of "business hours" include from the hours from 8:30 to 17:00.
• Times expressed as a number of "business days" include business hours, Monday through Friday, excluding designated holidays.

The symbol "---" indicates that no time applies in a category (for example, no outages are scheduled for a day).

top of page

2.0 About the Service

This section provides a description of the service and the user community, including their physical location.

2.1 Description

The UIUC Campus Active Directory Project Team provides the following service:

• Ensures that the UIUC Active Directory is available for users to log in and to authenticate users.
• Responds to and resolves user questions about, problems with, and requests for enhancements to the UIUC Active Directory.

CITES will offer Active Directory services to University departments. Subscribers will be given full administrative control of at least one Organizational Unit (OU) in the Active Directory forest. This service will enable subscribers to create directory objects within their OUs and to use the Active Directory services in order to manage and share computer resources with other departments at the University of Illinois.

CITES provides a high-availability environment for its servers, with backup UPS, RAID storage, climate control, and multiple locations. This environment is monitored 24 hours a day, ensuring that domain controllers in the UIUC Active Directory are always available. CITES also provides a physically secure environment for domain controllers.

CITES handles mappings between uiuc.edu Kerberos V5 realm account information i.e., NetIDs and UIUC Active Directory accounts, with automated, nightly updates. This will allow single sign-on, letting users access Active Directory resources from Windows 2000 client machines using their uiuc.edu realm credentials. Accounts are updated nightly so that all University faculty, staff, and students will have Active Directory accounts synchronized with the PH database so that there is no account creation overhead for system administrators. The Active Directory accounts can be immediately used by people for authentication and potential access to Windows NT and Active Directory resources. People can reset, unlock, and/or change passwords themselves for their Active Directory accounts via Bluestem at http://accounts.ad.uiuc.edu.

Campus user accounts are automatically created from UIUC NetIDs. Attribute values of user accounts are not editable. Users may reset, unlock, and change passwords on their own Active Directory accounts through a secure, Bluestem interface at http://accounts.ad.uiuc.edu. Campus user account names are identical to the associated UIUC NetID, so will not exceed 8 characters in length. OU administrators may create user accounts in their OUs for specific purposes (such as service accounts). Names of user accounts created within departmental OUs must exceed 8 characters in length to help guarantee uniqueness from potential UIUC NetIDs. These user account names should be prefixed with the department or unit name e.g., hpds-username. CITES may delete or rename accounts that are less than nine characters in length at any time without notice.

In order to ensure uniqueness for WINS, OU administrators should include the unit portion of the UIUC DNS name in the first 15 bytes of the computer name. If this suggestion is not followed, CITES will not intervene in NetBIOS naming disputes. It is also recommended that the same name be used for both the computer DNS hostname and the NetBIOS name. As an example, if the current DNS name is moe.hpds.uiuc.edu, then the NetBIOS name would be HPDS-MOE and the Active Directory DNS name would be hpds-moe.ad.uiuc.edu.

Each administrator requesting an OU in ad.uiuc.edu may also request an OU in a test Active Directory domain. The OU in the test domain will be used for testing any scripts that automate creation of objects before they are run in the production OU.

Notes:

Campus Active Directory Lockout Policies:

Users can be locked out from using the campus Active Directory because of incorrect login attempts (using an incorrect logon/password). 6 incorrect logon attempts in a 30-minute period will lock out a user for 60 minutes. A user who is locked out will not be able to log in to the campus Active Directory. Accounts are automatically unlocked after the 60-minute wait. Users can manually unlock their accounts by going to http://accounts.ad.uiuc.edu. Users must know their NetIDs and NetID passwords to manually unlock their campus Active Directory accounts.

2.2 User Environment

The business function is conducted in the following data processing environment as shown in Table A.2.

Table A.2 Service User Community Characteristics

2.3 User Support Services

Table A.2.1 Support Services for the User Community

top of page

3.0 About Service Availability

This section provides information about the normal schedule of times when the service is available. It also describes the process for enhancing or changing the service.

3.1 Normal Service Availability Schedule

Table A.3 shows the times the service is available for customer use.

Table A.3 Service Availability

**Adjusted when necessary for scheduled outages and non-emergency enhancements.

3.2 Scheduled Events That Impact Service Availability

Regularly scheduled events can cause a service outage or have an impact on performance (such as slow response time). Table A.4 shows when these are scheduled to occur.

Table A.4 Scheduled Maintenance for the Weekly Server Reboot

3.3 Non-Emergency Enhancements

All changes that take more than four hours to implement or that impact user workflow are reviewed by the UIUC Campus Active Directory Project Team for approval and prioritization.

Enhancements and changes that do not require a service outage and that do not impact user workflow are implemented upon completion.

Enhancements and changes that require a service outage are scheduled outside business hours. Users are notified at least two business days in advance when a non-emergency service outage is required to implement an enhancement or change.

To request an enhancement, submit a problem by contacting the Active Directory Support Team.

3.4 Change Process

Changes to any hardware or software affecting the application should be requested by contacting the Active Directory Support Team.

3.5 Requests for New Users

To request an OU, requires notifying the Active Directory Support Team. Requests are usually satisfied within 2 business days.

top of page

4.0 About Service Measures

The UIUC Campus Active Directory Project Team monitors and reports the service quality. Table A.5 shows the service measures that are reported along with the performance targets.

Table A.5 Service Quality Measurement

The Help Desk prioritizes requests for support according to the following priority-level guidelines:

1-High Priority

The UIUC Active Directory is not operational for multiple users during scheduled availability. A major function of the UIUC Active Directory is not operational for multiple users during the hours which the service is scheduled for availability to users.

2-Normal Priority

A minor function of the UIUC Active Directory is not operational for one or more users (who can continue to use other application functions). A user has questions about the UIUC Active Directory functionality or needs assistance in using the service. A user needs administrative assistance.

3-Low Priority

The UIUC Active Directory is not operational for one or more users outside the hours during which the service is scheduled for availability to users. A major function of UIUC Active Directory is reported as non-operational during the time period for which normal service is not available. Enhancement requests are logged as Priority 3-Low Priority, but are reviewed and scheduled by the UIUC Active Directory Advisory Board.

4.1 Service Dependencies

There are two Active Directory domain controllers deployed on the UIUC campus. These two domain controllers provide the Active Directory authentication. The UIUC campus Active directory service is dependant on one controller functioning properly. One of the Active Directory domain controllers is located at the CITES machine room. The other one is located at the Division of Intercollegiate Athletics in the Bielfeldt building.

This service depends on other services offered by CITES or by other service providers. These services are listed below along with the service provider and where available the service level definition/agreement between internal CITES services or external vendors.

Table A.5.1 Service Dependencies

top of page