20170901: MI inactive account proposal

Table of contents

• Status
• Summary
• Phased Implementation
• Partner mechanism to designate active resource accounts
• Business reasons for design change
• Assumptions
• Discussion
• Lifecycle Process Changes/Additions
  • Account with no UW NetID password or that loses the UW NetID password
  • Account unused for 1 year
  • Account disabled for 1 year
  • Reactivation
• Identified Problems

Status

This proposal has been accepted and is expected to be implemented in early 2019.

This change has been discussed with the Microsoft Technology community on 10/18/2017. Suggestions from that community were incorporated.

Summary

The Microsoft Infrastructure (MI) service will be adding disable and deletion events to the lifecycle process it uses to manage user accounts in the NETID Active Directory (AD) and the UW Entra ID . Since Entra ID user accounts are provisioned based on NETID AD accounts, removal of an AD account results in removal of the Entra ID account.

Note: After this point in this document, unless we specify otherwise, when we say “account” we mean both the NETID AD user account and the Entra ID user account. The scope of this change does not affect the underlying UW NetID.

This change will affect approximately 80% of all accounts in existence in September 2017, i.e. ~700,000 user accounts are expected to be affected.

Current account lifecycle behavior is:

• UW NetIDs without a password and those that lose the password service are disabled and otherwise treated as unused (in place already–this is current design)
• UW NetIDs which get a new password result in a re-enabled user account

We are adding two new behaviors:

1. User accounts that are not considered currently in use will be disabled
2. User accounts that have been disabled for a year will be deleted

Indicators that qualify a user account to be considered in current use are:

• UW NetID password has changed in last year
• NETID AD or Entra ID have recorded a logon in last year
• UW NetID has a current employee or student affiliation (more specifically: UW eduPerson affiliation=member)
• A business partner, such as the MSCA service or a delegated OU, have identified the user account as one which provides a currently active resource but does not logon, e.g. an Exchange resource mailbox
  • Each delegated OU will have a group _accountsthatdonotlogon to specify accounts they believe do not logon and should be considered active
  • MSCA has identified all accounts eligible for Office 365 services as active

Temporarily unused accounts can easily return to service without significant impact–the primary way for this to happen is to set the UW NetID password (see Reactivation). Longer absences of use will result in a new user account with the same UW NetID, which may mean the user will need to re-establish access to resources for which that account had previously been granted explicit access (rather than via a group membership).

Phased Implementation

The implementation needs to balance undesired impact with reaching the desired design to address the business reasons for the change. For this reason, implementation will have the following qualities:

• Prior to implementation, impacted accounts can be identified via a web application.
• Account deletions will happen as proposed, i.e. after a year in the disabled state
• Account disables will be phased in, gradually lowering the time criteria for inactivity–see details below.

After the implementation, this process will regularly run automatically.

Partner mechanism to designate active resource accounts

As noted above, one criteria which will ensure a given user account is considered active is an assertion by a business partner, such as the MSCA service. This is intended to identify user account which by design do not logon but which are actively used, where the most common scenario is a resource that requires a user account, e.g. an Exchange resource mailbox.

Microsoft Infrastructure has a well-defined mechanism to become a delegated OU customer; there are ~150 organizations represented. These OU customers represent almost all business partners for Microsoft Infrastructure. Delegated OU customers can leverage a role group _accountthatdonotlogon which their _oucontacts role group will be granted member manager permissions on to define resource accounts which MI should consider active. More details about this new role group will be provided with the customer communication package.

Business partners which do not currently have a delegated OU can get a delegated OU, even if they have no intention of otherwise using it. This is already true for other features MI provides, such as our DFS offering.

Business reasons for design change

As of September 2017, there are approximately 900,000 user accounts (in the NETID Active Directory and Entra ID). Of those, approximately 300,000 meet our definition of being in current use (this approximation may change considerably after partners define their current resource accounts). The approximately 600,000 accounts that are not in use present several operational challenges and institutional risks including:

1. Unused accounts represent a higher potential for account compromise. In some cases, this risk is compounded by the lack of mitigating controls over these inactive accounts, despite a general assumption by many that there are such controls.
2. The total number of user accounts in our AD and Entra ID results in higher operational costs due to factors such as complicated identity collisions, latency, hardware requirements, processing changes across such a large set of users, and other similar activities.
3. Keeping these unused accounts means we are significantly less agile for application integrations. This has been true for traditional LDAP-based application integrations for years, but is particularly significant for integrations involving Entra ID. Microsoft has focused all its identity integration investments there, and some 3rd party technologies which work fine in other enterprises won’t work here when confronted with the larger scale of users. Limiting the number of users improves potential issues, more easily allowing partners to adopt these new technologies.
4. With Microsoft’s changing business model, there’s an increasing number of products and services that require we license all user accounts, resulting in either higher licensing costs due to inactive accounts or an outcome where we can’t adopt or enable that product or service.

Assumptions

• The criteria and processes we’ve set will correctly identify active accounts and inactive accounts.
• Business partners such as the MSCA service will provide a group of accounts which they consider to be in active use. Those business partners will provide their own lifecycle management review of the members of that group, and assume responsibility for keeping it current.
• A 1 year period of inactivity is an acceptable period before making the account inactive and purging the Entra ID user account.
• A 2 year total period for inactivity is an acceptable period of time before any given NETID user is purged.
• We can not wait for an acceptable solution from the systems of record, as the scope and impact continue to increase; a broader solution is outside our scope of control. It’s worth noting that since the time we first proposed this design change in November 2015, the number of unused accounts has grown by 120,000.
• This change may help form a path for a broader solution from the systems of record.

Discussion

A UW NetID represents quite a few things to the account holder and their relationship to the UW, beyond just a basic identity and authentication capability. As that relationship changes, such as when an employee leaves or a student graduates, their UW NetID remains functionally active.

In the current NETID AD account lifecycle process, we provision a user account for every UW NetID with a password, and only delete or disable that account if the associated UW NetID is first deleted or disabled.  Over time, this means that the total number of UW NetIDs, and in turn NETID AD accounts, only increases–at a rate of about 60K/year.

The general customer assumption is that NETID user accounts are generally held only by current faculty, staff, and students. And many customers also incorrectly assume, for faculty and staff, that the NETID account is disabled or deleted upon termination or separation. However, only 10-15% of all UW NetIDs with a password are current faculty, staff or students. In some cases, these incorrect assumptions results in a person’s access to data, systems, and applications continuing past termination or separation–which could result in a security incident or data breach. There can also be poor outcomes based on default access to some resources which allow all NETID user accounts. While we have documented these issues and provided guidance on alternatives, relying on only those administrative controls is insufficient, particularly when technical controls are possible, would be more effective, and there are other reasons to put them in place. It is worth noting, however, that the Microsoft Infrastructure service cannot provide a pure technical control, as we don’t manage all of the services, systems, and applications that rely on the NETID AD.

A broader enterprise solution to the problem in this area would be preferred, however there is no indication that the systems of record have capacity or see this as a priority. Addressing this issue in the MI Service can be done more rapidly, at a relatively low cost, and without impact to the UW NetID service.

Functionally, the solution space is very small; an AD account either exists or doesn’t, and if it does, it is either enabled or disabled. We’ve decided to use a two stage approach, where accounts identified as unused for a year will be disabled, and those that have been disabled and have been unused for two years will be purged. Given the functional solution space, there aren’t other viable alternatives of significance.

For timeframes, we chose one and two years, seeking to minimize the risk of impacting an infrequently used account or a user on a longer absence, and the operational burden of implementing this process change. The possibility of tying this process to other lifecycle processes for either UW NetID or other IT services are possible future enhancements.

Exchange and Sharepoint are examples of services which have a set of “resource” accounts that do not logon regularly, but are in active use by other users. These “resource” accounts do not logon as themselves but access controls permit access to data owned by that account. We might be able to disable these accounts without impact, but deletion would result in an undesired outcome–loss of data or functionality considered critical to business processes. Allowing partners, who are best able to determine the currency status of these accounts, to explicitly identify them as active/current addresses this issue.

Proposed Lifecycle Process

Account with no UW NetID password or that loses the UW NetID password

For accounts with no UW NetID password, we will:

1. Disable the account (“enabled” attribute set to false). This means the AD user is disabled, and after Entra ID Connect sync, the Entra ID user is also disabled.
2. Move the associated user object to a different OU structure, which is still processed by Entra ID Connect and other identity data processes
3. Set the password to a random, 128 character value using a complex character set
4. Add the account to a group which globally has the ‘Deny access to this computer from the network’ user right.

Note: Logon token lifetimes mean that current sessions will persist beyond account disable. We do not plan to make any attempt to revoke existing logon tokens or sessions–those tokens will expire naturally. We believe this is the correct action to take because there is no indicated urgency to revoke those tokens. There are several supported scenarios at the UW where we do revoke existing logon tokens or sessions.

Account unused for 1 year

For accounts that have been unused for a year, we will:

1. Disable the account (“enabled” attribute set to false). This means the AD user is disabled, and after Entra ID Connect sync, the Entra ID user is also disabled.
2. Move the associated user object to a different OU structure, which is still processed by Entra ID Connect and other identity data processes
3. Set the password to a random, 128 character value using a complex character set
4. Add the account to a group which globally has the ‘Deny access to this computer from the network’ user right.

Note: Logon token lifetimes mean that current sessions will persist beyond account disable. We do not plan to make any attempt to revoke existing logon tokens or sessions–those tokens will expire naturally. We believe this is the correct action to take because there is no indicated urgency to revoke those tokens. There are other support processes available to urgently revoke existing logon tokens or sessions.

Account disabled for 1 year

Accounts that have been disabled for 1 year will be deleted.

Note: A new account with the same name can be created after deletion (see Reactivation).

Reactivation

There are two actions customers can take to reactivate an account:

1. Reset the UW NetID password. For an account that has been disabled, but not yet deleted, this action will immediately re-activate the NETID AD user account and return it to a usable state. The Entra ID user account will be re-activated after the Entra ID Connect sync process runs, which generally takes about an hour. For an account that has been deleted, this action will result in a new NETID AD user account creation, with no association to the previous NETID AD user account.  A new Entra ID user account will be created after the Entra ID Connect sync process runs, which generally takes about an hour.
2. Request recovery via AD recycle bin. For an account that has been disabled, this is not a valid option. For an account that has been deleted, we have the option of leveraging the AD recycle bin for a period of 180 days to manually recover a NETID AD user account. Using the AD recycle bin option requires manual intervention, initiated by an explicit request with a valid business reason to do so. This option requires that reactivation option #1 has not been exercised–if it has, we are unable to use this option. Once the NETID AD user account is restored, the Entra ID user account will be restored after the Entra ID Connect sync process runs, which generally takes about an hour. Whether associated resources such as an Exchange mailbox are also restored are outside our control and depend on configuration of other systems.

Identified Problems

Previously identified problems with Entra ID logon info were resolved via data in the Entra ID Security API and ADFS logging.

If additional problems are identified, there is a risk/cost analysis needed about how to deal with those problems. This design change addresses some significant risks/costs. Delaying or preventing this change may be a bigger risk/cost than the cost that some users will accidentally be disabled, with incidental support costs of manually re-enabling them.