Skip to main content
IT Connect

Information technology tools and resources at the UW

MI inactive account design

Table of contents

Status

This proposal has not yet been accepted. Revision and proposal to the appropriate change advisory boards is needed.

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 Azure AD. Since Azure AD user accounts are provisioned based on NETID AD accounts, removal of an AD account results in removal of the Azure AD 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 Azure AD 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 Azure AD 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, have identified the user account as one which provides a currently active resource but does not logon, e.g. an Exchange resource mailbox

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).

Notable changes from prior proposal (2015)

A prior version of this proposal poorly accounted for application designs which expect all students and employees to have an account. For example, there is a desire to have all employees and students in an Exchange Global Address book. This updated proposal better addresses that issue.

The prior version of this proposal also only allowed the MSCA service to identify “resource” accounts with no active logons which are considered in active use. This updated proposal allows other partners to also contribute to what is considered current.

The prior proposal did not treat the Azure AD user account outcome the same as the NETID AD user account outcome. This proposal has an identical outcome in both systems.

The prior proposal did not consider the potential for undesired impact when implementing this change. This proposal phases in implementation, and provides more transparency on which accounts will be impacted.

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 will be published.
  • Prior to implementation, impacted accounts will additionally be vetted against Exchange support org lists, with notification to appropriate technical contacts where there is overlap.
  • Account deletions will be phased in over a 6 month period, gradually lowering the time criteria for inactivity–see details below.
  • Account disables will be phased in over a 3 month period, gradually lowering the time criteria for inactivity–see details below.
Disable criteria Delete criteria
Implementation begins 4 years inactivity 8 years inactivity
30 days after implementation 3 years inactivity 7 years inactivity
60 days after implementation 2 years inactivity 6 years inactivity
90 days after implementation 1 year inactivity 5 years inactivity
120 days after implementation 1 year inactivity 4 years inactivity
150 days after implementation 1 year inactivity 3 years inactivity
180 days – implementation complete 1 year inactivity 2 years inactivity

6 months 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 currently 126 organizations represented. These OU customers represent almost all business partners for Microsoft Infrastructure. Delegated OU customers can leverage a role group which their _oucontacts role group will be granted member manager permissions on to define resource accounts which MI should consider active. 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 Azure AD). Of those, approximately 200,000 meet our definition of being in current use (this approximation may change considerably after partners define their current resource accounts). The approximately 700,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 AAD 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 Azure AD. 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 AAD 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.

Azure AD users should end up in a state which mirrors the NETID AD user state. So the following should be true:

  • a currently active user will have an enabled NETID AD and Azure AD user account,
  • a user which hasn’t been active for 1 year will have a disabled NETID AD and Azure AD user account
  •  a user which hasn’t been active for 2 years will have neither a NETID AD user account nor an Azure AD user account

Lifecycle Process Changes/Additions

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

NOTE: There are no changes here–this is the current service design and has been for many years, but we’re including the details here to be comprehensive.

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 Azure AD Connect sync, the Azure AD user is also disabled.
  2. Move the associated user object to a different OU structure, which is still processed by Azure AD 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 Azure AD Connect sync, the Azure AD user is also disabled.
  2. Move the associated user object to a different OU structure, which is still processed by Azure AD 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 Azure AD user account will be re-activated after the Azure AD 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 Azure AD user account will be created after the Azure AD 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 Azure AD user account will be restored after the Azure AD 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 AAD logon info can be resolved by data in the AAD Security API or 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.