For some reason it’s not straight-forward to create new credentials for an existing Service Principal account in Azure Active Directory using PowerShell.

I’m using PowerShell, because I’m not an Azure AD admin in my current organization, but as a developer, I am able to create and manage service principal accounts. This is extremely convenient, because we use them for automated deployments to Azure.

We started using Azure DevOps release management about a year ago, and thus I recently encountered the first credential expiration of a service principal that was used by Azure DevOps to deploy resources to Azure. This makes sense, because service principal credential lifetime defaults to one year.

Azure has the capability to create alerts on all sorts of events. If it can be expressed as a metric on a resource in Azure, then you can get an alert if the metric value reaches a state you don’t like.

One of those metrics is the “Endpoint Status by Endpoint” of Azure Traffic Manager.

Traffic Manager has a number of backend endpoints to which it directs traffic. If an endpoint is down for some reason, it doesn’t get any traffic. This is part of what makes Traffic Manager smart.

But you probably want to know about it, when an endpoint is down. That is alerting on the “Endpoint Status by Endpoint” metric can do.

I’ve started working with Azure DevOps (previously known as Visual Studio Team Services – VSTS, previously known as Visual Studio Online…).

I’m using it to automated Azure deployments in some projects.

In our setup we have several different environments (dev, test, prod, etc.). Depending on the project, the environments are either Azure Resource Groups or completely different Azure subscriptions. In any case, we have created service principal accounts in our Azure Active Directory, that have the necessary Contributor roles to those subscriptions or resource groups, where they should be able to deploy resources.

The service principals have been added to Azure DevOps as Service Connections, so that we have a service connection for each project and environment.

We want to use a Release Pipeline for each project. Each Pipeline has a stage per environment.

Releases are triggered using package management (in these projects we don’t use VSTS for source control and build). Instead, our build server generates NuGet packages and uploads them to Azure DevOps package management, and this triggers the release process.

I had some problems with the various PowerShell and bash samples in the Microsoft documentation on how to create a certificate chain for use with the Azure IoT Hub Device Provisioning Service. Why did it have to be so complicated to get started with X.509 based authentication towards DPS?

What if I wrote my own program to create the root certificate, some intermediaries, and could also create device certificates? I set out to do that.

In the end, it turned out to be not that hard. .NET Core 2.0 has some new classes to help with certificate requests, so it isn’t necessary to call into native Windows libraries or use an extra library like BouncyCastle etc.Continue reading »

In that post, I also showed how to create a Device Enrollment Group within the Device Provisioning Service (DPS). That’s all very nice, but the purpose of IoT Hub and the DPS is to connect devices. So let’s go ahead and do that.

First of all, the device needs its own certificate, which is trusted by the root CA certificate configured in the DPS device enrollment group.

At the very least, it is necessary to have a root Certificate Authority (Root CA) that can be used to sign device certificates.

The devices authenticate with the DPS using a device certificate which is signed by the root CA. That way, the DPS can verify that the device is allowed to connect to the DPS and be provisioned for communicating with the Azure IoT Hub.

It is better if the root CA is used to sign an intermediate CA certificate, which in turn can be used to sign the device certificates. Depending on the need, there can be a chain of intermediates.

The reason for the intermediate certificates is that it makes it easier to see who or what signed a device certificate. If it should become necessary to revoke the intermediate, only a subset of device certificates will stop functioning.

While it is possible to use a public CA as the root CA, it is not necessary. It is possible to create a root CA certificate on your own and use that for DPS. The whole area of X.509 certificates is complicated, so it may be a good idea to consult with professionals in the field before rolling your own CA.

This blog post is the first part of a series that will include C# code to create a certificate chain. The finished project also includes a sample showing how to let an IoT Hub device provision itself without factory-installed certificates or Hardware Security Module based tokens.

I recently wanted to create an Azure Resource Manager (ARM) template with a number of interdependent resources. This post contains a number of “Things I Learned”. Hopefully, you can avoid some of the problems I had.

The resources were:

SQL server and database

Azure function app

Azure web app for an ASP.NET Core site

Storage account

Application Insights instance for the web app

Application Insights instance for the function app

In my previous post I described a place to get detailed logs about Web App site extension installation. I had spent a long time to figure out the reason that the installation of the Application Insights site extension failed.

While trying to figure out a problem I had when using an ARM template to deploy a web app to Azure, I found a nice debug log that contains the full steps that the web app makes to install site extensions.

On my work computer, I have VS2017 and VS2017 preview installed. Recently both stopped being able to discover MSTest unit tests, and Resharper also did not discover tests until I opened a file containing some tests.

There was nothing in the Visual Studio log windows that indicated problems, and it proved to be an issue whose cause was hard to find.