Account lockout and authentication problems

  • Thread starter Thread starter Toni Van Remortel
  • Start date Start date
T

Toni Van Remortel

Hi all,

I have 3 domain controllers, all running Windows 2000 Advanced Server.
Since a week, random account lockouts occur, and I don't have any clue
anymore where to look.
I tried the entire document of MS (Account passwords and Policies)
concerning account lockout troubleshooting, but it didn't help me.

Now, I did 2 packet captures on 2 commands:

net use g: \\corbusier\remorto$ /user:OW_HA\remorto

This one locks out the account before there is asked for a password
(packet capture 1)

net use g: \\corbusier\remorto$ /user:OW_HA\remorto *

Doesn't lock out the account, request nicely a password and succeeds.
(packet capture 2)

Now, I really don't know why some domain accounts get locked out and
others don't. I already thought on virusses or spyware, but I haven't seen
any reports on that (anti-virus and anti-spam is up and running and should
be up2date).

Anybody an idea?

capture 1 : http://www.x-a.be/capt/1.txt
capture 2 : http://www.x-a.be/capt/2.txt
Format : libpcap (tcpdump, ethereal)

Thanx.
 
Toni this might be a good place to start.
Check your security audits event logs for clues
or change success/failure audit policy settings for both
logon/logoff etc.
 
Toni this might be a good place to start.
Check your security audits event logs for clues
or change success/failure audit policy settings for both
logon/logoff etc.
Click to expand...

I just enabled Kerberos logging and I will see tomorrow what the results
are.
Auditing should already be enabled, but the weird point is that I don't
get any feedback about failures, only successes (and the failure option is
checked for the audit).
 
On Mon, 14 Mar 2005 09:38:57 +0100, Toni Van Remortel wrote:

<lockout problems>

I discovered that all TCP traffic from my PDC has an incorrect checksum
(that is what Ethereal tells me). So I wonder if that might be the reason.
 
Hi all,

I have 3 domain controllers, all running Windows 2000 Advanced Server.
Since a week, random account lockouts occur, and I don't have any clue
anymore where to look.
Click to expand...

Update on the search for the reason:
* It cannot be a virus or trojan horse, because the lockouts only occur
during working hours (ie. between 07h30 and 22h00).
* Account lockout happens only when a user tries to log in (except the
Administrator account, but that might be caused by one of my many scripts
that use the Administrator to run under).
* Kerberos only states errors on prisoner.iana.org for DNS. That ain't a
problem, as far as I've found.
* Communication between 2 domain controllers is quite heavy, while the 3rd
seems to be quiet. Might be the result of the time I captured the events.
I'll take a look at that a bit further.
* Most errors in the Application log, are perflib errors. I don't worry
about that.
* DNS Server problems are solved (some article told me to point the DNS
servers to each other for their primary DNS lookup, but an article of MS
told me not to do and let them search only their own DNS and the DNS of
the gateway (which is also the forward server for the local DNS servers).

I don't know where to look now. I tried all solutions and debugging I've
found on the web, but I didn't find any evidence that states the problem.

I hope somebody sees a glimp of a possible error.
 
Enable auditing of account logon events in Domain Controller Security Policy
and logon events for at least failure in Domain Security Policy. Then you
should see failed account logon attempts in the security log of the domain
controller for the user account and from what computer the failed logon
originated from.You can then look in the security logs of domain computers
for logon failure Event ID 539 which will be in the security log of the
computer where the logon attempt was tried which may be a different computer
than shown in the domain controller security log if the user was attempting
a type 3 network logon to a computer that shows Event ID 539 in it's
security log. That will at least give you a clue as to what computers are
involved in these account lockouts.

Microsoft recommends that you use an account lockout threshold of no less
then ten bad attempts as a single failed logon can increase the lockout
attempt counter several times on the pdc fsmo. Twenty is probably a good
number to use assuming you enforce the use of strong passwords in the
domain. Common reasons for account lockouts is that the user is still using
old credentials via a logon to another computer [Terminal Server?], in
persistent mapped drive credentials, for an application that uses
credentials, in a Scheduled Task, or stored credentials if using XP Pro.

It would also be a good idea to check the health of your domain controllers
and the computers where this is happening. Use the support tools netdiag and
dcdiag to check domain controllers for problems and netdiag for domain
computers. Also check Event Viewer of domain controllers for any pertinent
errors. --- Steve
 
Steve,

Thank you for the answer. Now, I finally got some failure logs in de
security log. Event id 675 and 676 are occuring.

Now we re-mastered a lot of our pc's, but the old ones weren't removed
from AD, while the new were registered in the domain with the same name.
Might that be a problem?
If so, how can I re-create all my computer accounts in AD without manually
editing all machines (about 200).

Regards,
Toni.

Enable auditing of account logon events in Domain Controller Security Policy
and logon events for at least failure in Domain Security Policy. Then you
should see failed account logon attempts in the security log of the domain
controller for the user account and from what computer the failed logon
originated from.You can then look in the security logs of domain computers
for logon failure Event ID 539 which will be in the security log of the
computer where the logon attempt was tried which may be a different computer
than shown in the domain controller security log if the user was attempting
a type 3 network logon to a computer that shows Event ID 539 in it's
security log. That will at least give you a clue as to what computers are
involved in these account lockouts.

Microsoft recommends that you use an account lockout threshold of no less
then ten bad attempts as a single failed logon can increase the lockout
attempt counter several times on the pdc fsmo. Twenty is probably a good
number to use assuming you enforce the use of strong passwords in the
domain. Common reasons for account lockouts is that the user is still using
old credentials via a logon to another computer [Terminal Server?], in
persistent mapped drive credentials, for an application that uses
credentials, in a Scheduled Task, or stored credentials if using XP Pro.

It would also be a good idea to check the health of your domain controllers
and the computers where this is happening. Use the support tools netdiag and
dcdiag to check domain controllers for problems and netdiag for domain
computers. Also check Event Viewer of domain controllers for any pertinent
errors. --- Steve


Toni Van Remortel said:
Update on the search for the reason:
* It cannot be a virus or trojan horse, because the lockouts only occur
during working hours (ie. between 07h30 and 22h00).
* Account lockout happens only when a user tries to log in (except the
Administrator account, but that might be caused by one of my many scripts
that use the Administrator to run under).
* Kerberos only states errors on prisoner.iana.org for DNS. That ain't a
problem, as far as I've found.
* Communication between 2 domain controllers is quite heavy, while the 3rd
seems to be quiet. Might be the result of the time I captured the events.
I'll take a look at that a bit further.
* Most errors in the Application log, are perflib errors. I don't worry
about that.
* DNS Server problems are solved (some article told me to point the DNS
servers to each other for their primary DNS lookup, but an article of MS
told me not to do and let them search only their own DNS and the DNS of
the gateway (which is also the forward server for the local DNS servers).

I don't know where to look now. I tried all solutions and debugging I've
found on the web, but I didn't find any evidence that states the problem.

I hope somebody sees a glimp of a possible error.
Click to expand...
Click to expand...
 
Back
Top