Microsoft's Typology of Windows Local Accounts

Context	IAM
Title	Microsoft's Typology of Windows Local Accounts
Version	`1.0` Draft
Summary	Microsoft provides a partial typology of Windows Local Accounts. This typology is presented here.
See Also	A General Inventory of Empirical Identities (Research Note - IAM) Built-in (Dictionary Entry) Partial Typology (Dictionary Entry) Typology (Dictionary Entry)
TODO	Complete the section on the System vs Non-System dimension Propose a robust definition of Default / Built-in Propose a robust definition of System Start a similar article covering Linux

In Microsoft, 2019(1), Microsoft proposes a bi-dimensional partial typology of Windows Local Accounts. A number of empirical entities are typed, which gives us the following table:

	Default	Non-Default

	Default	Non-Default
System	LOCAL SERVICE Account NETWORK SERVICE Account SYSTEM Account	X
Non-System	DefaultAccount Account Guest Account HelpAssistant Account Local Administrator Account	Local User Account e.g.: “John Dow”

Empirical Entities in the Microsoft’s Partial Typology of Windows Local Accounts

The attentive reader will observe the absence of a description for the Non-Default Local System Account, which is why the typology is partial.

From that table, the following typology is inferred, where cells represent Windows Local Account types:

	Default	Non-Default

	Default	Non-Default
System	Default Local System Account	X
Non-System	Default Local User Account	Non-Default Local User Account

Microsoft’s Partial Typology of Windows Local Accounts

The Default vs. Non-Default Dimension

Per Microsoft, 2019(1), default accounts are built-in accounts created automatically when the OS is installed. Conversely, non-default accounts are non-built-in accounts created after OS installation.

Built-in is an ambiguous term (Built-in (Dictionary Entry)). In effect, the term designates an object that is related to another object for several distinct reasons, e.g. because:

it forms an integral part of it,
it is included, made or designed as part of it,
it was included in it when it was created,
it is permanently connected to it and cannot be easily removed.

These ambiguities do not allow to classify entities in some grey areas, such as:

when an account that is an integral part of the OS is deployed by Microsoft after OS installation as part of an upgrade,
when an account that is an integral part of the OS is deployed as part of the installation of a complementary Windows Component after OS installation,
when an account that is an integral part of the OS is deployed by a third party (e.g.: a device driver, that is defined as a trusted part of the OS that can execute within it with System account credentials, Russinovich et al., 2017),
when a custom account is created as part of a custom script during OS installation.

Propose here a more precise definition of default that allows the arbitrage of the given counterexamples.

Nevertheless, arbitrages can be made to classify accounts in these grey areas. In consequence, for operational purposes, we may state that the default vs non-default dimension satisfies in general the properties of exhaustivity and mutual exclusivity. That is to say, a Windows Local Account is either an integral part of the OS or it doesn’t and the default vs non-default dimension may be considered an unidimensional typology (cf. Bailey, 1994, p.3).

The System vs. Non-System Dimension

Complete this section.

Per Microsoft, 2019(1), System accounts are used by the OS and its services.

A Revised Typology

Check correlation of given types

Check consistency between definitions and the hierarchical classification of accounts proposed by MS