I’m trying to export the certificate to a network path. Unfortunately I will always get the following error:
2020-08-12 16:34:29.979 +02:00 [ERR] Failed to copy to destination file: \\<server>\<share>$\<path>\private.key:Der Zugriff auf den Pfad "\\<server>\<share>$\<path>\private.key" wurde verweigert.
I’ve tried it even without the dollor sign but, with the local and network user option but nothing worked so far.
Doing the same with a local path worked fine.
Access to the share is possible and I testet this with PowerShell. So this shouldn’t be the actual problem.
I’m in a domain so I used a domain user with the domain “prefix”.
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\user@email.com) 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.
Yep, you are right. It’s harder to get it right. I might should have posted the pic directly .
When creating a credential I can only choose the “Windows Credentials (Network)” when choosing the “Target Type” to be “Windows (Network)”. So this is what I filled in:
Or do I need to fill in “domain.com” for my domain?
Weird thing is that exporting it with the following credentials while choosing local folder works:
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.
I already had that info but thanks for explaining it again.
The path exists, there is no file with the same name in there (only one other) and with powershell (opened via “Open as different user”) I can overwrite the file.
You can change the debug log level in appsettings.json but that won’t help in this instance as there is no additional debug level logging for this feature.
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.
