IT Connect

Information technology tools and resources at the UW

MI inactive account design

Summary

The MI Service will be adding disable and purge events to the lifecycle process it uses to manage user accounts in the NETID Active Directory, affecting approximately 640,000 of the 780,000 NETID user accounts in existence in November 2015. User lifecycle behavior will be:

  • UW NetIDs without a password and those that lose the password service will be disabled immediately and otherwise treated as unused (in place already),
  • NETID AD accounts that have not been used in a year will be disabled, which will also purge the AAD user account, (new behavior)
  • NETID AD accounts that have been disabled for a year will be purged. (new behavior)

The initial run of this process will delete all accounts that have been unused for two years, and disable all accounts that have been unused for more than one year but less than two.  Subsequently, this process will run automatically on a regular basis.

This purges unused accounts while allowing temporary absences to easily return. Longer absences 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 that they previously had explicit access to (rather than via a group membership).

Some NETID AD and AAD accounts will not be deleted due to inactivity, when the MSCA service has identified a valid business reason to retain the user account.

Note: As of 11/2016, the total AD user count is now 843K, while the active user account estimate remains steady. In other words, this problem continues to grow at a rapid rate.

Business reasons for design change

As of November 2015, there are approximately 780,000 user accounts in the NETID Active Directory.  Of those, approximately 120,000 appear to be actively in use. The approximately 640,000 accounts that are not in use present several operational challenges and institutional risks that must be addressed, including:

  1. Unused accounts represent a higher potential for account compromise.  This risk is compounded by the lack of enterprise 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 results in higher operational costs, due to factors such as complicated identity collisions, latency, hardware requirements, etc.
  3. With Microsoft’s changing business model, there’s an increasing number of products and services that require we license all user accounts, resulting in higher licensing costs due to inactive accounts.

Assumptions

  • The criteria we’ve set will identify inactive accounts.
  • A 1 year period of inactivity is an acceptable period before making the NETID user 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 no longer wait for an acceptable solution from the systems of record, as the scope and impact continue to increase and have reached unacceptable levels; a broader solution is outside our scope of control.
  • The inherent capabilities within AD and AAD are sufficient to identify unused accounts based on the criteria we’ve set.
  • The MSCA service will provide a group of NETID AD accounts which should not be deleted. The MSCA service will provide their own lifecycle management review of the members of this group, and assumes responsibility for keeping it current.

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. A NETID user account is generally only used by current faculty, staff, and students. Many of our customers incorrectly assume, for faculty and staff, that the NETID account is disabled or deleted upon termination or separation. This results in a person’s access to data, systems, and applications continuing past termination or separation which could result in a security incident, such as a data breach. Similarly, our customers make what are ultimately poor choices in granting access to resources, as they assume that the built-in Active Directory group ‘Domain Users’ represents only current faculty, staff, and students. The default access control list for most Windows and AD servers and applications includes that ‘Domain Users’ group, which in turn results in significantly broader access to data, systems, and applications than is intended.  Even without membership in any groups, an enabled account can still be used to authenticate and automatically gets membership in ‘Domain Users’.  While we have documented these issues and provided guidance on alternatives, we don’t believe that relying on purely administrative controls is sufficient, particularly when technical controls are possible and would be more effective.  We 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 holistic, enterprise solution to this problem would be preferred, however we have been waiting for that to happen in the systems of record for quite some time. Addressing this issue in the MI Service can be done more rapidly, at relatively low cost, and without impact to other UW NetID services or access. 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 thus unused, for two years will be purged. Given the functional solution space, there aren’t other viable alternatives of significance. For timeframes, we choose 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. Tying this process to the existing time frames for disabling or removing other UW NetID services, is a likely future enhancement.

Azure AD users are affected, but Azure AD logons are not necessarily accounted for via strictly AD data discovery methods. This is because some users will use the MIT Kerberos u.washington.edu realm for authentication, via Weblogin, via Shibboleth IdP,  via ADFS, via Azure AD for applications that require an Azure AD logon token. Other AAD users are not federated, so the only logon data for them is at AAD–however, those users are not currently in the scope of this design change.

The MSCA service provides Exchange and Sharepoint services in which a subset of user accounts are not expected to logon regularly, but are “in active use” by other users who do logon regularly. These “shared” user accounts do not logon as themselves but access controls permit access to data owned by the shared user account. From an analysis perspective, it’d be fine to disable these user accounts, but deletion would result in an undesired outcome. Additionally, there is a desire to have all employees and students in a Global Address book. Not all employees and students logon regularly, so this outcome would also be defeated. To address these MSCA needs, an exclusion mechanism can prevent deletion for MSCA eligible NETID accounts assuming the MSCA service provides a group containing all such users. MSCA service will need to keep this group current, otherwise over time it’ll become an ever-growing group which will defeat the purpose of this inactive account design. If there are signs that this group is not being kept current, MI will need to reconsider this exclusionary mechanism.

Lifecycle Process Changes/Additions

Account with no UW NetID password or that loses the UW NetID password (no password set)

Accounts with no password will be disabled immediately. NOTE: This is not a change–this has been the current service design for quite a while.

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)
  2. move the associated user object to a different OU structure, which is not processed by Azure AD Sync or 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.
  5. purge the associated AAD account (a consequence of #2)

Account disabled for 1 year

Accounts that have been disabled for 1 year will be permanently deleted, unless they are members of the exclusionary MSCA group mentioned above. Members of that group have been identified as necessary to not be deleted to meet the business needs provided by the MSCA service.

Reactivation

  1. An account that has been disabled, but not yet deleted, can be re-activated by resetting the UW NetID password. The UW NetID password reset will automatically result in the account being usable.
  2. By default, an account that has been deleted cannot be reactivated. A new NETID AD user account will be provisioned, with no association possible or noted between the previous incarnation and the new one. Outside of automated flow, we have the option of leveraging the AD recycle bin for a period of 180 days to manually reactivate a NETID AD user account. Using the AD recycle bin option would require manual intervention, initiated by an explicit request with a valid business reason to do so.

Identified Problems and Analysis

None at this time. Previously identified problems with AAD logon info have been resolved by data in the AAD Security API.

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.

Implementation Details

  • need a users DB table in uwwiDB to span AD, AAD, and other data sources
  • Need a column to track the date on which an account was disabled
  • Need to reflect AAD or ADFS logons in process (because not all AAD logons are AD logons):
    • The AdfsRpLogins table in uwwiDB could be leveraged if a new column for user account name was added; a small code change would also be needed on the ADFS servers
    • AAD does not have a lastlogon timestamp attribute on users, so we’d need to use the AAD Security API to capture AAD logon data from the audit log.
      Note: Not all AAD users exist in our AD and future service design may not always leverage ADFS, so AAD logon data is preferred over ADFS
  • LastUse column algorithm:
    • Replace existing value with AD lastLogonTimestamp, if it is newer than existing value
    • Replace existing value with AD passwordLastSet, if it is newer than existing value
    • Replace existing value with AAD logon timestamp, if it is newer than existing value
      Note: retaining the last value for each of these individual sources in a column is a good idea
  • Action Criteria:
    • disable: if(not in MSCA group) & if(LastUse > (now() – 1 year)), then disable
    • delete: if(not in MSCA group) & (if ((disabledDate – 1y) > now() )) then delete.
  • powershell script checks all accounts against criteria, disabling and deleting as appropriate, and updating database with disable and delete timestamps.
  • database records for deleted accounts will be purged one year after deletion
  • disabled user account that gets kiwi pwd change request: fuzzy kiwi sets pwd, moves account back, re-enables. reconciler detects changed state and removes disabled timestamp in DB and adds “re-enabled” timestamp (for later analysis of whether our time period is too short/long).  This may require code changes.
  • will be different criteria for deletion for initial run of disable. initial run would delete accounts that haven’t been used in 2y, then run disable.

Additional Thoughts

While there isn’t a complete enterprise solution for all of the nuances of user lifecycle management, the affiliation of a user account could be leveraged. In particular:

  1. Active Affiliation – if an account has an active student/faculty/staff affiliation, should their AD account be removed even if never used?
    1. Does MSCA really need to include in the “exclusion” list users with active affiliations that grant them Office 365 licenses?
  2. Passive Affiliation – if an account is no longer actively affiliated (as above), then the user would no longer be eligible for an Office 365 license. Is there a process planned or in place to remove licenses and related user data? There have been extensive discussions of this but I don’t believe there are resources to put this into practice. It seems this issue is very much tied to the inactive account removal process.
  3. Other Affiliations – clearly the shared account affiliation is the one that introduces the most complexity. Again, does this list need to come from MSCA or can it be based entirely on the affiliation?
    1. What process is used to grant a shared account an Office 365 license? Could that process be leveraged to flag those accounts as do-not-delete?
  4. Should the subscription system, which currently grants access based on affiliation, be leveraged to provide data to MI?

Outcome

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