Context | IAM |
|---|---|
Title | Microsoft's Typology of Windows Local Accounts |
Version |
|
Summary | Microsoft provides a partial typology of Windows Local Accounts. This typology is presented here. |
See Also |
Microsoft proposes a partial typology of Windows Local Accounts in Microsoft, 2019(1) :
Default | Non-Default | |
|---|---|---|
System | X | |
Non-System |
The attentive reader will observe the absence of a description for the Non-Default Local System Account.
Default | Non-Default | |
|---|---|---|
System | ||
Non-System |
Empirical Entity | Of Identity Class? | Comments | References |
|---|---|---|---|
Windows Default Local System Account | Yes |
| |
Windows Default Local User Account | Yes |
| |
Windows Guest Account | Yes |
| |
Windows Local Account | Yes |
| |
Windows Local User Account | Yes |
|
But before getting into that, the first step in analyzing this partial typology is to define its dimensions.
Default vs. Non-Default
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).
System vs. Non-System
- 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
