Windows Remote Management and Kerberos Authentication

Windows Remote Management is used for communication between computers and involves the security of the communication using different methods of authentication and message encryption.

There are following types of authentications:

Basic Authentication:

Least secure
User name & Password is used for authentication
Can be used for HTTP or HTTPS transport
Used in a domain or workgroup

Negotiate Authentication:

Also called WIA ( Windows Integrated Authentication)
Negotiated, single sign on
SPNEGO – Simple & Protected GSSAPI negotiation mechanism
SPNEGO determines if to use kerberos or NTLM
Kerberos is prefered

Digest Authentication:

Client request -> server -> authentication server (domain controller)
If client is authenticated, then the server gets a digest session key for subsequent requests from the client

Kerberos Authentication:

Mutual authentication using encrypted keys between client & server
Client account must be on domain account in the same domain as the server


An authentication mechanism used by the client or server receiving requests for data through the WinRM in an Active Directory context
SPNEGO is based on an Request For Comments (RFC) protocol produced by the Internet Engineering Task Force (IETF)

Diff between kerberos and negotiate:

Kerberos is the default method of authentication when the client is in a domain and the remote destination string is not one of the following: localhost,, or [::1].
Negotiate is the default method when the client is in domain, but the remote destination string is one of the following: localhost,, or [::1].

CredSSP Authentication:

CredSSP authentication is intended for environments where Kerberos delegation cannot be used.
It was originally developed to support Remote Desktop Services single sign-on, however it can also be leveraged by other technologies such as PowerShell remoting.
CredSSP provides a non-kerb mechanism to delegate a session’s local credentials to a remote resource.

Setting up client and server for Kerberos Authentication

First steps

Create client and server machines.
Add them to the same domain

Configure Server

You can use the WinRM tool. Run the following commands –

winrm quickconfig -q
winrm set winrm/config/winrs @{MaxMemoryPerShellMB=”300″}
winrm set winrm/config @{MaxTimeoutms=”1800000″}
winrm set winrm/config/service @{AllowUnencrypted=”true”}
winrm set winrm/config/service/auth @{Basic=”false”}
netsh advfirewall firewall set rule name=”Windows Remote Management (HTTP-In)” profile=public protocol=tcp localport=5985 remoteip=localsubnet new remoteip=any
winrm set winrm/config/client/auth @{Digest=”false”}
winrm set winrm/config/service/auth @{Kerberos=”true”}
winrm set winrm/config/client @{TrustedHosts=”*”}

To ensure that Kerberos authentication is enabled on WinRM service:

winrm get winrm/config/service/auth

Connect to server from client

Using winrm –

winrm identify -auth:Kerberos -p:password

Using winrs –

winrs / /u:domain/username> /p:password dir

Using Chef’s knife-windows –

knife winrm -m -x username -P passowrd -R krb5_realm dir

knife winrm -m -x username -P passowrd -t kerberos-keytab -R krb5_realm -S kerberos-service dir


Chef Knife plugin for Windows Azure (IAAS)

Chef is an open-source systems management and cloud infrastructure automation framework created by Opscode. It helps in managing your IT infrastructure and applications as code. It gives you a way to automate your infrastructure and processes.

Knife is a CLI to create, update, search and delete the entities or manage actions on entities in your infrastructure like node (hosts), cloud resources, metadata (roles, environments) and code for infrastructure (recipes, cookbooks), etc. A Knife plug-in is a set of one (or more) subcommands that can be added to Knife to support additional functionality that is not built-in to the base set of Knife subcommands.

The knife azure is a knife plugin which helps you automate virtual machine provisioning in Windows Azure and bootstrapping it. This article talks about using Chef and knife-azure plugin to provision Windows/Linux virtual machines in Windows Azure and bootstrapping the virtual machine.

Understanding Windows Azure (IaaS):

A complete deployment for a virtual machine in Azure looks as below.

Windows Azure IaaS deployment model

To deploy a Virtual Machine in a region (or service location) in Azure, all the components shown described above have to be created;

  • A Virtual Machine is associated with a DNS (or cloud service).
  • Multiple Virtual Machines can be associated with a single DNS with load-balancing enabled on certain ports (eg. 80, 443 etc).
  • A Virtual Machine has a storage account associated with it which storages OS and Data disks
  • A X509 certificate is required for password-less SSH authentication on Linux VMs and HTTPS-based WinRM authentication for Windows VMs.
  • A service location is a geographic region in which to create the VMs, Storage accounts etc

The Storage Account

The storage account holds all the disks (OS as well as data). It is recommended that you create a storage account in a region and use it for the VMs in that region.
If you provide the option –azure-storage-account, knife-azure plugin creates a new storage account with that name if it doesnt already exist. It uses this storage account to create your VM.
If you do not specify the option, then the plugin checks for an existing storage account in the service location you have mentioned (using option –service-location). If no storage account exists in your location, then it creates a new storage with name prefixed with the azure-dns-name and suffixed with a 10 char random string.


This is also called as Role(specified using option –azure-vm-name). If you do not specify the VM name, the default VM name is taken from the DNS name( specified using option –azure-dns-name). The VM name should be unique within a deployment.
An Azure VM is analogous to the Amazon EC2 instance. Like an instance in Amazon is created from an AMI, you can create an Azure VM from the stock images provided by Azure. You can also create your own images and save them against your subscription.

Azure DNS

This is also called as Hosted Service or Cloud Service. It is a container for your application deployments in Azure( specified using option –azure-dns-name). A cloud service is created for each azure deployment. You can have multiple VMs(Roles) within a deployment with certain ports configured as load-balanced.

OS Disk

A disk is a VHD that you can boot and mount as a running version of an operating system. After an image is provisioned, it becomes a disk. A disk is always created when you use an image to create a virtual machine. Any VHD that is attached to virtualized hardware and that is running as part of a service is a disk. An existing OS Disk can be used (specified using option –azure-os-disk-name ) to create a VM as well.


For SSH login without password, an X509 Certificate needs to be uploaded to the Azure DNS/Hosted service. As an end user, simply specify your private RSA key using –identity-file option and the knife plugin takes care of generating a X509 certificate. The virtual machine which is spawned then contains the required SSH thumbprint.

Install knife-azure plugin

You can either install via rubygems or build it from the latest source code.

Gem Install

Run the command: gem install knife-azure

Install from Source Code

To get the latest changes in the knife azure plugin, download the source code, build and install the plugin:

1. Uninstall any existing versions

$ gem uninstall knife-azure

Successfully uninstalled knife-azure-1.2.0

2. Clone the git repo and build the code

$ git clone
$ cd knife-azure
$ gem build knife-azure.gemspec
WARNING: description and summary are identical
Successfully built RubyGem
Name: knife-azure
Version: 1.2.0
File: knife-azure-1.2.0.gem

3. Install the gem

$ gem install knife-azure-1.2.0.gem
Successfully installed knife-azure-1.2.0
1 gem installed
Installing ri documentation for knife-azure-1.2.0…
Building YARD (yri) index for knife-azure-1.2.0…
Installing RDoc documentation for knife-azure-1.2.0…

4. Verify your installation

$ gem list | grep azure
knife-azure (1.2.0)

To provision a VM in Windows Azure and bootstrap using knife,  Firstly, create a new windows azure account: and secondly, download the publish settings file from
The publish settings file contains certificates used to sign all the HTTP requests (REST APIs).

Azure supports two modes to create virtual machines – quick create and advanced.

Azure VM Quick Create

You can create a server with minimal configuration. On the Azure Management Portal, this corresponds to the “Quick Create – Virtual Machine” workflow. The corresponding sample command for quick create for a small Windows instance is:

knife azure server create
–azure-publish-settings-file ‘/path/to/your/cert.publishsettingsfile’
–azure-dns-name ‘myservice’
–azure-source-image ‘windows-image-name’
–winrm-password ‘jetstream@123’
–template-file ‘windows-chef-client-msi.erb’
–azure-service-location “West US”

Azure VM Advanced Create

You can set various other options in the advanced create including service location or region, storage-account, VM name etc. The corresponding command to create a Linux instance with advanced options is:

knife azure server create
–azure-publish-settings-file “path/to/your/publish/settings/file”
</strong>–azure-dns-name ‘myservice’
–azure-vm-name ‘myvm02’
–azure-service-location ‘West US’
–azure-source-image ‘source-image-name’
–ssh-user ‘jetstream’
–ssh-password ‘jetstream@123’

List Available Images

knife azure image list

List currently available virtual machines

knife azure server list

Delete and cleanup a virtual machine

knife azure server delete –azure-dns-name myvm02 ‘myservice’ –chef-node-name ‘myvm02’ –purge

knife azure server delete –azure-dns-name myvm02 ‘myservice’ –chef-node-name ‘myvm02’ –purge