Domain users unable to change passwords upon expiration

  • Thread starter Thread starter Jake Paris
  • Start date Start date
J

Jake Paris

Hey folks,

I have setup a password policy on my win2k domain that exires passwords
every 90 days. I have had a few users come to me recently complaining that
when they try to change their passwords, it says that they do not have
permission to do so. I of course checked the "user cannot change password"
option in the AD control panel, and it was not selected for any of the
accounts. Is there any other reason you can think of why they would not be
able to change their passwords?

Thanks,
 
It is set to zero days... I can't imagine that would be causing the issue...
no?

--
Jake W. Paris
Henrik Johansson said:
Check your policy for the minimum age of the passwords.
Click to expand...
 
No, MinAge=0 shouldn't give that problem.

It sounds like the problem is the ACL of the AD-object.
ADUC -> View -> Advanced Features (to make security tab visible)
Property of user object -> Security and check that the Everyone-group has
been granted to change password.
As always when handling ACL:s, check that the user isn't member of any group
that has been denyed the permission of the object.

See also KB 242795:
http://support.microsoft.com/default.aspx?scid=kb;en-us;242795


/Henrik

Jake Paris said:
It is set to zero days... I can't imagine that would be causing the issue...
no?

--
Jake W. Paris
Henrik Johansson said:
Check your policy for the minimum age of the passwords.
Click to expand...
not
Click to expand...
 
Well at least now I feel I have some conceptual understanding of what the
issue might be, but unfortunately I was unable to find any users with this
particular issue. From what I can see, all users have the everyone group set
to be able to change password... not sure how different that is from "reset
password" though... which only domain admins seem able to do on each
individual user. The only group-wise permissions I can see that might be a
problem is that "SELF" on the "Domain Users" group has only read permissions
on the group... no write access. Not sure what exactly that pertains to as
far as writing password changes though. As far as other groups users might
belong to goes, I really don't see any discrepancies there.

Any other suggestions? I really appreciate your help thus far.
 
Reset password = account operators don't nead to know original password of
the users to change password when using ADUC.

SELF shouldn't nead write access on the group object of Domain Users. This
is a user object problem.
What I ment before was that you should check that the user is not member of
any group that has been denied the change password property of the user
object. Deny overrides allow.

What does SELF say when checking the ACL on the user object that is having
the problem? It has allow by default.
Do you have any account that you know is ok that you can compare its ACL
with?
 
On the afflicted account, SELF has read perms, as well as change password,
and a bunch of other seemingly unrelated perms. All are defaults as far as I
can tell. The only groups this particular user is a member of are Domain
Users, and the Admin group... which actually has a higher level of
permissions than other users who have not been afflicted. Also, other users
in the Admin group have not had this issue. I really cant see any difference
in their ACLs. All these users were created off of the same basic template.

Would it be possible in some way to either reset the user to defaults to be
sure, or even recreate the user without losing her profile / home folder
settings?
 
Recreating user will give a new SID and nead to reassign all permissions and
groups for the user.

As said before: Compare the user object with a working user's ACL to see
that they are identical for relevant permissions.
If they are set to the same, it must be something with the policy.

What does "net user <username>" say about passwords? (Password changeable
etc)
Is it possibly that they have just tried to reuse an old password that is
cached in the password history assigned by the policy?
Do they match the password policy in length/complexity etc?

What happens if logged on as another user/admin and try to change password
by using <ctrl><alt><del> for the user that has the problem?
What happens if resetting password through ADUC? If success, is it possibly
for the users to change their password without administrative assistance?

/Henrik
 
Back
Top