We Keep Coding

Using XmlUriResolver to provide credentials to remote share

Thank you in advance for any and all help.
I have seen several post on Stack Overflow and other sites on the net (including Microsoft Docs), but none seeming to help resolve my issue.
I am working on a project that connects to a xml file on a remote file share from WinPE. I have used suggestions from another post on SO about using the XmlUriResolver class to "moderate" success.
The issue I am currently being faced with is either a "Access Denied" error (several attempts to modify the XmlUriResolver.Credentials class) or a complete failure without any reason for failure. I am assuming it is going to be another "Access Denied" error, but my try/catch (Exception e) isn't capturing the reason.
Below is a snippet and relevant part of the method I am trying to implement:
relativeSysData = relativeSysData.Replace(#"\", "/");
SysdataXml = $"file://{_globaldata.Server}/{_globaldata.Share}/{relativeSysData}";
XmlUrlResolver XmlResolver = new XmlUrlResolver();
XmlResolver.Credentials = new NetworkCredential(_UserName,
_Password);
XmlReaderSettings xmlSettings = new XmlReaderSettings();
xmlSettings.XmlResolver = XmlResolver;
LogWriter.WriteLogFile((int)LogWriter.EventID.Xml, (int)LogWriter.EventType.Info,
$"Connecting to (remote) System information store at: {SysdataXml}");
xDoc = XDocument.Load(XmlReader.Create(SysdataXml, xmlSettings));
if (xDoc == null)
{
LogWriter.WriteLogFile((int)LogWriter.EventID.XmlError, (int)LogWriter.EventType.Error,
$"Unable to connect to the (remote) data store located at: {SysdataXml}");
deploy = false;
capture = false;
return result;
}
This part of the method is specific to accessing the remote data. I have a try/catch statement encompassing all of the method.
If I have an open connection to the Network Share, the method will work flawlessly, but will cause the application this application starts to fail - due to an open connection already.
I have a possible alternative to work round this solution but will cost extra lines of code.
Any help in resolving this matter, without resorting to WNetAddConnection() will be gratefully received
Kind Regards
Richie
N.B. I am aware that this is an authentication issue.

After research into how the XmlUrlResolver class works, I think that it may be referencing/accessing API's that are not included within the WinPE API framework.
After testing, I have used the WNetAddConnection2() API to connect to the Server and authenticate before anything happens, ensuring that the local name of the NETRESOURCE structure is left null, and that DisplayType is set to Server.
public static int ConnectToServer()
{
int result = 0;
var _netresource = new NetResource()
{
scope = _ResourceScope.GlobalNetwork,
ResourceType = _ResourceType.Any,
DisplayType = _ResourceDisplayType.Server,
RemoteName = $#"\\{Program._globaldata.Server}"
};
string _username = $#"{Program._globaldata.Server}\RemoteDKBuild";
string _passsword = "Hic3nuasno6epyndtenars4yDifrts";
var _connectiontype = (int)_ConnectionType.Interactive | (int)_ConnectionType.Temporary;
LogWriter.WriteLogFile((int)LogWriter.EventID.NetMan, (int)LogWriter.EventType.Info,
$#"Attempting to connect to: \\{_netresource.RemoteName}");
result = WNetAddConnection2(_netresource, _passsword, _username, _connectiontype);
var res = Marshal.GetLastWin32Error();
if (result !=0)
{
LogWriter.WriteLogFile((int)LogWriter.EventID.NetMan, (int)LogWriter.EventType.Error,
$#"Failed to connect to: \\{_netresource.RemoteName}, Return Result: {result.ToString()}, Win32 Error Code: {res.ToString()}");
result = res;
}
else
{
LogWriter.WriteLogFile((int)LogWriter.EventID.NetMan, (int)LogWriter.EventType.Info,
$#"Connection to: \\{_netresource.RemoteName} has been successfull.");
}
return result;
}
[DllImport("mpr.dll", SetLastError = true)]
private static extern int WNetAddConnection2(NetResource netResource, string password, string username, int flags);

How do you programmatically fix a non-canonical ACL?

I have the following code:
DirectoryInfo directory = new DirectoryInfo(#"C:\Program Files\Company\Product");
if (!directory.Exists) { directory.Create(); }
DirectorySecurity directorySecurity = directory.GetAccessControl();
SecurityIdentifier securityIdentifier = new SecurityIdentifier(WellKnownSidType.BuiltinUsersSid, null);
directorySecurity.AddAccessRule(
new FileSystemAccessRule(
securityIdentifier,
FileSystemRights.Write,
InheritanceFlags.ContainerInherit | InheritanceFlags.ObjectInherit,
PropagationFlags.None,
AccessControlType.Allow));
directory.SetAccessControl(directorySecurity);
The call to AddAccessRule throws an InvalidOperationException with the following stack trace:
System.InvalidOperationException: This access control list is not in canonical form and therefore cannot be modified.
at System.Security.AccessControl.CommonAcl.ThrowIfNotCanonical()
at System.Security.AccessControl.CommonAcl.AddQualifiedAce(SecurityIdentifier sid, AceQualifier qualifier, Int32 accessMask, AceFlags flags, ObjectAceFlags objectFlags, Guid objectType, Guid inheritedObjectType)
at System.Security.AccessControl.DiscretionaryAcl.AddAccess(AccessControlType accessType, SecurityIdentifier sid, Int32 accessMask, InheritanceFlags inheritanceFlags, PropagationFlags propagationFlags)
at System.Security.AccessControl.CommonObjectSecurity.ModifyAccess(AccessControlModification modification, AccessRule rule, Boolean& modified)
at System.Security.AccessControl.CommonObjectSecurity.AddAccessRule(AccessRule rule)
at System.Security.AccessControl.FileSystemSecurity.AddAccessRule(FileSystemAccessRule rule)
This only happens on some systems (I've seen Windows XP and Windows 7). In the situations where the error occurs, viewing the security permissions for the directory using Windows Explorer usually causes a message box to be shown with the following text:
The permissions on are incorrectly ordered, which may
cause some entries to be ineffective. Press OK to continue and sort
the permissions correctly, or Cancel to reset the permissions.
Clicking OK at this point fixes the problem. What's going on here? How does a system get into this state, and is there any way to detect/fix it programmatically (i.e. without having the user manually use Explorer to fix this)?
Update
I did a bit more research about ACL, what canonical form is, and why it's necessary. I'm still not sure how a file would normally get into this state, but I found that the Icacls tool can be used to create a directory with a non-canonical ACL by saving the permission list, altering it to be out-of-order, and restoring it. Now I just need a way to fix it without requiring user interaction.

I found the solution to this in an MSDN blog post: Say wwhhhaaaat? - The access control list is not canonical. Basically, you need to construct a new DACL with the same permissions, but in the correct canonical order:
static void Main(string[] args)
{
// directory with known ACL problem (created using Icacls)
DirectoryInfo directoryInfo = new DirectoryInfo("acltest");
var directorySecurity = directoryInfo.GetAccessControl(AccessControlSections.Access);
CanonicalizeDacl(directorySecurity);
directoryInfo.SetAccessControl(directorySecurity);
}
static void CanonicalizeDacl(NativeObjectSecurity objectSecurity)
{
if (objectSecurity == null) { throw new ArgumentNullException("objectSecurity"); }
if (objectSecurity.AreAccessRulesCanonical) { return; }
// A canonical ACL must have ACES sorted according to the following order:
// 1. Access-denied on the object
// 2. Access-denied on a child or property
// 3. Access-allowed on the object
// 4. Access-allowed on a child or property
// 5. All inherited ACEs
RawSecurityDescriptor descriptor = new RawSecurityDescriptor(objectSecurity.GetSecurityDescriptorSddlForm(AccessControlSections.Access));
List<CommonAce> implicitDenyDacl = new List<CommonAce>();
List<CommonAce> implicitDenyObjectDacl = new List<CommonAce>();
List<CommonAce> inheritedDacl = new List<CommonAce>();
List<CommonAce> implicitAllowDacl = new List<CommonAce>();
List<CommonAce> implicitAllowObjectDacl = new List<CommonAce>();
foreach (CommonAce ace in descriptor.DiscretionaryAcl)
{
if ((ace.AceFlags & AceFlags.Inherited) == AceFlags.Inherited) { inheritedDacl.Add(ace); }
else
{
switch (ace.AceType)
{
case AceType.AccessAllowed:
implicitAllowDacl.Add(ace);
break;
case AceType.AccessDenied:
implicitDenyDacl.Add(ace);
break;
case AceType.AccessAllowedObject:
implicitAllowObjectDacl.Add(ace);
break;
case AceType.AccessDeniedObject:
implicitDenyObjectDacl.Add(ace);
break;
}
}
}
Int32 aceIndex = 0;
RawAcl newDacl = new RawAcl(descriptor.DiscretionaryAcl.Revision, descriptor.DiscretionaryAcl.Count);
implicitDenyDacl.ForEach(x => newDacl.InsertAce(aceIndex++, x));
implicitDenyObjectDacl.ForEach(x => newDacl.InsertAce(aceIndex++, x));
implicitAllowDacl.ForEach(x => newDacl.InsertAce(aceIndex++, x));
implicitAllowObjectDacl.ForEach(x => newDacl.InsertAce(aceIndex++, x));
inheritedDacl.ForEach(x => newDacl.InsertAce(aceIndex++, x));
if (aceIndex != descriptor.DiscretionaryAcl.Count)
{
System.Diagnostics.Debug.Fail("The DACL cannot be canonicalized since it would potentially result in a loss of information");
return;
}
descriptor.DiscretionaryAcl = newDacl;
objectSecurity.SetSecurityDescriptorSddlForm(descriptor.GetSddlForm(AccessControlSections.Access), AccessControlSections.Access);
}

There are extention methods for 'RawAcl' which seem to canonalize wrong ACEs.
But it's kind of mysterious. The methods are just present and I haven't found any documentation. Looking at the sourcode of .net 4.8 DirectoryObjectSecurity the author complains: A better way would be to have an internal method that would canonicalize the ACL and call it once
This is the signature of the methods:
{
//
// Summary:
// Canonicalizes the specified Access Control List.
//
// Parameter:
// acl:
// The Access Control List.
public static void Canonicalize(this RawAcl acl);
//
// Summary:
// Sort ACEs according to canonical form for this System.Security.AccessControl.ObjectSecurity.
//
// Parameter:
// objectSecurity:
// The object security whose DiscretionaryAcl will be made canonical.
public static void CanonicalizeAccessRules(this ObjectSecurity objectSecurity);
}
But As we know, there are ACEs which cannot be canonalized without lost of informations. These extention methods have no return value and seem not to throw any exception for this case. Therefore it may come to loss of informations using them. And the great answer from Kevin Kibler ma be the better way doing this.

Outlook 2k7 Integration (via P/Invoke) - Blocking unsafe attachments

We're currently developing a plug-in for a piece of software in C#. This plug-in extracts the contents of a PST file and stores all items in it as text files (with the exception of attachments, which are stored as their type in the same folder as the email).
It has been working without issue until we tested it on Windows 7 w/ Outlook 2K7. After running the same previous job on a machine with Outlook 2000 on it, we noticed that there were over 12,000 files missing. These files turned out to be attachments (mostly URLs)
We found that the issue is that Outlook 2K7 blocks attachments with specific extensions. If you open the email in Outlook itself, you see a blue bar at the top stating "Outlook blocked access to the following potentially unsafe attachments" and all the attachments in the emails.
Is there a way to programmatically get these attachments without Outlook blocking them?
The code we use to save the attachments is:
private void saveAttachment(ref object oEmail, StoreInfo currentStoreInfo, string sEmailID, string sExportPath)
{
int iAttachCount = 0;
object oAttach = null;
oAttach = getNextAttachment(oEmail, ref iAttachCount);
while (oAttach != null)
{
saveAttachment(sEmailID, sExportPath, oAttach);
oAttach = getNextAttachment(oEmail, ref iAttachCount);
}
}
private object getNextAttachment(object oEmail, ref int iAttachCount)
{
object oAttach = null;
try
{
iAttachCount++;
oAttach = GetProperty(oEmail, "Attachments", new object[] { iAttachCount });
}
catch //(Exception ex)
{
// There was no attachment to be gotten
oAttach = null;
}
return oAttach;
}

Just putting this on here in case anybody else runs into the same issue. Outlook 2K7 has a Level1 file type feature that blocks access to attachments with specific extensions.
However, you can change the registry to allow access to these files. Just remember to set it back to the way it was prior to you modifying it for security's sake.
private void SetLevel1RemoveValues()
{
// Get the base key for the current user HKEY_CURRENT_USER
Microsoft.Win32.RegistryKey regKey = Microsoft.Win32.RegistryKey.OpenRemoteBaseKey(Microsoft.Win32.RegistryHive.CurrentUser, "");
// Get the security key from the registry
Microsoft.Win32.RegistryKey subKey = regKey.OpenSubKey("Software\\Microsoft\\Office\\" + sCurrentOutlookVersion + ".0\\Outlook\\Security", true);
// If the Outlook\Security key doesn't exit, create one
if (subKey == null)
subKey = regKey.CreateSubKey("Software\\Microsoft\\Office\\" + sCurrentOutlookVersion + ".0\\Outlook\\Security");
// Loop through each Value in the registry to see if the Level1Remove key already exists.
string[] sValues = subKey.GetValueNames();
bool bHasLevel1RemoveKey = false;
foreach (string sValue in sValues)
if (sValue == "Level1Remove")
bHasLevel1RemoveKey = true;
// If the key already exists, store the data so we can reset it later
if (bHasLevel1RemoveKey)
sPrevLevel1RemoveValues = subKey.GetValue("Level1Remove").ToString();
else
sPrevLevel1RemoveValues = "";
// Create an array of all Level 1 Extensions
string[] level1Extensions = new string[] { ".ade", ".adp", ".app", ".asp", ".bas", ".bat",
".cer", ".chm", ".cmd", ".com", ".cpl", ".crt", ".csh", ".exe", ".fxp", ".gadget",
".hlp", ".hta", ".inf", ".ins", ".isp", ".its", ".js", ".jse", ".ksh", ".lnk",
".mad", ".maf", ".mag", ".mam", ".maq", ".mar", ".mas", ".mat", ".mau", ".mav", ".maw",
".mda", ".mdb", ".mde", ".mdt", ".mdw", ".mdz", ".msc", ".msi", ".msp", ".mst", ".ops",
".pcd", ".pif", ".pfr", ".prg", ".pst", ".reg", ".scf", ".scr", ".sct", ".shb", ".shs",
".tmp", ".url", ".vb", ".vbe", ".vbs", ".vsmacros", ".vss", ".vst", ".vsw",
".ws", ".wsc", ".wsf", ".wsh" };
// Set the value in the registry to the list of all Level 1 extensions so we can extract them
subKey.SetValue("Level1Remove", string.Join(";", level1Extensions));
// Close (and save) the values
subKey.Close();
regKey.Close();
}

What's wrong with Registry.GetValue?

I trying to get a registry value:
var value = Registry.GetValue(#"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography", "MachineGuid", 0);
In Windows XP all ok, but in Windows 7 returns 0. In HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography using regedit I see MachineGuid, but if I run
var keys = Registry.LocalMachine.OpenSubKey("SOFTWARE").OpenSubKey("Microsoft").OpenSubKey("Cryptography", RegistryKeyPermissionCheck.ReadSubTree).GetValueNames();
keys.Length is 0.
What do I do wrong? With other values all ok in both of OS.

The problem is that you probably are compiling the solution as x86, if you compile as x64 you can read the values.
Try the following code compiling as x86 and x64:
class Program
{
static void Main(string[] args)
{
Console.WriteLine("MachineGUID:" + MachineGUID);
Console.ReadKey();
}
public static string MachineGUID
{
get
{
Guid guidMachineGUID;
if (Microsoft.Win32.Registry.LocalMachine.OpenSubKey("SOFTWARE\\Microsoft\\Cryptography") != null)
{
if (Microsoft.Win32.Registry.LocalMachine.OpenSubKey("SOFTWARE\\Microsoft\\Cryptography").GetValue("MachineGuid") != null)
{
guidMachineGUID = new Guid(Microsoft.Win32.Registry.LocalMachine.OpenSubKey("SOFTWARE\\Microsoft\\Cryptography").GetValue("MachineGuid").ToString());
return guidMachineGUID.ToString();
}
}
return null;
}
}
}
You can read more about Accessing an Alternate Registry View.
You can found in here a way of reading values in x86 and x64.

It probably has to do with UAC (User Account Control). The extra layer of protection for Windows Vista and Windows 7.
You'll need to request permissions to the registry.
EDIT:
Your code right now:
var keys = Registry.LocalMachine.OpenSubKey("SOFTWARE")
.OpenSubKey("Microsoft")
.OpenSubKey("Cryptography", RegistryKeyPermissionCheck.ReadSubTree)
.GetValueNames();
Only requests the permissions on the Cryptography subkey, maybe that causes the problem (at least I had that once), so the new code would then be:
var keys = Registry.LocalMachine.OpenSubKey("SOFTWARE", RegistryKeyPermissionCheck.ReadSubTree)
.OpenSubKey("Microsoft", RegistryKeyPermissionCheck.ReadSubTree)
.OpenSubKey("Cryptography", RegistryKeyPermissionCheck.ReadSubTree)
.GetValueNames();
EDIT2:
I attached the debugger to it, on this code:
var key1 = Registry.LocalMachine.OpenSubKey("SOFTWARE", RegistryKeyPermissionCheck.ReadSubTree);
var key2 = key1.OpenSubKey("Microsoft", RegistryKeyPermissionCheck.ReadSubTree);
var key3 = key2.OpenSubKey("Cryptography", RegistryKeyPermissionCheck.ReadSubTree);
var key4 = key3.GetValueNames();
It turns out, you can read that specific value, at least that's my guess, because all data is correct, until I open key3, there the ValueCount is zero, instead of the expected 1.
I think it's a special value that's protected.

You say you're on 64-bit Windows: is your app 32-bit? If so it's probably being affected by registry redirection and is looking at HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Cryptography. You may have to P/Invoke to work around it: http://msdn.microsoft.com/en-us/library/aa384129.aspx.

If you're not an administrator, you only have read permission on HKLM. You need to open the key read-only instead. Not sure how to do that with .NET's Registry class; with the API directly, you use RegOpenKeyEx() with the KEY_READ flag.
EDIT: After checking MSDN, I see that OpenSubKey() does open read only, and returns the contents if it succeeds and nothing if it fails. Since you're chaining multiple OpenSubKey calls, it's most likely one of them that's failing that causes the others to fail. Try breaking them out into separate calls, and checking the intermediate values returned.

Maybe a little late to the party, but, none of the solutions worked for me.
This is how I've solved this issue:
public static Guid GetMachineGuid
{
get
{
var machineGuid = Guid.Empty;
var localMachineX64View = RegistryKey.OpenBaseKey(RegistryHive.LocalMachine, RegistryView.Registry64);
var cryptographySubKey = localMachineX64View.OpenSubKey(#"SOFTWARE\Microsoft\Cryptography");
if (cryptographySubKey == null) return machineGuid;
var machineGuidValue = (string)cryptographySubKey.GetValue("MachineGuid");
Guid.TryParse(machineGuidValue, out machineGuid);
return machineGuid;
}
}

I solved the problem when i imported Microsoft.Win32 and changed the application-settings to x64 like pedrocgsousa mentioned.

How to search for specific value in Registry keys

How can I search for specific value in the registry keys?
For example I want to search for XXX in
HKEY_CLASSES_ROOT\Installer\Products
any code sample in C# will be appreciated,
thanks

In case you don't want to take a dependency on LogParser (as powerful as it is): I would take a look at the Microsoft.Win32.RegistryKey class (MSDN). Use OpenSubKey to open up HKEY_CLASSES_ROOT\Installer\Products, and then call GetSubKeyNames to, well, get the names of the subkeys.
Open up each of those in turn, call GetValue for the value you're interested in (ProductName, I guess) and compare the result to what you're looking for.

Help here...
Microsoft has a great (but not well known) tool for this - called LogParser
It uses a SQL engine to query all kind of text based data like the Registry,
the Filesystem, the eventlog, AD etc...
To be usable from C#, you need to build an Interop Assembly from the
Logparser.dll COM server using following (adjust LogParser.dll path)
command.
tlbimp "C:\Program Files\Log Parser 2.2\LogParser.dll"
/out:Interop.MSUtil.dll
Following is a small sample, that illustrates how to query for the Value
'VisualStudio' in the \HKLM\SOFTWARE\Microsoft tree.
using System;
using System.Runtime.InteropServices;
using LogQuery = Interop.MSUtil.LogQueryClass;
using RegistryInputFormat = Interop.MSUtil.COMRegistryInputContextClass;
using RegRecordSet = Interop.MSUtil.ILogRecordset;
class Program
{
public static void Main()
{
RegRecordSet rs = null;
try
{
LogQuery qry = new LogQuery();
RegistryInputFormat registryFormat = new RegistryInputFormat();
string query = #"SELECT Path from \HKLM\SOFTWARE\Microsoft where
Value='VisualStudio'";
rs = qry.Execute(query, registryFormat);
for(; !rs.atEnd(); rs.moveNext())
Console.WriteLine(rs.getRecord().toNativeString(","));
}
finally
{
rs.close();
}
}
}

This method will search a specified registry key for the first subkey that contains a specified value. If the key is found then the specified value is returned. Searchign is only one level deep. If you require deeper searching then I suggest modifying this code to make use of recursion. Searching is case-sensitive but again you can modify that if required.
private string SearchKey(string keyname, string data, string valueToFind, string returnValue)
{
RegistryKey uninstallKey = Registry.LocalMachine.OpenSubKey(keyname);
var programs = uninstallKey.GetSubKeyNames();
foreach (var program in programs)
{
RegistryKey subkey = uninstallKey.OpenSubKey(program);
if (string.Equals(valueToFind, subkey.GetValue(data, string.Empty).ToString(), StringComparison.CurrentCulture))
{
return subkey.GetValue(returnValue).ToString();
}
}
return string.Empty;
}
Example usage
// This code will find the version of Chrome (32 bit) installed
string version = this.SearchKey("SOFTWARE\\WOW6432Node\\Microsoft\\Windows\\CurrentVersion\\Uninstall", "DisplayName", "Google Chrome", "DisplayVersion");

#Caltor your solution gave me the answer I was looking for. I welcome improvements or a completely different solution that does not involve the registry. I am working with enterprise applications on Windows 10 with devices joined to Azure AD. I want/need to use Windows Hello for devices and for HoloLens 2 in a UWP app. My problem has been getting the AAD userPrincipal name from Windows 10. After a couple days searching and trying lots of code I searched the Windows Registry for my AAD account in the Current User key and found it. With some research it appears that this information is in a specific key. Because you can be joined to multiple directories there may be more than one entry. I was not trying to solve that issue, that is done with the AAD tenant Id. I just needed the AAD userPrincipal name.
My solution de-dups the return list so that I have a list of unique userPrincipal names. App users may have to select an account, this is tolerable for even HoloLens.
using Microsoft.Win32;
using System.Collections.Generic;
using System.Linq;
namespace WinReg
{
public class WinRegistryUserFind
{
// Windows 10 apparently places Office/Azure AAD in the registry at this location
// each login gets a unique key in the registry that ends with the aadrm.com and the values
// are held in a key named Identities and the value we want is the Email data item.
const string regKeyPath = "SOFTWARE\\Classes\\Local Settings\\Software\\Microsoft\\MSIPC";
const string matchOnEnd = "aadrm.com";
const string matchKey = "Identities";
const string matchData = "Email";
public static List<string> GetAADuserFromRegistry()
{
var usersFound = new List<string>();
RegistryKey regKey = Registry.CurrentUser.OpenSubKey(regKeyPath);
var programs = regKey.GetSubKeyNames();
foreach (var program in programs)
{
RegistryKey subkey = regKey.OpenSubKey(program);
if(subkey.Name.EndsWith(matchOnEnd))
{
var value = (subkey.OpenSubKey(matchKey) != null)? (string)subkey.OpenSubKey(matchKey).GetValue(matchData): string.Empty;
if (string.IsNullOrEmpty(value)) continue;
if((from user in usersFound where user == value select user).FirstOrDefault() == null)
usersFound.Add(value) ;
}
}
return usersFound;
}
}
}