Develop Reference

Editing Local_Machine RegistryKeys Programmatically (C#)

I'm trying to make a program that changes the registry key values on remote machines to block/allow users from personalizing their lock-screen images. It seems the key I need to create is at HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Personalizationwith a name of NoChangingLockScreen.
I could easily do this with a .reg file and merge any changes into their registry (I planned on creating a windows service to monitor for changes in the file), although it seems I cannot even modify any keys inside the HKEY_LOCAL_MACHINE class.
Please note:
I am a domain admin across our network, and all remote computers have admin rights
This issue does not just occur when modifying a remote PC's keys, but my own as well
I've created the RegistryKey object as writable (See below code)
It seems I cannot even use the OpenSubKey method, as reading the local_machine path just throws an object exception
I've checked the permissions inside the Registry for that specific class and made sure my account had full control
I have found very little documentation on other people having permissions issues
RegistryKey myKey = Registry.LocalMachine.OpenSubKey(#"SOFTWARE\Policies\Microsoft\Windows", true);

Registry.ClassesRoot is for HKEY_CLASSES_ROOT. You need to use Registry.LocalMachine field like this:
using (var registryKey = Registry.LocalMachine.OpenSubKey(#"SOFTWARE\Policies\Microsoft\Windows", writable: true))
{
...
}
Also note, that this is for local registry access. If you wish to open remote registry, you need to use another method:
using (var remoteBaseKey = RegistryKey.OpenRemoteBaseKey(RegistryHive.LocalMachine, "RemoteMachineName"))
using (var registryKey = remoteBaseKey.OpenSubKey(#"SOFTWARE\Policies\Microsoft\Windows", writable: true))
{
...
}

TFS Error when writing logs to drop location: "The user name or password is incorrect."

I've used Azure File storage to configure a shared storage space that my Build Server has access to - https://azure.microsoft.com/en-us/blog/azure-file-storage-now-generally-available/
I used the following command to attach the space:
net use Z: \\portalxyz.file.core.windows.net\drops /u:portalxyz abcdef==
This works on both my Azure VMs (Build server included, with agents on it) and my local machine - I can see the drive and read/write to it.
However when I attempt a build after setting the drop location (in the build definition) to this share \\portalxyz.file.core.windows.net\drops, I get the following:
Exception Message: The user name or password is incorrect.
Looking at the exception details in the Event Log on the server, I can see that a service user is being used. I've logged into the machine as that user and mapped the space using the above command, but the error persists.
What am I doing wrong?

You Build Server needs to have the storage account key to access the Azure file share,
There are two options to achieve this
1) Create a system/service account using your Azure storage account name and key and then run the build server with this account
2) Use CMDKey to persistent the credential under current user context (refer to this blog for details)

To Set up a drop folder on a file share for your on-premises build controllers
You must be a member of the Administrators group on the computer where the drop folder resides.
More info about how to set up a drop folder on a file share from MSDN.

Access to registry seems to be different from different sources

I am trying to add a registry key in my C# code under
HKEY_CLASSES_ROOT\*\shell\blabla
I want the user to be able to send any file to my application, kind of like Open with UltraEdit or so.
I don't have administrator rights and the users won't have administrator privileges, too.
If I am doing that in my C# code as posted below, I get a
System.UnauthorizedAccessException
Registry.SetValue("HKEY_CLASSES_ROOT\\*\\shell\\blabla", null, "FastSearch");
string path = Application.ExecutablePath;
Registry.SetValue("HKEY_CLASSES_ROOT\\*\\shell\\blabla" + "\\Command", null, path + " \"%1\"");
If I run Regedit and attempt to do it manually myself, I get a similar error:
Error! Key could not be created. Error when writing to the registry.
BUT, if I double click a *.reg file that attempts to write the SAME KEY, everything works!
So why is that?
And do I have a chance to get this done through code?
Or should I just change my code to run that *.reg file?
UPDATE:
Actually the *.reg file did not write the SAME KEY as stated above, but
HKEY_CURRENT_USER\Software\Classes\*\shell\blabla
I didn't notice that. It seems as anything added under HKEY_CURRENT_USER\Software\Classes*\shell\blabla is also added to HKEY_CLASSES_ROOT\*\shell\blabla. Sorry for the confusion.

Although the problem is solved already and the reason for successful import of *.reg file was found out also in the meantime in comparison to C# code, here is a complete answer for this question.
HKEY_CLASSES_ROOT Key (short HKCR) as described by Microsoft shows file name extension associations and COM class registration information which are effective for the current user.
The real locations in registry for those keys are:
HKEY_LOCAL_MACHINE\Software\Classes (short HKLM\Software\Classes) containing the defaults for all users using a machine and
HKEY_CURRENT_USER\Software\Classes (short HKCU\Software\Classes) containing the user specific settings which override the default settings from HKLM\Software\Classes.
A registry write to HKEY_CLASSES_ROOT is always redirected to HKLM\Software\Classes. A write access to any key in HKLM requires administrative privileges which is the reason for the error message.
Microsoft recommends to write directly to either HKLM\Software\Classes or to HKCU\Software\Classes depending on changing the defaults or the effective file associations for the current user.
Write operations to keys under HKCU do not require administrative privileges.
HKCR should be used only for reading currently effective settings for file name extension associations and COM class registration information and not for adding or changing them.

Problems reading Windows Key on 64 bit machine

I want to read with a simple c# application the windows key from the registry. But on a x64 machine I recieve only BBBBB-BBBBB-BBBBB-BBBBB-BBBBB as the key and that is wrong... How can I fix that problem?
RegistryKey key = RegistryKey.OpenBaseKey(RegistryHive.LocalMachine, RegistryView.Registry64);
RegistryKey subkey = key.OpenSubKey("SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion");
Thanks!

According to this Web Site that makes CD Key recovery software and this Windows7Forums thread, the existance of all B's for the product ID is indicative of a MAK(Multiple Activation Key) key.
From First link:
The B’s means the cd key is not stored in your computer, so cannot be recovered. That can be due to a few reasons:
A MAK was used for activation;
SLMGR was used to remove the key from the windows registry,
or You’re running a pirated version of Windows.
From Second Link
This is a big problem when an administrator sets up many PCs with a
volume license key. Because everyone can extract the VLC key and use
it for additional installations. Because this reason the VLC key is
automatically deleted from the registry after activation. And after
this all key finder show only "not available" or
BBBBB-BBBBB-BBBBB-BBBBB-BBBBB. With command line: slmgr –dli you
can get a "Partial product key" – the last 5 characters of the product
key. This "Partial product key" is saved in encrypted form in the
certificate file "tokens.dat"
(C:\Windows\ServiceProfiles\NetworkService\AppData\Roaming\Microsoft\SoftwareProtectionPlatform\tokens.dat).
Everyone who fears that his key can be stolen can also delete manually
the product key from registry with this command line: slmgr –cpky
(cpky = clear product key = remove product key from the registry)

A quick web search shows many people with the same problem. One solution seems to be to get the DigitalProductID4 value if DigitalProductID is all B's.

Why does X509Certificate2 sometimes fail to create from a blob?

I have an ASP.NET web service which is receiving a byte array representing the contents of a .pfx file containing an X.509 certificate. The server-side code is using the System.Security.Cryptography.X509Certificate2 constructor to load the certificate from the bytes:
X509Certificate2 native_cert = new X509Certificate2(
pkcs12_buf /*byte array*/,
password,
X509KeyStorageFlags.PersistKeySet |
X509KeyStorageFlags.Exportable
);
Depending on who my service process is running as, this call will either succeed, or fail with an "internal error" exception. The last call on the exception stack is to X509Utils._LoadCertFromBlob, which is unmanaged code in mscore.dll.
This code succeeds when run from a console application in an interactive login using the service account's credentials. It fails when running under w3wp.exe in an application pool that uses the service account's credentials. Changing the app pool identity to an administrator fixes the problem, so it must be a privilege issue, but I have no idea what privilege could be necessary for this. The code does not touch either the filesystem or the Windows certificate stores.
[UPDATE: More Info]
This error appears in the Windows Event Log:
*Cryptographic Parameters:*
**Provider Name:** Microsoft Software Key Storage Provider
**Algorithm Name:** Not Available.
**Key Name:** {E182E13B-166D-472A-A24A-CBEF0808E9ED}
**Key Type:** User key.
*Cryptographic Operation:*
**Operation:** Open Key.
**Return Code:** 0x2
Any ideas?

I just found the solution to this one myself:
X509KeyStorageFlags flags = X509KeyStorageFlags.PersistKeySet | X509KeyStorageFlags.MachineKeySet;
X509Certificate2 cert = new X509Certificate2(pkcs12_buf, password, flags);
The trick here is to use the local key store MachineKeySet flag instead of the user profile key store, which is the default if you don't specify an alternative location. Because the ASP.NET process identity doesn't load the user profile store, you can't access the store when importing a certificate programmatically, but you can access the machine store.
I think PersistKeySet just keeps the private key loaded, but I'm not sure exactly what it does - it's required if you need to access the private key for some reason though.

Try granting the ASP.NET account permissions to the following folder: C:\Documents And Settings\All Users\Microsoft\Crypto\RSA\MachineKeys\ (may vary according to your environment)