users unable to change password

[rwiedower]

All of my users have complained that they are unable to change their
passwords when they are prompted to do so. If users choose to cancel instead
of changing before the deadline, they are then able to change their password
by clicking ctrl-alt-del and using that change password dialog box to do so.
If users wait until their passwords expire, they are unable to change their
password without administrator intervention.When they attempt to change
their password through the "password expires" dialog box they receive a
notice saying that they do not have permission to do so.

I suspect that the problem may be tied to the particular protocol used to
change the password in question.

http://support.microsoft.com/default.aspx?scid=kb;en-us;264480

This article seems to say that the NetUserChangePassword protocol is used
when pressing CTRL-ALT-DEL...which seems to work fine. But it doesn't
indicate what protocol the "password has expired" dialog box uses, or what
happens if that protocol fails.

Thoughts? Given that users are able to change their password (if it hasn't
fully expired yet) by logging in and using CTRL-ALT-DEL, I don't think
there's a dns issue, or a specific problem with one of the two domain
controllers. But I'm at a loss for why this is occuring.

end of line,

Reed Wiedower

 

[rwiedower]

One other item: when the user attempts to login, they actually do
authenticate:

Event Type: Success Audit
Event Source: Security
Event Category: Logon/Logoff
Event ID: 528
Date: 9/2/2003
Time: 11:59:23 AM
User: DOMAIN\juser
Computer: RADITZ
Description:
Successful Logon:
User Name: juser
Domain: DOMAIN
Logon ID: (0x0,0x89DB82)
Logon Type: 11
Logon Process: User32
Authentication Package: Negotiate
Workstation Name: RADITZ
Logon GUID: {00000000-0000-0000-0000-000000000000}


Followed immediately by a logoff:

Event Type: Success Audit
Event Source: Security
Event Category: Logon/Logoff
Event ID: 538
Date: 9/2/2003
Time: 11:59:23 AM
User: DOMAIN\juser
Computer: RADITZ
Description:
User Logoff:
User Name: juser
Domain: DOMAIN
Logon ID: (0x0,0x89DB82)
Logon Type: 11


And then the system itself generates a failure:


Event Type: Failure Audit
Event Source: Security
Event Category: Logon/Logoff
Event ID: 535
Date: 9/2/2003
Time: 11:59:24 AM
User: NT AUTHORITY\SYSTEM
Computer: RADITZ
Description:
Logon Failure:
Reason: The specified account's password has expired
User Name: juser
Domain: DOMAIN
Logon Type: 2
Logon Process: User32
Authentication Package: Negotiate
Workstation Name: RADITZ


That's all the info I have. Thoughts?

end of line,

Reed Wiedower

 

[Seaver]

Dear Reed,

Thank you for your posting.

According to your post, all the users fail to change their passwords freely.

If I have misunderstood your concern please don't hesitate to let me know.

I suggest the following troubleshooting steps:

a. Start the Active Directory Users and Computers tool, right-click the
Domain Controllers container, and then click Properties.
b. Click the Group Policies tab, click the Default Domain Controllers
policy, and then click Edit.
c. Expand the following items in the policy:

Computer Configuration
Windows Settings
Security Settings
Local Policies
User Rights Assignment

d. Double-click "Access this computer from the network", click Add, click
Browse, and then add Everyone and Authenticated Users.
e. Click OK in each dialog box or window to quit the policy editor. Close
the domain controller properties, and then quit Active Directory Users and
Computers.
f. At a command prompt, type "secedit /refreshpolicy machine_policy
/enforce" (without the quotation marks), and then press ENTER.

If the problem still remains, regrant Change Password Permissions to
Everyone Group using steps listed in the following article:

242795 Granting Change Password Permissions to the Everyone Group
http://support.microsoft.com/?id=242795

Have a great day!

Sincerely,

Seaver Ren

Product Support Services
Microsoft Corporation

This posting is provided "AS IS" with no warranties, and confers no rights
Get Secure! - www.microsoft.com/security

 

[rwiedower]

All of the users can change their passwords, but they simply can't do so
unless they log into a machine first. Therefore, I think Q article 258788
(which another q article you linked to had a link to) applies here:

http://support.microsoft.com/default.aspx?scid=kb;EN-US;258788

All of my users who were experiencing the problem had been migrated from an
NT4.0 domain, so I'm guessing that applying the proper permissions to the
"users" OU will do the trick. Thanks for your help with this.

end of line,

Reed

 

[rwiedower]

I just tested this out with a user and it failed to correct the problem. So
users still have to log into their machines in order to change their
passwords. If they attempt to change a password from the "your password has
expired" dialog box they receive a "you don't have permission to change your
password" prompt.

Any other ideas?

end of line,

Reed Wiedower

 

[rwiedower]

Okay, I just figured out one other important factor:

If I set the "RestrictAnonymous" setting on all my DCs to 0, I'm able to
change their password from the first prompt. Unfortunately, this isn't a
valid solution, because I'm required the keep the setting at 2. Any way to
allow the null session dialog prompt to go through without lowering security
through the RestrictAnonymous registry setting? I thought that the Q258788
article would work, (since it describes the problem exactly the way it is)
but it didn't seem to help at all.

end of line

Reed

 

[Seaver]

Dear Reed,

Thank you for your reply.

1. Please firstly confirm with me that the following command has been
finished implementing:

secedit /refreshpolicy machine_policy /enforce

2. In the meantime, follow the steps below exactly one by one, and then
contact me with the result.

a. Launch Active Directory Users and Computers snap-in.

b. Right-click your domain, and then click Advanced Features on the View
menu to enable advanced features.

c. Right-click the container hosting the user object to which you want to
grant the Change Password right (for example, Users), and then click
Properties .

d. Click the Security tab. Make sure that the Everyone group is listed in
the Name box. If it is not, click Advanced, and then add the Everyone group
to the list from the Advanced Access Control Settings dialog box. If the
Everyone group does exist, click Advanced and continue with the next step.

e. Click the Everyone group in the list, and then click View/Edit to edit
the group's permissions. In the Apply Onto box, click User Objects. In the
Permissions section, click to select the Change Password permission in the
Allow box.

f. Click OK to accept the changes.

Regards,

Seaver

 

[rwiedower]

1.) Yes, the command has finished implementing.

2.) The steps have been followed. Nothing has changed. Users are still
unable to reset their passwords through the "Password Expired" dialog box.
They are able to change their password only by hitting ctrl-alt-del after
having logged into their machine (which isn't possible if their password has
fully expired!) and using that dialog box.

3.) As I mentioned in a previous post, reseting the restrict anonymous key
to "0" will allow users to reset their passwords through the "Password
Expired" dialog box, but for security reasons I can't set all my DCs to
allow anonymous connections. I need to leave that setting at "2" and still
allow users to rest their passwords through the "Password Expired" dialog
box.

Thanks for your help.

end of line,

Reed Wiedower

 

[Seaver]

Dear Reed,

Thank you for your reply.

Please reconfirm whether you've tested the following combination:

1. Ensure the OU's Everyone Group has been granted "Change Password
Permissions".

2. In the meantime, please affirm the RestrictAnonymous registry entry
existent from

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA

Note that you should only use the level 2 setting for RestrictAnonymous in
a pure Windows 2000 environment.

Regards,

Seaver

 

[rwiedower]

1.) Yes, the OU's everyone Group has been granted "Change Password
Permission".

2.) The LSA Key is set to level 2 on both the Domain Controllers. The
environment is a pure Windows 2000 environment (the servers are Windows
2000, the clients are all Windows XP) and the domain is in native mode.

end of line,

Reed

 

[Seaver]

Dear Reed,

To make further research, please collect the Security EVT file from one
client PC which fail to change the password, and then e-mail the file as an
attachment to my Inbox <mailto:[email protected]>.

I appreciate your continual patience with us, thanks.

Regards,

Seaver

 

[rwiedower]

I just e-mailed you the event log along with the error from the DC, which
I'll replicate here:

Event Type: Failure Audit
Event Source: Security
Event Category: Account Logon
Event ID: 676
Date: 9/11/2003
Time: 2:28:46 PM
User: NT AUTHORITY\SYSTEM
Computer: KAIOSHIN
Description:
Authentication Ticket Request Failed:
User Name: XXXXXXX
Supplied Realm Name: DOMAIN
Service Name: krbtgt/DOMAIN
Ticket Options: 0x40810010
Failure Code: 0x17
Client Address: 192.168.0.23

The errors from the client pc are here:

Event Type: Failure Audit
Event Source: Security
Event Category: Logon/Logoff
Event ID: 537
Date: 9/11/2003
Time: 2:28:45 PM
User: NT AUTHORITY\SYSTEM
Computer: CELL
Description:
Logon Failure:
Reason: An error occurred during logon
User Name: XXXXXXX
Domain: DOMAIN
Logon Type: 11
Logon Process: User32
Authentication Package: Negotiate
Workstation Name: CELL
Status code: 0xC000005E
Substatus code: 0x0

For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.

Event Type: Failure Audit
Event Source: Security
Event Category: Logon/Logoff
Event ID: 535
Date: 9/11/2003
Time: 2:28:45 PM
User: NT AUTHORITY\SYSTEM
Computer: CELL
Description:
Logon Failure:
Reason: The specified account's password has expired
User Name: XXXXXXX
Domain: DOMAIN
Logon Type: 2
Logon Process: User32
Authentication Package: Negotiate
Workstation Name: CELL

For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.


Ideas?

eol,

Reed Wiedower

 

[Seaver]

Dear Reed,

I am sorry that the EVT file mentioned did not arrive as expected. Would
you mind resending it to my Inbox mailto:[email protected]? You may
keep yourself CCed to check the delivery status.

Sorry for any inconvenience brought, and I appreciate your continual
patience with us, thanks.

Regards,

Seaver

 

[Seaver]

Dear Reed,

Would you please let me know how things are going on now? Please do not
hesitate to reply me so that we can resolve the issue as soon as possible.

Sincerely,

Seaver

 

[rwiedower]

I just resent the .evt file, although I still feel the error messages from
the DC are more pertinent to the problem at hand. Please tell me if you fail
to receive it.

end of line,

Reed Wiedower

 

[Seaver]

Dear Reed,

Based on the provided information, the "Authentication Ticket Request
Failed" error can occur if the time was out of sync between both clients
and DC. I suggest that you refer to the following article to check the
correctness of time service.

216734 How to Configure an Authoritative Time Server in Windows 2000
http://support.microsoft.com/?id=216734

Regards,

Seaver

 

[rwiedower]

Both DCs have the proper time set from the Naval Observatory. I synchronized
the time with a client and then attempted to login with an expired account.
I still received the same error message about not having permission to
change the password.

There aren't any strange w32tme errors in the system log, so I think the
time settings are working fine. Since the error has occurred on a variety of
machine across my domain, I don't think it could be traced to one faulty
connection at one point in time.

Other ideas?

end of line,

Reed Wiedower

 

[Steven Liu [MSFT]]

Hi Reed,

This behavior occurs if you have an orphaned computer account which has the
same name, specifically the Service Principal Name (SPN), as your domain
controller in your Windows 2000 domain.

To resolve this issue:



Delete the duplicate orphaned computer account.



To check if there is a computer name which has the same name as your domain
controller's name in your windows 2000 domain do the following steps:



1- Double-click My Network Places


2- Double-click Entire Network


3- Double-click Directory


4- Mark the Domain which includes the machine accounts and click the right
button


5- Click find


6- To search for the computer account select in the Find window Computers


7- In the Computer Name window type the affected computer name


8- Click Find now


9- In the results you should have two accounts, the active Domain
Controller account and the orphaned account.


10- When you open the properties of the accounts, you will see that one has
the Domain Controller Role in the General property page.


11- In the Object pane (need to turn on Advanced Features for view) you
will also see the container the account is located in. This can provide an
additional hint to decide which account has to be deleted.

Thanks for using Microsoft News Group!

Sincerely,

Steven Liu

Microsoft Online Partner Support

MCSE 2000

Get Secure! - www.microsoft.com/security

This posting is provided "as is" with no warranties and confers no rights.

 

[rwiedower]

I only have two DCs and neither have orphaned accounts. I just checked.
Sorry...

Any other thoughts?

eol,

Reed Wiedower

 

[Seaver]

Dear Reed,

On the Windows 2000 DC, please perform the following checkings:

1. Navigate to: HLM\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters,
find and then modify the "DisablePasswordChange" value to "0".

2. Navigate to: HLM\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters,
find and then modify the "RefusePasswordChange" value to "0".

After that, reboot the DC, and then find one client computer to test the
situation.

Regards,

Seaver