"Your password must be at least 0 characters"... wait, what? (Windows 2003)

[no_neckbeard]

My users are suddenly getting this error message when trying to set their password:

"Your password must be at least 0 characters, cannot repeat any of your previous 0 passwords and must be at least 0 days old..."

This is very interesting, since the GPO is set to something like 14 characters, previous 24 passwords, etc.

I'm not sure exactly when this started happening, as we don't have a lot of people logging directly into the servers. This is on Windows 2003.

The current password policy settings are in a GPO applied at the root of the domain, and contain the following:

Enforce Password History: 24 passwords remembered
Maximum password age: 60 days
Minimum password age: 1 days
Minimum password length: 14 characters
Password must meet complexity requirements: Enabled
Store passwords using reversible encryption: Disabled

Pretty standard stuff. The LSA\Notification Packages value contains the default entries I think, either way they haven't changed in the last two years:

EnPasFlt
PPE

I haven't tested yet to see if the custom web page I have setup (not IISADMIN) still works for changing passwords, but this is enough of a problem by itself.

The best I can find so far googling is that this can be an issue if you have a custom password filter in place, or on older NT/2000 servers when the complexity rules were handled by an add-on filter, but no rules had been set yet. Nothing about this randomly popping up on a 2003 box.

I can still reset passwords through the AD snap-in without an issue.

 

[nicknomo]

I have no idea, but I just wanted to say that is one brutal password policy. 14 characters AND complexity requirements for only 60 days??? Ouch.

Edit: Maybe this applies to you?

http://support.microsoft.com/kb/196465
If your current account policy is set to permit blank password, this conflicts with the above requirements for PASSFILT

Maybe an erroneous entry in the GPO? Local or otherwise? I'd try setting blank password in the GPO to Disabled, then enforce the GPO..

Also check to make sure that the check box for "user can never change password" is not checked..

 

[no_neckbeard]

No, that NT KB article applied when there wasn't a GPO to modify password settings. Though I am going to try and monkey with the password filter list and see if that changes anything, but I can't do that until after hours sometime.

I tested on multiple users and we definitely don't have the "never change password" flag set. And I was definitely looking for anything obvious I could have overlooked :/

The only error I had in the GPOs (that I found so far) was a misspelled "admnistrators" (sic) on an unrelated policy (adding users to workstations I think), but apparently that's been there for years and probably wasn't affecting anything.

 

[Black_Obsidian]

Reading between the lines of your OP, this only happens to users changing their domain passwords on the Server 2K3 box, but not when they change their domain passwords on workstations? And the password GPO is applied at the root of the domain, without the server-containing OU being excluded or overriding it? That... is bizarre.

Or it could be your domain controller punishing you for setting password complexity rules that nigh-on guarantee a majority of your users are writing their passwords down somewhere convenient.

 

[no_neckbeard]

There are no workstations on this domain, just the DC (yes, just one >_<) and member servers.

The users, such as they are, only setup AD accounts once and then do nothing but use smartcard-enabled websites on the servers (most of which at this point I think use a completely separate authentication database, but I digress). The only people experiencing this issue right now are other admins (and potentially helpdesk folk) because they are the only people logging in directly.

update: this may only be occurring when the user's password has expired and they get prompted to change the password during the login process. We pretty much only login using terminal services. I was able to change my password normally when I was already logged in (through the ctrl-alt-del dialog).

 

[ANIXIS]

The PPE in your list of notification packages is Password Policy Enforcer, a third-party password filter. Whoever installed PPE most likely disabled the domain password policy, possibly because they were using the PPE client to replace the default message.

That still doesn't explain why your message does not match the GPO. This often happens when the GPO with the password policy is linked to an OU and not the domain root. You can try the "net accounts /domain" command to see the Windows domain password policy settings.

You also have the NSA's password filter installed, which means that passwords will be rejected unless they comply with the Windows, PPE, and NSA password policies (yes, all three).

Disclosure: I work for ANIXIS.

 

[no_neckbeard]

The LSA key is what I've been thinking about. In Server 2003, custom password filters aren't necessary to create basic requirements, these are met with the GPO and the built-in system. I'm fairly certain that the enpasflt.dll isn't even installed (nor is whatever the PPE setting refers to, I presume another dll).

I'm thinking about either leaving the value blank, or setting it back to default and see if that fixes it. We don't need any custom packages AFAIK, the GPO enforces our password policy just fine.

 

[ANIXIS]

Look for ppe.dll and enpasflt.dll in the system32 folder. If you don't need the additional filtering, then remove both from the list. It won't fix the problem because the problem you are having is with the Windows policy, but it's no point having them there if you don't need them.

What output did you get from net accounts /domain ?

 

[no_neckbeard]

The "net accounts /domain" results match the GPO settings exactly.

edit: and now I can't seem to reproduce the error. I wonder if it was just a one-time GPO processing issue. Will keep an eye on it for a few days though.

 

[ANIXIS]

I have never seen a case where net accounts did not match the Windows rejection message. You mentioned that you don't need PPE and EnPasFlt, so I would set the Notification Packages value back to default on your DC and restart it.

You will then be able to tell if the enforced policy is the one in the GPO, or the one with all settings disabled. At the moment you can't be sure if the password is being rejected by Windows or one of the other password filters.

I know you said earlier that they are using a domain account, but is it possible that the user reporting this was logged on with a local account on one of the servers? The policy for local accounts can be different to the domain policy.

 

[no_neckbeard]

Negative, definitely a domain account.

Can I leave the notification packages value blank? Or is an entry required there? Clearly the systems aren't using the existing settings since the DLLs aren't installed (I've verified this now), so is there any reason to have anything there at all?

 

[ANIXIS]

I would use the defaults. The file descriptions for the default DLLs on 2003 are

RASSFM - Remote Access Subauthentication dll
KDCSVC - KDC Service
WDIGEST - Microsoft Digest Access
Scecli - Windows Security Configuration Editor Client Engine

 

[AndreaFaulds]

This is an issue for a user on my server (Windows NT 4 Terminal Server). So it seems it's a bug that existed prior to 2003.

 

[daldrich]

AndreaFaulds[/url]":2tn0h6lz]This is an issue for a user on my server (Windows NT 4 Terminal Server). So it seems it's a bug that existed prior to 2003.

This thread is 4 years old. No need to be resurrected.

 

[Incarnate]

daldrich[/url]":19829ued]

AndreaFaulds[/url]":19829ued]This is an issue for a user on my server (Windows NT 4 Terminal Server). So it seems it's a bug that existed prior to 2003.

This thread is 4 years old. No need to be resurrected.

That's OK. They must be posting from the past. NT4 support ended 11 years ago.