Export certificate to network/UNC path failed

[nightmare1942]

Hello,

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”.

Any clues why this happens?

Best regards

[jljtgr]

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.

[jljtgr]

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.

[nightmare1942]

@jljtgr Thanks for these explainations but:

1. These are NOT the admin shares C$ or D$ but “sharename$” just to hide these.
2. Permissions are set bot on NTFS and Share side equally (RW access)
3. I tried it even without a hidden share … still the same error

So either way wasn’t working and I don’t know why.

And as I said, trying to access the share via powershell and creating a file through it was working as expected.

Maybe there is somethings else not working:

[jljtgr]

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.

[nightmare1942]

@jljtgr

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>$ .

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:

…image in next post…

[nightmare1942]

Is there a documentation on how to do it correctly (somewhere)?

[webprofusion]

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.

[webprofusion]

The other thing I’d check with this is what does the Event Log say on the target machine? The permission denial may be/should be logged there.

[nightmare1942]

@webprofusion

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.

I already had that info but thanks for explaining it again.

@webprofusion

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.

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.

[webprofusion]

Ok, I’ll investigate.

[nightmare1942]

@webprofusion

The other thing I’d check with this is what does the Event Log say on the target machine? The permission denial may be/should be logged there.

I looked into event logs but I couldn’t find anything about permission denial or anything like it.

@webprofusion

Ok, I’ll investigate.

Is there a way to turn on debug/trace logging?

[webprofusion]

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.

Behind the scenes we’re using https://github.com/mj1856/SimpleImpersonation so I wonder if the logon type is incorrect or if there is an async issue.

Could you try this test version of the deployment tasks dll?

https://certifytheweb.s3.us-east-1.amazonaws.com/downloads/test/Plugin.DeploymentTasks.Core.zip

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.

[nightmare1942]

@webprofusion Thx, I tried this new DLL and export is working fine now.
May I ask what has been the problem?

[webprofusion]

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.

[nightmare1942]

Okay, thanks for the info. I will use the provided DLL until then.

[webprofusion]

Hi, see the following thread for the next release candidate for testing:

Version 5.1.0 (Release Candidate) testing

Hi, Version 5.1.0 (Release Candidate) There is a new (release candidate) available for testing: https://certifytheweb.s3.us-east-1.amazonaws.com/downloads/archive/CertifyTheWebSetup_V5.1.0.exe This includes the following changes: Features: * Custom CSR (useful for SAP Netweaver and many other servers) and Custom Private Key support * RFC2136 DNS validation support via Posh-ACME and nsupdate * New Hashicorp Vault deployment task. * New Settings UI, including options to Enable/Disable previ…

[nightmare1942]

I’ve installed the RC version and it’s working.

[webprofusion]

Thanks, this version is now in general release as 5.1.2 - no issues reported so far.