How to setup User Account Administration of Windows 10 and Windows 11?

In this article, we will cover the concepts and technologies that enable the secure and productive use of the Windows 10 operating system as well as the advanced options available to secure the user account credentials and prevent unauthorized system configuration changes and software installation.
We will explore the following topics:

• Windows account types
• Account privileges
• Local Administrator Password Solution
• Creating policies to control local accounts
• Managing user sign in options
• Exploring security settings available with Mobile device management (MDM)
• User Account Control
• Windows Hello for Business
• Credential Guard
• Privileged Access Workstation

Windows account types

The Windows 10 operating system supports five types of accounts, each used to enable different functionality:

• System account: These accounts are used to run background services and are assigned specific permissions. They are not used to log in to the system, but may be used remotely. Domain-joined computers may have additional service accounts assigned to enable central administration.
• Local user account: By default, at least one local user account is created to run as the local administrator when first configuring the operating system. Depending on how Windows is installed, this account may be a generic account, such as administrator, or it could be named after the first user that completes the first-time run wizard and they choose not to register a Microsoft account. These accounts are governed by the local password policies, which can be configured via Group Policy, or a device/application management service, such as Microsoft Intune.
• Microsoft account: If the computer is not domain joined, the user can register their Microsoft account (such as @outlook.com) as their local user account. In this configuration, all user settings are synchronized with the Microsoft cloud to provide a seamless transition between multiple computers, or when rebuilding the computer. Microsoft accounts can coexist with local user accounts and Azure Active Directory (AD) accounts.
• Azure AD user account: This account type has the user's corporate credentials stored in Azure AD, such as an Office 365 user. This logon method can be enabled in one of two scenarios:
• If the computer account is joined to Azure AD (also known as workplace join), then the user can sign in with their corporate credentials in Azure AD.
• If the computer account is not joined to Azure AD, the user can sign in with either a local user account or a Microsoft account and then link their Azure AD account using the Connect to work or school option. When this is done, the user will be able to store their credentials securely to enable single sign-on (SSO) to company applications, such as Office 365.
• Windows Server AD user account: The majority of Windows 10 Enterprise computers are likely to be joined to a Windows server AD domain. When this occurs, the Microsoft account and Azure AD user account options are disabled. However, the AD user account can be automatically linked to the Azure AD user account, to enable SSO when the user is not on the corporate network.

Account privileges

Each account can be assigned a range of specific privileges, from a standard user account (with no systems access) to a full local administrator account.
Gaining access to administrative rights on the Windows operating system is one of the key attack vectors that needs to be prevented in every organization, and even personal PCs. Administrative rights are required when changing configurations or installing software, both of which should not be carried out by users, and therefore all user accounts should be restricted to standard user accounts only.
Where there is genuine need for a user to be granted local admin rights on a computer, they should never be assigned to the user's main account that they use for gaining access to email, documents, and websites. This leads to the potential for a user to open a document, or click on a hyperlink, that contains malware. A better design approach is to create a local user account specific to this user and provide them with the password to the account.
This way, when the user needs to make a change or install software, they can enter the local admin user ID and password into the User Account Control (UAC) prompt.
For AD domain-joined computers, the local administrator accounts should not share the same user ID and password. While this may make life easier for the support teams, it allows malware to rapidly spread across the network, infecting every machine it can reach. There are several practices that can help reduce this risk:

• Disable the default local administrator account (due to a well-known security identifier (SID))
• Create a new local administrator account and control the password using Local Administrator Password Solution (LAPS) (discussed in the next session)
• Prevent local accounts from using network resources
• Provide local admin rights using group membership (administrators)

Domain-joined computers will have specific domain accounts added to the local permissions on every PC, such as the local administrators group. This allows IT administrators and management systems to connect remotely to help support and configure the computers. IT administrators should not log on to any computers with domain-level privileged accounts (such as domain admin); this is one of the most well-known methods of gaining domainwide permissions through pass-the-hash attacks (list others). Instead, they should carry out their work via PowerShell remotely, and if they need to log in interactively they should take over the user's session and use the Run as administrator option (obtain the current unique password for the local administrator account first using LAPS).

Local Admin Password Solution

If a single password is configured for the local admin accounts across all domain-joined computers, there is a high risk that it can be used in a widespread attack to install malware, elevate privileges, or gain access to sensitive files. To resolve this issue, Microsoft offers the Local Admin Password Solution (LAPS). This works by setting a different random password on every computer in the domain and storing that password in AD. Administrators can choose who can access those passwords in order to support the PCs.
The solution is built into AD and doesn't require any other supporting technologies or licenses. LAPS uses the Group Policy client-side extension (CSE) that you install on managed computers to perform all management tasks. The solution's management tools provide easy configuration and administration.
At the next Group Policy refresh, the passwords are changed. Authorized administrators can then use the LAPS UI tool to search individual computers to retrieve the password and/or change the expiry date for the next password change:

Create policies to control local accounts

If you enable local admin accounts, for users that require them, you should
also enforce a set of policies to ensure the local accounts have strong
authentication standards. On domain joined computers, Group Policy can be
used to specify the settings of the local account policy, which contains two
subsets:

• Password Policy: These policy settings determine the controls for local account passwords, such as enforcement and lifetimes
• Account Lockout Policy: These policy settings determine the circumstances and length of time for which an account will be locked out of the system when the password is entered incorrectly

Password policy

The password policy enforces specific values that control how often the password is changed, how complex it is, and whether users can reuse old passwords. The default values are shown in the following screenshot:

You may want to configure this policy to be more restrictive than the domain-level password policy.

Account lockout policy

If an attacker attempts to guess the password of a local administrative account, the lockout policy will slow down their attempts by enforcing further restrictions on the number of attempts that can be made in a set time period. This, combined with the increased complexity of the password, should make it very difficult for a successful attack to take place before the account password expires. The default values are shown in the following screenshot:

In summary, the preceding configuration will allow an attacker to make no more than 15 bad password attempts in every 24 hours; if they do, the account is locked for one hour every time a subsequent bad attempt is made. This increases the usability for a genuine user who may make several bad attempts (but not 15) without locking them out unnecessarily, while also making it extremely difficult for a brute force attack to be achieved before the password is changed again.

Manage user sign in options

Windows 10 Enterprise offers a range of configurable options to manage the account logon process. Some of the features are designed to increase security, others are to improve the user experience.
As you consider the appropriate configuration of the settings for your environment, ensure you find the right balance between usability, privacy, and security. Options that prevent the user having to enter their password at each login can lead to increased security by removing the temptation for the user to write down their password, or make it so simple that it's easy to guess. Encourage users to adopt these new login methods, along with creating more complex passwords of 12 or more characters as they will not have to enter it every day.
IT administrators need to take special care of where they log in, as compromised credentials can lead to devastating attacks by a malicious user. For great guidance on how to mitigate this risk, see the section on Privileged Access Workstation (PAW) later in this Article.

User Account Control

UAC is a fundamental security control that helps mitigate the impact of malware, yet some enterprise administrators disable User Account Control (UAC) at the request of the users, because it is seen as annoying and unnecessary prompts that get in the way of productivity. The feature has improved greatly since it was first launched (as part of Windows Vista), so we encourage you to ensure this is enabled across all managed computers in your environment.
With UAC enabled, Windows 10 prompts for consent, or prompts for credentials of a valid local administrator account, before starting a program or task that requires a full administrator access token. This prompt ensures that no malicious software can be silently installed.
If the user is logged on with local admin rights (which is not recommended), the consent prompt is presented when a user attempts to perform a task that requires a user's administrative access token. The following is an example of the UAC consent prompt you will see if you have local admin rights:

Alternatively, the credential prompt is presented when a standard user attempts to perform a task that requires administrative access, such as installing software or making a system configuration change (both potential
signs of malware). Administrators can also be required to provide their credentials by setting the User Account Control: Behaviour of the elevation prompt for administrators in Admin Approval Mode policy setting value to Prompt for credentials. The following is an example of the UAC credential prompt:

Windows Hello for Business

Passwords are renowned as one of the main causes for weak security in most computer systems. Passwords may be reused across multiple systems (including social networks and weak websites), they may be created based on guessable information that can be socially engineered or cracked using specialized software, or most likely stored in a database that is then compromised and shared across the cyber criminal community. So no matter how well we educate users to create more complex passwords that are changed frequently, there is always going to be a risk of compromise of the password, which can then be used to gain access to systems, impersonating a valid user.
The best defense against this type of risk is to deploy multi-factor authentication (MFA) mechanisms: a method of authentication that requires the user to provide more than just a password to gain authorized access to a system. Deploying MFA solutions has been something only the most secure companies would have considered, or been able to afford, to deploy. Apart from the cost to purchase, deploy, and maintain the solutions, there is also a considerable amount of user training involved, and the potential lost productivity.
Windows Hello for Business combines and simplifies the deployment and management of Microsoft Passport and Windows Hello. It is designed to eliminate the use of passwords as the primary authentication method, replacing them with a range of alternative, more secure options. Users are prompted to configure this solution when they log on to a Windows 10 computer for the first time. To use this feature, users create a devicespecific gesture, such as a PIN number or biometric entry, which then unlocks the device and its TPM. The TPM protects a private key that is used to sign authentication requests for credentials, instead of a password.
To make the login process easier for the user, they are initially prompted to sign in with the simplest gestures, such as facial recognition or fingerprints.
If for some reason this attempt fails, the user can fall back to using their unique PIN number. These methods are more secure than a single password because of the way they present a second factor of authentication: access to the physical device used in the initial gesture registration. An attacker cannot simply obtain their password, they must also gain physical access to the device used to log on in order to provide the second factor.

Manage options for Windows Hello for Business

We recommend enabling this feature across all managed computers, but you must consider the user education that is required: if the user is able to set a simple PIN number to gain access to their device, this may reduce the security compared to a complex password. While the PIN is unique to the device, some users may still use the same PIN on each device.
Users can manage their own sign in preferences by going to Start | Settings | Accounts | Sign-in options, and select the options you prefer.
Administrators can also control the configuration of this feature via Group Policy, or using Microsoft Intune. By default, the PIN option may be disabled on all domain-joined devices.

Credential Guard

Credential Guard is unique to Windows 10 Enterprise and Windows Server 2016, and designed to protect against OS-level attempts to read credentials. It uses hardware and virtualization-based security to isolate secrets so that only privileged system software can access them. Credential Guard protects NTLM password hashes, Kerberos Ticket-Granting Tickets, and credentials stored by applications.
Usually, Windows stores secrets in the Local Security Authority (LSA), in process memory. With Credential Guard enabled, the LSA process in the operating system talks to a new component called the isolated LSA process that stores and protects those secrets. Data stored by the isolated LSA process is protected using virtualization-based security and is not accessible to the rest of the operating system. You can consider the isolated LSA as running like a small virtual machine that only the LSA can communicate with, using remote procedure calls.
To enable this feature, the computers must meet specific hardware, firmware, and software requirements. Also, be aware that due to the restrictions necessary to secure the credentials, some applications will not be compatible, especially those that require the following authentication methods:

• NTLMv1
• MS-CHAPv2
• Digest
• CredSSP

Applications will also break if they require:

• Kerberos DES encryption support
• Kerberos unconstrained delegation
• Extracting the Kerberos TGT

We recommended this solution be enabled due to the advanced protection it can provide against local attacks on workstations. Any applications that are not compatible should be replaced with more secure options.
You can use Group Policy to enable Credential Guard. This will add and enable the virtualization-based security features for you if needed:
1. From the Group Policy Management Console (GPMC), go to Computer Configuration | Administrative Templates | System | Device Guard.
2. Double-click Turn On Virtualization Based Security, and then click on the Enabled option.
3. In Select Platform Security Level option, choose Secure Boot and DMA Protection.
4. In the Credential Guard Configuration option, click on Enabled with UEFI lock, and then click on OK. If you want to be able to turn off Credential Guard remotely, choose Enabled without lock.

5. Close the Group Policy Management Console.
Source URL: https://docs.microsoft.com/en-us/windows/access-protection/credential-guard/credential-guard-manage.

Privileged Access Workstation

If you really want to take security seriously, then you need to provide the highest levels of security for your privileged accounts, to prevent malicious behavior through compromised access. Microsoft has developed a complete set of guidance material on how to configure specific workstations used by administrators, and other privileged accounts, to carry out sensitive tasks such as systems administration and high-value financial transactions.
In this model, the computers are designated specifically for privileged access, blocking any other accounts from logging on interactively or via the network. Instead of logging on to the computer as a standard user and elevating privileges to gain access to sensitive information and systems, the user logs onto the PAW computer directly with the privileged account and carries out the tasks required.
This system works by preventing the usual risky behaviors occurring on a computer, such as internet browsing, opening emails and attachments, or running unsanctioned programs. By locking down the computer to only run verified and trusted applications and only allowing a minimal set of trusted accounts to gain access, the computer remains as secure as possible. Other systems can then be configured to only allow administrators to log in if the request originates from a PAW computer, and deny all other administrative logon attempts.
The guide provides a phased approach to deployment, ensuring you can quickly gain the benefits and protect most critical accounts: domain administrators. Once that level of protection is in place, you can extend to other privileged accounts and configure security for administering cloud services, such as Office 365 and Azure.

Summary

Windows 10 Enterprise provides the tools required to provide a secure environment to access sensitive and valuable information and systems.
There are many options to consider when creating and securing local user accounts that will gain authorized access to your systems. The most important factors are:

• Never log in to computers with local admin rights enabled, use run-as to elevate rights with a separate administrative account
• Never log in to a client computer with domain-privileged accounts, limit logging on to trusted IT PCs only, such as PAW
• Ensure all administrative account passwords are unique across computers, complex, and changed regularly.