{
	"id": "100e6513-5fa0-4bc2-a5d3-71cdd9201586",
	"created_at": "2026-04-06T00:22:00.198811Z",
	"updated_at": "2026-04-10T13:11:28.530762Z",
	"deleted_at": null,
	"sha1_hash": "98679569deec26ac8ad13b356fb1877711a3e04d",
	"title": "Local Accounts",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 97869,
	"plain_text": "Local Accounts\r\nBy officedocspr5\r\nArchived: 2026-04-05 13:12:25 UTC\r\nThis article describes the default local user accounts for Windows operating systems, and how to manage the built-in accounts.\r\nAbout local user accounts\r\nLocal user accounts are defined locally on a device, and can be assigned rights and permissions on the device\r\nonly. Local user accounts are security principals that are used to secure and manage access to the resources on a\r\ndevice, for services or users.\r\nDefault local user accounts\r\nThe default local user accounts are built-in accounts that are created automatically when the operating system is\r\ninstalled. The default local user accounts can't be removed or deleted and don't provide access to network\r\nresources.\r\nDefault local user accounts are used to manage access to the local device's resources based on the rights and\r\npermissions that are assigned to the account. The default local user accounts, and the local user accounts that you\r\ncreate, are located in the Users folder. The Users folder is located in the Local Users and Groups folder in the\r\nlocal Computer Management Microsoft Management Console (MMC). Computer Management is a collection of\r\nadministrative tools that you can use to manage a local or remote device.\r\nDefault local user accounts are described in the following sections. Expand each section for more information.\r\nAdministrator\r\nThe default local Administrator account is a user account for system administration. Every computer has an\r\nAdministrator account (SID S-1-5-domain-500, display name Administrator). The Administrator account is the\r\nfirst account that is created during the Windows installation.\r\nThe Administrator account has full control of the files, directories, services, and other resources on the local\r\ndevice. The Administrator account can create other local users, assign user rights, and assign permissions. The\r\nAdministrator account can take control of local resources at any time by changing the user rights and permissions.\r\nThe default Administrator account can't be deleted or locked out, but it can be renamed or disabled.\r\nWindows setup disables the built-in Administrator account and creates another local account that is a member of\r\nthe Administrators group.\r\nhttps://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/local-accounts\r\nPage 1 of 11\n\nMembers of the Administrators groups can run apps with elevated permissions without using the Run as\r\nAdministrator option. Fast User Switching is more secure than using runas or different-user elevation.\r\nAccount group membership\r\nBy default, the Administrator account is a member of the Administrators group. It's a best practice to limit the\r\nnumber of users in the Administrators group because members of the Administrators group have Full Control\r\npermissions on the device.\r\nThe Administrator account can't be removed from the Administrators group.\r\nSecurity considerations\r\nBecause the Administrator account is known to exist on many versions of the Windows operating system, it's a\r\nbest practice to disable the Administrator account when possible to make it more difficult for malicious users to\r\ngain access to the server or client computer.\r\nYou can rename the Administrator account. However, a renamed Administrator account continues to use the same\r\nautomatically assigned security identifier (SID), which can be discovered by malicious users. For more\r\ninformation about how to rename or disable a user account, see Disable or activate a local user account and\r\nRename a local user account.\r\nAs a security best practice, use your local (non-Administrator) account to sign in and then use Run as\r\nadministrator to accomplish tasks that require a higher level of rights than a standard user account. Don't use the\r\nAdministrator account to sign in to your computer unless it's entirely necessary. For more information, see Run a\r\nprogram with administrative credentials.\r\nGroup Policy can be used to control the use of the local Administrators group automatically. For more information\r\nabout Group Policy, see Group Policy Overview.\r\nImportant\r\nBlank passwords are not allowed\r\nEven when the Administrator account is disabled, it can still be used to gain access to a computer by using\r\nsafe mode. In the Recovery Console or in safe mode, the Administrator account is automatically enabled.\r\nWhen normal operations are resumed, it's disabled.\r\nGuest\r\nThe Guest account lets occasional or one-time users, who don't have an account on the computer, temporarily sign\r\nin to the local server or client computer with limited user rights. By default, the Guest account is disabled and has\r\na blank password. Since the Guest account can provide anonymous access, it's considered a security risk. For this\r\nreason, it's a best practice to leave the Guest account disabled, unless its use is necessary.\r\nGuest account group membership\r\nhttps://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/local-accounts\r\nPage 2 of 11\n\nBy default, the Guest account is the only member of the default Guests group SID S-1-5-32-546 , which lets a\r\nuser sign in to a device.\r\nGuest account security considerations\r\nWhen enabling the Guest account, only grant limited rights and permissions. For security reasons, the Guest\r\naccount shouldn't be used over the network and made accessible to other computers.\r\nIn addition, the guest user in the Guest account shouldn't be able to view the event logs. After the Guest account is\r\nenabled, it's a best practice to monitor the Guest account frequently to ensure that other users can't use services\r\nand other resources. This includes resources that were unintentionally left available by a previous user.\r\nHelpAssistant\r\nThe HelpAssistant account is a default local account that is enabled when a Remote Assistance session is run. This\r\naccount is automatically disabled when no Remote Assistance requests are pending.\r\nHelpAssistant is the primary account that is used to establish a Remote Assistance session. The Remote Assistance\r\nsession is used to connect to another computer running the Windows operating system, and it's initiated by\r\ninvitation. For solicited remote assistance, a user sends an invitation from their computer, through e-mail or as a\r\nfile, to a person who can provide assistance. After the user's invitation for a Remote Assistance session is\r\naccepted, the default HelpAssistant account is automatically created to give the person who provides assistance\r\nlimited access to the computer. The HelpAssistant account is managed by the Remote Desktop Help Session\r\nManager service.\r\nHelpAssistant account security considerations\r\nThe SIDs that pertain to the default HelpAssistant account include:\r\nSID: S-1-5-\u003cdomain\u003e-13 , display name Terminal Server User. This group includes all users who sign in\r\nto a server with Remote Desktop Services enabled.\r\nSID: S-1-5-\u003cdomain\u003e-14 , display name Remote Interactive Logon. This group includes all users who\r\nconnect to the computer by using a remote desktop connection. This group is a subset of the Interactive\r\ngroup. Access tokens that contain the Remote Interactive Logon SID also contain the Interactive SID.\r\nFor the Windows Server operating system, Remote Assistance is an optional component that isn't installed by\r\ndefault. You must install Remote Assistance before it can be used.\r\nFor details about the HelpAssistant account attributes, see the following table.\r\nHelpAssistant account attributes\r\nhttps://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/local-accounts\r\nPage 3 of 11\n\nAttribute Value\r\nWell-Known SID/RID\r\nS-1-5-\u003cdomain\u003e-13 (Terminal Server User), S-1-5-\r\n\u003cdomain\u003e-14 (Remote Interactive Logon)\r\nType User\r\nDefault container CN=Users, DC=\u003cdomain\u003e\r\nDefault members None\r\nDefault member of\r\nDomain Guests\r\nGuests\r\nProtected by ADMINSDHOLDER? No\r\nSafe to move out of default container? Can be moved out, but we don't recommend it.\r\nSafe to delegate management of this group to\r\nnon-Service admins?\r\nNo\r\nDefaultAccount\r\nThe DefaultAccount account, also known as the Default System Managed Account (DSMA), is a well-known user\r\naccount type. DefaultAccount can be used to run processes that are either multi-user aware or user-agnostic.\r\nThe DSMA is disabled by default on the desktop editions and on the Server operating systems with the desktop\r\nexperience.\r\nThe DSMA has a well-known RID of 503 . The security identifier (SID) of the DSMA will thus have a well-known SID in the following format: S-1-5-21-\\\u003cComputerIdentifier\u003e-503 .\r\nThe DSMA is a member of the well-known group System Managed Accounts Group, which has a well-known\r\nSID of S-1-5-32-581 .\r\nThe DSMA alias can be granted access to resources during offline staging even before the account itself is created.\r\nThe account and the group are created during first boot of the machine within the Security Accounts Manager\r\n(SAM).\r\nHow Windows uses the DefaultAccount\r\nFrom a permission perspective, the DefaultAccount is a standard user account. The DefaultAccount is needed to\r\nrun multi-user-manifested-apps (MUMA apps). MUMA apps run all the time and react to users signing in and\r\nsigning out of the devices. Unlike Windows Desktop where apps run in context of the user and get terminated\r\nwhen the user signs off, MUMA apps run by using the DSMA.\r\nhttps://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/local-accounts\r\nPage 4 of 11\n\nMUMA apps are functional in shared session SKUs such as Xbox. For example, Xbox shell is a MUMA app.\r\nToday, Xbox automatically signs in as Guest account and all apps run in this context. All the apps are multi-user-aware and respond to events fired by user manager. The apps run as the Guest account.\r\nSimilarly, Phone auto logs in as a DefApps account, which is akin to the standard user account in Windows but\r\nwith a few extra privileges. Brokers, some services and apps run as this account.\r\nIn the converged user model, the multi-user-aware apps and multi-user-aware brokers will need to run in a context\r\ndifferent from that of the users. For this purpose, the system creates DSMA.\r\nHow the DefaultAccount is created on domain controllers\r\nIf the domain was created with domain controllers running Windows Server 2016, the DefaultAccount exists on\r\nall domain controllers in the domain. If the domain was created with domain controllers running an earlier version\r\nof Windows Server, the DefaultAccount is created after the PDC Emulator role is transferred to a domain\r\ncontroller that runs Windows Server 2016. The DefaultAccount is then replicated to all other domain controllers in\r\nthe domain.\r\nRecommendations for managing the Default Account (DSMA)\r\nMicrosoft doesn't recommend changing the default configuration, where the account is disabled. There's no\r\nsecurity risk with having the account in the disabled state. Changing the default configuration could hinder future\r\nscenarios that rely on this account.\r\nDefault local system accounts\r\nSYSTEM\r\nThe SYSTEM account is used by the operating system and by services running under Windows. There are many\r\nservices and processes in the Windows operating system that need the capability to sign in internally, such as\r\nduring a Windows installation. The SYSTEM account was designed for that purpose, and Windows manages the\r\nSYSTEM account's user rights. It's an internal account that doesn't show up in User Manager, and it can't be added\r\nto any groups.\r\nOn the other hand, the SYSTEM account does appear on an NTFS file system volume in File Manager in the\r\nPermissions portion of the Security menu. By default, the SYSTEM account is granted Full Control permissions\r\nto all files on an NTFS volume. Here the SYSTEM account has the same functional rights and permissions as the\r\nAdministrator account.\r\nNote\r\nTo grant the account Administrators group file permissions does not implicitly give permission to the SYSTEM\r\naccount. The SYSTEM account's permissions can be removed from a file, but we do not recommend removing\r\nthem.\r\nNETWORK SERVICE\r\nhttps://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/local-accounts\r\nPage 5 of 11\n\nThe NETWORK SERVICE account is a predefined local account used by the service control manager (SCM). A\r\nservice that runs in the context of the NETWORK SERVICE account presents the computer's credentials to\r\nremote servers. For more information, see NetworkService Account.\r\nLOCAL SERVICE\r\nThe LOCAL SERVICE account is a predefined local account used by the service control manager. It has minimum\r\nprivileges on the local computer and presents anonymous credentials on the network. For more information, see\r\nLocalService Account.\r\nHow to manage local user accounts\r\nThe default local user accounts, and the local user accounts you create, are located in the Users folder. The Users\r\nfolder is located in Local Users and Groups. For more information about creating and managing local user\r\naccounts, see Manage Local Users.\r\nYou can use Local Users and Groups to assign rights and permissions on only the local server to limit the ability\r\nof local users and groups to perform certain actions. A right authorizes a user to perform certain actions on a\r\nserver, such as backing up files and folders or shutting down a server. An access permission is a rule that is\r\nassociated with an object, usually a file, folder, or printer. It regulates which users can have access to an object on\r\nthe server and in what manner.\r\nYou can't use Local Users and Groups on a domain controller. However, you can use Local Users and Groups on a\r\ndomain controller to target remote computers that aren't domain controllers on the network.\r\nNote\r\nYou use Active Directory Users and Computers to manage users and groups in Active Directory.\r\nYou can also manage local users by using NET.EXE USER and manage local groups by using NET.EXE\r\nLOCALGROUP, or by using various PowerShell cmdlets and other scripting technologies.\r\nRestrict and protect local accounts with administrative rights\r\nAn administrator can use many approaches to prevent malicious users from using stolen credentials such as a\r\nstolen password or password hash, for a local account on one computer from being used to authenticate on another\r\ncomputer with administrative rights. This is also called lateral movement.\r\nThe simplest approach is to sign in to your computer with a standard user account, instead of using the\r\nAdministrator account for tasks. For example, use a standard account to browse the Internet, send email, or use a\r\nword processor. When you want to perform administrative tasks such as installing a new program or changing a\r\nsetting that affects other users, you don't have to switch to an Administrator account. You can use User Account\r\nControl (UAC) to prompt you for permission or an administrator password before performing the task, as\r\ndescribed in the next section.\r\nThe other approaches that can be used to restrict and protect user accounts with administrative rights include:\r\nhttps://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/local-accounts\r\nPage 6 of 11\n\nEnforce local account restrictions for remote access\r\nDeny network logon to all local Administrator accounts\r\nCreate unique passwords for local accounts with administrative rights\r\nEach of these approaches is described in the following sections.\r\nNote\r\nThese approaches do not apply if all administrative local accounts are disabled.\r\nEnforce local account restrictions for remote access\r\nUser Account Control (UAC) is a security feature that informs you when a program makes a change that requires\r\nadministrative permissions. UAC works by adjusting the permission level of your user account. By default, UAC\r\nis set to notify you when applications try to make changes to your computer, but you can change when UAC\r\nnotifies you.\r\nUAC makes it possible for an account with administrative rights to be treated as a standard user nonadministrator\r\naccount until full rights, also called elevation, is requested and approved. For example, UAC lets an administrator\r\nenter credentials during a nonadministrator's user session to perform occasional administrative tasks without\r\nhaving to switch users, sign out, or use the Run as command.\r\nIn addition, UAC can require administrators to specifically approve applications that make system-wide changes\r\nbefore those applications are granted permission to run, even in the administrator's user session.\r\nFor example, a default feature of UAC is shown when a local account signs in from a remote computer by using\r\nNetwork logon (for example, by using NET.EXE USE). In this instance, it's issued a standard user token with no\r\nadministrative rights, but without the ability to request or receive elevation. Consequently, local accounts that sign\r\nin by using Network logon can't access administrative shares such as C$, or ADMIN$, or perform any remote\r\nadministration.\r\nFor more information about UAC, see User Account Control.\r\nThe following table shows the Group Policy and registry settings that are used to enforce local account restrictions\r\nfor remote access.\r\nNote\r\nYou can also enforce the default for LocalAccountTokenFilterPolicy by using the custom ADMX in Security\r\nTemplates.\r\nTo enforce local account restrictions for remote access\r\n1. Start the Group Policy Management Console (GPMC)\r\n2. In the console tree, expand \u003cForest\u003e\\Domains\u003cDomain\u003e, and then Group Policy Objects where forest is\r\nthe name of the forest, and domain is the name of the domain where you want to set the Group Policy\r\nhttps://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/local-accounts\r\nPage 7 of 11\n\nObject (GPO)\r\n3. In the console tree, right-click Group Policy Objects \u003e New\r\n4. In the New GPO dialog box, type \u003cgpo_name\u003e, and \u003e OK where gpo_name is the name of the new GPO.\r\nThe GPO name indicates that the GPO is used to restrict local administrator rights from being carried over\r\nto another computer\r\n5. In the details pane, right-click \u003cgpo_name\u003e, and \u003e Edit\r\n6. Ensure that UAC is enabled and that UAC restrictions apply to the default Administrator account by\r\nfollowing these steps:\r\nNavigate to the Computer Configuration \u003e Windows Settings \u003e Security Settings \u003e Local\r\nPolicies \u003e Security Options\r\nSelect User Account Control: Run all administrators in Admin Approval Mode \u003e Enabled \u003e\r\nOK\r\nSelect User Account Control: Admin Approval Mode for the Built-in Administrator account \u003e\r\nEnabled \u003e OK\r\n7. Ensure that the local account restrictions are applied to network interfaces by following these steps:\r\nNavigate to Computer Configuration\\Preferences and Windows Settings, and \u003e Registry\r\nRight-click Registry, and \u003e New \u003e Registry Item\r\nIn the New Registry Properties dialog box, on the General tab, change the setting in the Action\r\nbox to Replace\r\nEnsure that the Hive box is set to HKEY_LOCAL_MACHINE\r\nSelect (…), browse to the following location for Key Path \u003e Select for:\r\nSOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System\r\nIn the Value name area, type LocalAccountTokenFilterPolicy\r\nIn the Value type box, from the drop-down list, select REG_DWORD to change the value\r\nIn the Value data box, ensure that the value is set to 0\r\nVerify this configuration, and \u003e OK\r\n8. Link the GPO to the first Workstations organizational unit (OU) by doing the following:\r\nNavigate to the *Forest*\\\u003cDomains\u003e\\*Domain*\\*OU* path\r\nRight-click the Workstations \u003e Link an existing GPO\r\nSelect the GPO that you created, and \u003e OK\r\n9. Test the functionality of enterprise applications on the workstations in that first OU and resolve any issues\r\ncaused by the new policy\r\n10. Create links to all other OUs that contain workstations\r\n11. Create links to all other OUs that contain servers\r\nhttps://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/local-accounts\r\nPage 8 of 11\n\nDeny network logon to all local Administrator accounts\r\nDenying local accounts the ability to perform network logons can help prevent a local account password hash\r\nfrom being reused in a malicious attack. This procedure helps to prevent lateral movement by ensuring that stolen\r\ncredentials for local accounts from a compromised operating system can't be used to compromise other computers\r\nthat use the same credentials.\r\nNote\r\nTo perform this procedure, you must first identify the name of the local, default Administrator account, which\r\nmight not be the default user name \"Administrator\", and any other accounts that are members of the local\r\nAdministrators group.\r\nThe following table shows the Group Policy settings that are used to deny network logon for all local\r\nAdministrator accounts.\r\nNo. Setting Detailed Description\r\nPolicy\r\nlocation\r\nComputer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User\r\nRights Assignment\r\n1 Policy name Deny access to this computer from the network\r\nPolicy setting Local account and member of Administrators group\r\n2\r\nPolicy\r\nlocation\r\nComputer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User\r\nRights Assignment\r\nPolicy name Deny log on through Remote Desktop Services\r\nPolicy setting Local account and member of Administrators group\r\nTo deny network logon to all local administrator accounts\r\n1. Start the Group Policy Management Console (GPMC)\r\n2. In the console tree, expand \u003cForest\u003e\\Domains\u003cDomain\u003e, and then Group Policy Objects, where forest is\r\nthe name of the forest, and domain is the name of the domain where you want to set the Group Policy\r\nObject (GPO)\r\n3. In the console tree, right-click Group Policy Objects, and \u003e New\r\n4. In the New GPO dialog box, type \u003cgpo_name\u003e, and then \u003e OK where gpo_name is the name of the new\r\nGPO indicates that it's being used to restrict the local administrative accounts from interactively signing in\r\nto the computer\r\n5. In the details pane, right-click \u003cgpo_name\u003e, and \u003e Edit\r\nhttps://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/local-accounts\r\nPage 9 of 11\n\n6. Configure the user rights to deny network logons for administrative local accounts as follows:\r\n7. Navigate to the Computer Configuration\\Windows Settings\\Security Settings, and \u003e User Rights\r\nAssignment\r\n8. Double-click Deny access to this computer from the network\r\n9. Select Add User or Group, type Local account and member of Administrators group, and \u003e OK\r\n10. Configure the user rights to deny Remote Desktop (Remote Interactive) logons for administrative local\r\naccounts as follows:\r\n11. Navigate to Computer Configuration\\Policies\\Windows Settings and Local Policies, and then select User\r\nRights Assignment\r\n12. Double-click Deny log on through Remote Desktop Services\r\n13. Select Add User or Group, type Local account and member of Administrators group, and \u003e OK\r\n14. Link the GPO to the first Workstations OU as follows:\r\nNavigate to the \u003cForest\u003e\\Domains\u003cDomain\u003e\\OU path\r\nRight-click the Workstations OU, and \u003e Link an existing GPO\r\nSelect the GPO that you created, and \u003e OK\r\n15. Test the functionality of enterprise applications on the workstations in that first OU and resolve any issues\r\ncaused by the new policy\r\n16. Create links to all other OUs that contain workstations\r\n17. Create links to all other OUs that contain servers\r\nNote\r\nYou might have to create a separate GPO if the user name of the default Administrator account is different on\r\nworkstations and servers.\r\nCreate unique passwords for local accounts with administrative rights\r\nPasswords should be unique per individual account. While it's true for individual user accounts, many enterprises\r\nhave identical passwords for common local accounts, such as the default Administrator account. This also occurs\r\nwhen the same passwords are used for local accounts during operating system deployments.\r\nPasswords that are left unchanged or changed synchronously to keep them identical add a significant risk for\r\norganizations. Randomizing the passwords mitigates \"pass-the-hash\" attacks by using different passwords for\r\nlocal accounts, which hamper the ability of malicious users to use password hashes of those accounts to\r\ncompromise other computers.\r\nPasswords can be randomized by:\r\nhttps://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/local-accounts\r\nPage 10 of 11\n\nPurchasing and implementing an enterprise tool to accomplish this task. These tools are commonly referred\r\nto as \"privileged password management\" tools\r\nConfiguring Local Administrator Password Solution (LAPS) to accomplish this task\r\nCreating and implementing a custom script or solution to randomize local account passwords\r\nSource: https://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/local-accounts\r\nhttps://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/local-accounts\r\nPage 11 of 11",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/local-accounts"
	],
	"report_names": [
		"local-accounts"
	],
	"threat_actors": [
		{
			"id": "aa73cd6a-868c-4ae4-a5b2-7cb2c5ad1e9d",
			"created_at": "2022-10-25T16:07:24.139848Z",
			"updated_at": "2026-04-10T02:00:04.878798Z",
			"deleted_at": null,
			"main_name": "Safe",
			"aliases": [],
			"source_name": "ETDA:Safe",
			"tools": [
				"DebugView",
				"LZ77",
				"OpenDoc",
				"SafeDisk",
				"TypeConfig",
				"UPXShell",
				"UsbDoc",
				"UsbExe"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434920,
	"ts_updated_at": 1775826688,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/98679569deec26ac8ad13b356fb1877711a3e04d.pdf",
		"text": "https://archive.orkl.eu/98679569deec26ac8ad13b356fb1877711a3e04d.txt",
		"img": "https://archive.orkl.eu/98679569deec26ac8ad13b356fb1877711a3e04d.jpg"
	}
}