I'm working at a client site that uses AD for network authentication. My laptop is not domain connected, but I can reach their shared drives when hard-wired into their LAN by using a NET USE command like this:

net use S: \\<ServeName>\<Share> /persistent:no /user:<domain>\<username>

This will prompt me for my AD password and, when supplied, map the requested drive. Ninety-nine percent of the time, this works great. However, if I fat-finger or otherwise type the password incorrectly the command pauses for around 30 seconds and my AD account is subsequently locked out.

Is the NET USE command retrying the password? The number of retries is set to five, so that's not the problem. Is this command sending the credentials multiple times? Is it possible that I'm not getting the group retry policy because my workstation is not domain administered?

  • 1
    What is the account lockout threshold set to in the client's domain?
    – joeqwerty
    May 9 '17 at 18:36
  • @joeqwerty The threshold is set to 5 in the client's domain. However, when I do a NET ACCOUNTS command on my workstation the lockout threshold reports "Never", probably because it's reporting what's on my workstation, not the domain.
    – Bob Mc
    May 9 '17 at 19:32
  • Yes. The account lockout threshold on your machine isn't relevant to the domain and vice versa. I'd fire up a Wireshark capture on your machine and attempt the net use command again and see what's happening "under the covers".
    – joeqwerty
    May 9 '17 at 19:37
  • @joeqwerty Thanks Joe. I was hoping to not have to investigate down to the packet level, but I guess there's no hope for it. It may not be worth it since this is only when I'm not careful.
    – Bob Mc
    May 9 '17 at 20:12

Well in the documentation Net use Certainly doesn't seem to say anything about retrying password. As @joeqwerty says is irrelevant the policy in your local system when is a DC in between.

What I think that is happening is since your computer is not domain joined and it's accessing for an external system (outside the domain) the account automatically lock down since it's similar to somebody trying to access the account from the wire to hack it or something which makes more sense for me.

I think that saving a ".Bat" file with the initial line and the correct password will fix your fat fingering or human errors.

 net use * \d \y
 net use S: \\<ServeName>\<Share> /persistent:no /user:<domain>\<username>
  • Interesting take on the external system attack. That may be the answer. Can you explain how the first line helps? I'm already using a batch file with the second line. Your suggestion just deletes all existing shares. It will still prompt for a password, which is where I have to be more aware.
    – Bob Mc
    May 10 '17 at 13:20
  • Ohh the 1st line just helps to delete any previous drive connection, and the \d (delete) and \y (to confirm to delete). Basically, saves you the need to write every single drive letter, and removes them all. It's one common for me to set the GPOS in windows server logon scripts. but you can just use net use S: \d \y May 10 '17 at 13:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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