Passwords usage is a common practice to authenticate users, especially to windows-based environments, but this is coming a weak point when it comes to password distribution and management of a large number of instances.

Introduction: Password-less Linux instance deployment

Linux and Unix based operating system have solved this issue a long time by using solutions like SSH with key pairs of public and private keys.

The main idea is that the private key is kept secret by the user, while the public key can be accessed by anyone.

OpenStack guest authentication is commonly based on this model, with keypairs managed by Nova and easily handled via the Horizon dashboard or the command line.

When a guest boots, the public key belonging to a given keypair is shared between the OpenStack environment and the guest via metadata, which is simply a json encoded dictionary and some additional files accessible by the guest via HTTP or other means.

Although it is possible (and unfortunately common) to provide passwords in clear text inside of the metadata, this is definitely not a good idea. On the other side, putting an SSH public key has no security implications, as by definition the key is public. Once the key has been deployed inside of the guest by cloud-init or other tools, the user can authenticate with her/his private key.

WinRM: Windows native alternative to SSH

Well, surprisingly, most Windows administrator probably never heard about it. Windows contains a little jewelry called Windows Remote Management (WinRM), included with every version of the OS since Windows Server 2008 / Windows Vista and also available as a free additional download for Windows Server 2003 and Windows XP.

In a nutshell, WinRM provides a command line interface that can be used to perform common management tasks, and also provides a scripting API so you can write your own Windows Scripting Host based scripts.

WinRM is considered as the Windows equivalent of SSH in most scenarios. The communication between clients and servers is based on the WS-Management (WSMan) open standard (a SOAP protocol), which means that it is not limited to Windows only.

When it used with a remote PowerShell session, you’ll see that not only it is possible to manage a Windows host remotely, but it’s also a great experience once you see what PowerShell is capable of.

WinRM supports various forms of authentication (Basic, Digest, Kerberos and Certificate) and various transport protocols, including HTTP and HTTPS.

So, why isn’t WinRM hugely popular today, like, for example, SSH? My two cents here are that it’s notoriously complicated to configure, on both servers and clients, to the point that it remained matter for initiated sysadmins…

Cloudbase-Init and WinRM

The main idea behind the development of cloudbase-init was to push openstack metadata to windows instance. This means that once a guest Windows instance gets deployed in Bluvalt Cloud, cloudbase-init takes care of all the configuration details: setting the hostname, creating users and setting passwords, expanding file systems, running custom scripts, deploying heat templates and more.

Cloudbase-init as well automate completely the WinRM configuration in Windows guest instance, without a single action required from the user side.

WinRM HTTPS Listener

The ConfigWinRMListenerPlugin configures a WinRM HTTPS listener with a self signed certificate generated on the spot and enables (optionally) basic authentication, which means that a secure communication channel can be established between any client and the server being provisioned, without the requirement of having both the client and the server in the same domain. A firewall rule is added by cloudbase-init in the Windows firewall for TCP port 5986.

Sure you need to access openstack APIs to perform the below tasks. I’ll publish another blog about how to access Bluvalt Cloud APIs.

At this point you can login into your server. To begin with, don’t forget to add a rule to your security groups in Bluvalt Cloud.

# Add rule to security group
nova secgroup-add-rule default tcp 5986 5986 0.0.0.0/0

# Get the admin password for the instance:
nova get-password yourinstance ~/.ssh/your_ssh_rsa_key

# On your client connect to your instance as shown in the following PowerShell snippet:
$ComputerName="yourserveraddress"

# Provide your username and password (by default "Admin" and the password you just obtained)

$c = Get-Credential

Make sure which user is injecting your meta-data. Normally, it’s admin or cloud-init

$c = Get-Credential
$opt = New-PSSessionOption -SkipCACheck -SkipCNCheck -SkipRevocationCheck
$session = New-PSSession -ComputerName $ComputerName -UseSSL -SessionOption $opt -Authentication Basic -Credential $c
Enter-PSSession $session

At this point you’ll be connected to the remote host and all the commands will be executed remotely. You can change your user’s password, create additional users, configure the server, etc.

Here’s another snapshot showing a PowerShell command executed remotely from my Windows Machine

Then you can do whatever you want to do in Windows powershell, create new user, reset administrator password, etc.