Hi Steve,
I would like to confirm my understanding of this issue:
You have noticed that Event ID 643 is logged in the application log in
win2k server. However, what do you mean by " on a standalone Windows 2000
server"? Is this server in the domain or a workgroup?
Technically speaking, Event ID 643 has indicated that Domain Policy
Changed. As you have found, this policy will be generated when you change
the domain policy or local policy as described in the following link:
http://support.microsoft.com/default.aspx?scid=kb;en-us;301677
Based on my research, Event ID 643 could be trigger by the following causes:
1. By design behavior.
============================
This behavior is by design and is not indicating a problem with security or
auditing. This audit event can be safely ignored.
"Password Policy Change" (event 643) does not distinguish between policy
refresh and actual password policy change. Thus, each time that a client
or server refreshes their local security policy (5 minutes for Active
Directory domain clients or 16 hours for NT 4.0 domain clients), the audit
event 643 occurs.
In the event that there is no associated Event 1704 in the application
event log for a 643 event, then this may very well be because of a password
policy change.
2. Refreshes its local security policy
========================================
This event is logged each time that the server refreshes its local security
policy.
This is normal behavior when a Windows 2000 system refreshes the policy,
the specific audit mechanism for password policies doesn't differentiate
between a policy refresh and a policy update. Thus, each refresh registers
a 643 event.
3. DC has reached the an enforce interval
=========================================
The Domain Controller has reached an enforce interval for Security Policy
as
defined by the following Registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Winlogon\GPExtensions\{827D319E-6EAC-11D2-A4EA-00C04F79F83
A}
Value: MaxNoGPOListChangesInterval
Data: Minutes of delay, entered in hexadecimal
By default, this value is set to 0x3c0, (960 minutes or 16 hours)
For more details how to resolve this issue, please refer to the following
article:
277543 How to delay security policies from being applied
http://support.microsoft.com/?id=277543
In the conclusion, I believe you don't need to worry about this event log,
probably, you have encounter a by design behavior.
In addition, if you want to track the domain policy change, there is no
built-in tool to achieve this goal. Based on my further research, there is
a third-party tool which can compare gpttmpl.inf file. For example, if you
save the current gpttmpl.inf file which is located in sysvol folder (you
can search gpttmpl.inf in the sysvol folder), when the domain policy
changes, compare the current version of gpttmpl.inf with the original one
by using WinDiff function or manually compare to find out the difference.
Another method is to compare the settings using GPMC. A third-party tool
called TripWire provides change control down to the contents of a file.
(
http://www.tripwire.com).
Note: The third-party product discussed is manufactured by a vendor
independent of Microsoft; we make no warranty, implied or otherwise,
regarding this product's performance or reliability.
Any update, let us get in touch!
Best regards,
Rebecca Chen
MCSE2000 MCDBA CCNA
Microsoft Online Partner Support
Get Secure! -
www.microsoft.com/security
=====================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
=====================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
