Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have 2 standalone servers (not in any domain/AD) - Windows 2003 and Windows 2008.

When connecting to shares on them, using the UNC path from Windows 2000 pro, or Samba (under linux), if I make a mistake typing the password, these servers will lock the account on first attempt.

It works OK, when connecting from Windows 2003, Windows 2008 and Vista.

On all the connecting machines, it'll report auth failure, and will ask for credentials again. But from Windows 2000 and Samba it'll continue to fail on the second attempt even if the password is correct. Trying to log to these machines will report account locked.

The policy set is to lock account on 10 failures, and it behaves correctly when the connection attempt is done from W2008 or W2003 - i.e. even if the first attempt fails, the next one will succeed.

I've done the experiment to unlock the account, the from W2000 box I intentionally try to log with bad password, and even without second attempt I can see that the account is locked.

Any idea what I may change, so I avoid this problem? It usually happens when I'm in a hurry (of course :) ), so dealing with logging on the machines to unlock the account is really frustrating.

share|improve this question
    
I'd suggest using Wireshark to determine if the W2K and Samba boxes are performing more than one authentication attempt per "password entry". Also you could compare the auth methods they use to the auth methods used by W2K3 or W2K8 clients. Also, I'm going to put on my "nagging mother hat" and remind you that Microsoft is ending all support for W2K on 13 July 2010 -- time to upgrade! –  fission Feb 27 '10 at 1:50
    
@fission: Thanks for the suggestion. Please, put an answer (not comment) with more detailed instructions what to look for in Wireshark. That way, your answer can be voted (or I can accept it) if it helps me to find solution for my problem. There's bounty after all :) –  Sunny Mar 1 '10 at 14:59
add comment

3 Answers

up vote 8 down vote accepted
+150

I'm not sure what your level of familiarity is with Wireshark, so my apologies if this is too verbose or terse. ;-)

Essentially you'd want to install and start Wireshark on either end – it shouldn't matter which – and begin capturing on the appropriate interface:

  1. In Wireshark, click the Capture menu, then Options…
  2. Select the appropriate interface.
  3. Since you mention you're not on a domain, I'd suggest entering a Capture Filter to limit the amount of captured traffic, something like:
    host 169.254.255.127
    The IP address should be for the remote host.
  4. Start the capture, then attempt to browse the share.
  5. Wait until the share appears, or you are presented with an invalid username/password box, then stop the capture.

I might suggest that you do this twice from each location; first, with a correct username and password; and second, with an invalid username and/or password. In between each attempt, be sure to disconnect from the remote share (so that it will re-request authentication), by doing:

net use \\remoteserver\SharedFolder /delete

What we are looking for here is SMB data, so the first way to prune out everything unrelated is to apply a simple Display filter in the Filter: field in the toolbars:

smb

In the beginning, you should see essentially three types of transmissions in the Info field:

  • Negotiate Protocol Request/Response
    These show the protocols supported by the client, and which protocol was accepted by the server. You can expand this out in the Packet details section to see whether the server is using NTLM, Kerberos, etc.
  • Session Setup AndX Request/Response
    This is authentication, which is hopefully happening in a challenge/response style. You'll see several possible Responses from the server:
    • STATUS_MORE_PROCESSING_REQUIRED: authentication is underway.
    • STATUS_LOGON_FAILURE: this is a logon failure – you will be most interested in these!
    • (nothing), in which case you can expand SMB > SMB Header and look for NT Status: STATUS_SUCCESS, which indicates a successful authentication.
  • Tree Connect AndX Request/Response
    This is the client asking to connect to a particular location on the server; you'll typically see accesses to IPC$ as well as the share you really want.

So what you're actually looking for, then, are lines that say STATUS_LOGON_FAILURE. Then, look one line above that to see which user failed to authenticate.

Now, it's typical to see login failures whenever you browse a share; that's because Windows tries to authenticate using the logged-on user account first. So don't be surprised to see, even between the "modern" OS families (2k3, Vista, 2k8), logon failures.

When I ran this test earlier, I saw three logon failures with LOCALCOMPUTER\localuser before it even tried to use REMOTECOMPUTER\remoteuser (which, in my case, succeeded on the first try). And when I tried it against a machine on another domain, I got ten logon failures! That's before it even prompted me for alternate credentials.

If you want to filter out everything but authentication, change the display filter to:

smb.cmd == 0x73

To see a list of all logon failures, change the display filter to:

smb.nt_status == 0xc000006d

Keep in mind that these logon failures might not have any impact, as typically the account won't exist on the remote machine (so there is no "negative accounting", so to speak, to be done for it).

Edit: You might want to pause for a few seconds when it prompts for alternate credentials, so that you have a clear idea of which authentication failures belong to the "automated" attempts, and which belong to you deliberately mistyping the credentials.

Let us know what you find out!

share|improve this answer
    
+1, Great answer. –  Massimo Mar 3 '10 at 6:59
    
Even if that I had no time to play with this, most probably it'll help me to identify the problem. Bounty for fission :) Cheers –  Sunny Mar 5 '10 at 17:11
    
Thanks! :-) If you do, let us know the result – I'm curious now to see what this is… –  fission Mar 5 '10 at 20:49
add comment

You are most likely having a problem with the difference between NTLM and NTLMv2. Windows 2000 and Samba default to NTLM which appears to a Windows 2003 and Windows 2008 server as a valid password attempt, but can't interpret the password correctly while expecting NTLMv2.

I believe that Windows 2000 can now support NTLMv2 along with the latest Samba bits...

You might try and configure your Windows 2000 and Samba to use NTLMv2...

Another strategy you might try is to downgrade the NTLM version on your Windows 2003/2008 servers to see if you still have the problems. I wouldn't leave it at NTLM, since NTLMv2 is much safer.

share|improve this answer
    
Thanks, but the problem is not that I can not authenticate at all. The problems is that it looks like W2k and Samba do not handle well (W2K8 returns something unusual) the second challenge when the first attempt fails. So they just make many more attempts with the same bad password, and the account get locked. –  Sunny Feb 24 '10 at 14:25
    
Sorry, re-read the question and I guess I missed the part where you mentioned the mistype... –  Dscoduc Feb 24 '10 at 15:47
add comment

This can happen if you have a user whose username is the same in two domains (but the password differs), and they try to connect from a machine in one domain to a machine in the other.

This could also be due to several sequential authentication challenges per connection attempt. There's a KB article and a Win2K fix at http://support.microsoft.com/kb/264678

You may want to disable authentication methods which you aren't using either way, for that matter. :)

share|improve this answer
    
Thanks, but this article is for W2K, my servers are 2003 and 2008. Also, my settings are for 10 unauthenticated requests, and I see locks after only one. I doubt there are 10 authentication methods. –  Sunny Feb 26 '10 at 22:59
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.