The symptom
Someone changes their Active Directory password (or it expires and they set a new one), signs into Foldr, and Foldr asks them to update their cached password. By the time that prompt appears, their account is already locked, and it stays locked until you unlock it in Active Directory. Sign in again and the same thing happens.
The usual report from the helpdesk is that Foldr seems to be trying the old password against the file servers over and over rather than trying it once, and that this is new behaviour. The first half of that is very nearly right. The second half almost never is.
What Foldr is doing with the password
On an appliance authenticating against on-premise LDAP or Active Directory, Foldr caches a user’s password after they sign in (encrypted with AES-256-CBC and signed with a MAC, see Security). It isn’t there for convenience. It’s there because Foldr connects to your SMB shares as that person, so the file server applies their NTFS permissions rather than a service account’s. To do that it needs a credential to present, and the only one it has is the one they typed.
So when the password changes somewhere other than Foldr, the cached copy is now wrong, and Foldr doesn’t find out until it tries to use it.
Here’s the part that produces the lockout: Foldr presents that credential once per share it opens. Not once per sign-in. If a member of staff has a home drive and five departmental shares, and the web app or the desktop client touches all six, that’s six failed logons at the file servers, each one passed back to a domain controller and counted against badPwdCount for the account.
Two other things add to the same total. Foldr asks the directory whether the stored password is still any good, so that it knows whether to prompt the person or simply tell them they have no access, and that check is itself a sign-in attempt with the same stale password. And every device they’ve got signed in re-checks the cached password when it refreshes its token, which is another attempt each. So six shares, a phone and a laptop is more like nine attempts, arriving within a second or two of each other.
It’s worth saying what doesn’t happen, because it’s the first thing people assume: Active Directory does not collapse these into one. The same wrong password presented six times in a few seconds counts six times, and we’ve measured that (see below).
With a lockout threshold of five, four shares are enough, and an account can be locked before the page has finished loading, which is exactly why the prompt to update the cached password looks like it arrives too late. It doesn’t arrive late. It arrives as soon as the first share comes back with an access failure, and by then the other five have already been tried.
Why it feels like something changed
Nothing in this behaviour is new (it’s how per-user SMB access has always worked), but three things move underneath it and any of them will make September look different from June:
- The number of shares. Every share you add to a group multiplies the attempts a stale password generates for everyone in that group.
- The number of signed-in devices. Phone, laptop, home PC, each one refreshing its token.
- How many people come back at once. Which brings us to the seasonal version of this.
The one that catches schools after a long holiday
By default Foldr clears a cached password after two weeks of inactivity (the inactivity setting under Foldr Settings → Security → Passwords, which reads Clear after inactivity on current builds). Over a summer holiday that quietly empties the cache for most of the staff list, and in the meantime a good number of them will have changed or been forced to change their network password.
They come back in September, sign in (very often through Entra ID, so the sign-in itself succeeds), and Foldr has no cached password to send to the file servers at all. Here’s the part that surprises people: it still attempts each share, this time with the account name and nothing else, and Windows counts a blank password as a failed logon for that account in exactly the same way it counts a wrong one. So an empty cache is no safer than a stale one at the file server, though it is at least cheaper elsewhere: with no password to send, the directory check above costs nothing at all. Then the prompt appears asking for the new password, on an account that’s already locked.
That’s why this arrives as a wave rather than as a trickle, and why it genuinely does feel like a change in behaviour when it’s really a change in circumstances. Shortening or lengthening that inactivity period doesn’t help, incidentally: a stale cached password and a cleared one both end up as failed logons. The fix is further down.
Where to look for evidence
The clearest evidence is on the Active Directory side, and it’s the same evidence your AD administrator would use for any lockout investigation: event 4625 on the file servers, with the account name and a wrong-password status, repeating several times within a second or two of the person signing into Foldr. Count those, compare the number with your lockout threshold, and you have the whole story.
On the Foldr side, the smb log records failed share access checks (on recent builds it also names the share, the file server and the identity it presented). One entry per share, at the moment of sign-in, is the shape you’re looking for.
What we measured
We tested this against a Windows domain controller with lockout disabled (so nothing could actually lock), watching badPwdCount on the account move between runs:
| What we sent | Attempts | badPwdCount rose by |
|---|---|---|
| The same wrong password each time | 3 | 3 |
| A different wrong password each time | 3 | 3 |
| A blank password (the cleared-cache case) | 3 | 3 |
| A blank password, through Foldr’s own share access check | 5 | 5 |
| A stale password, through Foldr’s own share access check | 5 | 5 |
| A stale password, through the directory check that decides whether to prompt | 5 | 5 |
| A blank password, through that same directory check | 5 | 0 |
| A stale password, across a simulated six-share sign-in | 6 shares | 6 |
Four things fall out of that. Every attempt counts, so nothing is deduplicated. A blank password costs exactly what a wrong one costs at the file server. And the total grows with the number of shares Foldr touches for that person, which is the thing to hold in your head when you pick a threshold: it isn’t one attempt per sign-in, it’s one per share and then some.
Fixing it
1. Set the lockout threshold to a workable number
A threshold of five was never really compatible with any application that holds a credential on a user’s behalf, and Microsoft’s own guidance has moved away from it: the older Active Directory guidance suggests numbers up to 50 for larger environments, and the current recommendation is to set the threshold to 10 or to zero (no lockout) and lean on other controls instead.
- How an incorrectly configured account lockout policy can give more pain than security
- Set the account lockout threshold to the recommended value
Pick a number with your share count in mind, and leave headroom for the directory check and for each signed-in device. If people routinely have eight shares, ten is uncomfortably close, and you’ll want to combine this with one of the changes below.
2. Take the password out of the path entirely
This is the proper fix, and it’s worth doing even if you also raise the threshold. There are two ways to reach an SMB share without a cached password, and both keep per-user NTFS permissions intact:
- Kerberos on the share. Foldr authenticates using the appliance’s machine account and, where you’ve enabled constrained delegation, obtains a ticket for the user via S4U2Proxy. No password is stored or presented, so there is nothing to go stale and nothing to lock anybody out. See Kerberos authentication for SMB shares.
- A service account with full ACL support. Turn on Use service account for all access on the share and enable Enable full ACL support, and Foldr connects as the service account while still reading each person’s NTFS permissions to decide what they can see and do. See Configuring service accounts.
Once every SMB share is on one of those, you can turn password caching off altogether (the Cache passwords switch under Foldr Settings → Security → Passwords), which purges the stored passwords immediately and takes Foldr out of the lockout conversation for good. Be aware that this is all or nothing: with caching off, every SMB and WebDAV share needs a service account or Kerberos, otherwise those shares stop working.
3. Get the cached password updated promptly
For the people already caught by it, the sequence is: unlock the account in Active Directory, then have them sign into Foldr and answer the prompt with their new password. Once the cache is correct the attempts stop. If they’re signed in on several devices, it’s worth doing it on one and letting the others catch up rather than trying all of them at once.
We’ll be honest about the limit here: Foldr has no way of knowing your password changed until something it tries fails, because Active Directory doesn’t tell it. Anything that keeps a credential on a user’s behalf has the same problem, which is why the Kerberos and service account routes above are the ones that actually end it.
Related articles
- Security - how cached passwords are stored, and the inactivity clear-down
- Kerberos authentication for SMB shares
- Configuring service accounts
- Presenting storage to users (SMB)
- Troubleshooting SMB share visibility
- Changing your password