Skip to end of metadata
Go to start of metadata

Status

This proposal is being drafted dead. gMSAs will be released as a UWWI only capability.

Track progress via these items:

Version History

This is the first version.

Background

The UW NetID system provides identifiers for accounts at the UW. Use of the UW NetID system is greatly beneficial, ensuring support for many other valuable services, including the Access Management Service, Directory Service, and others.

Active Directory introduced a new kind of security principal with Windows Server 2008. This was called the managed service account. This was not appealing because it was limited to use on a single computer. With Windows Server 2008 R2, Microsoft extended this capability so it could be used across multiple domain joined computers. This extended security principal was called the group managed service account (gMSA). Features of a gMSA include:

  • Is a security principal capable of authentication
  • Existing password is not known by any human
  • Password is updated automatically every 30 days, just as domain joined computer passwords are updated
  • Password is complex, with a length that is difficult to attain when humans are involved
  • Domain joined computers must be registered as associated with the gMSA in order to get a copy of its current password hash, to support authentication use by services on those computers

For the identity needs of an application/service, use of a gMSA over something like a Shared UW NetID or Application UW NetID greatly improves the security exposure, addressing these common issues:

  • No need to change application passwords due to IT staff turnover
  • No need to store application passwords
  • Application passwords are regularly changed, improving the overall password entropy thereby reducing risk of brute-force guessing
  • Application passwords are complex, also greatly improving the password entropy thereby reducing risk of brute-force guessing

Goal Statement

There is a request fulfillment process for Active Directory gMSAs (msDS-GroupManagedServiceAccount objects) in the NETID Domain Service which results in a corresponding UW NetID whose password can not be set/changed via the UW NetID service.

The NETID Domain Service and UW NetID service provide operational support for gMSAs over their lifecycle.

Assumptions

UW NetID integration for gMSAs is highly desired. This is because:

  • It's a requirement for Groups Service capabilities.
  • gMSAs share the same namespace as UW NetIDs do within the NETID Domain Service.
  • The UW NetID service provides highly useful metadata and lifecycle mechanisms.
  • As a part of the UW IdM system, it would be good for gMSAs to conform to the same identity vetting and credentialing process in the UW NetID service.

There is a way to prevent a UW NetID password set/change for a given UW NetID.

A UW NetID corresponding to a gMSA will only ever authenticate against the NETID Domain Services (UWWI).

Limiting where a gMSA can authenticate, while possible via Authentication Silos, is out of the scope of this proposal. However, some awareness to the possibility of later adding that capability is welcome.

Challenges

There are several challenges. At a high-level:

  1. Determine how to prevent passwords on UW NetIDs associated with gMSAs
  2. Determine how to model gMSAs within the UW NetID service and Person Registry
  3. Define the request fulfillment process
  4. Provision gMSAs in the NETID Domain Service

The design options below will focus on these challenges, with options specific to challenge 1, labeled 1-1, 1-2, and so on.

Design Options

Option 1-1: Explicit Deny on Kerberos Subscription

Description:

  • UW NetID is given an explicit deny on the Kerberos subscription. This will block implicit or explicit permits, thus preventing password assignment.

Downsides:

  • Requires an additional step for each gMSA request fulfillment.

Benefits:

  • None

Outlook: Good.

Option 1-2 Implicit Deny on Kerberos Subscription via Category

Description: 

  • UW NetID is assigned a category which has an implicit deny for the Kerberos subscription. This will block implicit or explicit permits, thus preventing password assignment.

Downsides:

  • May require a new category

Benefits:

  • One less step required for gMSA request fulfillment.

Outlook: Great

Option 

Description:

Downsides:

Benefits:

Outlook: 

Option 

Description:

Downsides:

Benefits:

Outlook: 


Option 

Description:

Downsides:

Benefits:

Outlook: 


Option 

Description:

Downsides:

Benefits:

Outlook: 



---


Open Issues

k

Recommendation

k