In angry black <
[email protected]> posted a question
Then Kevin replied below:
: We are having serious problems with some of our users.
: The user accounts continue to be locked out for some
: reason. I though it was because of multiple sites. I
: imputed the ip in the subnet section so clients can use
: the closest dc to them still no help. The error that
: comes up is
: Replication warning: The directory is busy. It couldn't
: update object CN=user name,OU=Trading
: OU,OU=domainusersUsers,DC=,DC=,DC=com with changes made
: by directory 593f2a0d-7b79-4dd3-8339-
: ba58bbc17f1f._msdcs.domain.com. Will try again later.
:
: Microsoft said this problem does accur in article 1083
: however nothing i do seems to help. In desprate need can
: anyone help.
I doubt if the users getting locked out has anything to do with replication,
I'll have to study it to verify.
I'll let Ace handle the replication problem since he has already replied for
that you will need to post what he has asked for.
As for the users getting locked out, it could be a hacker, or it could even
possibly be a scheduled task with the wrong password.
If the users are allowed to set up scheduled tasks on their computers they
supply a username and password for the task to run when they are not logged
on. If they change their logon password the scheduled task still has the old
password. You would have to visit each machine and look a scheduled tasks to
verify this.
Have you enabled security auditing?
You can do this in the domain security, I would also enable it on the domain
controller. To do this, if you had the Administration pack installed
(adminpak.msi) go to Start, Programs, Administrative Tools, setting the
policy for the domain click on Domain Security Policy, then expand Windows
Settings, Security Settings, Local Policies and select Audit Policy, this
will display the audit settings in the right pane, double click Audit
account logon events and define at least Failure. Do the same for Audit
logon events. You can also audit Success events, too. But this will make the
security event log to fill rather quickly. Depending on the size of your
organization you may need to increase the maximum size of the Security Event
log.
You can define the size of the event log in this policy by expanding Event
Log and selecting Settings for the Event Logs, these setting will be
propagated to all domain members. The default security log is seven days and
512 bytes if the log fills before that at startup the machine will popup a
warning that the security log is full.
After you make these settings you can look at the event log to see when the
lockout occurred, Then it is just a process of determining what was
happening at the time of the lockout.
It could be something very simple though, take this for an instance I've
seen. A user has a local machine logon account and a domain logon account
using the same username but both have different passwords. The users logs on
to the local machine account then tries to access domain resources with
these credentials, the domain finds a match for the account username but the
password is not correct for the account name and the domain locks out the
user based on that alone.
Or they could have a resource on their own machine that the domain account
has access to but the local account doesn't.
I hope you can figure this out lockouts can be difficult to nail down to the
source.
The first step is to enable audit account logon events. I'm sorry for the
length of this post but as you can see it may be difficult or simple.
