The 9 Windows Server security settings you need to get right

Best practices for configuring security features in Windows Server have changed in recent years. We’ve just said (official) good-bye to Windows Server 2008 R2, and we should be getting ready to say good-bye to Server 2012 R2 as support ends in three years. It’s harder for those older servers to deal with today’s threats, such as new ways to gain access through tampering with and spoofing code-signing certs.

Here are nine security settings that no longer have the same impact, depending on what server or cloud platform you are using, and the settings or policies you should be using in addition to them or in their place.

1. Old advice: Rename the administrator account

Once upon a time, the main guidance was renaming the administrator account. This was even made into a wizard process on some server platforms. A few years ago, attackers would go after account names, and if you renamed the administrator account to something else, you would make it harder for attackers. Today, renaming the administrator account is no longer as impactful because attackers can use phishing and harvesting of credentials left behind on systems to gain a toe-hold into your system.   

New advice: Use different admin passwords Instead, I recommend that you don’t use the same local administrator password across your network. Want to make it easy for ransomware attackers to perform lateral movement in your network? Use the same password on each workstation. You should deploy the Local Administrators Password Solution (LAPS) to ensure that there is a random password assigned. While deploying it, don’t forget that attackers know to review for users with “all extended rights” that can view passwords and all computers with LAPS enabled.

Configure Group Policy to prevent local administrator accounts from authenticating over the network. The following Group Policy objects (GPOs) are recommended:

• Deny access to this computer from the network: local account, enterprise admins, domain admins
• Deny logon through Remote Desktop Services: local account, enterprise admins, domain admins
• Deny logon locally: enterprise admins, domain admins

2. Old advice: Disable guest accounts

Windows once shipped operating systems with the guest account enabled. Now Windows 10 goes so far to urge you not to install an account with administrative rights. The main administrator account is also disabled. So, disabling guest accounts is still good advice, but it doesn’t go far enough.

New advice: Minimize the number of accounts with administrative rights The question you should ask is can you deploy machines without elevating rights to deploy or install software. Chrome has led the way of not needing administrator rights by installing in the user’s “Application Data” folder. Windows user rights have long been abused by both users and attackers. Never give anyone rights to guest accounts in a domain and don’t recommend the use of guest accounts in home networks as well. Users sharing resources even in home networks should be set up explicitly to have rights on each resource.

3. Old advice: Stop using LAN Manager and NTLM v1

I hope you are no longer using LAN Manager (LM) or NTLMv1 authentication as they have known security vulnerabilities. This is another case where the advice is still valid, but you need to look beyond it.

New advice: Review all network protocols 2020 should be the year that you review protocols used in your network. Go a step further and review for the use of SMBv1 and disable that as well if you can. In March 2020, Microsoft will implement LDAP channel binding and LDAP signing. Review your network for unsigned LDAP and SMBv1 and and remove them from your network.

You should also worry about Kerberos Ticket Granting Server (TGS) service ticket offline cracking (Kerberoast) and mitigate this risk by having service account passwords longer than 25 characters. Managed Service Accounts and Group Managed Service Accounts are a good method to ensure that service account passwords are long, complex and change regularly.

4. Old advice: Don’t store LM hashes on the server

It’s now the default that LM hashes are not stored on the server.

New advice: Check for LM hashes stored on legacy locations Audit to find any LM hashes left behind in legacy locations by reviewing Active Directory (AD). Using a PowerShell tool, you can scan and check all accounts in your AD Forest and review for account and password hygiene.

5. Old advice: Enforce a minimum password length and maximum password age

A policy of requiring employees to use longer passwords and change them regularly has long been considered a best practice.

New advice: Enable multi-factor authentication Employees hate to choose and change passwords, which makes a policy of minimum password length and maximum password age difficult to enforce. Forcing people to change passwords means that they will choose lesser passwords that are more easily guessed. Enabling multi-factor authentication (MFA) on all accounts makes it harder for attacker to leverage compromised passwords. You can use either Microsoft’s or Google’s authenticator app to set up MFA.

6. Old advice: Turn on event logs

Turning on and regularly checking event logs is still a good way to detect malicious network activity.

New advice: Take advantage of newer Microsoft event logging tools Microsoft recently introduced a new online tool to consolidate and track events called Azure Sentinel. Even without adding that product to your cloud arsenal, other new logging capabilities range from System Monitor (Sysmon) to Windows Defender Advanced Threat Protection (ATP), which is also available for servers and in preview for Azure Virtual Machines (VMs).

7. Old advice: Disable anonymous security identifier (SID) enumeration

Once upon a time any user could query AD for SIDs that are assigned to users, groups and other security subjects. Microsoft disabled this enumeration.

New advice: Review your network for harvesting Now attackers can use social media locations to obtain usernames, and from there use phishing attacks to gain access to a domain user. From there they can launch attacks to pivot from domain users to domain admins by harvesting passwords left behind in the system volume (SYSVOL) folder and Group Policy preferences. You’ll want to review your past practices and ensure that passwords are not saved in Group Policy preferences, or tasks.  A sensitive password left behind can be an easy way for attackers to gain access.  Again, deploy LAPS as a best practice of handling passwords for network administration.

8. Old advice: Don’t allow an anonymous account in the everyone group

Starting in 2000, Microsoft removed the anonymous account from the everyone group. Assigning the anonymous account was easy to do and made everything work for applications. It also made it easier for attackers.

New advice: Audit for and remove guest accounts As you pivot to the cloud, review when you’ve added guest accounts to resources and haven’t removed them. Audit the use — and lack of clean up — of guest accounts in Microsoft Office 365.

9. Old advice: Enable User Account Control (UAC)

UAC gives non-administrators some administrative rights in a safe manner. It was introduced in Windows 7 because developers demanded administrator rights and is now enabled by default.

New advice: Whitelist applications, block local account access Attackers are now used to not having administrator rights available and use other means to gain higher privileges. Once they gain admin rights, attackers have many more ways to avoid detection and remain persistent on a system.

So, how do you stop them? Application whitelisting will help prevent attackers from using unauthorized executables on the network, but for many organizations, it’s hard to mandate a list of specific applications. Tools such as AaronLocker work easier on systems without administrator rights.

Don’t overlook the basics. Microsoft’s Windows security baselines recommend denying network logon to local accounts and thus blocking the threat of lateral movement through them. Attackers are getting smarter, so we need to get smarter in defending our networks.