{
	"id": "a71ede59-c29f-40f5-8f32-0f3fb1da7ff8",
	"created_at": "2026-04-06T02:12:02.936596Z",
	"updated_at": "2026-04-10T03:22:04.501181Z",
	"deleted_at": null,
	"sha1_hash": "d67cd49913b23aa039bd5b162c58f6988b733fb7",
	"title": "Implementing Least-Privilege Administrative Models",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 113622,
	"plain_text": "Implementing Least-Privilege Administrative Models\r\nBy robinharwood\r\nArchived: 2026-04-06 02:05:40 UTC\r\nThe following excerpt is from The Administrator Accounts Security Planning Guide, first published on April 1,\r\n1999:\r\n\"Most security-related training courses and documentation discuss the implementation of a principle of\r\nleast privilege, yet organizations rarely follow it. The principle is simple, and the impact of applying it\r\ncorrectly greatly increases your security and reduces your risk. The principle states that all users should\r\nlog on with a user account that has the absolute minimum permissions necessary to complete the current\r\ntask and nothing more. Doing so provides protection against malicious code, among other attacks. This\r\nprinciple applies to computers and the users of those computers. \"One reason this principle works so\r\nwell is that it forces you to do some internal research. For example, you must determine the access\r\nprivileges that a computer or user really needs, and then implement them. For many organizations, this\r\ntask might initially seem like a great deal of work; however, it is an essential step to successfully secure\r\nyour network environment. \"You should grant all domain administrator users their domain privileges\r\nunder the concept of least privilege. For example, if an administrator logs on with a privileged account\r\nand inadvertently runs a virus program, the virus has administrative access to the local computer and to\r\nthe entire domain. If the administrator had instead logged on with a nonprivileged (nonadministrative)\r\naccount, the virus's scope of damage would only be the local computer because it runs as a local\r\ncomputer user. \"In another example, accounts to which you grant domain-level administrator rights\r\nmust not have elevated rights in another forest, even if there is a trust relationship between the forests.\r\nThis tactic helps prevent widespread damage if an attacker manages to compromise one managed\r\nforest. Organizations should regularly audit their network to protect against unauthorized escalation of\r\nprivilege.\"\r\nThe following excerpt is from the Microsoft Windows Security Resource Kit, first published in 2005:\r\n\"Always think of security in terms of granting the least amount of privileges required to carry out the\r\ntask. If an application that has too many privileges should be compromised, the attacker might be able\r\nto expand the attack beyond what it would if the application had been under the least amount of\r\nprivileges possible. For example, examine the consequences of a network administrator unwittingly\r\nopening an email attachment that launches a virus. If the administrator is logged on using the domain\r\nAdministrator account, the virus will have Administrator privileges on all computers in the domain and\r\nthus unrestricted access to nearly all data on the network. If the administrator is logged on using a local\r\nAdministrator account, the virus will have Administrator privileges on the local computer and thus\r\nwould be able to access any data on the computer and install malicious software such as key-stroke\r\nlogging software on the computer. If the administrator is logged on using a normal user account, the\r\nvirus will have access only to the administrator's data and will not be able to install malicious software.\r\nhttps://technet.microsoft.com/en-us/library/dn487450.aspx\r\nPage 1 of 15\n\nBy using the least privileges necessary to read email, in this example, the potential scope of the\r\ncompromise is greatly reduced.\"\r\nThe principles described in the preceding excerpts have not changed, but in assessing Active Directory\r\ninstallations, we invariably find excessive numbers of accounts that have been granted rights and permissions far\r\nbeyond those required to perform day-to-day work. The size of the environment affects the raw numbers of overly\r\nprivileged accounts, but not the proportion-midsized directories may have dozens of accounts in the most highly\r\nprivileged groups, while large installations may have hundreds or even thousands. With few exceptions, regardless\r\nof the sophistication of an attacker's skills and arsenal, attackers typically follow the path of least resistance. They\r\nincrease the complexity of their tooling and approach only if and when simpler mechanisms fail or are thwarted by\r\ndefenders.\r\nUnfortunately, the path of least resistance in many environments has proven to be the overuse of accounts with\r\nbroad and deep privilege. Broad privileges are rights and permissions that allow an account to perform specific\r\nactivities across a large cross-section of the environment- for example, Help Desk staff may be granted\r\npermissions that allow them to reset the passwords on many user accounts.\r\nDeep privileges are powerful privileges that are applied to a narrow segment of the population, such as giving an\r\nengineer Administrator rights on a server so that they can perform repairs. Neither broad privilege nor deep\r\nprivilege is necessarily dangerous, but when many accounts in the domain are permanently granted broad and\r\ndeep privilege, if only one of the accounts is compromised, it can quickly be used to reconfigure the environment\r\nto the attacker's purposes or even to destroy large segments of the infrastructure.\r\nPass-the-hash attacks, which are a type of credential theft attack, are ubiquitous because the tooling to perform\r\nthem is freely available and easy-to-use, and because many environments are vulnerable to the attacks. Pass-the-hash attacks, however, are not the real problem. The crux of the problem is twofold:\r\n1. It is usually easy for an attacker to obtain deep privilege on a single computer and then propagate that\r\nprivilege broadly to other computers.\r\n2. There are usually too many permanent accounts with high levels of privilege across the computing\r\nlandscape.\r\nEven if pass-the-hash attacks are eliminated, attackers would simply use different tactics, not a different strategy.\r\nRather than planting malware that contains credential theft tooling, they might plant malware that logs keystrokes,\r\nor leverage any number of other approaches to capture credentials that are powerful across the environment.\r\nRegardless of the tactics, the targets remain the same: accounts with broad and deep privilege.\r\nGranting of excessive privilege isn't only found in Active Directory in compromised environments. When an\r\norganization has developed the habit of granting more privilege than is required, it is typically found throughout\r\nthe infrastructure as discussed in the following sections.\r\nIn Active Directory, it is common to find that the EA, DA and BA groups contain excessive numbers of accounts.\r\nMost commonly, an organization's EA group contains the fewest members, DA groups usually contain a multiplier\r\nof the number of users in the EA group, and Administrators groups usually contain more members than the\r\npopulations of the other groups combined. This is often due to a belief that Administrators are somehow \"less\r\nhttps://technet.microsoft.com/en-us/library/dn487450.aspx\r\nPage 2 of 15\n\nprivileged\" than DAs or EAs. While the rights and permissions granted to each of these groups differ, they should\r\nbe effectively considered equally powerful groups because a member of one can make himself or herself a\r\nmember of the other two.\r\nWhen we retrieve the membership of local Administrators groups on member servers in many environments, we\r\nfind membership ranging from a handful of local and domain accounts, to dozens of nested groups that, when\r\nexpanded, reveal hundreds, even thousands, of accounts with local Administrator privilege on the servers. In many\r\ncases, domain groups with large memberships are nested in member servers' local Administrators groups, without\r\nconsideration to the fact that any user who can modify the memberships of those groups in the domain can gain\r\nadministrative control of all systems on which the group has been nested in a local Administrators group.\r\nAlthough workstations typically have significantly fewer members in their local Administrators groups than\r\nmember servers do, in many environments, users are granted membership in the local Administrators group on\r\ntheir personal computers. When this occurs, even if UAC is enabled, those users present an elevated risk to the\r\nintegrity of their workstations.\r\nImportant\r\nYou should consider carefully whether users require administrative rights on their workstations, and if they do, a\r\nbetter approach may be to create a separate local account on the computer that is a member of the Administrators\r\ngroup. When users require elevation, they can present the credentials of that local account for elevation, but\r\nbecause the account is local, it cannot be used to compromise other computers or access domain resources. As\r\nwith any local accounts, however, the credentials for the local privileged account should be unique; if you create a\r\nlocal account with the same credentials on multiple workstations, you expose the computers to pass-the-hash\r\nattacks.\r\nIn attacks in which the target is an organization's intellectual property, accounts that have been granted powerful\r\nprivileges within applications can be targeted to allow exfiltration of data. Although the accounts that have access\r\nto sensitive data may have been granted no elevated privileges in the domain or the operating system, accounts\r\nthat can manipulate the configuration of an application or access to the information the application provides\r\npresent risk.\r\nAs is the case with other targets, attackers seeking access to intellectual property in the form of documents and\r\nother files can target the accounts that control access to the file stores, accounts that have direct access to the files,\r\nor even groups or roles that have access to the files. For example, if a file server is used to store contract\r\ndocuments and access is granted to the documents by the use of an Active Directory group, an attacker who can\r\nmodify the membership of the group can add compromised accounts to the group and access the contract\r\ndocuments. In cases in which access to documents is provided by applications such as SharePoint, attackers can\r\ntarget the applications as described earlier.\r\nThe larger and more complex an environment, the more difficult it is to manage and secure. In small\r\norganizations, reviewing and reducing privilege may be a relatively simple proposition, but each additional server,\r\nworkstation, user account, and application in use in an organization adds another object that must be secured.\r\nBecause it can be difficult or even impossible to properly secure every aspect of an organization's IT\r\ninfrastructure, you should focus efforts first on the accounts whose privilege create the greatest risk, which are\r\nhttps://technet.microsoft.com/en-us/library/dn487450.aspx\r\nPage 3 of 15\n\ntypically the built-in privileged accounts and groups in Active Directory, and privileged local accounts on\r\nworkstations and member servers.\r\nAlthough this document focuses on securing Active Directory, as has been previously discussed, most attacks\r\nagainst the directory begin as attacks against individual hosts. Full guidelines for securing local groups on member\r\nsystems cannot be provided, but the following recommendations can be used to help you secure the local\r\nAdministrator accounts on workstations and member servers.\r\nOn all versions of Windows currently in mainstream support, the local Administrator account is disabled by\r\ndefault, which makes the account unusable for pass-the-hash and other credential theft attacks. However, in\r\ndomains containing legacy operating systems or in which local Administrator accounts have been enabled, these\r\naccounts can be used as previously described to propagate compromise across member servers and workstations.\r\nFor this reason, the following controls are recommended for all local Administrator accounts on domain-joined\r\nsystems.\r\nDetailed instructions for implementing these controls are provided in Appendix H: Securing Local Administrator\r\nAccounts and Groups. Before implementing these settings, however, ensure that local Administrator accounts are\r\nnot currently used in the environment to run services on computers or perform other activities for which these\r\naccounts should not be used. Test these settings thoroughly before implementing them in a production\r\nenvironment.\r\nBuilt-in Administrator accounts should never be used as service accounts on member servers, nor should they be\r\nused to log on to local computers (except in Safe Mode, which is permitted even if the account is disabled). The\r\ngoal of implementing the settings described here is to prevent each computer's local Administrator account from\r\nbeing usable unless protective controls are first reversed. By implementing these controls and monitoring\r\nAdministrator accounts for changes, you can significantly reduce the likelihood of success of an attack that targets\r\nlocal Administrator accounts.\r\nIn one or more GPOs that you create and link to workstation and member server OUs in each domain, add the\r\nAdministrator account to the following user rights in Computer Configuration\\Policies\\Windows\r\nSettings\\Security Settings\\Local Policies\\User Rights Assignments:\r\nDeny access to this computer from the network\r\nDeny log on as a batch job\r\nDeny log on as a service\r\nDeny log on through Remote Desktop Services\r\nWhen you add Administrator accounts to these user rights, specify whether you are adding the local Administrator\r\naccount or the domain's Administrator account by the way that you label the account. For example, to add the\r\nNWTRADERS domain's Administrator account to these deny rights, you would type the account as\r\nNWTRADERS\\Administrator, or browse to the Administrator account for the NWTRADERS domain. To\r\nensure that you restrict the local Administrator account, type Administrator in these user rights settings in the\r\nGroup Policy Object Editor.\r\nNote\r\nhttps://technet.microsoft.com/en-us/library/dn487450.aspx\r\nPage 4 of 15\n\nEven if local Administrator accounts are renamed, the policies will still apply.\r\nThese settings will ensure that a computer's Administrator account cannot be used to connect to the other\r\ncomputers, even if it is inadvertently or maliciously enabled. Local logons using the local Administrator account\r\ncannot be completely disabled, nor should you attempt to do so, because a computer's local Administrator account\r\nis designed to be used in disaster recovery scenarios.\r\nShould a member server or workstation become disjoined from the domain with no other local accounts granted\r\nadministrative privileges, the computer can be booted into safe mode, the Administrator account can be enabled,\r\nand the account can then be used to effect repairs on the computer. When repairs are completed, the Administrator\r\naccount should again be disabled.\r\nLaw Number Six: A computer is only as secure as the administrator is trustworthy. - Ten Immutable Laws of\r\nSecurity (Version 2.0)\r\nThe information provided here is intended to give general guidelines for securing the highest privilege built-in\r\naccounts and groups in Active Directory. Detailed step-by-step instructions are also provided in Appendix D:\r\nSecuring Built-In Administrator Accounts in Active Directory, Appendix E: Securing Enterprise Admins Groups in\r\nActive Directory, Appendix F: Securing Domain Admins Groups in Active Directory, and in Appendix G:\r\nSecuring Administrators Groups in Active Directory.\r\nBefore you implement any of these settings, you should also test all settings thoroughly to determine if they are\r\nappropriate for your environment. Not all organizations will be able to implement these settings.\r\nIn each domain in Active Directory, an Administrator account is created as part of the creation of the domain. This\r\naccount is by default a member of the Domain Admins and Administrator groups in the domain, and if the domain\r\nis the forest root domain, the account is also a member of the Enterprise Admins group. Use of a domain's local\r\nAdministrator account should be reserved only for initial build activities and, possibly, disaster-recovery\r\nscenarios. To ensure that a built-in Administrator account can be used to effect repairs in the event that no other\r\naccounts can be used, you should not change the default membership of the Administrator account in any domain\r\nin the forest. Instead, you should following guidelines to help secure the Administrator account in each domain in\r\nthe forest. Detailed instructions for implementing these controls are provided in Appendix D: Securing Built-In\r\nAdministrator Accounts in Active Directory.\r\nThe goal of implementing the settings described here is to prevent each domain's Administrator account (not a\r\ngroup) from being usable unless a number of controls are reversed. By implementing these controls and\r\nmonitoring the Administrator accounts for changes, you can significantly reduce the likelihood of a successful\r\nattack by leveraging a domain's Administrator account. For the Administrator account in each domain in your\r\nforest, you should configure the following settings.\r\nBy default, all accounts in Active Directory can be delegated. Delegation allows a computer or service to present\r\nthe credentials for an account that has authenticated to the computer or service to other computers to obtain\r\nservices on behalf of the account. When you enable the Account is sensitive and cannot be delegated attribute\r\non a domain-based account, the account's credentials cannot be presented to other computers or services on the\r\nnetwork, which limits attacks that leverage delegation to use the account's credentials on other systems.\r\nhttps://technet.microsoft.com/en-us/library/dn487450.aspx\r\nPage 5 of 15\n\nWhen you enable the Smart card is required for interactive logon attribute on an account, Windows resets the\r\naccount's password to a 120-character random value. By setting this flag on built-in Administrator accounts, you\r\nensure that the password for the account is not only long and complex, but is not known to any user. It is not\r\ntechnically necessary to create smart cards for the accounts before enabling this attribute, but if possible, smart\r\ncards should be created for each Administrator account prior to configuring the account restrictions and the smart\r\ncards should be stored in secure locations.\r\nAlthough setting the Smart card is required for interactive logon flag resets the account's password, it does not\r\nprevent a user with rights to reset the account's password from setting the account to a known value and using the\r\naccount's name and new password to access resources on the network. Because of this, you should implement the\r\nfollowing additional controls on the account.\r\nAlthough disabling the Administrator account in a domain makes the account effectively unusable, you should\r\nimplement additional restrictions on the account in case the account is inadvertently or maliciously enabled.\r\nAlthough these controls can ultimately be reversed by the Administrator account, the goal is to create controls that\r\nslow an attacker's progress and limit the damage the account can inflict.\r\nIn one or more GPOs that you create and link to workstation and member server OUs in each domain, add each\r\ndomain's Administrator account to the following user rights in Computer Configuration\\Policies\\Windows\r\nSettings\\Security Settings\\Local Policies\\User Rights Assignments:\r\nDeny access to this computer from the network\r\nDeny log on as a batch job\r\nDeny log on as a service\r\nDeny log on through Remote Desktop Services\r\nNote\r\nWhen you add local Administrator accounts to this setting, you must specify whether you are configuring local\r\nAdministrator accounts or domain Administrator accounts. For example, to add the NWTRADERS domain's local\r\nAdministrator account to these deny rights, you must either type the account as NWTRADERS\\Administrator,\r\nor browse to the local Administrator account for the NWTRADERS domain. If you type Administrator in these\r\nuser rights settings in the Group Policy Object Editor, you will restrict the local Administrator account on each\r\ncomputer to which the GPO is applied.\r\nWe recommend restricting local Administrator accounts on member servers and workstations in the same manner\r\nas domain-based Administrator accounts. Therefore, you should generally add the Administrator account for each\r\ndomain in the forest and the Administrator account for the local computers to these user rights settings.\r\nIn each domain in the forest, the Default Domain Controllers policy or a policy linked to the Domain Controllers\r\nOU should be modified to add each domain's Administrator account to the following user rights in Computer\r\nConfiguration\\Policies\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignments:\r\nDeny access to this computer from the network\r\nDeny log on as a batch job\r\nDeny log on as a service\r\nhttps://technet.microsoft.com/en-us/library/dn487450.aspx\r\nPage 6 of 15\n\nDeny log on through Remote Desktop Services\r\nNote\r\nThese settings will ensure that the local Administrator account cannot be used to connect to a domain controller,\r\nalthough the account, if enabled, can log on locally to domain controllers. Because this account should only be\r\nenabled and used in disaster-recovery scenarios, it is anticipated that physical access to at least one domain\r\ncontroller will be available, or that other accounts with permissions to access domain controllers remotely can be\r\nused.\r\nWhen you have secured each domain's Administrator account and disabled it, you should configure auditing to\r\nmonitor for changes to the account. If the account is enabled, its password is reset, or any other modifications are\r\nmade to the account, alerts should be sent to the users or teams responsible for administration of AD DS, in\r\naddition to incident response teams in your organization.\r\nThe Enterprise Admins group, which is housed in the forest root domain, should contain no users on a day-to-day\r\nbasis, with the possible exception of the domain's local Administrator account, provided it is secured as described\r\nearlier and in Appendix D: Securing Built-In Administrator Accounts in Active Directory.\r\nWhen EA access is required, the users whose accounts require EA rights and permissions should be temporarily\r\nplaced into the Enterprise Admins group. Although users are using the highly privileged accounts, their activities\r\nshould be audited and preferably performed with one user performing the changes and another user observing the\r\nchanges to minimize the likelihood of inadvertent misuse or misconfiguration. When the activities have been\r\ncompleted, the accounts should be removed from the EA group. This can be achieved via manual procedures and\r\ndocumented processes, third-party privileged identity/access management (PIM/PAM) software, or a combination\r\nof both. Guidelines for creating accounts that can be used to control the membership of privileged groups in\r\nActive Directory are provided in Attractive Accounts for Credential Theft and detailed instructions are provided in\r\nAppendix I: Creating Management Accounts for Protected Accounts and Groups in Active Directory.\r\nEnterprise Admins are, by default, members of the built-in Administrators group in each domain in the forest.\r\nRemoving the Enterprise Admins group from the Administrators groups in each domain is an inappropriate\r\nmodification because in the event of a forest disaster-recovery scenario, EA rights will likely be required. If the\r\nEnterprise Admins group has been removed from Administrators groups in a forest, it should be added to the\r\nAdministrators group in each domain and the following additional controls should be implemented:\r\nAs described earlier, the Enterprise Admins group should contain no users on a day-to-day basis, with the\r\npossible exception of the forest root domain's Administrator account, which should be secured as described\r\nin Appendix D: Securing Built-In Administrator Accounts in Active Directory.\r\nIn GPOs linked to OUs containing member servers and workstations in each domain, the EA group should\r\nbe added to the following user rights:\r\nDeny access to this computer from the network\r\nDeny log on as a batch job\r\nDeny log on as a service\r\nDeny log on locally\r\nDeny log on through Remote Desktop Services.\r\nhttps://technet.microsoft.com/en-us/library/dn487450.aspx\r\nPage 7 of 15\n\nThis will prevent members of the EA group from logging on to member servers and workstations. If jump servers\r\nare used to administer domain controllers and Active Directory, ensure that jump servers are located in an OU to\r\nwhich the restrictive GPOs are not linked.\r\nAuditing should be configured to send alerts if any modifications are made to the properties or membership\r\nof the EA group. These alerts should be sent, at a minimum, to users or teams responsible for Active\r\nDirectory administration and incident response. You should also define processes and procedures for\r\ntemporarily populating the EA group, including notification procedures when legitimate population of the\r\ngroup is performed.\r\nAs is the case with the Enterprise Admins group, membership in Domain Admins groups should be required only\r\nin build or disaster-recovery scenarios. There should be no day-to-day user accounts in the DA group with the\r\nexception of the local Administrator account for the domain, if it has been secured as described in Appendix D:\r\nSecuring Built-In Administrator Accounts in Active Directory.\r\nWhen DA access is required, the accounts needing this level of access should be temporarily placed in the DA\r\ngroup for the domain in question. Although the users are using the highly privileged accounts, activities should be\r\naudited and preferably performed with one user performing the changes and another user observing the changes to\r\nminimize the likelihood of inadvertent misuse or misconfiguration. When the activities have been completed, the\r\naccounts should be removed from the Domain Admins group. This can be achieved via manual procedures and\r\ndocumented processes, via third-party privileged identity/access management (PIM/PAM) software, or a\r\ncombination of both. Guidelines for creating accounts that can be used to control the membership of privileged\r\ngroups in Active Directory are provided in Appendix I: Creating Management Accounts for Protected Accounts\r\nand Groups in Active Directory.\r\nDomain Admins are, by default, members of the local Administrators groups on all member servers and\r\nworkstations in their respective domains. This default nesting should not be modified because it affects\r\nsupportability and disaster recovery options. If Domain Admins groups have been removed from the local\r\nAdministrators groups on the member servers, they should be added to the Administrators group on each member\r\nserver and workstation in the domain via restricted group settings in linked GPOs. The following general controls,\r\nwhich are described in depth in Appendix F: Securing Domain Admins Groups in Active Directory should also be\r\nimplemented.\r\nFor the Domain Admins group in each domain in the forest:\r\n1. Remove all members from the DA group, with the possible exception of the built-in Administrator account\r\nfor the domain, provided it has been secured as described in Appendix D: Securing Built-In Administrator\r\nAccounts in Active Directory.\r\n2. In GPOs linked to OUs containing member servers and workstations in each domain, the DA group should\r\nbe added to the following user rights:\r\nDeny access to this computer from the network\r\nDeny log on as a batch job\r\nDeny log on as a service\r\nhttps://technet.microsoft.com/en-us/library/dn487450.aspx\r\nPage 8 of 15\n\nDeny log on locally\r\nDeny log on through Remote Desktop Services\r\nThis will prevent members of the DA group from logging on to member servers and workstations. If jump\r\nservers are used to administer domain controllers and Active Directory, ensure that jump servers are\r\nlocated in an OU to which the restrictive GPOs are not linked.\r\n3. Auditing should be configured to send alerts if any modifications are made to the properties or membership\r\nof the DA group. These alerts should be sent, at a minimum, to users or teams responsible for AD DS\r\nadministration and incident response. You should also define processes and procedures for temporarily\r\npopulating the DA group, including notification procedures when legitimate population of the group is\r\nperformed.\r\nAs is the case with the EA and DA groups, membership in the Administrators (BA) group should be required only\r\nin build or disaster-recovery scenarios. There should be no day-to-day user accounts in the Administrators group\r\nwith the exception of the local Administrator account for the domain, if it has been secured as described in\r\nAppendix D: Securing Built-In Administrator Accounts in Active Directory.\r\nWhen Administrators access is required, the accounts needing this level of access should be temporarily placed in\r\nthe Administrators group for the domain in question. Although the users are using the highly privileged accounts,\r\nactivities should be audited and, preferably, performed with a user performing the changes and another user\r\nobserving the changes to minimize the likelihood of inadvertent misuse or misconfiguration. When the activities\r\nhave been completed, the accounts should immediately be removed from the Administrators group. This can be\r\nachieved via manual procedures and documented processes, via third-party privileged identity/access management\r\n(PIM/PAM) software, or a combination of both.\r\nAdministrators are, by default, the owners of most of the AD DS objects in their respective domains. Membership\r\nin this group may be required in build and disaster recovery scenarios in which ownership or the ability to take\r\nownership of objects is required. Additionally, DAs and EAs inherit a number of their rights and permissions by\r\nvirtue of their default membership in the Administrators group. Default group nesting for privileged groups in\r\nActive Directory should not be modified, and each domain's Administrators group should be secured as described\r\nin Appendix G: Securing Administrators Groups in Active Directory, and in the general instructions below.\r\n1. Remove all members from the Administrators group, with the possible exception of the local Administrator\r\naccount for the domain, provided it has been secured as described in Appendix D: Securing Built-In\r\nAdministrator Accounts in Active Directory.\r\n2. Members of the domain's Administrators group should never need to log on to member servers or\r\nworkstations. In one or more GPOs linked to workstation and member server OUs in each domain, the\r\nAdministrators group should be added to the following user rights:\r\nDeny access to this computer from the network\r\nDeny log on as a batch job,\r\nDeny log on as a service\r\nhttps://technet.microsoft.com/en-us/library/dn487450.aspx\r\nPage 9 of 15\n\nThis will prevent members of the Administrators group from being used to log on or connect to\r\nmember servers or workstations (unless multiple controls are first breached), where their credentials\r\ncould be cached and thereby compromised. A privileged account should never be used to log on to a\r\nless-privileged system, and enforcing these controls affords protection against a number of attacks.\r\n3. At the domain controllers OU in each domain in the forest, the Administrators group should be granted the\r\nfollowing user rights (if they do not already have these rights), which will allow the members of the\r\nAdministrators group to perform functions necessary for a forest-wide disaster recovery scenario:\r\nAccess this computer from the network\r\nAllow log on locally\r\nAllow log on through Remote Desktop Services\r\n4. Auditing should be configured to send alerts if any modifications are made to the properties or membership\r\nof the Administrators group. These alerts should be sent, at a minimum, to members of the team\r\nresponsible for AD DS administration. Alerts should also be sent to members of the security team, and\r\nprocedures should be defined for modifying the membership of the Administrators group. Specifically,\r\nthese processes should include a procedure by which the security team is notified when the Administrators\r\ngroup is going to be modified so that when alerts are sent, they are expected and an alarm is not raised.\r\nAdditionally, processes to notify the security team when the use of the Administrators group has been\r\ncompleted and the accounts used have been removed from the group should be implemented.\r\nNote\r\nWhen you implement restrictions on the Administrators group in GPOs, Windows applies the settings to members\r\nof a computer's local Administrators group in addition to the domain's Administrators group. Therefore, you\r\nshould use caution when implementing restrictions on the Administrators group. Although prohibiting network,\r\nbatch and service logons for members of the Administrators group is advised wherever it is feasible to implement,\r\ndo not restrict local logons or logons through Remote Desktop Services. Blocking these logon types can block\r\nlegitimate administration of a computer by members of the local Administrators group. The following screenshot\r\nshows configuration settings that block misuse of built-in local and domain Administrator accounts, in addition to\r\nmisuse of built-in local or domain Administrators groups. Note that the Deny log on through Remote Desktop\r\nServices user right does not include the Administrators group, because including it in this setting would also block\r\nthese logons for accounts that are members of the local computer's Administrators group. If services on computers\r\nare configured to run in the context of any of the privileged groups described in this section, implementing these\r\nsettings can cause services and applications to fail. Therefore, as with all of the recommendations in this section,\r\nyou should thoroughly test settings for applicability in your environment.\r\nleast privilege admin models\r\nGenerally speaking, role-based access controls (RBAC) are a mechanism for grouping users and providing access\r\nto resources based on business rules. In the case of Active Directory, implementing RBAC for AD DS is the\r\nprocess of creating roles to which rights and permissions are delegated to allow members of the role to perform\r\nday-to-day administrative tasks without granting them excessive privilege. RBAC for Active Directory can be\r\ndesigned and implemented via native tooling and interfaces, by leveraging software you may already own, by\r\nhttps://technet.microsoft.com/en-us/library/dn487450.aspx\r\nPage 10 of 15\n\npurchasing third-party products, or any combination of these approaches. This section does not provide step-by-step instructions to implement RBAC for Active Directory, but instead discusses factors you should consider in\r\nchoosing an approach to implementing RBAC in your AD DS installations.\r\nIn the simplest RBAC implementation, you can implement roles as AD DS groups and delegate rights and\r\npermissions to the groups that allow them to perform daily administration within the designated scope of the role.\r\nIn some cases, existing security groups in Active Directory can be used to grant rights and permissions appropriate\r\nto a job function. For example, if specific employees in your IT organization are responsible for the management\r\nand maintenance of DNS zones and records, delegating those responsibilities can be as simple as creating an\r\naccount for each DNS administrator and adding it to the DNS Admins group in Active Directory. The DNS\r\nAdmins group, unlike more highly privileged groups, has few powerful rights across Active Directory, although\r\nmembers of this group have been delegated permissions that allow them to administer DNS and is still subject to\r\ncompromise and abuse could result in elevation of privilege.\r\nIn other cases, you may need to create security groups and delegate rights and permissions to Active Directory\r\nobjects, file system objects, and registry objects to allow members of the groups to perform designated\r\nadministrative tasks. For example, if your Help Desk operators are responsible for resetting forgotten passwords,\r\nassisting users with connectivity problems, and troubleshooting application settings, you may need to combine\r\ndelegation settings on user objects in Active Directory with privileges that allow Help Desk users to connect\r\nremotely to users' computers to view or modify the users' configuration settings. For each role you define, you\r\nshould identify:\r\n1. Which tasks members of the role perform on a day-to-day basis and which tasks are less frequently\r\nperformed.\r\n2. On which systems and in which applications members of a role should be granted rights and permissions.\r\n3. Which users should be granted membership in a role.\r\n4. How management of role memberships will be performed.\r\nIn many environments, manually creating role-based access controls for administration of an Active Directory\r\nenvironment can be challenging to implement and maintain. If you have clearly defined roles and responsibilities\r\nfor administration of your IT infrastructure, you may want to leverage additional tooling to assist you in creating a\r\nmanageable native RBAC deployment. For example, if Forefront Identity Manager (FIM) is in use in your\r\nenvironment, you can use FIM to automate the creation and population of administrative roles, which can ease\r\nongoing administration. If you use Microsoft Endpoint Configuration Manager and System Center Operations\r\nManager (SCOM), you can use application-specific roles to delegate management and monitoring functions, and\r\nalso enforce consistent configuration and auditing across systems in the domain. If you have implemented a public\r\nkey infrastructure (PKI), you can issue and require smart cards for IT staff responsible for administering the\r\nenvironment. With FIM Credential Management (FIM CM), you can even combine management of roles and\r\ncredentials for your administrative staff.\r\nIn other cases, it may be preferable for an organization to consider deploying third-party RBAC software that\r\nprovides \"out-of-box\" functionality. Commercial, off-the-shelf (COTS) solutions for RBAC for Active Directory,\r\nhttps://technet.microsoft.com/en-us/library/dn487450.aspx\r\nPage 11 of 15\n\nWindows, and non-Windows directories and operating systems are offered by a number of vendors. When\r\nchoosing between native solutions and third-party products, you should consider the following factors:\r\n1. Budget: By investing in development of RBAC using software and tools you may already own, you can\r\nreduce the software costs involved in deploying a solution. However, unless you have staff who are\r\nexperienced in creating and deploying native RBAC solutions, you may need to engage consulting\r\nresources to develop your solution. You should carefully weigh the anticipated costs for a custom-developed solution with the costs to deploy an \"out-of-box\" solution, particularly if your budget is limited.\r\n2. Composition of the IT environment: If your environment is comprised primarily of Windows systems, or if\r\nyou are already leveraging Active Directory for management of non-Windows systems and accounts,\r\ncustom native solutions may provide the optimal solution for your needs. If your infrastructure contains\r\nmany systems that are not running Windows and are not managed by Active Directory, you may need to\r\nconsider options for management of non-Windows systems separately from the Active Directory\r\nenvironment.\r\n3. Privilege model in the solution: If a product relies on placement of its service accounts into highly\r\nprivileged groups in Active Directory and does not offer options that do not require excessive privilege be\r\ngranted to the RBAC software, you have not really reduced your Active Directory attack surface you've\r\nonly changed the composition of the most privileged groups in the directory. Unless an application vendor\r\ncan provide controls for service accounts that minimize the probability of the accounts being compromised\r\nand maliciously used, you may want to consider other options.\r\nPrivileged identity management (PIM), sometimes referred to as privileged account management (PAM) or\r\nprivileged credential management (PCM) is the design, construction, and implementation of approaches to\r\nmanaging privileged accounts in your infrastructure. Generally speaking, PIM provides mechanisms by which\r\naccounts are granted temporary rights and permissions required to perform build-or-break fix functions, rather\r\nthan leaving privileges permanently attached to accounts. Whether PIM functionality is manually created or is\r\nimplemented via the deployment of third-party software one or more of the following features may be available:\r\nCredential \"vaults,\" where passwords for privileged accounts are \"checked out\" and assigned an initial\r\npassword, then \"checked in\" when activities have been completed, at which time passwords are again reset\r\non the accounts.\r\nTime-bound restrictions on the use of privileged credentials\r\nOne-time-use credentials\r\nWorkflow-generated granting of privilege with monitoring and reporting of activities performed and\r\nautomatic removal of privilege when activities are completed or allotted time has expired\r\nReplacement of hard-coded credentials such as user names and passwords in scripts with application\r\nprogramming interfaces (APIs) that allow credentials to be retrieved from vaults as needed\r\nAutomatic management of service account credentials\r\nOne of the challenges in managing privileged accounts is that, by default, the accounts that can manage privileged\r\nand protected accounts and groups are privileged and protected accounts. If you implement appropriate RBAC and\r\nPIM solutions for your Active Directory installation, the solutions may include approaches that allow you to\r\neffectively depopulate the membership of the most privileged groups in the directory, populating the groups only\r\ntemporarily and when needed.\r\nhttps://technet.microsoft.com/en-us/library/dn487450.aspx\r\nPage 12 of 15\n\nIf you implement native RBAC and PIM, however, you should consider creating accounts that have no privilege\r\nand with the only function of populating and depopulating privileged groups in Active Directory when needed.\r\nAppendix I: Creating Management Accounts for Protected Accounts and Groups in Active Directory provides\r\nstep-by-step instructions that you can use to create accounts for this purpose.\r\nLaw Number Six: There really is someone out there trying to guess your passwords. - 10 Immutable Laws of\r\nSecurity Administration\r\nPass-the-hash and other credential theft attacks are not specific to Windows operating systems, nor are they new.\r\nThe first pass-the-hash attack was created in 1997. Historically, however, these attacks required customized tools,\r\nwere hit-or-miss in their success, and required attackers to have a relatively high degree of skill. The introduction\r\nof freely available, easy-to-use tooling that natively extracts credentials has resulted in an exponential increase in\r\nthe number and success of credential theft attacks in recent years. However, credential theft attacks are by no\r\nmeans the only mechanisms by which credentials are targeted and compromised.\r\nAlthough you should implement controls to help protect you against credential theft attacks, you should also\r\nidentify the accounts in your environment that are most likely to be targeted by attackers, and implement robust\r\nauthentication controls for those accounts. If your most privileged accounts are using single factor authentication\r\nsuch as user names and passwords (both are \"something you know,\" which is one authentication factor), those\r\naccounts are weakly protected. All that an attacker needs is knowledge of the user name and knowledge of the\r\npassword associated with the account, and pass-the-hash attacks are not required the attacker can authenticate as\r\nthe user to any systems that accept single factor credentials.\r\nAlthough implementing multi-factor authentication does not protect you against pass-the-hash attacks,\r\nimplementing multi-factor authentication in combination with protected systems can. More information about\r\nimplementing protected systems is provided in Implementing Secure Administrative Hosts, and authentication\r\noptions are discussed in the following sections.\r\nIf you have not already implemented multi-factor authentication such as smart cards, consider doing so. Smart\r\ncards implement hardware-enforced protection of private keys in a public-private key pair, preventing a user's\r\nprivate key from being accessed or used unless the user presents the proper PIN, passcode, or biometric identifier\r\nto the smart card. Even if a user's PIN or passcode is intercepted by a keystroke logger on a compromised\r\ncomputer, for an attacker to reuse the PIN or passcode, the card must also be physically present.\r\nIn cases in which long, complex passwords have proven difficult to implement because of user resistance, smart\r\ncards provide a mechanism by which users may implement relatively simple PINs or passcodes without the\r\ncredentials being susceptible to brute force or rainbow table attacks. Smart card PINs are not stored in Active\r\nDirectory or in local SAM databases, although credential hashes may still be stored in LSASS protected memory\r\non computers on which smart cards have been used for authentication.\r\nAnother benefit of implementing smart cards or other certificate-based authentication mechanisms is the ability to\r\nleverage Authentication Mechanism Assurance to protect sensitive data that is accessible to VIP users.\r\nAuthentication Mechanism Assurance is available in domains in which the functional level is set to Windows\r\nServer 2012 or Windows Server 2008 R2. When it is enabled, Authentication Mechanism Assurance adds an\r\nhttps://technet.microsoft.com/en-us/library/dn487450.aspx\r\nPage 13 of 15\n\nadministrator-designated global group membership to a user's Kerberos token when the user's credentials are\r\nauthenticated during logon using a certificate-based logon method.\r\nThis makes it possible for resource administrators to control access to resources, such as files, folders, and\r\nprinters, based on whether the user logs on using a certificate-based logon method, in addition to the type of\r\ncertificate used. For example, when a user logs on by using a smart card, the user's access to resources on the\r\nnetwork can be specified as different from what the access is when the user does not use a smart card (that is,\r\nwhen the user logs on by entering a user name and password). For more information about Authentication\r\nMechanism Assurance, see the Authentication Mechanism Assurance for AD DS in Windows Server 2008 R2\r\nStep-by-Step Guide.\r\nIn Active Directory for all administrative accounts, enable the Require smart card for interactive logon\r\nattribute, and audit for changes to (at a minimum), any of the attributes on the Account tab for the account (for\r\nexample, cn, name, sAMAccountName, userPrincipalName, and userAccountControl) administrative user objects.\r\nAlthough setting the Require smart card for interactive logon on accounts resets the account's password to a\r\n120-character random value and requires smart cards for interactive logons, the attribute can still be overwritten\r\nby users with permissions that allow them to change passwords on the accounts, and the accounts can then be used\r\nto establish non-interactive logons with only user name and password.\r\nIn other cases, depending on the configuration of accounts in Active Directory and certificate settings in Active\r\nDirectory Certificate Services (AD CS) or a third-party PKI, User Principal Name (UPN) attributes for\r\nadministrative or VIP accounts can be targeted for a specific kind of attack, as described here.\r\nAlthough a thorough discussion of attacks against public key infrastructures (PKIs) is outside the scope of this\r\ndocument, attacks against public and private PKIs have increased exponentially since 2008. Breaches of public\r\nPKIs have been broadly publicized, but attacks against an organization's internal PKI are perhaps even more\r\nprolific. One such attack leverages Active Directory and certificates to allow an attacker to spoof the credentials of\r\nother accounts in a manner that can be difficult to detect.\r\nWhen a certificate is presented for authentication to a domain-joined system, the contents of the Subject or the\r\nSubject Alternative Name (SAN) attribute in the certificate are used to map the certificate to a user object in\r\nActive Directory. Depending on the type of certificate and how it is constructed, the Subject attribute in a\r\ncertificate typically contains a user's common name (CN), as shown in the following screenshot.\r\nScreenshot that shows the Subject attribute in a certificate typically contains a user's common name.\r\nBy default, Active Directory constructs a user's CN by concatenating the account's first name + \" \"+ last name.\r\nHowever, CN components of user objects in Active Directory are not required or guaranteed to be unique, and\r\nmoving a user account to a different location in the directory changes the account's distinguished name (DN),\r\nwhich is the full path to the object in the directory, as shown in the bottom pane of the previous screenshot.\r\nBecause certificate subject names are not guaranteed to be static or unique, the contents of the Subject Alternative\r\nName are often used to locate the user object in Active Directory. The SAN attribute for certificates issued to users\r\nfrom enterprise certification authorities (Active Directory integrated CAs) typically contains the user's UPN or\r\nhttps://technet.microsoft.com/en-us/library/dn487450.aspx\r\nPage 14 of 15\n\nemail address. Because UPNs are guaranteed to be unique in an AD DS forest, locating a user object by UPN is\r\ncommonly performed as part of authentication, with or without certificates involved in the authentication process.\r\nThe use of UPNs in SAN attributes in authentication certificates can be leveraged by attackers to obtain fraudulent\r\ncertificates. If an attacker has compromised an account that has the ability to read and write UPNs on user objects,\r\nthe attack is implemented as follows:\r\nThe UPN attribute on a user object (such as a VIP user) is temporarily changed to a different value. The SAM\r\naccount name attribute and CN can also be changed at this time, although this is usually not necessary for the\r\nreasons described earlier.\r\nWhen the UPN attribute on the target account has been changed, a stale, enabled user account or a freshly created\r\nuser account's UPN attribute is changed to the value that was originally assigned to the target account. Stale,\r\nenabled user accounts are accounts that have not logged on for long periods of time, but have not been disabled.\r\nThey are targeted by attackers who intend to \"hide in plain sight\" for the following reasons:\r\n1. Because the account is enabled, but hasn't been used recently, using the account is unlikely to trigger alerts\r\nthe way that enabling a disabled user account might.\r\n2. Use of an existing account doesn't require the creation of a new user account that might be noticed by\r\nadministrative staff.\r\n3. Stale user accounts that are still enabled are usually members of various security groups and are granted\r\naccess to resources on the network, simplifying access and \"blending in\" to an existing user population.\r\nThe user account on which the target UPN has now been configured is used to request one or more certificates\r\nfrom Active Directory Certificate Services.\r\nWhen certificates have been obtained for the attacker's account, the UPNs on the \"new\" account and the target\r\naccount are returned to their original values.\r\nThe attacker now has one or more certificates that can be presented for authentication to resources and\r\napplications as if the user is the VIP user whose account was temporarily modified. Although a full discussion of\r\nall of the ways in which certificates and PKI can be targeted by attackers is outside the scope of this document,\r\nthis attack mechanism is provided to illustrate why you should monitor privileged and VIP accounts in AD DS for\r\nchanges, particularly for changes to any of the attributes on the Account tab for the account (for example, cn,\r\nname, sAMAccountName, userPrincipalName, and userAccountControl). In addition to monitoring the accounts,\r\nyou should restrict who can modify the accounts to as small a set of administrative users as possible. Likewise, the\r\naccounts of administrative users should be protected and monitored for unauthorized changes.\r\nSource: https://technet.microsoft.com/en-us/library/dn487450.aspx\r\nhttps://technet.microsoft.com/en-us/library/dn487450.aspx\r\nPage 15 of 15",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://technet.microsoft.com/en-us/library/dn487450.aspx"
	],
	"report_names": [
		"dn487450.aspx"
	],
	"threat_actors": [],
	"ts_created_at": 1775441522,
	"ts_updated_at": 1775791324,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/d67cd49913b23aa039bd5b162c58f6988b733fb7.pdf",
		"text": "https://archive.orkl.eu/d67cd49913b23aa039bd5b162c58f6988b733fb7.txt",
		"img": "https://archive.orkl.eu/d67cd49913b23aa039bd5b162c58f6988b733fb7.jpg"
	}
}