An Azure Service Principal is a service account created in Azure AD and can be leveraged in PowerShell scripts for automation. It is recommended to use Service Principals for security reasons since they have separate credentials and very constrained rights.

You can either use password-based authentication or certificate-based authentication with Service Principals. In this article, only password-based authentication is covered. Certificate-based authentication is treated in the Microsoft article linked at the end of the page.

First of all, the Az Powershell Module is needed.

Install-Module -Name Az -AllowClobber -Scope Allusers

If you have multiple subscriptions, make sure you have selected the correct one.

Get-AzSubscription

Select-AzSubscription -SubscriptionId xxxxxxxxx

Now create the Principal:

$sp = New-AzADServicePrincipal -DisplayName PowershellAutomation

The $sp object contains a secret parameter (the password), which is not in clear-text and an ApplicationID, that will be used as the username. To decrypt the secret parameter use the following commands:

$BSTR = [System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($sp.secret)
$UnsecurePassword = [System.Runtime.InteropServices.Marshal]::PtrToStringAuto($BSTR)

In a script the $UnsecurePassword should not be hardcoded, instead, it should be saved as an encrypted XML file and decrypted when the script is executed. I wrote a post about securing credentials in PowerShell scripts, check it out: https://www.ajni.it/2020/05/powershell-encrypt-and-store-your-credentials-securely/.

Logging in is also straightforward. The Tenant id can be retrieved in the main page of Azure AD.

Connect-AzAccount -ServicePrincipal -Credential $credentials -Tenant xxxxx

When assigning rights, the newly created identity will be listed:

References:

https://docs.microsoft.com/en-us/powershell/azure/create-azure-service-principal-azureps?view=azps-3.8.0

So here is a challenge I had to face today: I created a virtual machine (VM) in Azure from a custom image that was previously Sysprep’d by me. The image contained several applications intended to run on a RDSH (Remote Desktop Session Host) for Citrix Virtual Apps and Desktops (former XenApp), so the RDS role was also installed. The VM was not part of the domain, it was in a Workgroup and it could not reach the RDS license server. Which meant: I could not RDP into the machine to perform Domain Join. And if you already have some experience with Microsoft Azure, you will know that there is no Remote Console like in VMware or Hyper-V.

The VM was still reachable over the network. So here are four PowerShell commands that allowed me to remotely perform a Domain Join on that particular machine. Nothing fancy, but it might come in handy.

$Server=”10.10.10.10″

Set-Item -Path WSMan:\localhost\Client\TrustedHosts -Value $Server -Confirm:$false -Force

This credential variable stores the local username and password of the computer. Something like computername\admin along with the password.

$Cred = Get-Credential

Add-Computer -DomainName “ajni.lab” -Restart

After executing the last command you will be prompted to insert domain credentials. The user obviously must have the right to create computers in the domain.

Saving credentials and secrets inside your code is a very bad idea and should be avoided. PowerShell has built-in commands to export and import encrypted data in your code.

There might be a lot of ways to achieve this, but this is how I like to do it. This is very elegant and easy to implement.

Let’s say we have a secret password that we want to secure and avoid saving in the source code.

$secretPW = “SecretPassword” | ConvertTo-SecureString -AsPlainText -Force

We can export this variable to an encrypted XML file with

$secretPW | Export-Clixml -Path .\secret.xml

The password is not human readable:

To import this file use

$secretPW = Import-Clixml -Path .\secret.xml

The plain-text password can be obtained through (I had to split the command into two lines)

[System.Runtime.InteropServices.Marshal]::
PtrToStringAuto([System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($secretPW))

Just outputting the variable won’t show the password, because the variable is a System.Security.SecureString object.

Credentials can also be saved this way:

$credentials = Get-Credential

You can show the plain-text password with

$credentials.GetNetworkCredential().password

$credentials | Export-Clixml -Path .\credentials.xml

Only the username is shown in clear text.

Same thing again with the import

$credentials = Import-Clixml -Path .\credentials.xml

$credentials.GetNetworkCredential().password

The password can be decrypted by the same user that created the XML file on that specific computer.

References:

https://devblogs.microsoft.com/scripting/decrypt-powershell-secure-string-password/

https://pscustomobject.github.io/powershell/functions/PowerShell-SecureString-To-String/

A quick post on how to change the Windows display language with Powershell. You might use these commands based on any logic that determines the user’s location/language. For instance, I created a script that gets executed on logon and sets the language based on some criteria (maybe an Active-Directory group or attribute).

Set-Culture en-US
Set-WinSystemLocale -SystemLocale en-US
Set-WinUILanguageOverride -Language en-US
Set-WinUserLanguageList en-US -Force
Set-WinHomeLocation -GeoId 244

You can find the right GeoID on Microsoft’s website

Hey folks!

Here is a quick way to find inactive AD Users in your environment. Get-ADUser ist the cmdlet we are going to use.

We are getting all users from the highest OU (domain.com) and using the Property LastLogonDate, which will not be returned if not specified in the -Properties parameter. After that a Where statement is going to show users that haven’t logged in since 90 days or more.

Get-ADUser -Filter * -Properties lastlogondate | where { $_.lastlogondate -lt (Get-Date).AddDays(-90) }

We could also specify the OU where the command is going to search:

Get-ADUser -Filter * -Properties lastlogondate -SearchBase “OU=TerminatedEmployees,DC=Company,DC=com”| where { $_.lastlogondate -lt (Get-Date).AddDays(-90) }|select Name,Lastlogondate

There is also the -SearchScope Onelevel parameter to determine that we are not going to search recursively:

Get-ADUser -Filter * -Properties lastlogondate -SearchBase “OU=TerminatedEmployees,DC=Company, DC=com” -SearchScope OneLevel | where { $_.lastlogondate -lt (Get-Date).AddDays(-90) }|select Name,Lastlogondate

Have fun!