{
	"id": "3d5e6761-24cb-4e95-8e0f-243652beb648",
	"created_at": "2026-04-06T00:09:44.19302Z",
	"updated_at": "2026-04-10T03:22:00.586598Z",
	"deleted_at": null,
	"sha1_hash": "3347c2e4a0311fd5a91e019535739650f6d35c01",
	"title": "Active Directory Accounts",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 111830,
	"plain_text": "Active Directory Accounts\r\nBy robinharwood\r\nArchived: 2026-04-05 16:22:31 UTC\r\nWindows Server operating systems are installed with default local accounts. In addition, you can create user\r\naccounts to meet the requirements of your organization.\r\nThis reference article describes the Windows Server default local accounts that are stored locally on the domain\r\ncontroller and used in Active Directory. It doesn't describe default local user accounts for a member, standalone\r\nserver, or Windows client. For more information, see Local accounts.\r\nDefault local accounts in Active Directory\r\nDefault local accounts are built-in accounts that are created automatically when a Windows Server domain\r\ncontroller is installed and the domain is created. These default local accounts have counterparts in Active\r\nDirectory. They also have domain-wide access and are completely separate from the default local user accounts\r\nfor a member or standalone server.\r\nYou can assign rights and permissions to default local accounts on a particular domain controller, and only on that\r\ndomain controller. These accounts are local to the domain. After the default local accounts are installed, they're\r\nstored in the Users container in Active Directory Users and Computers. It's a best practice to keep the default local\r\naccounts in the User container and not attempt to move these accounts to, for example, a different organizational\r\nunit (OU).\r\nThe default local accounts in the Users container include: Administrator, Guest, and KRBTGT. The HelpAssistant\r\naccount is installed when a Remote Assistance session is established. The following sections describe the default\r\nlocal accounts and their use in Active Directory.\r\nDefault local accounts perform the following actions:\r\nLet the domain represent, identify, and authenticate the identity of the user who's assigned to the account\r\nby using unique credentials (user name and password). It's a best practice to assign each user to a single\r\naccount to ensure maximum security. Multiple users aren't allowed to share one account. A user account\r\nlets a user sign in to computers, networks, and domains with a unique identifier that can be authenticated\r\nby the computer, network, or domain.\r\nAuthorize (grant or deny) access to resources. After a user’s credentials have been authenticated, the user is\r\nauthorized to access the network and domain resources based on the user’s explicitly assigned rights on the\r\nresource.\r\nAudit the actions that are carried out on user accounts.\r\nhttps://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/active-directory-accounts\r\nPage 1 of 16\n\nIn Active Directory, administrators use default local accounts to manage domain and member servers directly and\r\nfrom dedicated administrative workstations. Active Directory accounts provide access to network resources.\r\nActive Directory User accounts and Computer accounts can represent a physical entity, such as a computer or\r\nperson, or act as dedicated service accounts for some applications.\r\nEach default local account is automatically assigned to a security group that's preconfigured with the appropriate\r\nrights and permissions to perform specific tasks. Active Directory security groups collect user accounts, computer\r\naccounts, and other groups into manageable units. For more information, see Active Directory security groups.\r\nOn an Active Directory domain controller, each default local account is referred to as a security principal. A\r\nsecurity principal is a directory object that's used to secure and manage Active Directory services that provide\r\naccess to domain controller resources. A security principal includes objects such as user accounts, computer\r\naccounts, security groups, or the threads or processes that run in the security context of a user or computer\r\naccount. For more information, see Security principals.\r\nA security principal is represented by a unique security identifier (SID). The SIDs that are related to each of the\r\ndefault local accounts in Active Directory are described in the next sections.\r\nSome of the default local accounts are protected by a background process that periodically checks and applies a\r\nspecific security descriptor. A security descriptor is a data structure that contains security information that's\r\nassociated with a protected object. This process ensures that any successful unauthorized attempt to modify the\r\nsecurity descriptor on one of the default local accounts or groups is overwritten with the protected settings.\r\nThis security descriptor is present on the AdminSDHolder object. If you want to modify the permissions on one of\r\nthe service administrator groups or on any of its member accounts, you must modify the security descriptor on the\r\nAdminSDHolder object to ensure that it's applied consistently. Be careful when you make these modifications,\r\nbecause you're also changing the default settings that are applied to all your protected accounts.\r\nAdministrator account\r\nAn Administrator account is a default account that's used in all versions of the Windows operating system on\r\nevery computer and device. The Administrator account is used by the system administrator for tasks that require\r\nadministrative credentials. This account can't be deleted or locked out, but the account can be renamed or disabled.\r\nThe Administrator account gives the user complete access (Full Control permissions) to the files, directories,\r\nservices, and other resources that are on that local server. You can use the Administrator account to create local\r\nusers, and to assign user rights and access control permissions. You can also use the account to take control of\r\nlocal resources at any time simply by changing the user rights and permissions. Although files and directories can\r\nbe protected from the Administrator account temporarily, the account can take control of these resources at any\r\ntime by changing the access permissions.\r\nAccount group membership\r\nThe Administrator account has membership in the default security groups, as described in the Administrator\r\naccount attributes table later in this article.\r\nhttps://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/active-directory-accounts\r\nPage 2 of 16\n\nThe security groups ensure that you can control administrator rights without having to change each Administrator\r\naccount. In most instances, you don't have to change the basic settings for this account. However, you might have\r\nto change its advanced settings, such as membership in particular groups.\r\nSecurity considerations\r\nAfter installation of the server operating system, your first task is to set up the Administrator account properties\r\nsecurely. This includes setting up an especially long, strong password, and securing the Remote control and\r\nRemote Desktop Services profile settings.\r\nThe Administrator account can also be disabled when it's not required. Renaming or disabling the Administrator\r\naccount makes it more difficult for malicious users to try to gain access to the account. However, even when the\r\nAdministrator account is disabled, it can still be used to gain access to a domain controller by using safe mode.\r\nOn a domain controller, the Administrator account becomes the Domain Admin account. The Domain Admin\r\naccount is used to sign in to the domain controller, and this account requires a strong password. The Domain\r\nAdmin account gives you access to domain resources.\r\nNote\r\nWhen the domain controller is initially installed, you can sign in and use Server Manager to set up a local\r\nAdministrator account, with the rights and permissions you want to assign. For example, you can use a local\r\nAdministrator account to manage the operating system when you first install it. By using this approach, you can\r\nset up the operating system without getting locked out. Generally, you don't need to use the account after\r\ninstallation. You can create local user accounts on the domain controller only before Active Directory Domain\r\nServices is installed, and not afterward.\r\nWhen Active Directory is installed on the first domain controller in the domain, the Administrator account is\r\ncreated for Active Directory. The Administrator account is the most powerful account in the domain. It's given\r\ndomain-wide access and administrative rights to administer the computer and the domain, and it has the most\r\nextensive rights and permissions over the domain. The person who installs Active Directory Domain Services on\r\nthe computer creates the password for this account during the installation.\r\nAdministrator account attributes\r\nAttribute Value\r\nWell-known SID/RID S-1-5- \u003cdomain\u003e -500\r\nType User\r\nDefault container CN=Users, DC= \u003cdomain\u003e , DC=\r\nDefault members N/A\r\nDefault member of Administrators, Domain Admins, Enterprise Administrators,\r\nDomain Users (the Primary Group ID of all user accounts is\r\nhttps://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/active-directory-accounts\r\nPage 3 of 16\n\nAttribute Value\r\nDomain Users)\r\nGroup Policy Creator Owners, and Schema Admins in Active\r\nDirectory Domain Users group\r\nProtected by AdminSdHolder? Yes\r\nSafe to move out of default container? Yes\r\nSafe to delegate management of this\r\ngroup to nonservice administrators?\r\nNo\r\nGuest account\r\nThe Guest account is a default local account that has limited access to the computer and is disabled by default. By\r\ndefault, the Guest account password is left blank. A blank password allows the Guest account to be accessed\r\nwithout requiring the user to enter a password.\r\nThe Guest account enables occasional or one-time users, who don't have an individual account on the computer, to\r\nsign in to the local server or domain with restricted rights and permissions. The Guest account can be enabled, and\r\nthe password can be set up if needed, but only by a member of the Administrator group on the domain.\r\nGuest account group membership\r\nThe Guest account has membership in the default security groups that are described in the following Guest\r\naccount attributes table. By default, the Guest account is the only member of the default Guests group, which lets\r\na user sign in to a server, and the Domain Guests global group, which lets a user sign in to a domain.\r\nA member of the Administrators group or Domain Admins group can set up a user with a Guest account on one or\r\nmore computers.\r\nGuest account security considerations\r\nBecause the Guest account can provide anonymous access, it's a security risk. It also has a well-known SID. For\r\nthis reason, it's a best practice to leave the Guest account disabled, unless its use is required and then only with\r\nrestricted rights and permissions for a very limited period of time.\r\nWhen the Guest account is required, an Administrator on the domain controller is required to enable the Guest\r\naccount. The Guest account can be enabled without requiring a password, or it can be enabled with a strong\r\npassword. The Administrator also grants restricted rights and permissions for the Guest account. To help prevent\r\nunauthorized access:\r\nDon't grant the Guest account the Shut down the system user right. When a computer is shutting down or\r\nstarting up, it's possible that a Guest user or anyone with local access, such as a malicious user, could gain\r\nhttps://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/active-directory-accounts\r\nPage 4 of 16\n\nunauthorized access to the computer.\r\nDon't provide the Guest account with the ability to view the event logs. After the Guest account is enabled,\r\nit's a best practice to monitor this account frequently to ensure that other users can't use services and other\r\nresources, such as resources that were unintentionally left available by a previous user.\r\nDon't use the Guest account when the server has external network access or access to other computers.\r\nIf you decide to enable the Guest account, be sure to restrict its use and to change the password regularly. As with\r\nthe Administrator account, you might want to rename the account as an added security precaution.\r\nIn addition, an administrator is responsible for managing the Guest account. The administrator monitors the Guest\r\naccount, disables the Guest account when it's no longer in use, and changes or removes the password as needed.\r\nFor details about the Guest account attributes, see the following table:\r\nGuest account attributes\r\nAttribute Value\r\nWell-known SID/RID S-1-5- \u003cdomain\u003e -501\r\nType User\r\nDefault container CN=Users, DC= \u003cdomain\u003e , DC=\r\nDefault members None\r\nDefault member of Guests, Domain Guests\r\nProtected by AdminSdHolder? No\r\nSafe to move out of default container?\r\nCan be moved out, but we don't recommend\r\nit.\r\nSafe to delegate management of this group to non-Service\r\nadmins?\r\nNo\r\nHelpAssistant account (installed with a Remote Assistance session)\r\nThe HelpAssistant account is a default local account that's 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's 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 email 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\nhttps://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/active-directory-accounts\r\nPage 5 of 16\n\nlimited access to the computer. The HelpAssistant account is managed by the Remote Desktop Help Session\r\nManager service.\r\nHelpAssistant 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 to\r\na server with Remote Desktop Services enabled. In Windows Server 2008, Remote Desktop Services is\r\ncalled Terminal Services.\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 you can use it.\r\nFor details about the HelpAssistant account attributes, see the following table:\r\nHelpAssistant account attributes\r\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 , DC=\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\nKRBTGT account\r\nThe KRBTGT account is a local default account that acts as a service account for the Key Distribution Center\r\n(KDC) service. This account can't be deleted, and the account name can't be changed. The KRBTGT account can't\r\nhttps://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/active-directory-accounts\r\nPage 6 of 16\n\nbe enabled in Active Directory.\r\nKRBTGT is also the security principal name used by the KDC for a Windows Server domain, as specified by RFC\r\n4120. The KRBTGT account is the entity for the KRBTGT security principal, and it's created automatically when\r\na new domain is created.\r\nWindows Server Kerberos authentication is achieved by the use of a special Kerberos ticket-granting ticket (TGT)\r\nenciphered with a symmetric key. This key is derived from the password of the server or service to which access is\r\nrequested. The TGT password of the KRBTGT account is known only by the Kerberos service. To request a\r\nsession ticket, you must present the TGT to the KDC. The TGT is issued to the Kerberos client from the KDC.\r\nKRBTGT account maintenance considerations\r\nA strong password is assigned to the KRBTGT and trust accounts automatically. You should change these\r\npasswords on a regular schedule, as you would with any privileged service account. The password for the KDC\r\naccount is used to derive a secret key for encrypting and decrypting the TGT requests that are issued. The\r\npassword for a domain trust account is used to derive an inter-realm key for encrypting referral tickets.\r\nTo reset the password, you need to either be a member of the Domain Admins group or be delegated the\r\nappropriate authority. In addition, you must be a member of the local Administrators group or be delegated the\r\nappropriate authority.\r\nAfter you reset the KRBTGT password, ensure that event ID 9 in the (Kerberos) Key-Distribution-Center event\r\nsource is written to the System event log.\r\nKRBTGT account security considerations\r\nIt's also a best practice to reset the KRBTGT account password to ensure that a newly restored domain controller\r\ndoesn't replicate with a compromised domain controller. In this case, in a large forest recovery that's spread across\r\nmultiple locations, you can't guarantee that all domain controllers are shut down and, if they're shut down, that\r\nthey can't be rebooted again before all the appropriate recovery steps are performed. After you reset the KRBTGT\r\naccount, another domain controller can't replicate this account password by using an old password.\r\nAn organization suspecting domain compromise of the KRBTGT account should consider the use of professional\r\nincident response services. The impact to restore the ownership of the account is domain-wide, labor intensive,\r\nand should be undertaken as part of a larger recovery effort.\r\nThe KRBTGT password is the key from which all trust in Kerberos chains up to. Resetting the KRBTGT\r\npassword is similar to renewing the root CA certificate with a new key and immediately not trusting the old key,\r\nresulting in almost all subsequent Kerberos operations being affected.\r\nFor all account types (users, computers, and services):\r\nAll the TGTs that are already issued and distributed will be invalid because the DCs will reject them. These\r\ntickets are encrypted with the KRBTGT so any DC can validate them. When the password changes, the\r\ntickets become invalid.\r\nhttps://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/active-directory-accounts\r\nPage 7 of 16\n\nAll currently authenticated sessions that signed-in users have established (based on their service tickets) to\r\na resource (such as a file share, SharePoint site, or Exchange server) are good until the service ticket is\r\nrequired to reauthenticate.\r\nNTLM authenticated connections aren't affected.\r\nBecause it's impossible to predict the specific errors that will occur for any given user in a production operating\r\nenvironment, you must assume that all computers and users will be affected.\r\nImportant\r\nRebooting a computer is the only reliable way to recover functionality, because doing so will cause both the\r\ncomputer account and user accounts to sign back in again. Signing in again will request new TGTs that are valid\r\nwith the new KRBTGT, which will correct any KRBTGT-related operational issues on that computer.\r\nRead-only domain controllers and the KRBTGT account\r\nThe RODC is advertised as the Key Distribution Center (KDC) for the branch office. The RODC uses a different\r\nKRBTGT account and password than the KDC on a writable domain controller when it signs or encrypts TGT\r\nrequests. After an account is successfully authenticated, the RODC determines whether a user's credentials or a\r\ncomputer's credentials can be replicated from the writable domain controller to the RODC by using the Password\r\nReplication Policy.\r\nAfter the credentials are cached on the RODC, the RODC can accept that user's sign-in requests until the\r\ncredentials change. When a TGT is signed with the KRBTGT account of the RODC, the RODC recognizes that it\r\nhas a cached copy of the credentials. If another domain controller signs the TGT, the RODC forwards requests to a\r\nwritable domain controller.\r\nKRBTGT account attributes\r\nFor details about the KRBTGT account attributes, see the following table:\r\nAttribute Value\r\nWell-known SID/RID S-1-5- \u003cdomain\u003e -502\r\nType User\r\nDefault container CN=Users, DC= \u003cdomain\u003e , DC=\r\nDefault members None\r\nDefault member of\r\nDomain Users group. (The Primary Group ID of all user\r\naccounts is Domain Users.)\r\nProtected by AdminSdHolder? Yes\r\nSafe to move out of default container? Can be moved out, but we don't recommend it.\r\nhttps://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/active-directory-accounts\r\nPage 8 of 16\n\nAttribute Value\r\nSafe to delegate management of this group to\r\nnon-Service admins?\r\nNo\r\nSettings for default local accounts in Active Directory\r\nEach default local account in Active Directory has several account settings that you can use to configure password\r\nsettings and security-specific information, as described in the following table:\r\nAccount setting Description\r\nUser must change\r\npassword at next\r\nlogon\r\nForces a password change the next time that the user signs in to the network. Use this\r\noption when you want to ensure that the user is the only person who knows their\r\npassword.\r\nUser can't change\r\npassword\r\nPrevents the user from changing the password. Use this option when you want to\r\nmaintain control over a user account, such as for a Guest or temporary account.\r\nPassword never\r\nexpires\r\nPrevents a user password from expiring. It's a best practice to enable this option with\r\nservice accounts and to use strong passwords.\r\nStore passwords\r\nusing reversible\r\nencryption\r\nProvides support for applications that use protocols requiring knowledge of the\r\nplaintext form of the user’s password for authentication purposes.\r\nThis option is required when you're using Challenge Handshake Authentication\r\nProtocol (CHAP) in Internet Authentication Services (IAS), and when you're using\r\ndigest authentication in Internet Information Services (IIS).\r\nAccount is disabled\r\nPrevents the user from signing in with the selected account. As an administrator, you\r\ncan use disabled accounts as templates for common user accounts.\r\nSmart card is\r\nrequired for\r\ninteractive logon\r\nRequires that a user has a smart card to sign on to the network interactively. The user\r\nmust also have a smart card reader attached to their computer and a valid personal\r\nidentification number (PIN) for the smart card.\r\nWhen this attribute is applied on the account, the effect is as follows:\r\nThe attribute restricts only initial authentication for interactive sign-in and Remote\r\nDesktop sign-in. When interactive or Remote Desktop sign-in requires a subsequent\r\nnetwork sign-in, such as with a domain credential, an NT Hash provided by the\r\ndomain controller is used to complete the smart card authentication process.\r\nEach time the attribute is enabled on an account, the account’s current password hash\r\nvalue is replaced with a 128-bit random number. This invalidates the use of any\r\nhttps://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/active-directory-accounts\r\nPage 9 of 16\n\nAccount setting Description\r\npreviously configured passwords for the account. The value doesn't change after that\r\nunless a new password is set or the attribute is disabled and re-enabled.\r\nAccounts with this attribute can't be used to start services or run scheduled tasks.\r\nAccount is trusted\r\nfor delegation\r\nLets a service running under this account to perform operations on behalf of other user\r\naccounts on the network. A service running under a user account (also known as a\r\nservice account) that's trusted for delegation can impersonate a client to gain access to\r\nresources, either on the computer where the service is running or on other computers.\r\nFor example, in a forest that's set to the Windows Server 2003 functional level, this\r\nsetting is found on the Delegation tab. It's available only for accounts that have been\r\nassigned service principal names (SPNs), which are set by using the setspn\r\ncommand from Windows Support Tools. This setting is security-sensitive and should\r\nbe assigned cautiously.\r\nAccount is\r\nsensitive and can't\r\nbe delegated\r\nGives control over a user account, such as a Guest account or a temporary account.\r\nThis option can be used if this account can't be assigned for delegation by another\r\naccount.\r\nUse DES\r\nencryption types\r\nfor this account\r\nProvides support for the Data Encryption Standard (DES). DES supports multiple\r\nlevels of encryption, including Microsoft Point-to-Point Encryption (MPPE) Standard\r\n(40-bit and 56-bit), MPPE standard (56-bit), MPPE Strong (128-bit), Internet Protocol\r\nSecurity (IPSec) DES (40-bit), IPSec 56-bit DES, and IPSec Triple DES (3DES).\r\nDon't require\r\nKerberos\r\npreauthentication\r\nProvides support for alternative implementations of the Kerberos protocol. Because\r\npreauthentication provides additional security, use caution when you're enabling this\r\noption. Domain controllers running Windows 2000 or Windows Server 2003 can use\r\nother mechanisms to synchronize time.\r\nNote\r\nDES isn't enabled by default in Windows Server operating systems (starting with Windows Server 2008 R2) or in\r\nWindows client operating systems (starting with Windows 7). For these operating systems, computers won't use\r\nDES-CBC-MD5 or DES-CBC-CRC cipher suites by default. If your environment requires DES, this setting might\r\naffect compatibility with client computers or services and applications in your environment.\r\nFor more information, see Hunting down DES to securely deploy Kerberos.\r\nManage default local accounts in Active Directory\r\nAfter the default local accounts are installed, these accounts reside in the Users container in Active Directory\r\nUsers and Computers. You can create, disable, reset, and delete default local accounts by using the Active\r\nDirectory Users and Computers Microsoft Management Console (MMC) and by using command-line tools.\r\nhttps://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/active-directory-accounts\r\nPage 10 of 16\n\nYou can use Active Directory Users and Computers to assign rights and permissions on a specified local domain\r\ncontroller, and that domain controller only, to limit the ability of local users and groups to perform certain actions.\r\nA right authorizes a user to perform certain actions on a computer, such as backing up files and folders or shutting\r\ndown a computer. In contrast, an access permission is a rule that's associated with an object, usually a file, folder,\r\nor printer, that regulates which users can have access to the object and in what manner.\r\nFor more information about creating and managing local user accounts in Active Directory, see Manage local\r\nusers.\r\nYou can also use Active Directory Users and Computers on a domain controller to target remote computers that\r\naren't domain controllers on the network.\r\nYou can obtain recommendations from Microsoft for domain controller configurations that you can distribute by\r\nusing the Security Compliance Manager (SCM) tool. For more information, see Microsoft Security Compliance\r\nManager.\r\nSome of the default local user accounts are protected by a background process that periodically checks and applies\r\na specific security descriptor, which is a data structure that contains security information that's associated with a\r\nprotected object. This security descriptor is present on the AdminSDHolder object.\r\nThis means that, when you want to modify the permissions on a service administrator group or on any of its\r\nmember accounts, you're also required to modify the security descriptor on the AdminSDHolder object. This\r\napproach ensures that the permissions are applied consistently. Be careful when you make these modifications,\r\nbecause this action can also affect the default settings that are applied to all your protected administrative\r\naccounts.\r\nRestrict and protect sensitive domain accounts\r\nRestricting and protecting domain accounts in your domain environment requires you to adopt and implement the\r\nfollowing best practices approach:\r\nStrictly limit membership to the Administrators, Domain Admins, and Enterprise Admins groups.\r\nStringently control where and how domain accounts are used.\r\nMember accounts in the Administrators, Domain Admins, and Enterprise Admins groups in a domain or forest are\r\nhigh-value targets for malicious users. To limit any exposure, it's a best practice to strictly limit membership to\r\nthese administrator groups to the smallest number of accounts. Restricting membership in these groups reduces\r\nthe possibility that an administrator might unintentionally misuse these credentials, creating a vulnerability that\r\nmalicious users can exploit.\r\nMoreover, it's a best practice to stringently control where and how sensitive domain accounts are used. Restrict the\r\nuse of Domain Admins accounts and other Administrator accounts to prevent them from being used to sign in to\r\nmanagement systems and workstations that are secured at the same level as the managed systems. When\r\nAdministrator accounts aren't restricted in this manner, each workstation from which a domain administrator signs\r\nin provides another location that malicious users can exploit.\r\nhttps://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/active-directory-accounts\r\nPage 11 of 16\n\nImplementing these best practices is separated into the following tasks:\r\nSeparate Administrator accounts from user accounts\r\nRestrict administrator sign-in access to servers and workstations\r\nDisable the account delegation right for sensitive Administrator accounts\r\nTo provide for instances where integration challenges with the domain environment are expected, each task is\r\ndescribed according to the requirements for a minimum, better, and ideal implementation. As with all significant\r\nchanges to a production environment, ensure that you test these changes thoroughly before you implement and\r\ndeploy them. Then stage the deployment in a manner that allows for a rollback of the change if technical issues\r\noccur.\r\nSeparate Administrator accounts from user accounts\r\nRestrict Domain Admins accounts and other sensitive accounts to prevent them from being used to sign in to\r\nlower trust servers and workstations. Restrict and protect Administrator accounts by segregating Administrator\r\naccounts from standard user accounts, by separating administrative duties from other tasks, and by limiting the use\r\nof these accounts. Create dedicated accounts for administrative personnel who require administrator credentials to\r\nperform specific administrative tasks, and then create separate accounts for other standard user tasks, according to\r\nthe following guidelines:\r\nPrivileged account: Allocate Administrator accounts to perform the following administrative duties only:\r\nMinimum: Create separate accounts for domain administrators, enterprise administrators, or the\r\nequivalent, with appropriate administrator rights in the domain or forest. Use accounts that have\r\nbeen granted sensitive administrator rights only to administer domain data and domain controllers.\r\nBetter: Create separate accounts for administrators that have reduced administrative rights, such as\r\naccounts for workstation administrators, and accounts with user rights over designated Active\r\nDirectory organizational units (OUs).\r\nIdeal: Create multiple, separate accounts for an administrator who has several job responsibilities\r\nthat require different trust levels. Set up each Administrator account with different user rights, such\r\nas for workstation administration, server administration, and domain administration, to let the\r\nadministrator sign in to specified workstations, servers, and domain controllers based strictly on\r\ntheir job responsibilities.\r\nStandard user account: Grant standard user rights for standard user tasks, such as email, web browsing,\r\nand using line-of-business (LOB) applications. These accounts shouldn't be granted administrator rights.\r\nImportant\r\nEnsure that sensitive Administrator accounts can't access email or browse the internet, as described in the\r\nfollowing section.\r\nTo learn more about privileged access, see Privileged access devices.\r\nhttps://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/active-directory-accounts\r\nPage 12 of 16\n\nRestrict administrator sign-in access to servers and workstations\r\nIt's a best practice to restrict administrators from using sensitive Administrator accounts to sign in to lower-trust\r\nservers and workstations. This restriction prevents administrators from inadvertently increasing the risk of\r\ncredential theft by signing in to a lower-trust computer.\r\nImportant\r\nEnsure that you either have local access to the domain controller or you've built at least one dedicated\r\nadministrative workstation.\r\nRestrict sign-in access to lower-trust servers and workstations by using the following guidelines:\r\nMinimum: Restrict domain administrators from having sign-in access to servers and workstations. Before\r\nyou start this procedure, identify all OUs in the domain that contain workstations and servers. Any\r\ncomputers in OUs that aren't identified won't restrict administrators with sensitive accounts from signing in\r\nto them.\r\nBetter: Restrict domain administrators from nondomain controller servers and workstations.\r\nIdeal: Restrict server administrators from signing in to workstations, in addition to domain administrators.\r\nNote\r\nFor this procedure, don't link accounts to the OU that contain workstations for administrators that perform\r\nadministration duties only, and don't provide internet or email access.\r\nTo restrict domain administrators from workstations (minimum)\r\n1. As a domain administrator, open the Group Policy Management Console (GPMC).\r\n2. Open Group Policy Management, expand \u003cforest\u003e\\Domains\\ \u003cdomain\u003e .\r\n3. Right-click Group Policy Objects, and then select New.\r\nScreenshot of the Group Policy Management console window, showing the \"Group Policy Objects\"\r\ncommand and shortcut menu.\r\n4. In the New GPO window, name the GPO that restricts administrators from signing in to workstations, and\r\nthen select OK.\r\nScreenshot of the \"New GPO\" window for entering the group name and source starter GPO.\r\n5. Right-click New GPO, and then select Edit.\r\n6. Configure user rights to deny sign-in locally for domain administrators.\r\n7. Select Computer Configuration \u003e Policies \u003e Windows Settings \u003e Local Policies, select User Rights\r\nAssignment, and then do the following:\r\nhttps://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/active-directory-accounts\r\nPage 13 of 16\n\n1. Double-click Deny logon locally, and then select Define these policy settings.\r\n2. Select Add User or Group, select Browse, type Enterprise Admins, and then select OK.\r\n3. Select Add User or Group, select Browse, type Domain Admins, and then select OK.\r\nScreenshot of the \"User Rights Management\" window, showing that the \"Define these policy settings\"\r\ncheckbox is selected and two domain accounts are being denied local sign-in.\r\nTip\r\nYou can optionally add any groups that contain server administrators whom you want to restrict from\r\nsigning in to workstations.\r\nNote\r\nCompleting this step might cause issues with administrator tasks that run as scheduled tasks or services\r\nwith accounts in the Domain Admins group. The practice of using domain Administrator accounts to run\r\nservices and tasks on workstations creates a significant risk of credential theft attacks and, therefore, should\r\nbe replaced with alternative means to run scheduled tasks or services.\r\nd. Select OK to complete the configuration.\r\n8. Link the GPO to the first Workstations OU. Go to the \u003cforest\u003e\\Domains\\ \u003cdomain\u003e \\OU path, and then do\r\nthe following:\r\na. Right-click the workstation OU, and then select Link an Existing GPO.\r\nScreenshot of the Group Policy Management console window, where you right-click a Workstations\r\nitem and select \"Link an Existing GPO\".\r\nb. Select the GPO that you just created, and then select OK.\r\nScreenshot of the \"Select GPO\" window, where you select a domain and Group Policy Objects.\r\n9. Test the functionality of enterprise applications on workstations in the first OU, and resolve any issues\r\ncaused by the new policy.\r\n10. Link all other OUs that contain workstations.\r\nHowever, don't create a link to the Administrative Workstation OU if it's created for administrative\r\nworkstations that are dedicated to administration duties only and are without internet or email access.\r\nImportant\r\nIf you later extend this solution, don't deny sign-in rights for the Domain Users group. The Domain Users\r\ngroup includes all user accounts in the domain, including Users, Domain Administrators, and Enterprise\r\nAdministrators.\r\nhttps://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/active-directory-accounts\r\nPage 14 of 16\n\nDisable the account delegation right for sensitive Administrator accounts\r\nAlthough user accounts aren't marked for delegation by default, accounts in an Active Directory domain can be\r\ntrusted for delegation. This means that a service or a computer that's trusted for delegation can impersonate an\r\naccount that authenticates to it to access other resources across the network.\r\nFor sensitive accounts, such as those belonging to members of the Administrators, Domain Admins, or Enterprise\r\nAdmins groups in Active Directory, delegation can present a substantial risk of rights escalation. For example, if\r\nan account in the Domain Admins group is used to sign in to a compromised member server that's trusted for\r\ndelegation, that server can request access to resources in the context of the Domain Admins account and escalate\r\nthe compromise of that member server to a domain compromise.\r\nIt's a best practice to configure the user objects for all sensitive accounts in Active Directory by selecting the\r\nAccount is sensitive and cannot be delegated checkbox under Account options to prevent the accounts from\r\nbeing delegated. For more information, see Settings for default local accounts in Active Directory.\r\nAs with any configuration change, test this enabled setting fully to ensure that it performs correctly before you\r\nimplement it.\r\nScreenshot of the Active Directory account properties window. The \"Account is sensitive and cannot be\r\ndelegated\" checkbox is selected.\r\nSecure and manage domain controllers\r\nIt's a best practice to strictly enforce restrictions on the domain controllers in your environment. This ensures that\r\nthe domain controllers:\r\nRun only required software.\r\nRequire that software is regularly updated.\r\nAre configured with the appropriate security settings.\r\nOne aspect of securing and managing domain controllers is to ensure that the default local user accounts are fully\r\nprotected. It's of primary importance to restrict and secure all sensitive domain accounts, as described in the\r\npreceding sections.\r\nBecause domain controllers store credential password hashes of all accounts in the domain, they're high-value\r\ntargets for malicious users. When domain controllers aren't well managed and secured by using restrictions that\r\nare strictly enforced, they can be compromised by malicious users. For example, a malicious user could steal\r\nsensitive domain administrator credentials from one domain controller, and then use these credentials to attack the\r\ndomain and forest.\r\nIn addition, installed applications and management agents on domain controllers might provide a path for\r\nescalating rights that malicious users can use to compromise the management service or administrators of that\r\nservice. The management tools and services that your organization uses to manage domain controllers and their\r\nadministrators are equally important to the security of the domain controllers and the domain Administrator\r\naccounts. Ensure that these services and administrators are fully secured with equal effort.\r\nhttps://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/active-directory-accounts\r\nPage 15 of 16\n\nRelated content\r\nSecurity principals\r\nAccess control overview\r\nSource: https://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/active-directory-accounts\r\nhttps://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/active-directory-accounts\r\nPage 16 of 16",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/active-directory-accounts"
	],
	"report_names": [
		"active-directory-accounts"
	],
	"threat_actors": [],
	"ts_created_at": 1775434184,
	"ts_updated_at": 1775791320,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/3347c2e4a0311fd5a91e019535739650f6d35c01.pdf",
		"text": "https://archive.orkl.eu/3347c2e4a0311fd5a91e019535739650f6d35c01.txt",
		"img": "https://archive.orkl.eu/3347c2e4a0311fd5a91e019535739650f6d35c01.jpg"
	}
}