The concept of zero trust is that nothing should be trusted by default. Most of us are trying to work our way to zero trust but are not there yet. Until then, you can take steps to protect your networks better, starting with handling passwords better in your domain. Here are some tips:
Use Microsoft’s LAPS toolkit
By now I hope everyone has deployed Microsoft’s Local Administrator Password Solution (LAPS) toolkit. It should be the starting point for any organization. As the download instructions note:
“[LAPS] mitigates the risk of lateral escalation that results when customers use the same administrative local account and password combination on their computers. LAPS stores the password for each computer’s local administrator account in Active Directory, secured in a confidential attribute in the computer’s corresponding Active Directory object. The computer is allowed to update its own password data in Active Directory, and domain administrators can grant read access to authorized users or groups, such as workstation helpdesk administrators.”
For anyone moving to non-domain joined machines or cloud virtual machines, the Azure marketplace has several options for deploying a unique local administrator password for Intune-joined machines. The first is LAPS with Intune by Synergix Labs, LAPS for Azure also by Synergix Labs, and Admin Password Manager for Enterprise by GreyCorbel Solutions. Any of these solutions ensure that as you move assets to the cloud, the local administrator password will not be an easy entry point for an attacker.
Manage separation of duties
Another concept you should consider is separation of duties. Even in a small organization or one controlled by a managed service provider, your domain administrator users should be restricted in use of day-to-day operations and should demand and require two-factor tokens to perform their duties. Domain administrators should not manage normal servers and certainly not workstations. You want to ensure that no hash values are left behind on a lowly laptop. The same should be true for workstation administrators; the tasks should be kept separate.
Review password policy
Next, review your password policy. Once upon a time we would set our password policies with the intention of making our users change their passwords on a regular basis. Now the recommended password policy is exactly opposite: Passwords are not changed as it triggers users to pick less than secure passwords. The NIST guidance is mandatory for federal entities but something all of us should strive for.
NIST mandates that passwords have a minimum of eight characters, preferably more. Users should be able to make passwords up to 64 characters. It’s a wise practice to ensure that your users’ passwords are not reused in other locations. The US Federal Trade Commission took action against the tax preparation site TaxSlayer to mandate that they compare the passwords of users in their database against hacked passwords and remind the users to not reuse passwords. Another mandate that the NIST recommends is that you allow all ASCII/Unicode characters, including emojis and spaces, and that you do not allow users to use sequential numbers (1234) or multiple characters in a row (AAAA).
Account lockout used to be a best practice. Now it’s recommended to allow a user to have ten tries before lockout. You may also wish to put geofencing around a log in. For example, if a user only logs in from the United States, you can put an Azure or Firewall limitation such that any access from an IP address outside of the US is blocked.
Surprisingly, NIST recommends that you do not allow password hints or knowledge-based password reset techniques that use information that would be readily available. I am reminded of the number of times high profile people’s emails have been hacked because they used a reset reminder such as “Where did you go to high school” that was documented in Wikipedia.
Use an app-based authentication process
NIST also recommends that you do not use SMS-based text messaging for two-factor authentication (2FA) and instead use an app-based authentication process. There are many horror stories where SIM swapping was used to spoof the phone number and allow an attacker to take over an account. As many have said, any 2FA is better than no 2FA, so don’t block SMS-based text messaging if the alternative is no 2FA.
How to review your domain password policy
If you haven’t reviewed your organization’s domain password policy, use the following PowerShell command:
Get-ADDefaultDomainPasswordPolicy
Review the settings that you see in the resulting window shown below.
Susan BradleyIf you haven’t revisited your password policy in years, you might find that your settings are woefully out of date. You can use Group Policy in an Active Directory domain to set the password settings accordingly: Computer Configuration\Policies\Windows Settings\Security Settings\Account Policies\Password Policy.
Since Windows 10 1903, Microsoft has recommended the following settings:
- Enforce Password History: 24
- Maximum password age: not set
- Minimum password age: not set
- Minimum password length: 14
- Password must meet complexity: Enabled
- Store passwords using reversible encryption: Disabled
“Enforce password history” defines how many unique passwords must be used before an old password can be reused. Maximum and minimum password age is now recommended to not be set as forcing password changes encourages users to pick less secure passwords. Rather look to adding 2FA, biometric authentication, Windows Hello, or other password-less options.
If you need unique policies in your domain, I recommend setting up fine-grained password policies. Of course, you can also set the password policies using Intune’s settings.