- AccessChk: View effective permissions on files and folders - Thu, Apr 13 2023
- Read NTFS permissions: View read, write, and deny access information with AccessEnum - Wed, Mar 29 2023
- Kill Windows a process with Tskill and Taskkill - Mon, Mar 13 2023
Security policy settings control various aspects of system protection, as explained in my post User rights assignment in Windows Server 2016. Settings available in Security Options allow you to configure things related to user accounts, interactive logon, network access, network security, and the UAC feature. Today, I will cover settings related to interactive user behavior and built-in accounts. You should add these to your security baseline group policies and apply them on all computers.
Each setting uses the following format:
Name of the setting—Recommended value or values
Accounts
Accounts: Administrator account status—Disabled
The built-in Administrator account is often a target of attackers because it is a well-known account with complete control of the system. Furthermore, the account lockout policy does not apply to this account, so brute-force attacks will not lock it. Despite the fact you can rename the account with the Accounts: Rename administrator account setting, the recommended approach is to disable this account. Enumerating user account names is one of the first steps attackers undertake.
Note that in case of issues like a broken domain trust, you will need to reboot the system to safe mode, where the account is always enabled, or have another local account with administrator privileges available.
Accounts: Block Microsoft accounts—Users can't add or log on with Microsoft accounts
Users should be able to use only accounts your organization provides. This option will prevent access to Microsoft online accounts.
Accounts: Guest account status—Disabled
Even though the Guest account has no rights by default, it is a best practice to disable it completely and rename it with the Accounts: Rename guest account option.
TIP: Renaming the Guest account to Administrator is a good trick on attackers—they think they are trying to hack the Administrator account, but in reality, they are hacking an account with no permissions. This may slow down an attack.
Accounts: Limit local account use of blank passwords to console logon only—Enabled
There may be some leftover local accounts with no passwords, which is far from secure. Enabling this setting ensures no one can use such accounts for Remote Desktop Protocol (RDP) connections or network access to a share. Physical access to the keyboard (or VMware console) is required to use such accounts.
Settings related to built in accounts
Interactive logon
Interactive logon: Do not display last user name—Disabled
Normally, when Windows boots up, it shows the username of the last logged-on user. The username is sensitive information. An attacker could use it to discover your naming convention and then guess other usernames.
Interactive logon: Do not require CTRL+ALT+DEL—Disabled
This well-known key combination prevents exploits that present users with a fake logon screen, capturing entered credentials.
Interactive logon: Number of previous logons to cache (in case domain controller is not available)—2
Cached logons are stored on the local filesystem. If an attacker gains access to the filesystem, he can also find these cached logons. It is not very common that a domain-joined server can't reach domain controllers to authenticate a user.
Interactive logon: Require Domain Controller authentication to unlock workstation—Enabled
Enabling this setting ensures that changes to user accounts apply to users already logged on. For example, disabling a user account means no one can use it any longer to unlock a previously logged-on session. If you are working offline, this setting is not applied.
User Account Control
User Account Control: Admin Approval Mode for the Built-in Administrator account—Enabled
User Account Control: Run all administrators in Admin Approval Mode—Enabled
These two settings control whether UAC is enabled or not. By default, the first option is set to disabled; if you are logged on as Administrator, everything is running with elevated privileges. It is a best practice to enable UAC for the Administrator account also.
User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode—Prompt for consent on the secure desktop
User Account Control: Switch to the secure desktop when prompting for elevation—Enabled
User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop—Disabled
Configuring all three settings as above ensures that the system will always switch to the secure desktop (a dimmed screen with a prompt). Malware can spoof a standard elevation prompt—once you enter your elevated credentials, the attacker has them.
Secure desktop prompt
User Account Control: Detect application installations and prompt for elevation—Enabled
Some malware may look like a trusted program. When you permit it, it will try to install the malicious code. Enabling this setting will display another prompt, allowing you to mitigate damage.
User Account Control: Behavior of the elevation prompt for standard users—Automatically deny elevation requests
When a standard user attempts to install software with this setting, the system will automatically deny the request, showing an error message that it has blocked the installation. It requires installing the software under an account with administrator privileges or using the Run as Administrator option.
Subscribe to 4sysops newsletter!
Error message for a standard user
Wrap-up
As you can see, many security settings are available in Windows Server 2016. A clean installation leaves many of them not configured for high security. I highly recommend changing them, especially those related to built-in accounts and the UAC feature. By doing so, you are making your server more secure.
