Best practices for configuring security features in Windows Server have changed in recent years. We\u2019ve 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\u2019s harder for those older servers to deal with today\u2019s 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 accountOnce 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.\u00a0 \u00a0New advice: Use different admin passwordsInstead, I recommend that you don\u2019t 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)\u00a0to ensure that there is a random password assigned. While deploying it, don\u2019t forget that attackers know to review for users with \u201call 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 adminsDeny logon through Remote Desktop Services: local account, enterprise admins, domain adminsDeny logon locally: enterprise admins, domain admins2. Old advice: Disable guest accountsWindows 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\u2019t go far enough.New advice: Minimize the number of accounts with administrative rightsThe 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\u2019t 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 v1I 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 protocols2020 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\u00a0and\u00a0Group Managed Service Accounts\u00a0are a good method to ensure that service account passwords are long, complex and change regularly.4. Old advice: Don\u2019t store LM hashes on the serverIt\u2019s now the default that LM hashes are not stored on the server.New advice: Check for LM hashes stored on legacy locationsAudit 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 ageA policy of requiring employees to use longer passwords and change them regularly has long been considered a best practice.New advice: Enable multi-factor authenticationEmployees 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\u2019s or Google\u2019s authenticator app to set up MFA.6. Old advice: Turn on event logsTurning 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 toolsMicrosoft 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) enumerationOnce 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 harvestingNow 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\u2019ll want to review your past practices and ensure that passwords are not saved in Group Policy preferences, or tasks.\u00a0 A sensitive password left behind can be an easy way for attackers to gain access.\u00a0 Again, deploy LAPS as a best practice of handling passwords for network administration.8. Old advice: Don\u2019t allow an anonymous account in the everyone groupStarting 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 accountsAs you pivot to the cloud, review when you\u2019ve added guest accounts to resources and haven\u2019t removed them. Audit the use \u2014 and lack of clean up \u2014 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 accessAttackers 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\u2019s hard to mandate a list of specific applications. Tools such as AaronLocker work easier on systems without administrator rights.Don\u2019t overlook the basics. Microsoft\u2019s 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.