Remote Desktop connection to an Entra ID-joined Windows Server with Entra ID credentials… quick and dirty

By Tomica Kaniski in Other 1 Comment

Connecting via Remote Desktop to an Entra ID-joined Windows machine, by using the Entra ID credentials, should be easy, right? It usually is… if you have covered all the prerequisites.

Multiple such guides are around, but none has listed all the steps needed (or I just haven’t found the right one) – I chose to follow this one, from my MVP colleague Tom Wechsler, available here.

Some points before we start:

In my case, all the required steps that allowed me to finally access my Entra ID-joined Windows (Server) machine in Azure via (publicly accessible) Remote Desktop (FOR DEMO PURPOSES), are the following:

Create an Entra ID-joined Windows virtual machine in Azure:

  • first, you will need to select a supported operating system (Windows 10/11, Windows Server Datacenter 2019/2022):
    • worked for me with both Windows Server 2019 Datacenter and Windows Server 2022 Datacenter

  • another thing needed during the creation of the machine itself is to select Login with Microsoft Entra ID under Management settings so that your machine would be automatically joined to the Entra ID and have the extension installed (note that this option automatically creates the system-assigned managed identity as well, and if not selected at the time of creation, it can also be added later, under virtual machine’s Extensions):

Create a user that will connect to the virtual machine:

  • the easiest thing would be to create a fresh, new Entra ID user, that will be used for connecting to this virtual machine (you can also use an existing user, but make sure it is not using MFA, which will prevent you from connecting) – my user will be called vmuser
  • try to sign in with this new user into the Azure portal if you need to change its password, or just to skip the MFA setup:

  • as the machine is Entra ID-joined, under the Access Control (IAM) settings of the virtual machine (in my case, temp-1), assign this user (vmuser) either the Virtual Machine User Login or the Virtual Machine Administrator Login role:

Connect to the virtual machine with a local admin account (created with the machine):

  • if you run dsregcmd /status command, the following should be configured already:
    • AzureAdJoined: YES
    • AzureAdPrt: NO
    • IsDeviceJoined: YES
  • next, go to the System Properties – Remote Desktop settings and disable the Network Level Authentication option (enabled by default):

On the computer you will be connecting from (not Entra ID-joined):

  • next, download the RDP connection file from the portal:

  • and then edit the downloaded RDP file (with Notepad) – it should look like the below (more on the available options):
    • remove the line with the username (as it will be provided on connection)
    • add the following two lines:
      • enablecredsspsupport:i:0
      • authentication level:i:2

  • try connecting to the virtual machine now, by using the edited RDP file, username, and password of your Entra ID account:
    • for the username, make sure you are using the AzureAD\upn-or-email-address format (in my case, AzureAD\[email protected])

  • your connection should be working, and you will have either the user or admin permissions on the system (depending on the assigned Entra ID role):

Hope this helps.

Cheers!

What about this Bicep?

By Tomica Kaniski in Other 0 Comment

You’ve probably heard about Azure Resource Manager (ARM) – the deployment and management service/layer of Azure, which enables you to manage (create, configure, delete) your Azure resources. Also, you are probably aware that ARM uses so called ARM templates – basically, JSON files that actually define the infrastructure and configuration you want to deploy to Azure (think Infrastructure as Code, IaC).

So, if you have dealt with ARM/JSON in the past, you may have been finding it difficult to start with, and somewhat complex.

Bicep is here to help.

Here is a short overview of Bicep – basically, it’s a language which enables you easier deployment of Azure resources, without messing around (too much) with JSON. To be frank, it somehow reminds of Terraform, but it’s also different. It has many cool features, immediately supports all new Azure features and APIs, can be built (converted) into .json and deployed as such or it can be deployed straight away as .bicep, doesn’t require state file, it’s open and free, has great support in Visual Studio Code and much more. And it’s still in active development!

If you’re dealing with IaC and Azure, try it.

To show you the power (and simplicity) of Bicep, here is a short example of deploying Linux virtual machine in Azure (together with a resource group, virtual network, virtual network subnet, virtual NIC and network security group), done “the old way” (in JSON, which was actually converted from Bicep… it’s easier than writing JSON from the scratch) and then done via Bicep (“the right way”? 😀).

Additionally, you’ll see that I’ve tried to break stuff into modules – with more or less sucess. 😀

The ARM/JSON way (could be done nicer/shorter, with parameters inside .parameters.json… if you know what you’re doing – this is converted from Bicep and serves just for illustrative purposes):

 

The Bicep way:



Bicep seems a bit easier to read and shorter, right (while still doing basically the same thing)? 😀

If we deploy the .bicep files above (note that I’m deploying the “raw” .bicep file directly – which is cool!):


We finally get our resources:

So, where should you start if you’re new to Bicep?

I would certainly recommend starting with free and official Deploy and manage resources in Azure by using Bicep learning path on Microsoft Learn.

After that, you can probably pick up Freek Berson’s book Getting started with Bicep: Infrastructure as Code on Azure (first and only book on Bicep that I know of – really liked it because of the simple (yet effective) examples with storage accounts, it connects everything and flows naturally – building up “brick by brick” and not “jumping around”, just to show off what Bicep can do).

Another great resource are also the Bicep examples – there’s plenty to learn from them too!

Of course, you’ll also need to practice – install the Azure CLI or Azure PowerShell module, add Bicep and use Visual Studio Code for your first steps with creating, deleting, configuring and breaking stuff… powered by Bicep! 😀

Cheers!

Deploying Kubernetes on top of Azure Stack (Development Kit)

By Tomica Kaniski in Other 0 Comment

If you had a chance to deploy Azure Stack or Azure Stack Development Kit (ASDK) in your environment, maybe you’ve asked yourself “OK, but what should I do with it now?“.

Well, one of many things you “can do with it” is offer your users to deploy Kubernetes clusters on top of it (at least, that was what I did the other day… on my ASDK deployment) – in short, official documentation has you pretty much covered. I know, Azure enables it as well… and the process here is similar, or – the same.

The main thing you have to decide at the beginning, is if you’ll use Azure AD or ADFS for identity management (the same as with Azure Stack deployment, if you remember, from my previous posts). Why – because the installation steps differ a bit.

Once you decide it (or you ask your Azure Stack administrator how it’s done in your case), you can proceed with the installation – I assume you have your Azure Stack/ASDK up and running.

Next, in the admin portal (https://adminportal.local.azurestack.external/), you’ll need to add the prerequisites from Azure Marketplace (for this, if you remember, your Azure Stack/ASDK has to be registered):

Once done, you’re ready to set up the service principal, to which you’ll then assign the required permissions on both – the Azure side and on the Azure Stack side! (don’t forget this detail… it is well documented, but easy to overlook)

In case you don’t give your service principal the required permissions on both “sides”, you’ll probably get the “error 12” and your deployment will fail:

And you can see details in the log:

So… be careful with service principal and permissions! 🙂

Next thing you’ll need to make sure of is that you create a plan and an offer, but set your quotas right! It depends on your Kubernetes cluster deployment settings, but if you’ll go with the defaults, the default quotas (disk, in particular) need to be expanded!

If not, you’ll probably get this error:

If you were careful while reading the official docs (with a few “lessons learned” in this post), and you’ve made it to here… you’re probably set to deploy your first Kubernetes cluster on top of your Azure Stack/ASDK.

In the user portal (https://portal.local.azurestack.external/), you now have the option to deploy something called Kubernetes Cluster (preview):

Here you really can’t miss much – you’ll give your deployment a brand new (or empty) resource group, user details (together with your public SSH key, of course), DNS prefix, number and size of nodes and service principal details:

After that, your deployment starts and runs for some time (it, again, depends on your hardware and settings you’ve chosen for your cluster). Hopefully, it will end with this message:

If all is good, you can SSH into one of your master nodes and see the details of your cluster:

One other thing that would be nice to have is the Kubernetes dashboard – the process of enabling it is well documented here:

And – you’re done!

You now have your own Kubernetes cluster deployment on top of your Azure Stack/ASDK! How cool is that?! 🙂

One last thing to note – currently, this is in preview (as it says on the template), but… it works. 🙂

Cheers!