C$, D$ etc are automatically generated admin shares. Any share made with a dollar sign($) means that it will be hidden if the machine is browsed to on the network, but it is part of the logical share name regardless of visibility and holds no other innate significance. If you were to make the share cdrive$, it would be hidden but not considered an admin share unless you restricted it that way manually.
If you are using the “admin” shares, only admin users of that machine may access them. I would expect that giving Certify credentials of a domain user that is considered an admin of <server> should work. Are you sure you are able to RDP to that machine using those credentials and perform elevated tasks? (admin users are always part of the RDP permission group, if RDP is enabled)
Lastly, the share permissions and NTFS permissions are different things… but if those credentials are considered for an admin, it shouldn’t come up.
As a side note… automatic admin shares are widely known as an attack vector for worms. Depending on your OS version, using them remotely may be disabled requiring a registry change to re-enable them. But by that point, you’re better off creating a new share that is not C$, D$, etc.
Well, obfuscating everything you explain makes it easy to misinterpret what you’re doing and makes it impossible to directly test your issue. C$ fits just as much as cdrive$ when all you say is <share>$.
I can’t really confirm it works. I don’t have multiple domain machines I can test this on… which means my only “domain” choice is the MicrosoftAccount prefix. (eg. MicrosoftAccount\[email protected]) When my target type is local, the service impersonates my local user even though I specify the MicrosoftAccount domain – so access denied. If I try the network target type, I get an error stating “Task with Windows Credentials requires username and password.”… which sounds like a separate issue. I don’t think it likes the @ in my username.
Hmm, so you want to use Windows Credentials (Network) and make sure that’s the credential type selected in the Deployment Task itself. Note that the file copy can’t elevate the user to Admin, it can impersonate but only in the same way as if you had opened powershell (for instance) without UAC.
The username format is DOMAIN\username and it does work for me but there could indeed be a bug I don’t know about. I’m assuming the folder path you are trying to copy to exists (the copy won’t create folders for you) and that the file either doesn’t exists already or can be overwritten without elevated permissions.
You’d just need to backup your copy of C:\Program Files\CertifyTheWeb\Plugins\Plugin.DeploymentTasks.Core.dll then copy this dll over the top of the existing one, restart the Certify background service and re-launch the UI.
We were using the Network logon type whereas it seems that for some uses the NewCredential logon types has more success: https://github.com/mj1856/SimpleImpersonation/issues/51 - I now need to test if Powershell would be better to use this method as well. This change will be in the next release.