Understanding Azure Linux VM Authentication with SSH Key Pairs

The best and most secure option for authenticating to an Azure Linux VM is with a private & public key pair. It is possible to configure password authentication during the deployment of a VM, but this could be subject to a brute-force attack. A private & public key pair is used to secure the authentication, the Azure Linux VM has the public key and the administrator’s workstation stores the private key. It is possible to use the same key pair to authenticate to multiple Azure Linux VM instances, any most do.

I am going to start by deploying a new Ubuntu instance as an Azure VM, from the deployment I am going to select SSH Public Key for the authentication type. For certificate-based authentication you must still specify a username, in this example I have went with AzureUser. I have also selected the option to generate a new key pair as part of this deployment. This key pair will become my primary set of keys to authenticate to all my Azure Linux VM instances, so I have given it a descriptive name. 

Continue through the rest of the wizard to deploy a new Azure Virtual Machine. Once you get to send and you push the configuration to Azure Resource Manager in the form of a deployment you will be faced with this. You must select the option to download the private key as Azure does not store this for you. If you fail to download the private key at this stage this key pair will be null and void. 

The default format is PEM when you generate a key pair directly from Azure. This is what format the private key is downloaded in. If you want to authenticate to Azure Linux VMs using Putty you will have to convert the PEM file to PPK, or authentication will fail. To do this the PuttyGen tool can be used. The first step is to import the private key PEM file from Azure. 

Once successfully imported you must then use the Save Private Key option to ensure you end up with a PPK file which Putty can parse for authentication. 

Once you have a PPK version of the private key, you can use Putty to authenticate to the Azure Linux VM. Do not forget you must point to the PPK file from inside Putty under SSH > Auth.

Ok so we have covered how to deploy a new Azure Linux VM with a new key pair, convert the private key to a form in which Putty can use and authenticate to a VM.

The next step is to configure other Azure Linux VM’s to use this key pair for authentication. A new resource is created in the Azure Resource Group in which the next Azure Linux VM was deployed, this resource is an SSH Key. This is the public key side of this key pair which can be configured on other VM instances. If you query the SSH Key, we can copy and paste the key itself. 

Now if we want to update existing VMs to use the key pair we can go to the VM and under Reset Password select thee Reset SSH Public Key option. From here we paste in the new public key which was created as part of the original VM. 

Once this has been committed, we will be able to use out master private key to authenticate to this Azure Linux VM. 

Configure Azure Linux VM for Certificate Authentication

PuttyGen is handy tool which is installed as part of Putty. It allows you to generate key pairs, this first step is to click Generate. This will then use mouse inputs to generate a random key pair. Once this has completed you will see a Public Key displayed in the Key window.

In this example I am going to reconfigure an existing Azure Linux VM to use certificate-authentication instead of passwords. This VM was deployed using password authentication, which will still work post this configuration change. When key pairs are used for authentication they are placed in the following way:

·         Public Key - this is placed on the Azure Linux VM

·         Private Key - this is kept on the administrative workstation

The key pair can be used to authenticate to many Azure Linux VMs, the important factor is keeping the private key secure. The next step is to click Save Public Key, you will be prompted to enter a passphrase which is entirely optional. If a passphrase is entered here, you will be required to enter it when you authenticate to your Azure Linux VM's using this key pair. Once this has been done, we also must do the same for the private key so click Save Private Key and choose a suitable location for PuttyGen to write it. 

All going well we should be left with two files, one holding the public key and one holding the private key.

Open the public key file, this is the key we must configure the Azure Linux VM with. Copy the entire contents of the public key file. 

From the Azure Portal find the Azure Linux VM you are looking to reconfigure and go to the Reset Password option. Click on Reset SSH Public Key.

You will be presented with the following fields. You must enter a valid username on the Azure Linux VM, in my case the default AzureUser was still being used. You then must paste in the entire public key. Click Update to commit any changes.

To test the configuration open Putty and click Connection > SSH > Auth, from here we must point to the private key file so that Putty can present it when asked by the Azure Linux VM. 

Now try to connect. You will be presented with a username prompt, I entered AzureUser in my example and as you can see the connection has been authenticated successfully with the certificates. 

How to Configure Office 365 Multi Factor Authentication

Multi Factor Authentication can be attractive to businesses looking to migrate to Office 365, this allows administrators to enforce two methods of authentication on to users. This makes it harder for black hat hackers to compromise corporate data, this is mainly because stolen (or cracked passwords) will not be sufficient to gain access to the Office 365 services. In this example I am going to configure basic MFA with Office 365, there is more advanced features that can be utilized which I will explore in further posts.

Sign in to Office 365 as a Global Administrator, click Active Users and then click Set Up under Set Multi-Factor Authentication Requirements.

Select Users and then click Enable under the Quick Steps pane.

You will be asked to confirm if you want to enable Multi Factor Authentication, click Enable MFA to enable it.

Under the Service Settings tab, ensure Allow users to create app passwords to sign in to non-browser apps this will allow users to create app passwords to ensure they can still use full-functioning clients such as Outlook etc. These app passwords replace the standard passwords in Outlook profiles.

Now if you try to login to Office 365 as a user you will be prompted to complete the setup of MFA. Click Set it up now to continue.

Probably one of the easiest way to integrate MFA, in its most basic fashion with Office 365 is to link user account to company issued mobile phones. Select Authentication Phone and enter your Country Code and Mobile/Cell phone number. I have also selected Send me a code by text message. Click Contact Me.

Within seconds you will receive a 6 digit code from Microsoft.

The screen will automatically refresh allowing you to enter the 6 digit code, once you have done this click Verify.

Take note of this default app password and click Finished.

Now when you try to login as a user you will be prompted with a secondary authentication box for you to populate with the 6 digit code Microsoft will send every time you try to login. As I am connecting via a domain-joined computer ADFS and SSO has passed-through my standard network credentials leaving only the secondary authentication. If you were connecting from an internet computer you would have to enter both sets of credentials.

Another code is sent to my mobile phone to authenticate this login request.

The next step is to create app passwords to ensure users can use full-Outlook etc. Once logged into to Office 365 click on the Settings cog and select Office 365 Settings. You will be faced with this page, Click Additional Security Verification. 

 Click on the App Passwords tab.

Click Create and name the new app password something descriptive.

Office 365 will automatically generate a new app password for you. Select Copy password to clipboard and then Close.

It is within the Outlook profile you should populate with the newly create app password.

Configuring Citrix NetScaler to Load Balance ADFS v3.0

Configuring Citrix NetScaler to Load Balance ADFS v3.0

The link below is broken, I also do not have a copy of the full document I created in July 2015. Do not e-mail me directly asking for a copy.

To ensure ADFS and the WAP servers are highly available a hardware load balance is recommended. In this example I have outlined how to configure Citrix NetScalers to do this. If you are deploying ADFS for Office 365, it is important that the service is highly available otherwise users will not be able to authenticate to ADFS. 

Microsoft supports NetScaler as a hardware load balance but there is lack of documentation around how to deploy the two solutions together.

Some of the configuration settings such as MAC based forwarding, SSL bridging, session persistence and Client IP header are some of the settings that are not obviously required.

Although the full guide I created no longer exists, I have summarised how to configure the NetScaler to load balance ADFS 3.0 below. This is not a full and conclusive guide. I won't be re-doing the guide until I am asked to do it for a customer. 

Although this diagram is for MS Lync, it's similar for ADFS. Imagine you have 2 x WAP in the DMZ and 2 x ADFS in your LAN. 

Most places won't have two separate physical NetScaler pairs. The above topology can be achieved using a single pair of Netscalers, with network interfaces on each of the DMZ/LAN networks. Netscaler vServers can then be used to load balance each component. If your security requirements state you must have a physical break then it's different.

High level steps (from memory)

• Base configure the Netscalers (NSIP, SIP, routes, default gateways etc)
• at this point it's important to have an interface on each network. If you are deploying the ADFS WAP servers, these should be in your DMZ. Therefore an interface from the NS is required on each of the separate Layer 2 networks. 
• if you have problems research "Mac based forwarding"

• Configure high availability of the Netscalers
• Easy to do, Google it. I normally set my HA configuration to Active/Passive.

• Define the server's both ADFS and WAP
• Traffic Management/Load Balancing/Server
• Create a new server object for each of the ADFS/WAP's. Set the protocol to SSL Bridge
• Create a new service one for the WAP's and one for the ADFS's. Traffic Management/Load Balancing/Services
• service 1 = "adfs_https" protocol SSL Bridge
• service 2 = "wap_https" protocol SSL Bridge
• It's important the protocol type matches on the servers/services.

At this point, if you servers are listening on TCP 443 (https) and you have configured the networking correctly the server/services will show as "up" and the light will be green. If not there is some kind of networking problem (remember your WAP servers don't listen on 443 until you have them successfully paired with the ADFS servers)

• You should configure SSL session persistence (I cant remember the exactly menu, you either do this in the service configuration or on the vServer, check eDocs)
• Now create a new vServer for each the WAP's and the ADFS's
• vserver1 = "adfs" give the vserver an IP on the network the backend servers sit on
• vserver2 = "wap" same as above
• When you create the vserver, bind them to the corresponding service (adfs - adfs etc), and set the load balancing method to round robin.

DNS 

Now you have the NS configured, on the WAP servers create a hosts file entry to point your ADFS service name i.e sso.domain.com to the NS vServer for the ADFS servers. Try to run the WAP-ADFS pairing. If you get an error check out the bindings.

http://blog.ryanbetts.co.uk/2015/12/adfs-wap-unable-to-retrieve-proxy.html