Best practice guide for rolling out Specops Password Policy

Rolling out a new password policy without a plan is a recipe for disaster. You want to avoid a situation where all end users are prompted to change their passwords at the exact same time – triggering chaos for your service desk or IT team. Every organization is different, but Specops Senior Product Manager, Darren James, has shared the best practices he’d recommend to anyone planning to transition to Specops Password Policy.  

The ultimate aim of a password policy roll-out is that everyone should change their password to one that conforms to the new policy – and isn’t currently a known breached password. However, there are a few things to consider before arriving there that we’ll cover in this post: 

• Are you going to have more than one password policy? 
• Do you want to handle users with known breached passwords before the roll-out? 
• Are you working to a specific timeframe – do expiry dates need adjusting? 
• Where are your users located and what devices do they generally use? 
• Do you have a self-service password reset system? 

If you’re looking for some general advice on creating a new password policy, there are some best practice tips here. Or start here if you’re looking for advice on specifically creating a NIST 800-63b compliant password policy. But if you’ve got those bases covered and are ready to implement Specops Password Policy, read on for practical tips on rolling out the solution to your user base.  

Managing more than one policy  

It’s common for organizations to need more than one password policy.  For example, you might want different policies for standard end users, admins, and service accounts. Some may need to fall under a specific regulation such as PCI or HIPAA. So, after crafting your policies, you need to make sure that you can apply them to the right users.  

As we use Group Policy, we can do this either by linking the Group Policy Objects (GPOs) to an Organizational Unit (OU). From there, you can use security filtering as well as GPO precedence. For example, you may have multiple types of user in the same OU, but then use security filtering and/or GPO precedence to make sure the right policy is applying to the right user. If you don’t want the policies to apply immediately, you can create GPOs and then disable the links. 

Finding breached passwords 

Do you want to handle known breached passwords within your Active Directory before rolling out Specops Password Policy? A quick win to reduce your risk is to use the Specops Password Auditor breached password report to highlight your users that are already using known breached passwords. These users are usually a good option to choose for your pilot group for the roll-out, because you’ll get feedback about your new policies from the people that will be impacted most.  

It’s important to also use this group to test your end user guidance approach. Remember to keep things simple and easy to understand. If they’re moving from a short complex password policy (e.g. eight characters with a mix of numbers, lower case, upper case, and a special character) to a simpler but longer passphrase, this will be somewhat of a culture shock and different to policies they’ve had to follow in the past.  

Keep in mind too that Specops Password Auditor will only use a fraction (1 billion unique compromised passwords) of the Complete Specops database (over 4 billion unique compromised passwords). But the benefit of the audit is it only takes a few moments to run. 

Alternatively, you can also use the Continuous Scanning feature of Specops Password Policy with Breached Password Protection which will scan your users existing Active Directory passwords against our Complete database and can produce a more exhaustive report. This will likely highlight further risky users after you find some quick wins with Specops Password Auditor, however this scan does take more time to run. 

Moving expiries to fit a specific timeframe  

It’s possible you want the rollout to be complete within a certain timeframe, perhaps before your next pen test or audit. This might not line up with when some (or many) end users are due to change their passwords. Some organizations might even have never-expire passwords. There a few tactics you can use here. If you need help with password expiry – here’s a short guide on changing the pwdlastset attribute. We also have a great blog post on how you can expire passwords on a specific day in the future for some or all of your users.  

If you do choose to do this, we’d definitely recommend making use of the password expiration emails that are part of your Specops Password Policy solution to communicate any changes to expiry. Also, don’t forget you can also use Specops Password Auditor to get a report of which users’ passwords are going to expire up to a year away – this is useful for identifying which end users you might want to target first.  

For example, if a group of passwords are going to expire in the next few days or weeks anyway, why not apply the new policy to those users first? For users that still have a long time until their passwords expire due to only having changed it recently, they might find it frustrating to change again so soon – you could leave them until nearer your roll-out deadline.  

Managing remote users with different devices 

It’s great if you can install the Specops Authentication client on every Windows client and server that presents a desktop to your users, such as regular Windows 10/11 laptops, servers, terminal servers/Citrix, and other Windows VDI systems. Our client provides your end users with dynamic feedback at the password reset screen about how to meet your new password policy. If possible, it’s a good idea to get the client deployed before you rollout your new policy as it works with the standard Microsoft rules as well as the new Specops rules. This will immediately reduce calls to the service desk due to the clear guidance it provides. 

Your users’ locations when you’re going to ask them to change their passwords is another factor to consider. If everyone comes into your office at some point, then it’s pretty easy. They’ll all have “line of site” to a Domain Controller (DC) and will be asked to change their password at next login to their domain-joined Windows device. However, if they don’t use a domain-joined windows device (e.g. Mac, iOS, Android, Chromebook, Linux, or Entra ID only joined PC or laptop), they won’t have the Specops client installed, and they won’t get the prompt to change password.  

Another thing to bear in mind with remote users. Even if they have domain-joined devices, if you don’t have an “Always on VPN” providing that line of site to your DCs, they won’t be prompted to change. These end users will also run into all sorts of issues with cached credentials – changing their password at next logon will be difficult and confusing, to say the least. This is where a self-service password reset system will really help. 

Self-service password reset system (SSPR) 

If you have an externally facing SSPR solution, this can help with the non-domain joined devices mentioned in the previous section. However, remember if it’s not Specops uReset your users won’t receive any helpful feedback about the policy, and only Specops uReset has the capability to update the cached credentials on a remote laptop. We’d recommend including a note in your expiry warning emails that the user should use the SSPR system to change their passwords or wait until they are next on site before they try to change. 

Need more help? 

The best practices we’ve covered in this post are deliberately high level, as every organization is different. However, if you have specific questions related to your own organization, your Specops Account Managers and onboarding teams are always here to help. It’s all part of the service we offer – so please don’t hesitate to reach out and arrange a call to discuss any specific requirements.