Services

WHAT IS A SERVICE ACCOUNT AND WHAT CAN IT BE USED FOR?

A Service Account is a non-person account.  A non-person account is an account that is used by a system or application rather than by a person.  The Service Account allows the system for which it was created to authenticate to other Penn State Systems in order to access data, run processes, or perform actions on the other system.  The specific resources that can be accessed and actions that can be performed depends on the permissions that have been granted to the account.

A Service Account is a non-sharable credential.  Even though a Service Account is a non-person account, each Service Account must be associated with one (and only one) person who is responsible for the use and management of the account.  That person (the owner of the account) is not to share the password with anyone else. If you need a shared credential, you should create a collaborative space that others can access with their own Penn State Accounts (e.g. a Microsoft Teams space).

There are two types of Service Accounts, Group Managed Service Accounts (gMSA) and Standard Service Accounts. If you are unsure of which type of Service Account to request, see “Which Kind of Service Account Do I Need?”

HOW DO I REQUEST A SERVICE ACCOUNT?

EAD Service Accounts

• To request a service account specifically for connecting to Penn State’s Enterprise Active Directory, see Request a Service Account (Service ID) for Enterprise Active Directory (EAD)

All Other Service Accounts

• How Do I Request a Service Account?

HOW DO I MANAGE A SERVICE ACCOUNT?

EAD Service Accounts

• Change a known password for an EAD account not managed by CyberArk.
• Reset Forgotten Password for EAD Admin Account NOT Managed By CyberArk.

All Other Service Accounts

• Where Can I Find Information About the Service Accounts I Own?
• Change or Reset the Password on My Service Account / Service ID
• How Do I Change the Owner / Transfer Ownership of a Service Account / Service ID?
• How Do I Add PASS or Web Space to an Existing Service Account / Service ID?
• How Do I Delete an Existing Service Account / Service ID?

DO SERVICE ACCOUNTS OR SERVICE ACCOUNT PASSWORDS EXPIRE?

Service Accounts do not have an expiration date;  therefore they do not expire automatically and do not need to be periodically renewed.

Service Account passwords no longer expire automatically, so there’s no need to change the password except when one of the following events occurs:

• The account has been compromised (the password has been shared with or accessed by an unauthorized user)
• The account is transferred to a different owner

WHO IS THE OWNER OF A SERVICE ACCOUNT AND WHAT ARE THEY RESPONSIBLE FOR?

Who is responsible for the appropriate use of a Service Account?

The owner of the account is responsible for its appropriate use.  The owner must be identified when the Service Account is requested.  The owner is the individual who will configure the application or applications to use the account; that is, the person who needs to know the ID and password for the Service Account. Their responsibilities include:

• Ensuring that there’s a record of the process or application that uses the account
• Ensuring that appropriate security measures are taken to protect the ID and password from compromise
• Requesting that the owner be changed if you are no longer the appropriate person to oversee the account (for example, before you leave Penn State, or when you move to a different department or position)
• Ensuring that the account is used only for appropriate interaction/integration with other systems
• Otherwise complying with Penn State policies (including AD95 and its associated Security Standards).

Who is responsible for configuring a system to use a Service Account?

The unit or department responsible for the application that uses a Service Account is responsible for configuring the application to use it.

• Any questions regarding configuration should be directed to the owners of the services(s) to which the account requires access.
• Responsibility for configuration may be delegated, but accountability for the credential itself may not be.
• If it becomes necessary to delegate some portion of the configuration (for example, to a vendor or another developer), the account owner is responsible for the other party’s use of the account, and for changing the password once the delegated work is complete.