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

Azure has a lot of pre-defined roles, but you can also create very specific roles with the help of Azure Powershell or Bash and a JSON config file. In this example, the user that gets this role is only able to start, stop, or restart a VM.

Start off by opening the cloud shell. If this is the first time opening it, a storage account must be created.

Create a new json config file and insert the following:

code role.json

{
"Name": "Virtual Machine Operator",
"IsCustom": true,
"Description": "Can deallocate, start and restart virtual machines.",
"Actions": [
"Microsoft.Compute/*/read",
"Microsoft.Compute/virtualMachines/start/action",
"Microsoft.Compute/virtualMachines/restart/action",
"Microsoft.Compute/virtualMachines/deallocate/action"
],
"NotActions": [
, "AssignableScopes": [ "/subscriptions/xxxx" ]
}

You can save with CTRL+S and exit the visual editor with CTRL+Q.

The role grants read permission and allow to start, restart, and stop the VM. Do not forget to add your subscription id at the end (line 16).

When assigning a role the custom role should also be listed. You can either assign this role to a Resource Group or the VM directly.

References:

https://stackoverflow.com/questions/23668154/allow-users-to-start-stop-particular-azure-vms

The first step to securing your SSH configuration is to configure key-based authentication and not allow password authentication at all. That topic has already been discussed. Check out my post about that: https://www.ajni.it/2020/03/configure-ssh-key-based-authentication-on-a-linux-system/

The second step is to introduce an Intrusion Detection System (IDS or IPS). Fail2ban can achieve that specific goal. It analyses SSH authentication logs (it can be also set for other services) and blacklists IP addresses after n failed attempts with the help of iptables (firewall rules). Let's check it out.

First of all make sure to update your system:

apt update

apt upgrade

Now install fail2ban:

apt install fail2ban

Start and enable the fail2ban service:

systemctl start fail2ban

systemctl enable fail2ban

Now a "jail" can be configured for failed ssh login attempts. There is a default /etc/fail2ban/jail.conf file, but we are going to create a new config jail.local.

nano /etc/fail2ban/jail.local

Paste following parameters in the file:

[sshd]
enabled = true
port = 22
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
mode = aggressive
bantime = -1
findtime = 3600

Mode=aggressive includes failed attempts with public key authentication. Bantime = -1 is for persistent bans. Findtime indicates how far back logs are checked (now - 3600 minutes or 1 hour).

After saving the file, restart fail2ban:

service fail2ban restart

Blacklisted IPs can be viewed with

fail2ban-client status sshd

After some minutes one IP already showed up:

Or you can also view it with iptables.

iptables -L -n -v

Removing an IP from the blacklist is also easy (the command is self-explanatory)

fail2ban-client set sshd unbanip 10.10.10.1

Some other security considerations:

• Don't log in as root and do not allow user root over SSH
• Use public-key authentication
• Change the SSH port
• Implement an IDS/IPS (fail2ban)

References:

https://www.techrepublic.com/article/how-to-install-fail2ban-on-ubuntu-server-18-04/

https://serverfault.com/questions/686422/modify-fail2ban-failregex-to-match-failed-public-key-authentications-via-ssh/686436

https://security.stackexchange.com/questions/188908/what-is-this-ssh-attack-am-i-hacked

https://www.liquidweb.com/kb/install-configure-fail2ban-ubuntu-server-16-04/

https://serverfault.com/questions/808866/get-fail2ban-to-check-findtime-every-x-minutes

If you are looking for a VPS with good performance, check out Evolution Host at https://evolution-host.com/vps-hosting.php.
They offer virtual servers starting at 5€ per month.

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.

Have you ever wondered what this setting in Citrix Workspace App does?

Well, today I figured out: you can set multiple virtual desktops for your session in a split-screen fashion. Just like this:

The session must be in full-screen mode. Here is how it looks: