 G'day viewers, my name is Oren Thomas. I'm a principal hybrid cloud advocate at Microsoft. In this video, I'll cover the steps for securing the Active Directory Domain Services built in Administrator account. This advice is based on the documentation published online.microsoft.com at the link in this video's description. In each domain in an Active Directory forest, an Administrator account is created as part of the creation of the domain. This account is by default a member of the domain admins and administrators groups in the domain. If the domain is a forest root domain, the account is also a member of the enterprise admins group. This makes the account a tenting target for any attacker trying to compromise your organization's ADDS deployment. Use of the domain's administrator account should be reserved only for initial build activities and possibly disaster recovery scenarios. To ensure that an administrator account can be used to affect repairs in the event that no other accounts can be used, you should not change the default membership of the administrator account in any domain in the forest. Instead, you should secure the administrator account in each domain in the forest as described in this video. Some guides recommend disabling the account. You should consider the advice in this video about securing rather than disabling the account as this is the only account that allows ADDS logon without a global catalog server. Controls you should apply to the built-in administrator accounts. Enable the account is sensitive and cannot be delegated option on the account. Enable the smart card is required for interactive logon option on the account. You should also see GPOs to restrict the administrator accounts use on domain join systems. To do this, you should create and link a special GPO to workstation and member server OUs in each domain. Configure this GPO with the following user rights in located in the computer configuration policies. Windows settings, security settings, local policies, user rights assignments, section of the policy. Deny access to this computer from the network. Deny logon as a batch job. Deny logon as a service. Deny logon through remote desktop services. When you add accounts to this setting, you must specify whether you are configuring local administrator accounts or domain administrator accounts. For example, to add the tailspin toys domains administrator account to these deny rights, you must type the account as tailspin toys slash administrator or brass to the administrator account for the tailspin toys domain. A common mistake is just typing administrator in these user rights settings in the group policy object editor. If you do this, you will restrict the local administrator account on each computer to which the GPO is applied but not the built in domain administrator account. Microsoft recommends restricting local administrator accounts on member servers and workstations in the same manner as domain based administrator accounts. Therefore, you should generally add the administrator account for each domain in the forest and the administrator account for the local computers to these user rights settings. These settings will ensure that the domains built in administrator account cannot be used to remotely connect to a domain controller, although the account can log on locally to domain controllers because this account should only be used in disaster recovery scenarios. You need to ensure that physical access to at least one domain controller will be available or that other accounts with the missions to access domain controllers remotely can be used. This access could include logging on directly to a server from a virtualization host that hosts the domain controller through virtual machine connection. The screenshot displayed shows an example of configuring these user rights to block local administrator accounts and a domain's administrator account from performing logons that should not be needed for these accounts. When each domain's administrator account is secure, you should configure auditing to monitor for usage of or changes to the account. If the account is signed into, its password is reset or any other modifications are made to the account, alerts should be sent to the users or teams responsible for administration of active directory in addition to incident response teams in your organization. To do this, you should configure the following auditing policies under computer configuration, window settings, security settings, advanced audit policy configuration, audit policies, audit logon events, success and failure, audit account management, success and failure. Use event log forwarding or log collection software to ensure that the event log data that records this auditing information is not stored on ADDS domain controllers. In this video, you learned about steps you can take to secure the built-in domain administrator account that is created by default in each domain in an active directory forest. The advice in this video is drawn from the article linked in the video description. Increasing the security controls applied to the built-in administrator account will improve your overall ADDS security posture that will not make your systems invulnerable. The built-in administrator account should be considered an option of last resort to disaster recovery scenarios and should not be used for day-to-day active directory operations. Security is always a matter of balancing what can be pragmatically accomplished by administrators in day-to-day operations with an assumed breach philosophy. We are interested in hearing about your experiences as an ADDS administrator. Have you implemented any of the security controls outlined in this video in your environment? What steps do you take in your own active directory domain services environment to secure the built-in administrator account? Have you disabled the domain built-in administrator account entirely? I hope you found this video useful and informative. My name is Oren Thomas. You can find me at aka.ms slash oren. And if you've got any questions or feedback, drop a comment below.