Hello guys,
I have an annoying problem, my service account is getting locked when using copy-item
Exeample: copy-item \server1\Share1$\file1.txt \server2\Share2$\file1.txt
The account has admin rights on both servers.
The strange thing is the copy is successful for the first two attempts (two different files), but if I try a third copy, I get an error that “the username or password is incorrect”. At that time the account is locked.
I’ve requested a second service account and I get the same problem.
The commands are run from my laptop from a PowerShell console. The accounts are not used for other services, applications, drive mappings, task schedulers…
One mention, the service accounts are enrolled in CyberArk and they are set to renew the password each 48 hours, but when the lockout happens the password is still the same as it was when I logon into the PowerShell console. On the DC, the lockouts logs are pointing to my laptop. The accounts are getting unlocked automatically after a few hours. Restarting my laptop helps for a few days and I can run repeatedly copy-item without locking out the account, but eventually it starts getting locked again.
Invoke-command for example is working fine without locking the account.
Any idea what may be the cause ?
PowerShell : 5.1.22621.4391
My laptop: Windows 11
Servers: Windows server 2016,2022
Probably better to ask this on a general windows forum, since this really isn’t a Powershell issue in my opinion.
Have you not gone over the security logs on all 3 systems to see the root cause? It should be logged if your audit policy is properly configured. I would also have a look at stored creds on the laptop. “control keymgr.dll”
In my experiences every time I work with network shares and AD account lockouts, it’s almost always a persistent drive mapping.
To find out open a CMD prompt and type “net use” without the quotes
If you see any reference to the server or share you are using you need to remove it to get rid of those “persistent” mappings.
To delete one you type “net use \\$ServerName\$ShareName /delete”, I know what you’re thinking if you’re like me the word delete makes you nervous. So trust but verify you can type “net use /?” to see the help file for the net command and the use operator. “DELETE” is indeed the verb that team chose to use. Rest assured the files on the share will be safe it is the mapping on your machine that you are deleting and nothing else.
You need to replace the variables with the actual names. Additionally, if it’s too hard to figure out the syntax and if you don’t need any of the drive mappings to be persistent you can use the wild card method. “Net use * /DELETE” to remove them all. Your credentials are stored in persistent drive mappings and is a lot of times the cause of account lockouts when it comes to Windows File Shares.
And to disable these, enter the following
“net use /persistent:no”
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.