/
Service Account Standard

Service Account Standard

Scope

This standard applies to all service accounts provisioned within the university’s central identity authorities.  It governs the creation, use, management, and deprovisioning of service accounts used by software components—such as applications, scripts, containers, and automated services—to access university systems and data.

This standard applies to:

  • University-managed on-premises and cloud-hosted systems

  • Research computing environments and high-performance computing clusters

  • Enterprise applications and integrations

  • IT infrastructure components requiring automated authentication

  • Third-party vendor systems that require service account access under a formal agreement

This standard does not apply to:

  • Standard user accounts for faculty, staff, students, or guests

  • Privileged user accounts (e.g., administrative or break-glass accounts)

  • Generic email mailboxes unless explicitly tied to a service account

Definitions

Central Identity Authority

A trusted system that manages and verifies digital identities, centralizing authentication, authorization, which includes Microsoft Entra ID, Microsoft Active Directory, Kerberos, and 389/LDAP. 

Owner\Manager\Sponsor

A full-time university-affiliated faculty or staff member in a paid role responsible for overseeing, managing, and complying with a privileged account's lifecycle. This person is the primary point of contact for IT and security teams regarding the account’s usage, configuration, access controls, life cycle, and associated risk management. Unique individuals are not required to fill these roles; multiple users may hold the same role if appropriate.

Service Accounts

A non-human identity used by software components to authenticate, execute processes, and interact securely with other systems . 

Software Components

Applications, services, scripts, containers, or integrations between applications, services, scripts, and containers.

Standards and Procedures

Eligibility & Sponsorship

Eligibility:

  • IT service owners or system administrators managing software components or their related infrastructure.

  • Research computing teams deploying automated workflows, pipelines, or data integrations.

  • University-affiliated faculty or staff in a paid role responsible for managing software components requiring automated university system access.

Access Control

Access should be restricted solely to the systems and software components essential for the service account’s intended function

Password Requirements

Password Length and Lifecycle Hygiene 

  • Service accounts must have passwords which:

    • Meet the University password complexity requirements

    • Are at least 32 characters in length, randomly generated, and are managed using secure credential rotation services (e.g. Azure Key Vault).

    • Be stored only in ITS-approved password management software.

  • Passwords must be rotated at least once every 36 months, or sooner if a security risk arises, including but not limited to:

    • Suspected or confirmed password compromise

    • Departure of personnel who had access to the password

    • Security audit findings requiring remediation

  • Password rotations must be documented, including the reason for rotation and date of change.

Naming Convention and Required Attributes

The “NetID” (represented as uid in 389 Directory/LDAP and sAMAccountName and CN in Active Directory) should be a derivative of the application name it supports.

To clearly distinguish it as a service account, all new NetIDs must be prefixed with s_. Previously created service accounts must have the account type set to service.

Email Access and Generic Mailboxes for Service Accounts

  • Service accounts are not provisioned with email mailboxes by default. If an application requires the ability to send or receive email, a separate Generic Mailbox must be requested and provisioned as a distinct service offering.

  • For application-based generic mailboxes, the employeeType attribute must be set to service to clearly distinguish them from user-based mailboxes and support accurate identity classification and lifecycle management.

Provisioning / De-Provisioning

Provisioning:

  • Must minimally meet the requirements of the Generic Account Standard.

  • Service accounts will have an expiration date no more than two (2) years from the date of creation or last renewal.

  • Service accounts should be provisioned according to the principle of least privilege

  • Service accounts shall be provisioned only in the central identity authorities required for access

  • Service accounts shall be provisioned using the authentication mechanism providing the highest level of integrity practicable, eg. Certificate authentication over password authentication

  • AD service accounts that only need to be logged into specific workstations shall have the LogonWorkstations attribute set to the workstation(s) for which they are permitted

  • By default, AD service accounts shall NOT be permitted to log on to Microsoft Entra ID/Microsoft 365.  If such access is required, it must be explicitly requested.

  • By default, 389/LDAP service accounts shall NOT be permitted to directly log onto UNIX-based systems (thus, they should be considered “LDAP-only”).  If shell/full UNIX account access is required, it must be explicitly requested.

  • Service accounts and which services/service offerings they are used for should be recorded in a central repository.

Deprovisioning:

  • Must minimally meet the requirements of the Generic Account Standard.

  • Service accounts must be recertified annually to ensure continued necessity, appropriate use, and compliance with security policies. If the Account Manager/Owner does not respond to renewal requests within the specified timeframe, the accounts will be disabled.

  • Expiration dates for each service account will be extended by no more than two (2) years from the date of the last review.

Account Review

Must minimally meet the requirements of the Generic Account Standard.

Logging and Auditing

Must minimally meet the requirements of the Generic Account Standard.

Exceptions

Must minimally meet the requirements of the Generic Account Standard.

Exceptions must be approved by ITS and reviewed annually.

Incident Response

Must minimally meet the requirements of the Generic Account Standard.