Azure Functions: Managed Identity, Microsoft Graph, and Roles to Read Security Events

It may be necessary to automate processing of Security Alerts from Microsoft Graph through an Azure Function. In order to do this, the Azure Function needs to have the role permissions to read Security Events in Microsoft Graph.

To accomplish this, you’ll need to create a Managed Identity for the Azure Function. Once that has been created, we’ll use PowerShell to assign the permissions to that Managed Identity in Azure.

$msi = Get-AzureADServicePrincipal -ObjectId <Managed Identity GUID>
$graph = Get-AzureADServicePrincipal -Filter “AppId eq ‘00000003-0000-0000-c000-000000000000′”
$role = $graph.AppRoles | Where{$_.Value -eq “SecurityEvents.Read.All”}
New-AzureADServiceAppRoleAssignment -ObjectId $msi.ObjectId -PrincipalId $msi.ObjectId -Id $role.Id -ResourceId $graph.ObjectId

Now that the permission has been assigned, your Azure Function should be able to read the Security Events from Microsoft Graph. This is because the AzureServiceTokenProvider automatically leverages the managed identity when you use it to obtain an Access Token for Microsoft Graph.

Happy dev’ing!

Multi-Version .NET Targeting and the Subsequent System.Net.Http Issue[s]

When developing an library that targets multiple .NET versions, you most likely start-off with a .NET Standard library and change the CSPROJ file to include other .NET versions.

When you do this, Visual Studio and/or NuGet have a hard time deciphering just which verison of the System.Net.Http assembly to use. You’ll see this manifest as the below exception:

CS0234 C# The type or namespace name ‘Http’ does not exist in the namespace ‘System.Net’ (are you missing an assembly reference?)

The easiest way to fix/resolve this, despite what other links on the internet tell you is a plausible route to use, is to tell Visual Studio which version of the .NET Framework assembly that you want to use (as that is the assembly that it cannot resolve).

You can do this by adding the below into your Item Group:

<PackageReference Include=”System.Net.Http” Version=”4.3.0″/>

Save the CSPROJ file and, after a few seconds, Visual Studio should now be able to resolve the assembly and the exception[s] should go away.

Thanks for coming to this TEDPost and happy dev’ing!

.NET Core 2.0: Expression: [Recursive resource lookup bug]

When developing Azure Functions and targeting .NET Core 2.0 (or higher), you may run into an infinite recursion bug that prevents you from successfully building the Azure Function; worst of all is that it may happen at a seeming random time.

Assert Failure
Expression: [Recursive resource lookup bug]
Description: Infinite recursion during resource lookup within System.Private.CoreLib.  This may be a bug in System.Private.CoreLib, or potentially in certain extensibility points such as assembly resolve events or CultureInfo names.
Resource name: ArgumentNull_Generic

When you go looking for any related bugs/issues, you’ll find all of them resolved around the last quarter of 2019 with a note that it’s been fixed in .NET Core 2.0.3.

.NET Core 2.0.3 is a servicing update to .NET Core and it isn’t pushed through Windows Update – because reasons, I guess?

becauseFuckYouThatsWhy

The easiest way to get around this issue is to move from .Net Core 2.0.0 to .NET Core 2.0.3. The SDK can be found here and the Runtime can be found here.

After installing, all of your localisation will be clear-sailing without even a hint or a trace of infinite recursion at build-time from that point-forward.

Happy dev’ing! =]

iTunes: Save Your Money and Don’t But the Singles, Buy the EP

A new album, Innan det tar slut, dropped on 29 Nov 2019 and I finally got around to purchasing it today. When I went to play the six track album, here’s what it looked like in iTunes:

It’s a six song EP. So, where did the rest of the songs go?

Well, they were singles that I had bought before the album dropped (see the “More by GAMMAL” section in the photo); so, they only show up if I tap Visa komplett album or I go into the singles’ albums.

What’s even more fun is if I tap on a song I already own, from this full album view, – say Hemma Igen – Apple wants me to sign-up for Apple Music. Apparently, I can only play them from the limited album view, I guess?

Some might try to argue that a single from the single album and the same song from the EP are – in fact – logically different songs; however, unless the ones and zeroes of these two files differs and they’re of different sizes, then they’re actually the same song! In fact, iTunes considers that I already own the songs, I just haven’t “downloaded” them, yet. (Fun-filled fact: They exist under the album single album forevermore,)

Anyways, long-story short of it is that you should just wait for the full album to drop and buy it all at once, rather than dealing with such nonsensical maladies of music listening.

…but you don’t have to take my word for it! The internet is littered with complaints regarding this same issue and it looks like Apple is not going to fix it any time soon.

So, don’t fall into the same trap. Just wait for the album. 🙃

C#: Recursively Getting Subfolders Whilst Ignoring the Errors that Would Stop Other Traversal Means

So, I’m writing something that is – eventually – meant to scrub the harddrive on IoC (indicators of compromise). The first major problem to solve is the following:

If I have drive ‘C:\’, and I try to enumerate all of the folders under the drive, Directory.EnumerateDirectories (including the recursive search option of all directories), then the first exception that throws stops the iteration – entirely.

This is, I suppose, desired behaviour from a code-provider’s perspective but entirely undesirable from a code consumer’s perspective.

So, how can we get around this? Well, we need a way to “swallow” the exceptions but to carry-on with the folders that we can access but we need to keep processing for this to occur. Instead of nesting foreach ad-infinitum (because we never know how deep or shallow the traversal might be), we would – instead – call the method recursively on itself.

So, it breaks down in the following code:

private static void EnumerateSubfolders(string path)
{
try
{
string[] directories = Directory.EnumerateDirectories(path).ToArray();
foldersList.AddRange(directories);
foreach (string directory in directories)
{
EnumerateSubfolders(directory);
}
}
catch
{
// Dispose of all of the exceptions about access because we can’t do anything about them.
}
}

Note that all we’re doing is going one child-folder deep, adding the results to the list of string of folders and then for each of those, traversing one child-folder deep, again. In this way, even if we hit an exception, we’ve gone one child deep and we stop processing for that child – without it affecting the traversal of the other children; which, while not the idyllic for obtaining all of the folders in Windows, is a far cry better than the entire process stopping on the first exception thrown.

Happy programming! 🙂

 

 

Zen Installer: Installing Arch Linux and the Subsequently Confusing FSCK Issue

So, I recently installed Arch Linux (via the Zen Installer) and all went well. Well, until I removed the USB the OS was installed from and rebooted, that is…

systemd_fsck_dependency_failure

Plug the USB stick back in and the system would boot normally. Checked FSTAB and it looked entirely valid and was, since the system was in running state when I did.

Markering_001

O.k., let’s try this again but this time check the journal (journalctl -xb) to see what’s happening.

jul 14 21:37:42 [REDACTED] systemd[1]: Starting File System Check on /dev/sdb1…
jul 14 21:37:42 [REDACTED] systemd-fsck[463]: /dev/sdb1: 17 files, 12139/130807 clusters
jul 14 21:37:42 [REDACTED] systemd[1]: Started File System Check on /dev/sdb1.
jul 14 21:37:42 [REDACTED] audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg=’[email protected] comm=”systemd” exe=”/usr/lib/systemd/systemd” hostname=? addr=? terminal=? res=success’
jul 14 21:37:42 [REDACTED] kernel: audit: type=1130 audit(1563133062.173:11): pid=1 uid=0 auid=4294967295 ses=4294967295 msg=’[email protected] comm=”systemd” exe=”/usr/lib/systemd/systemd” hostname=? addr=? terminal=? res=success’
jul 14 22:19:49 [REDACTED] systemd[1]: [email protected]: Succeeded.
jul 14 22:19:49 [REDACTED] systemd[1]: Stopped File System Check on /dev/sdb1.
jul 14 22:19:49 [REDACTED] audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg=’[email protected] comm=”systemd” exe=”/usr/lib/systemd/systemd” hostname=? addr=? terminal=? res=success’
jul 14 22:19:49 [REDACTED] kernel: audit: type=1131 audit(1563135589.643:55): pid=1 uid=0 auid=4294967295 ses=4294967295 msg=’[email protected] comm=”systemd” exe=”/usr/lib/systemd/systemd” hostname=? addr=? terminal=? res=success’
jul 14 22:21:44 [REDACTED] systemd[1]: dev-sdb1.device: Job dev-sdb1.device/start timed out.
jul 14 22:21:44 [REDACTED] systemd[1]: Timed out waiting for device /dev/sdb1.
jul 14 22:21:44 [REDACTED] systemd[1]: Dependency failed for File System Check on /dev/sdb1.
jul 14 22:21:44 [REDACTED] systemd[1]: [email protected]: Job [email protected]/start failed with result ‘dependency’.
jul 14 22:21:44 [REDACTED] systemd[1]: dev-sdb1.device: Job dev-sdb1.device/start failed with result ‘timeout’.

Well, that didn’t help too much, save to tell me that fsck can’t load a dependency. Wait a minute… It can’t be… Can it?

Ctrl+Alt+F1 to open the terminal. Nano’ed fstab. Changed all of the sdb to sda (since the usb was no longer plugged in) and rebooted. It worked.

So, here’s what was happening:

When the USB drive was plugged in, the HDD drive was /dev/sdb. When the USB was not plugged in, it was no longer /dev/sda but the HDD was now /dev/sda.

The ultimate work-around to prevent this from happening again? Use the UUIDs instead of the non-static drive assignments, as the kernel’s name descriptors are not persistent. (See the Arch Linux Wiki for more details.)

Obligatory desktop screenshot? Obligatory desktop screenshot.

Markering_004

 

 

NuGet: Targeting All of the .NET Versions Plausible (The Easy Way)

I recently published a NuGet package that targets .NET vesions from 4.5 to the latest (currently, 4.8). (I could only go back to .NET 4.5 because that’s when HttpClient first dropped. Sorry, not sorry.)

In previous NuGet packages, I had to set-up different build iterations for each .NET version and build them all, independently and manually. This was not a fun process, to be sure.

So, how did I do this latest NuGet package so I didn’t have to go through all of that heartache? Well, when you create a new project in Visual Studio, select Class Library (.NET Standard).

Trust me, I’m aware it seems counter-intuitive to do this but there’s a trick coming up that will save you hours of work and heartache.

One the project is loaded, right click on the Project in Solution Explorer and select Edit Project File. One here, you should see some XML beginning with

<Project Sdk=”Microsoft.NET.Sdk”>

and a node that has TargetFrameworkVersion. We’re going to change this and replace the line to be plural-indicative:

<TargetFrameworks>net45;net451;net452;net46;net461;net462;net47;net471;net472;net48;</TargetFrameworks>

Once this is done, we’re going to do one more thing to make our lives 1000% easier:

Right-click the Project in Solution Explorer, again, click Properties. Select the Package tab. Here, you’ll see most of the fields that you would expect to see in a nuspec file. Edit these fields to contain the values that you want and then select Generate NuGet package on build and, if you require the license to be accepted, Require license acceptance.

Now, you’ll have to close and re-open Visual Studio when you save everything but, trust me, this is a far more favourable pain than individually building to each .NET target.

When you build in this project, now, you’ll get a nupkg dropped into your flavour folder (debug or release), which you can then upload into NuGet. The nupkg will – automatically – contain all of the .NET versioned binaries for you. No more action is required on your part.

That’s it! You can now target multiple .NET versions for your NuGet package, without having to do much of anything else (except to ensure that what you’re targeting is included in versions of .NET that you’re targeting and, if not, code for those conditions).

Happy coding! 🙂

 

HttClient: The Myths Behind ‘Using’ on a ReEntrant Object

In developing a solution in Azure to [REDACTED], I discovered a “bug” in HttpClient that seems to be somewhat common knowledge but I figured that I would share it with you, in case you run into the same problems.

This bug surfaced – moreso – because we’re using Azure, than anything else. You see, anything in Azure should be considered multitenancy; meaning that your app is running parallel to – potentially – hundreds of other apps within the infrastructure’s backplane.

So, I was using Parallel.ForEach and .ctor’ing a new HttpClient per thread and making a call to obtain data from a rest endpoint from a unique sub-url; which was entirely dependent on data that I had previously obtained via another rest call. Obscurity is strong with this one, I’m aware.

Every once in a while, I would get the exceptions (by unboxing them): “Only one usage of each socket address (protocol/network/port) is normally permitted: <ipAddressGoesHere>.

In technicality, I was only using one address per HttpClient but there’s a catch/caveat to all of this. Even if you use the ‘using‘ statement, the IDispose interface isn’t immediately called.

The socket would still be in use, even if it were. This is because the socket that the HttpClient uses is put into TIME_WAIT. So, you have an open socket in use to that host and because the host hasn’t closed the socket, if you instantiated all new HttpClients (which used new ephemeral ports), you could potentially run out of ports to consume.

…but, wait, there’s more!™

The HttpClient is considered reentrant (and this is where our true problem comes in). This means that some (if not all) of your non-disposed of HttpClients could be re-used to try to go what the HttpClient considers a currently in-use object (because the port is still considered open when it’s in TIME_WAIT).

In fact, if we chase down the SocketException –> Win32Exception –> hResult, we can see that this comes from the system as 0x00002740, which is WSAEADDRINUSE.

The solution? Since public static (I think just static, really) instances of HttpClient are considered thread-safe, the singleton model is what we want to go with.

So, instead of instantiating an HttpClient per call, you would instantiate a singleton instance that would be used per-host in your class instance. This allows the HttpClient and it’s port to be re-used (thus, reducing potential ephemeral port exhaustion as a byproduct). And since it appears that Azure re-instantiates your class per run (if you’re using the TimerTrigger, for example), then you create a scenario where the object’s lifetime is bound to your class. (Assuming you call HttpClient.Dispose() before the run completes and the object moves out of scope.)

…but MSDN says to use ‘using’ for IDisposable objects!

Yes, this is true but, again, we have to consider that even though .Dispose() might be called when we leave scope, we have no control over when GC actually comes through and disposes of the object from the Gen1/Gen2 heaps. We also cannot control when the TCP port is actually closed because that’s dependent on the host. So, even if HttpClient.Dispose() is called, you’re still at the whims of the keep-alive configured on the host for the actual port to be closed.

Diagram from the IETF? Diagram from the IETF.

Time_Wait

So, even though it’s been practically beaten into you throughout your CS career to use ‘using’, there are times when the singleton model (and not invoking using) are more favourable to your software design needs, expectations, and requirements than what you’ve been taught is the best practice.

Happy coding! 🙂

Testing Private Methods in Static Classes: The Not-So-Easy Way

I had a problem with testing a method: The method is intentionally private, as exposing it public wouldn’t benefit anyone and it merely reduces code-overhead for repeated operations – given ‘x’ condition.

In this case, it was if the product of two numbers was greater than nine, then take those numbers and add them together and that was the new number. So, for example, if the product was ten, we would then add one and zero and get the new number 1; or if it was eleven, we would get one and one, which is two, and so on…

So, because the class is static and can be instantiated without a reference, you can’t reference it as a PrivateType, which I came to quickly realize:

PrivateTestFailure

The way to get around this, was to construct the type, itself (since it’s static), and try to access the private method from that instantiation:

PrivateTestSucceeding

Once that happens, your tests should now be able to access your private static method contained within your public static class.

A Dev’s First NuGet Package™: A Short Story

So, I killed literal hours today, trying to push my first NuGet package. It isn’t much, currently, it just has two extension methods for the System.DateTime object. You can find it here.

What this post aims to do is to fill the gaps that I lost hours of my life over, so that someone else doesn’t have to do the same thing. I suffered the heartache of it, let me prevent that same heartache from happening to you, yeah? 🙂

So, first things first, you need a DLL. It needs to do something. It doesn’t have to be fancy, like computing the potentiality of the quantum state of spin or anything like that. It just… …shouldn’t be an empty class and should contribute something that you think would save someone ‘x’ amount of time doing (repeatedly).

O.k., now that you have your project done, you’ll want to head over to NuGet and create an account. This just makes one of the later steps a lot easier to perform.

While you’re there, download the latest and greatest NuGet command-line tool. Copy the exe from your downloads folder to your project’s folder to make life easier for these nexts steps.

Open your choice of terminal, command or PowerShell, and navigate to where your project is. Now, run the following command, replacing the project name with the project you’ve made.

nuget.exe spec myProject.csproj

This will generate the nuspec file, which contains a list of specifications for your NuGet package.

Before you continue, open your AssemblyInfo.cs file and make the necessary changes. (Hint: When you want to bump your NuGet version, you can do that through this file).

In your nuspec file that was created, add the files section like below but targeting the .NET version of your specific assembly.

<files>
    <file src="..\..\Project\bin\Release\Assembly.dll" target="lib\net472" />
    <file src="..\..\Project\bin\Release\Assembly.pdb" target="lib\net472" />
</files>

Also, it’s important to pick the license that’s good for your needs, so head over to SPDX’s site to see which one fits your end-goals. Once you find the license you want to use, modify your nuspec file to something like the following, specifying your chosen license instead.

<license type="expression">MPL-2.0-no-copyleft-exception</license>

When everything’s as you want it, go back to your prompt and run the following command:

nuget.exe pack myProject.csproj

This will generate the nupkg file.

Now that you have the nupkg file, go back to NuGet and, using your account that you created earlier, upload the nupkg that you just created to NuGet.

…and that’s it, you have now published an assembly to NuGet for the world to consume. 🙂