Deploying a SailPoint IdentityNow Virtual Appliance in Azure

Introduction

The CentOS image that SailPoint provide for the IdentityNow Virtual Appliance that performs integration between ‘Sources’ and IdentityNow is VMWare based. I don’t have any VMWare Infrastructure to run it on and really didn’t want to run up any VMWare environments for this component. All my other infrastructure is in Azure. I’d love to run my VA(s) in Azure too.

In discussions with SailPoint I understand it is simply a case that they haven’t certified their CentOS image on Azure. So I figured I’d convert the VM, get it into Azure and see if it works from my Sandpit environment. This blog post details how I got it working.

Disclaimer: If you use this for more than a Sandpit/Test environment let your SailPoint CSM know. This isn’t an approved process or a support configuration. That said it works for me.

Overview

This is the high-level process I threw together that worked for me.

  1. Obtain the CentOS Image from the IdentityNow Virtual Appliance Setup
  2. Convert the VMWare VMDK image to Hyper-V VHD format using VirtualBox vboxmanage (free)
  3. From the Azure MarketPlace create a Seed VM based on CentOS (with new Resource Group, Storage Account, Virtual Network etc)
  4. Upload the VHD to the Azure Storage Account (associated with VM from Step 3) using Azure Storage Explorer
  5. Create a new VM based off the VM from Step 3 to use the disk from Step 4 as the Operating System disk
  6. Log in and configure the Virtual Appliance

Convert VMWare VM to Hyper-V.png

Prerequisites

  1. Virtual Box (for the disk image converter). You could probably do it with other tools but I’ve used this before and it just works.
  2. Enough hard disk space for the VA image and the converted image. The base image is ~2.8Gb and when converted to a fixed disk image it becomes ~128Gb (which can compress to ~3Gb for initial upload).
  3. Azure Storage Explorer. We’ll need this to upload the converted virtual disk to Azure.

SailPoint Virtual Appliance CentOS VMWare Image

To download the CentOS VMWare Image login to the Admin section of your IdentityNow Tenant.  Under Admin => Connections => Virtual Appliances create a New Cluster. Select that Cluster then Virtual Appliances => New 

Download the Appliance Package 

Create New VA.PNG

Converting the CentOS VMWare Virtual Disk to a Fixed Hyper-V Virtual Disk

I already had Virtual Box installed on my computer. I had to give the full path to VBoxManage (as shown below) and called it with the switches to convert the image;

vboxmanage clonehd –format VHD –variant Fixed

The –variant Fixed switch takes the dynamic image and converts it to Fixed as this is a requirement in Azure.

ConvertVADisk 1.PNG

The image conversion started and completed in under ten minutes.

Converted Fixed.PNG

Creating an Azure CentOS VM

In the Azure Portal I created a New Resource and chose CoreOS.

NewCoreOS 1

I gave it a name, chose HDD as the disk type and gave it a Username and Password.

NewCoreOS 2

I chose sizing in line with the recommendations for a Virtual Appliance.

NewCoreOS 3

And kept everything else simple (for my sandpit environment).

NewCoreOS 4

After the VM had deployed I had a Resource Group with the necessary Virtual Network, Storage Account etc.

Resource Group.PNG

Upload the Converted Disk to Azure Storage

I created a vhd container (in the Storage Group associated with the VM I just created) to hold the new VHD. Using Azure Storage Explorer I then uploaded the converted image. Select Page Blob for the blob type.

Upload VHD

You’ll want to have a decent internet connection to do this. I converted the SailPoint image on an Azure VM (to which I added a 256Gb data disk too). I then uploaded the new 128Gb VHD disk image from within Azure to the target Resource Group in about 75 minutes.

Upload VHD 2

Below I show the SailPoint Virtual Appliance CentOS OS converted disk image uploaded to Azure Storage Account Blob Storage.

Upload VHD 3.PNG

Generate SAS Token / Get Blob URI

We won’t used a SAS Token, but this just gives easy access to the Storage Blob URL. Right click on the VHD Blob and select Generate Shared Access Signature. Select Create.

Right Click - Get Shared Access Signature

Copy the URL. We’ll need parts of this for the script to create a new CentOS VM with our VA Disk Image.

Get VHD and BLOB Details

Create the new VM for our Virtual Appliance

Update the script below for:

  • The Resource Group you created the Seed VM in (line 2)
  • The Seed VM Name (line 4)
  • The Seed VM Subnet Name (line 6)

Each of those are easily obtained from the Seed VM Summary as highlighted below.

  •  update the Disk Blob details in Live 8 and 10 as copied earlier

After stepping through the script to create the new VM, and happy with the new name etc, I executed the New-AzureRMVM command.

Create New VM

And the VM was created in a couple of minutes.

Create VM Initiated

Accessing the new VM

Getting the IP address from the new VM Summary I SSH’d into it.

VM Started

And logged in with the default credentials from SailPoint. (Windows Subsystem for Linux is awesome).

SSH In to VA

Next Steps

  1. Change the password on your Virtual Appliance (passwrd)
  2. Create a DNS Name, update the configuration as per SailPoint VA Configuration tasks
  3. Create the VA and Test the Connection from the IdentityNow Portal
  4. Delete your original SeedVM as it is no longer required
  5. Add an NSG to the new VM
  6. Create another VM in a different location for High Availability and configure it in IdentityNow

Below shows my Azure based Virtual Appliance connected and all setup.

Cluster Up and Running.PNG

Summary

Whilst not officially supported it is possible to convert the SailPoint Virtual Appliance VMWare based image to an Azure compatible Hyper-V image and assign it as the Operating System disk on an Azure Linux (CoreOS) Virtual Machine. If you need to do something similar I hope my approach gives you some ideas.

If you then need to create another Virtual Appliance in Azure you have a Data Disk you can assign to a VM and upload to wherever it needs to be for creation of another Virtual Appliance VM.

Enabling and Scripting Azure Virtual Machine Just-In-Time Access

Last week (19 July 2017) one of Microsoft’s Azure Security Center’s latest features went from Private Preview to Public Preview. The feature is Azure Just in time Virtual Machine Access.

What is Just in time Virtual Machine access?

Essentially JIT VM Access is a wrapper for automating an Azure Network Security Group rule set for access to an Azure VM(s) for a temporal period on a set of network ports restricted to a source IP/Network.

Personally I’d done something a little similar earlier in the year by automating the update of an NSG inbound rule to allow RDP only for my current public IP Address. Details on that are here. But that is essentially now redundant.

Enabling Just in time VM Access

In the Azure Portal Select the Security Center icon.

In the central pane you will find an option to Enable Just in time VM Access. Select that link.

In the right hand pane you will then see a link for Try Just in time VM Access. Select that.

If you have not previously enabled the Security Center you will need to select a Pricing Tier. The Free Tier does not include the JIT VM Access, but you should get an option for a 60 day trial for the Standard Tier that does.

With everything enabled you can select Recommended to see a list of VM’s that JIT VM Access can be enabled for.

I’ve selected one of mine from the list and then selected Enable JIT on 1 VM.

In the Enable JIT VM Config you can add and remove ports as required. Also the maximum timeframe for the access. The Per-Request for source IP will enable the rule for the requester and their current IP.  Select Ok.

With the rule configured you can now Request access

When requesting access we can tailor the access based on what is in the rule. Select the ports we want from within the policy and IP Range or Current IP and reduce the timeframe if required. Then select Open Ports.

For the VM we can now see that JIT VM Access has been requested and is currently active.

Looking at the Network Security Group that is associated with the VM we can see the rules that JIT VM Access has put in place. We can also see that the rules are against my current IP Address.

Automating JIT VM Access Requests via PowerShell

Now that we have Just-in-time VM Access all configured for our VM, the reality is I just want to invoke the access request via PowerShell, start-up my VM (as they would normally be stopped unless in use) and utilise the resource.

The script below is a simplified version of the my previous script to automate NSG rules  detailed here. It assumes you enabled JIT VM Access as per the manual process above, and that your VM would normally be in an off state and you’re about to enable access, start it up and connect.

You will need to have the AzureRM and the new Azure-Security-Center PowerShell Modules. If you are running PowerShell 5.1 or later you can install them by un-remarking lines 3 and 5.

Update lines 13, 15 and 19 for your Resource Group name, Virtual Machine name and the link to your RDP file. Update line 21 for the number of hours to request access (in line with your policy).

Line 28 uses the new Invoke-ASCJITAccess cmdlet from the Azure-Security-Center Powershell module to request access. 

Summary

This simplifies the management of NSG Rules for access to VM’s and reduces the exposure of VM’s to brute force attacks. It also simplifies for me the access to a bunch of VM’s I only have running on an ad-hoc basis.

Looking into the Azure-Security-Center PowerShell module there are cmdlets to also manage the JIT Policies.

How to quickly recover from a FAILED AzureRM Virtual Machine using Powershell

Problem

I have a development sandpit in Azure which I use quite a lot to test and mess with different ideas and concepts. This week when shutting it down things didn’t go that smoothly. All but one virtual machine finally stopped and de-allocated, but one virtual machine just didn’t make it. I tried resizing the VM. I tried changing the configuration of it and obviously tried starting it up many times via the portal and Powershell all without any success.

Failed VM.png

I realised I was at the point where I just needed to build a new VM but I wanted to attach the OS vhd from the failed VM to it so I could recover my work and not have to re-install the applications and tools on the OS drive.

Solution

I created a little script that does the basics of what I needed to recover a simple single HDD VM and keep most of the core settings. If your VM has multiple disks you can probably attach the other HDD’s manually after you have a working VM again.

Via the AzureRM Portal select your busted VM and get the values highlighted in the screenshot below for VM Name, VM Resource Group and VM VNet Subnet.

InputsForScript.png

The Script then:

  • Takes the values for the information you got above as variables for the;
    • Broken VM Name
    • Broken VM Resource Group
    • Broken VM VNet Subnet
  • Queries the Failed VM and obtains the
    • VM Name
    • VM Location
    • VM Sizing
    • VM HDD information (location etc)
    • VM Networking
  • Copies the VHD from the failed virtual machine to a new VHD file so you don’t have the bite the bullet and kill the failed VM off straight away to release the vhd from the VM.
    • Names the copied VHD <BustedVMName-TodaysDate(YYYYMMDD)>
  • Creates a new Virtual Machine with;
    • Original Name suffixed by ‘2’
    • Same VM Sizing as the failed VM
    • Same VM Location as the failed VM
    • Assigns the copy of the failed VM OS Disk to the new VM
    • Creates a new Public IP for the VM named
    • Creates a new NIC for the VM named

Summary

With only 3 inputs using this script you can quickly recovery your busted and broken failed AzureRM virtual machine and be back up and running quickly. Once you’ve verified your VM is all good, delete the failed one.

VMList.png

Take this script, change lines 2, 4 and 6 for your failed or VM you want to clone to reflect your Resource Group, Virtual Machine Name and Virtual Machine Subnet. Step through it and let it loose.

Follow Darren on Twitter @darrenjrobinson

PowerShell error “Run Login-AzureRmAccount to login.” in AzureRM when already logged in

Usually when I’m writing PowerShell scripts I do it from a development virtual machine with a known environment state. However, yesterday I was trying to do something simple and quick and was writing it on my everyday laptop.

My script was using Windows Management Framework 5.0 and I was creating a new burn environment in AzureRM. I was authenticated and could query and enumerate most of my AzureRM environment, however I was getting erroneous responses on some cmdlets and was unable to create a new resource group. Essentially whenever I tried to perform anything of value to what I was trying to achieve PowerShell would return ”Run Login-AzureRmAccount to login.”

I was authenticated and all looks as it should.

LoggedIn

Query ARM RG and get the error, ”Run Login-AzureRmAccount to login.”

LoginError

I started digging to find out what my environment was looking like. Did I have WMF5 installed?  $PSVersionTable showed I did and all looked as it should.

PSEnv

What modules did I have installed? Get-InstalledModule | Out-GridView

PSModules

Lots of differing versions is what I saw *Note: screenshot above is after resolving my issue.

So what fixed my issue? I ran Update-Module and watched PowerShell update my modules and get my environment back into spec. A restart of my laptop and back in action.

What caused my issue? I’m thinking I updated an individual module at some point and dependencies were missed.

Hope this helps someone else and saves some of those “this should just be working, why isn’t it” moments.