Impact of running Specops Password Policy on Active Directory
(Last updated on February 17, 2021)
We are often asked about the technical impact of using our solutions on Active Directory, and other services. In this blog post, we will look at the impact of Specops Password Policy (SPP) and Breached Password Protection (BPP).
Specops Password Policy and Breached Password Protection
This solution allows you to enforce a better password, or passphrase policy in your AD environment.
There are 4 components:
- Specops Password Policy Sentinel: This is the most important component as it enforces the rules regardless of how the password is being changed. It also provides notifications, and creates the feedback for the users. It resides on all of the writable DCs in the domain. If it’s not installed, then we can’t enforce the rules so it’s very important to make sure this is added to your DC build process.
- Specops Password Policy Admin tool: This does what it says on the tin and allows you to configure the solution. Ideally, it should be installed where ever you would normally create or edit your GPO’s e.g. on an admin workstation, management server, or even your DCs.
- Specops Arbiter Service – This is only required if you have the BPP module enabled, and is responsible for communicating to the Specops Cloud which hosts the Complete version of the leaked database. It is also responsible for relaying alerts if a breached password is detected.
- Specops Authentication Client – This is the client-side software that runs on the domain-joined windows clients that your users use. This is usually a workstation/laptop but can also be a server e.g. Terminal Server, Citrix, but not usually DCs, or regular member servers.
So, let’s take a look at each of these in a little more detail.
Specops Password Policy Sentinel
This is function made up of 2 parts: a password filter, SPP3FLT.DLL, and a Windows service, called the Specops Password Sentinel Service.
The Specops Password Filter
The password filter is a small DLL that hooks into the regular LSASS.exe process that runs on every DC. This is a standard Microsoft documented procedure that allows AD admins to create their own password filters. The only downside to installing the filter is that it requires that the DC is rebooted, because LSASS.exe isn’t a service that can be restarted while the OS is running.
To comply with Microsoft best practice, the Specops Filter always sits behind the standard Microsoft Password filter that applies the rules from the Default Domain Policy (or other top-level GPO if you have configured it that way), or any Fine-Grained Password Policies (FGPP) you have configured. This is important to remember as you may find you need to “dumb down” the DDP/FGPP to allow things like passphrases to work because as they are certainly much long and much harder to crack, they don’t usually meet the complexity rules that most organisations have switched on in their Microsoft policies. Don’t worry, we have a few tricks up our sleeve to workaround this issue if you want to run a limited trial in your live environment, just ask Specops Support for some help.
The installer is a small 4Mb MSI file that can be pushed from an admin PC where you are running the setup from, or manually installed. The installer will NOT reboot your DCs this will have to be done manually.
The filter is responsible for enforcing all the rules you have in your Specops Policy and also for creating the custom feedback for the client-side to read. Every DC should have at least 2 CPUs assigned to it, to avoid any deadlock situations. This is where the password change process can take up an entire CPU thread. Having 2 CPUs/vCPUs means there is always a spare thread for other DC operations.
The filter also creates a password history ClassStore object underneath each user account in AD. This is a regular AD object, NO SCHEMA EXTENSIONS are required. By default, the user’s password history is non-reversibly encrypted, there are a couple of rules that require reversible encryption, but these aren’t regularly used. This ClassStore object also stores any extra days the user might have earned by using a longer password if you have enabled Length-Based Password Aging in your policies.
The same Length Based Password Aging feature also requires a security group to allow admins to be able to read when a user’s password will expire in SPA. This group is called “Specops Password Policy Custom Expiration Readers” and is created in the Users container. It can be renamed and moved, if required, after it has been created.
The Filter installed on the PDC emulator is also responsible for checking that the licence numbers are correct, and writes a new licence checksum to the SYSVOL folder every night (00:01) which then replicates using normal SYSVOL replication to all the other DCs so that they are kept up to date. The PDC emulator is also responsible for producing a list of users who should receive a password expiry email each night. Once it has this, it passes that info onto the second purpose of the Sentinel.
Specops Password Sentinel Service
This service has two functions, the first is to send email notifications. These could be for upcoming password expiry to end users, but also BPP emails if a user has set a compromised password, and needs to change it. The second function is only required if you are using the BPP Module’s Complete database (2.5 Billion unique leaked password hashes and growing).
So, as it’s responsible for sending emails, it must be able to communicate with your email server or relay. You’ll need to know the DNS name/IP Address, what port the mail server uses, if TLS is required, and a username and password if anonymous connections aren’t allowed. It’s fully compatible with all known email systems, including Microsoft 365.
If you don’t have the BPP module, the only DC using email will be the one holding the PDC emulator FSMO role. If you do have the BPP module, all writable DCs will require access to the SMTP server.
You can choose to use the Specops Mail system rather than your own, but most customers don’t choose this option as it means they have to allows the Specops Mail Server IP address through their spam filters.
Finally, the other process this service manages on the PDC DC is the ability to scan your users’ passwords for new breached passwords every time the Express database is updated (approximately 6 times a year). This means that if a user sets a perfectly good password today, but ends up on our Express list tomorrow, that user will be forced to change it the next time they login once you download the new Express database. This is great in theory, but just be careful that if you have a lot of people working from home, they might not have a good way to change their password remotely, unless you have a self-service password reset system e.g. Specops uReset.
Specops Password Policy Admin Tools
The Specops Password Policy Admin tools should be installed wherever you would normally edit your GPOs from. They require the latest .net to be installed for them to run, and can obviously only be run from a domain joined machine.
Saying that, it’s also helpful to install them on at least one DC as you can then test your email configuration with the built-in button.
The admin tools are supplied as a zero config MSI file so you can easily install them.
During the installation process of the admin tools you will also be prompted to “Install ADUC Menu Extensions.”
This is a completely optional step, but it does require enterprise admin level rights (higher than domain admin), because it needs to write some display specifier information to the Configuration Container of your AD. THIS IS NOT A SCHEMA UPDATE and is completely reversible, but it does provide a useful feature in that you will get an extra menu item when you right click on a user in ADUC that will tell you which password policy applies to them.
The most important integration is with Group Policy Editor, as this is actually how you create your policies. Rather than using the limited ADMX interface, we decided to use the API’s that Microsoft provide to extend group policy. You’ll find the Specops Password Policy settings under User Configuration>Windows Settings>Specops Password Policy.
Again, there is NO SCHEMA EXTENSION required for this, and it provides a much richer and friendlier interface for admins to manage.
Just like any other GPO, you can filter these policies using OU, Groups or Users by using the Security filtering options in Group Policy Management Console, we don’t support WMI filtering though due to how the policy is applied or more accurately “not applied” because it doesn’t write anything to the user hive in a local computers registry. It is purely processed by the Sentinel on the DC when the user’s password is changed or reset.
When you create a new Specops Password policy, all settings are stored in the Policies folder in SYSVOL. Any dictionaries you add to the policy, either custom or downloaded, will also be stored here. Be careful of some of the sizes of dictionaries you might find from 3rd party sources on the internet as they could be huge. The downloadable dictionaries from Specops, when you don’t have BPP, add up to about 168mb, and block around 9 million common passwords. These dictionaries are loaded into RAM when you reboot your DCs so shouldn’t cause any problems as they are relatively small.
The other password settings for passwords/passphrases aren’t stored in the .pol file and are instead written to an INI file, this is because as I mentioned above, they don’t need to be written to the client PCs.
You can have as many policies as you wish, containing as many different settings as you like. Most organisations end up with at least 3, one for Users, one for Admins and one for Service Accounts, but you might need more e.g. one for PCI DSS affected users in the finance team.
The Specops Password Policy Domain Administration tool also allows you to check the status of the Sentinels installed on your DCs. To do this, it must be able to connect to them over the standard set of ports that ADUC would require, plus it also needs to be able to connect to each DC’s Admin$ share.
Note that it might display 2 different version numbers for one DC. This can happen just after you have upgraded, but not yet rebooted the DC. Once rebooted, the Installed and Running version should match.
The Password Policy Templates are stored in the SYSVOL share under the Policies\SpecopsPassword folder along with any language files.
These folders don’t take up much space at all, just a few kilobytes.
However, also notice the Dictionaries folder. If you have the BPP module installed and configured to use the Express database, this will consume 5GB of space on each DC’s SYSVOL volume and cannot currently be moved. It’s been done this way so that we can be sure that the user’s password can be processed against the Express database as quickly as possible (as its local to each DC) and that it is consistent across the entire domain. Please make sure that your DCs have enough space before hitting the download button. NOTE this 5GB database is NOT loaded into memory like the other regular dictionary options I mentioned above, it is only stored on disk. When you update the Express Database, wherever you are running the admin tools, it’ll download the entire new express database to a temp folder. Once complete it will then move it to the closest DC’s SYSVOL share and then DFS-R on the DC will decide which parts of each file have changed, and replicate the differences to the rest of the DCs. If the domain is still using FRS to replicate SYSVOL, then all files will be replicated again to the other DCs. So, I would advise migrating to DFS-R for SYSVOL replication if you plan to use the Express database.
So that’s how we use the on-prem based dictionaries, how about the BPP Complete Database? This leads us nicely onto the last section.
The Specops Arbiter Service
This is a small service that sits between your DCs and the Specops BPP Complete Database in the Cloud. The reason we have this service is so that you do not need to allow your DCs to connect outside of your network. It acts almost like a proxy between your DCs and our Cloud-based database. You can have multiple Arbiters for fault tolerance, you simply install the service onto another domain-joined server with internet access (don’t forget to install the latest .net again) and register the Arbiter in the admin tools with your API key.
Whenever you register an Arbiter is creates an entry in the System Container in AD so that the DCs can find them.
So how does this work exactly? When a user changes their password, it goes up to the DC and is processed by the Specops Filter which will check to see if you have the BPP module enabled, if the option to check with the Complete Database in the Cloud is enabled in the policy that applies to the user who is changing their password.
If it is enabled, the user’s password will first of all be hashed (SHA256), then hashed again (BCRYPT) by the Specops Password Sentinel Service which will then send only the first 4 characters of that hash to the Arbiter or whichever Arbiter responds first, over port 4383. The Arbiter will then query, over port 443 using TLS 1.2, the BPP Complete database and ask for it to return all hashes in its database that begin with those first 4 characters. Do not try and inspect this HTTPS traffic as it will be detected as a “man in the middle” attack and the transmission will stop. You can lock down the query to a specific URL if required: https://breach-protection.specopssoft.com and also http://crl.godaddy.com to check the certificate.
The Specops Cloud will then return around 5000 records to the Arbiter. The Arbiter will then send those records up to the DC who will compare the 5000 hashes received with the user’s password hash. If it does not find a match – great!
But if it does find a match, depending on what’s configured in the GPO, it can force the user to change the compromised password at next logon, and alert the user/helpdesk by sending them an email and/or a SMS text. The email address is read from the users email field in AD, and can be sent via your Internal SMTP config that was set in the Admin tools from the DC that processed the change, or the email can be created and sent by our Cloud service via the arbiter. If SMS Alerts are enabled, this is always sent by the Specops SMS service via the Arbiter.
Specops Authentication Client
This client is used across all of Specops password solutions, i.e. SPP, SPR, uReset, and performs different functions depending on what services you have installed. In this blog post, I’m just going to detail it in relation to Specops Password Policy.
The client is approximately 4mb in size and comes in the form of a zero configuration MSI. Which means it can easily be deployed via any MSI deployment system including Group Policy, SCCM, Specops Deploy, etc. There’s no need to repackage it, it’s ready to go, and comes in x64 and x86 flavours (if you still have any x86 workstations). You can deploy the client to any domain joined Windows OS from Windows 7 onwards, and also to any Windows Server OS from 2008 onwards e.g. remote desktop servers. There is also a an ADMX template that can be used to control the behaviour of the client via a GPO applied to the client computers. Typically, if you are only using Specops Password Policy in your environment you will only use this ADMX file to disable the creation of the Start Menu shortcuts for the Self-Service Password Reset Systems. There are a couple of other settings available to SPP users, but these are used to workaround issues where the client cannot find the custom feedback message and fails to display that custom message to the users. Usually Failure to display the custom message is down to a conflict with the MS policy, I mentioned the passphrase vs. DDP Complex Password scenario in the Specops Password Filter section, but it could also be a clash with another Credential Provider such as a 3rd party VPN, SSO, Disk encryption client that can cause this. Please contact Specops Support to resolve any such issues – we are always happy to help and advise.
The client also provides a password expiry notification by way of a balloon tip/popup, but this does require “line of site” to a DC at login, just like the Microsoft one. If you have people working remotely, make sure you enable the email notifications in your SPP policies, as well, if you don’t have an Always On VPN such as DirectAccess.
I hope this detailed blog has been useful and explains in detail what impact deploying SPA, SPP and BPP will have on your AD and the reasons why Specops have made some of those design decisions.