Assuming you do not want to, or cannot, use ADAL in PowerShell, you can script this flow entirely in native PowerShell.

$clientId = "1950a258-227b-4e31-a9cf-717495945fc2"       # This is the standard Client Identifier for Windows Azure PowerShell
$redirectUrl = [System.Uri]"urn:ietf:wg:oauth:2.0:oob"   # This is the standard Redirect URI for Windows Azure PowerShell
$tenant = "YOURTENANTNAME.onmicrosoft.com"
$resource = "https://graph.windows.net";
$serviceRootURL = "https://graph.windows.net/$tenant"
$authUrl = "https://login.microsoftonline.com/$tenant";

$postParams = @{resource="$resource";client_id="$clientId"}
$response = Invoke-RestMethod -Method POST -Uri "$authurl/oauth2/devicecode" -Body $postParams
Write-Host $response.message

$tokenParams = @{grant_type="device_code"; resource="$resource"; client_id="$clientId"; code="$($response.device_code)"}

$tokenResponse = $null
$maxDate = (Get-Date).AddSeconds($response.expires_in)

while (!$tokenResponse -and (Get-Date) -lt $maxDate)
{
    try
    {
        $tokenResponse = Invoke-RestMethod -Method POST -Uri "$authurl/oauth2/token" -Body $tokenParams
    } 
    catch [System.Net.WebException] 
    {
        if ($_.Exception.Response -eq $null)
        {
            throw
        }

        $result = $_.Exception.Response.GetResponseStream()
        $reader = New-Object System.IO.StreamReader($result)
        $reader.BaseStream.Position = 0
        $errBody = ConvertFrom-Json $reader.ReadToEnd();

        if($errBody.Error -ne "authorization_pending")
        {
            throw
        }

        Start-Sleep($response.interval);
        Write-Host -NoNewline ".";
    }
}

After executing this script, and after successfully authenticating against Azure AD, the variable $tokenResponse should contain your tokens as issued by Azure AD.

Using the Azure MFA Server Web SDK

Using the Azure MFA Server Client Runtime DLL

Conclusion

Important note: This article assumes you are using AD FS Farm Behavior Level 2 (AD_FS_BEHAVIOR_LEVEL_2) or higher.

Shared Secret

• Register a key used to sign JSON Web Tokens for authentication This option is used to allow a confidential client to authenticate itself using a certificate.
• Windows Integrated Authentication This option is used to allow a confidential client to authenticate itself using WIA; a Windows user context.

Signed JSON Web Tokens

Windows Integrated Authentication

Conclusion

• Shared Secret
• Signed JWT’s
• Windows Integrated Authentication

Here is an example of a user trying to access the Office 365 Portal at https://portal.office.com. First, the user gets directed to the Security Token Service (STS) the organization has configured. (In this case, it’s AD FS running on Windows Server 2016.) After authenticating using a username and password (since the user is accessing Office 365 from the ‘extranet’) the users gets a prompt for MFA:

After successfully verifying the request, the user is redirected back to https://login.microsoftonline.com, the STS for Office 365. For Office 365, the customer has configured MFA to be required, and the STS for Office 365 requests MFA once more;

This can happen when (any form of) MFA is required on the “Microsoft Office 365 Identity Platform” Relying Party in AD FS, and it’s also required to access Office 365 (using conditional access rules or simply because the user is enabled for Azure MFA).

The cause of the double MFA prompt is that the AD FS farm, while issuing the token to the “Microsoft Office 365 Identity Platform”, did not ‘inform’ the recipient of the token about the fact that the user already did MFA. Part of the token that is sent from the AD FS farm to the “Microsoft Office 365 Identity Platform” is the way the user authenticated. It’s passed as a claim within the token. Whether the user did MFA or not, can be passed in another claim. This claim is not sent by default.

We can easily change this behavior by modifying the Claim Issuance Policy for the “Microsoft Office 365 Identity Platform” Relying Parting in AD FS.

In the AD FS Management Console, navigate to “Relying Party Trusts”, select the “Microsoft Office 365 Identity Platform” Relying Party Trust and click, on the right side, on “Edit Claim Issuance Policy…”.

In the “Edit Claims Issuance Policy for Microsoft Office 365 Identity Platform” screen, click on the “Add Rule…” button.

Under “Claim rule template:”, select “Pass Through or Filter and Incoming Claim”.

Click “Next >” to continue,

In the next screen, give the rule a friendly name, for example “Pass Through MFA Claims”, and next to “Incoming claim type:” select “Authentication Methods References”.

Click “Finish” to add the rule.

After that, try it again!

The only MFA prompt the user will get is from AD FS, and no longer from the Office 365 STS! Should a user in your tenant authenticate with a non-federated account, so an account which is not ‘served’ by AD FS, the user will be challenged for MFA by the Office 365 STS.

(And this also works for any other applications that you have registered with your Azure Active Directory Tenant.)

1. Create an application in Azure Active Directory.
2. Grant the application permissions to the resource(s) in Azure.
3. From your application, get an Access Token from Azure Active Directory.
4. Execute Azure Resource Manager REST API calls.
5. Try it!

Create an application Azure Active Directory.

Grant the application permissions to the resource(s) in Azure.

Get an Access Token from Azure Active Directory.

• The name (or identifier) of your Azure Active Directory instance.
• The Client ID of the application in Azure Active Directory.
• The Client Secret of the application in Azure Active Directory.

using Microsoft.IdentityModel.Clients.ActiveDirectory;

private async Task<string> GetAccessToken(string tenantName, string clientId, string clientSecret)
{
    var authString = "https://login.microsoftonline.com/" + tenantName;
    var resourceUrl = "https://management.azure.com/";

    var authenticationContext = new AuthenticationContext(authString, false);
    var clientCred = new ClientCredential(clientId, clientSecret);
    var authenticationResult = await authenticationContext.AcquireTokenAsync(resourceUrl, clientCred);
    var token = authenticationResult.AccessToken;

    return token;
}

Execute Azure Resource Manager REST API calls.

• An Access Token.
• Identifier of the Azure Subscription.
• Resource Group Name.
• Name or Identifier of the resource(s) you want to create, remove or modify.

• Route Table Name
• Route Name
• The IP Address

using Microsoft.Azure.Management.Network
using Microsoft.Rest

private async Task ChangeRouting(string token, string subscriptionId, string resourceGroup, string routeTableName, string routeName, string ipAddress)
{
    var credential = new TokenCredentials(token);
    var client = new NetworkManagementClient(credential);
    client.SubscriptionId = subscriptionId;

    var route = client.Routes.Get(resourceGroup, routeTableName, routeName);
    route.NextHopIpAddress = ipAddress;
    await client.Routes.CreateOrUpdateAsync(resourceGroup, routeTableName, routeName, route);
}

Try it!

var tenantName = "blogsample.onmicrosoft.com";
var clientId = "cae58962-1234-5678-abcd-84de99ecc675";
var clientSecret = "WxO+54VsAMNf2W3rbnBQZi15yTUiqpIexzBrNrNf+rQ=";

var token = GetAccessToken(tenantName, clientId, clientSecret).Result;

var subscriptionId = "1a917324-4b19-4ab2-8c17-f25e89c58715";
var resourceGroup = "Default-Networking";
var routeTableName = "routetable1";
var ipAddress = "192.168.100.10";

ChangeRouting(token, subscriptionId, resourceGroup, routeTableName, routeTableName, ipAddress).Wait();

await client.Routes.CreateOrUpdateAsync(resourceGroup, routeTableName, routeName, route);

client.VirtualNetworks.Get(resourceGroup, "MyVirtualNetwork");

TOTP is based on a secret key, shared between the server and the client. Using this key, codes are generated. The generation of the TOTP codes also involves a time component; by doing this, the generated code is only valid for a limited amount of time. (According to RFC6238, by default, 30 seconds.) Next to that, there are some additional requirements, perhaps not imposed by the RFC's themselves, but maybe by Google's implementation or simple user friendliness.

What we will create

We will create a Multi-Factor Authentication Provider for AD FS 3.0 that adheres to these requirements;

- Implement a Time-Based One-Time Password for MFA in AD FS 3.0.
- The secret key is a 16-character key using [A-Z][2-7] (due to Base32 Encoding).
- Generated codes are 6 characters long and only contain numbers.
- Generated codes are valid for 30 seconds.
- Implement some time tolerance (client and server might not have the exact same time).
- Codes cannot be used more than once.
- Configure the Authenticator app using a QR Code.
- Adhere to the (encryption) protocols in the RFC6238 and, hence, RFC4226.

- Should work with the Google Authenticator App and the Microsoft Verificator App and potentially other apps that implement TOTP based on RFC6238.

Creating Secret Keys, Intervals and Codes

First, we need to be able to generate the 16-character secret key consisting of the characters that are allowed. The RFC dictates; "The keys SHOULD be randomly generated or derived using key derivation algorithms." We will use the Random function in the .NET framework to accomplish this.

public static string GenerateSecretKey()
{
      Random random = new Random((int)DateTime.Now.Ticks & 0x0000FFFF);
      return new string((new char[secretKeyLength]).Select(c => c = allowedCharacters[random.Next(0, allowedCharacters.Length)]).ToArray());
}

In this snippet, allowedCharacters is a string containing the characters that are allowed in the secret key, and it's defined elsewhere in the code.

To generate codes that are valid for X seconds, the RFC dictates that we should count the number of X second intervals from the Unix Epoch (1970-1-1):

"X represents the time step in seconds (default value X = 30 seconds) and is a system parameter."
"T0 is the Unix time to start counting time steps (default value is 0, i.e., the Unix epoch) and is also a system parameter."

By default, we will use intervals of 30 seconds.

private static long GetInterval(DateTime dateTime)
{
      TimeSpan elapsedTime = dateTime.ToUniversalTime() - unixEpoch;
      return (long)elapsedTime.TotalSeconds / validityPeriodSeconds;
}

In this snippet, unixEpoch is defined elsewhere as DateTime(1970, 1, 1, 0, 0, 0, DateTimeKind.Utc).

Using the Secret Key and the Interval, we can generate the TOTP code. The code can't be longer than 6 numeric characters, we'll simply truncate it if it turns up longer. If it's shorter, we will prepend it with 0's. According to RFC4226 we have to use Base32 encoding, and we will use SHA1 for the HMAC key. (I won't bother you with the details, read the RFC if you're interested in this stuff. The RFC contains sample code in what I think is Java, but this my .NET translation of that code.)

private static string GetCode(string secretKey, long timeIndex)
{
    var secretKeyBytes = Base32Encode(secretKey);
    HMACSHA1 hmac = new HMACSHA1(secretKeyBytes);
    byte[] challenge = BitConverter.GetBytes(timeIndex);
    if (BitConverter.IsLittleEndian) Array.Reverse(challenge);
    byte[] hash = hmac.ComputeHash(challenge);
    int offset = hash[19] & 0xf;
    int truncatedHash = hash[offset] & 0x7f;
    for (int i = 1; i < 4; i++)
    {
        truncatedHash <<= 8;
        truncatedHash |= hash[offset + i] & 0xff;
    }
    truncatedHash %= 1000000;
    return truncatedHash.ToString("D6");
}

private static byte[] Base32Encode(string source)
{
    var bits = source.ToUpper().ToCharArray().Select(c =>
        Convert.ToString(allowedCharacters.IndexOf(c), 2).PadLeft(5, '0')).Aggregate((a, b) => a + b);
    return Enumerable.Range(0, bits.Length / 8).Select(i => Convert.ToByte(bits.Substring(i * 8, 8), 2)).ToArray();
}

We can now generate a secret key, calculate the proper interval starting 1970-1-1 and create a 6-character TOTP code.

Validating Codes

We now need to be able to validate code entered by a client. Since the client and the server might not have the exact same time, and transferring the code from the clients machine to the server might take "some" time, chances are that the client is presenting the server with "the previous code" or "the next code" (from the server's perspective). So when we validate the TOTP code provided by the client, we must also validate if the code presented perhaps is the previous or the next code. Therefore we will implement a configurable future- and past-tolerance. This tolerance is implement by means of past- and future intervals. Remember that 1 interval, by default, is 30 seconds. (From the RFC: "We RECOMMEND that at most one time step is allowed as the network delay.")

Another thing we need to take into account when validating the codes, is that a code for a specific user can only be used once. Once a user has used the code has to successfully authenticate, the same code cannot be used again. The hard part, from an AD FS MFA perspective, is to check whether or not the code has been used previously. Since you might have multiple AD FS servers in a farm, and these servers do not share state, we cannot use in-memory lists or other objects to check if a code has been used previously. The easiest way to get this check accomplished is by using a database that all servers in the AD FS farm can access and use to store and check used keys. This is also the mechanism I chose to implement. Here is the SQL script for the database that I'm using in my sample.

USE [master]
GO

CREATE DATABASE [TOTPAuthentication]
 CONTAINMENT = NONE
 ON  PRIMARY 
( NAME = N'TOTPAuthentication', FILENAME = N'https://storageaccount.blob.core.windows.net/container/TOTPAuthentication.mdf' , SIZE = 1048576KB , MAXSIZE = UNLIMITED, FILEGROWTH = 1024KB )
 LOG ON 
( NAME = N'TOTPAuthentication_log', FILENAME = N'https://storageaccount.blob.core.windows.net/container/TOTPAuthentication_log.ldf' , SIZE = 1048576KB , MAXSIZE = 1073741824KB , FILEGROWTH = 10%)
GO

USE [TOTPAuthentication]
GO

CREATE TABLE [dbo].[Secrets](
    [upn] [varchar](255) NOT NULL,
    [secret] [char](16) NOT NULL,
 CONSTRAINT [PK_Secrets] PRIMARY KEY CLUSTERED 
(
    [upn] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]

GO

CREATE TABLE [dbo].[UsedCodes](
    [upn] [varchar](255) NOT NULL,
    [interval] [bigint] NOT NULL
) ON [PRIMARY]

GO

The method to validate the codes could look something like this;

private static bool CheckCode(string secretKey, string code, string upn, DateTime when)
{
    long currentInterval = GetInterval(when);
    bool success = false;
    for (long timeIndex = currentInterval - pastIntervals; timeIndex <= currentInterval + futureIntervals; timeIndex++)
    {
        string intervalCode = GetCode(secretKey, timeIndex);
        bool intervalCodeHasBeenUsed = CodeIsUsed(upn, timeIndex);
        if (!intervalCodeHasBeenUsed && ConstantTimeEquals(intervalCode, code))
        {
            success = true;
            SetUsedCode(upn, timeIndex);
            break;
        }
    }
    return success;
}

In the snippet, you see that we use a configurable tolerance; pastIntervals and futureIntervals. We now need to implement the "CodeIsUsed" method to check whether the code has been previously used or not. Of course, after a successful authentication we would also have to indicate that the code has been used; SetUsedCode. Last, I want to point out to you the ConstantTimeEquals method. We could simple do "a.Equals(b)" or "a == b" or something like that, but apparently some hackers would then be able to find out where in the process the codes are different, to finally hack the code. (https://codahale.com/a-lesson-in-timing-attacks/) You could just use "a == b", but if you want to, here is the code for the Constant Time Equals operation;

protected static bool ConstantTimeEquals(string a, string b)
{
    uint diff = (uint)a.Length ^ (uint)b.Length;
    for (int i = 0; i < a.Length && i < b.Length; i++)
    {
        diff |= (uint)a[i] ^ (uint)b[i];
    }
    return diff == 0;
}

We are pretty much done. We only now need to tie a secret key to a user. I have chosen to store the secret keys in a database. I could use Active Directory for that, but due to possible replication latency and permissions issues I have chose not to use that.

Putting it all together

Now that we have all to code to create a secret key, to create a time-based code and to validate it, it's time to combine all the components into the AD FS Multi-Factor Authentication provider. I have chosen to implement this MFA in the following manner;

The first time the user is required to use MFA, and uses the TOTP MFA Provider, a secret key is generated. Using the QR Code "generator" from Google, I will show the user the correct QR code. The user uses this QR code to configure the application. This is shown ONLY ONCE. The key is then stored in the database. If the user should lose the application, or phone, delete the key from the database and the next time the user logs on, he will get a new secret key and a new QR code. (For a taste of the QR code; click here.)

After the initial setup, the secret key from the database will be used to validate the codes from the client.

Now, using the same methodology I described earlier here, or the methodology described on MSDN, we can create our MFA Provider for AD FS 3.0. You can download the whole C# project here. You will have to create the proper reference to the AD FS DLL, create a database and configure the proper SQL Connection String. After compilation, copy it to the AD FS servers in the farm, add the DLL to the Global Assembly Cache and register the MFA provider. (Not sure how to do that? Check the references I pointed out to you!)

Good luck! I've tested the solution with the Microsoft Verificator App, some "random" Google Authenticator Apps for Windows Phone and some for Windows. I don't own an iPhone, iPad or Android device. So if you have tried this solution with any of those devices and apps; please let me know how that worked!

Some key things to take into account before you start using this codebase for your own authentication provider:

Safety

This code has not been created with safety in mind. Think about encrypting the location where secret keys are stored.

Stability

No proper error handling has been implement. This could severely impact the working of the AD FS farm.

Support

This is only Proof-of-Concept code. This code is NOT SUPPORTED by me or Microsoft in any way, shape or form.

# THIS CODE AND ANY ASSOCIATED INFORMATION ARE PROVIDED “AS IS” WITHOUT
# WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT
# LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS
# FOR A PARTICULAR PURPOSE. THE ENTIRE RISK OF USE, INABILITY TO USE, OR 
# RESULTS FROM THE USE OF THIS CODE REMAINS WITH THE USER.

Introduction

Recently, Microsoft has introduced a new feature in Microsoft Azure to allow a direct VPN connection between multiple Virtual Networks (VNets). In this blog post I will explain how to connect multiple VNets to each other within Microsoft Azure.

A good starting point to read more on how to configure a connection between two VNets can be found here: Configure a VNet to VNet Connection and Creating a Stretched Network on Microsoft Azure. The examples give you great guidance on how to configure VNet <--> VNet connectivity.

From the Virtual Network FAQ we read that we connect multiple VNets to each other:

Q: How many on premises sites and virtual networks can one virtual network connect to?
A: Max. 10 combined; e.g., one Azure virtual network and connect to 6 on premises sites and 4 virtual networks.

Yet, configuring a connection from one VNet to multiple other VNets is not as trivial as it perhaps should be. So what if you want to create some "star" topology? Or you need to connect two VNets to one other VNet? None of the articles mentioned before care to explain how something like that could be configured, but things functionality in Microsoft Azure will unleash new scenario's that previously where only possible using multiple VPN connections to on-premises locations. This is specifically try for people that want to deploy geo-redundant IaaS or PaaS solutions in Azure.

Solution

Let's assume you want to deploy two Cloud Services, in two different Microsoft Azure Datacenters. By using Microsoft Azure Traffic Manager, you can make sure that clients connect to that specific Cloud Service that performs best for their locations. (For any geographically dispersed, geo-redundant, solution, this should be something that you at least take a look at.) A Cloud Service would be deployed in a Virtual Network, and a Virtual Network is tied to Microsoft Azure Datacenter. Hence, both Cloud Services would be deployed in their own Virtual Network. Previously, if these Cloud Services would need to connect to a "shared resource", like a Microsoft SQL Database, the only option would be to connect both Virtual Networks to an on-premises VPN endpoint (for example a Cisco- or Juniper device, or a Windows Server 2012 R2 Routing and Remote Access Server.) Then, the on-premises equipment could route traffic between the two VNets. All traffic between the two VNets would then be routed through the on-premises infrastructure.

So let's assume we have this sort of solution; deployed in two different Microsoft Azure Datacenters, and they both need to connect to a Microsoft SQL Database on the back-end. This Microsoft SQL Database is deployed on Microsoft Azure Infrastructure-as-a-Service, running in a third Microsoft Azure Datacenter, in it's own Cloud Service (Let's call it CSDB) and it's own Virtual Network (Let's call it VNET3). The front-ends are deployed in two Cloud Services (let assume the are named CSINET1 and CSINET2) and their corresponding Virtual Networks (Let's call these VNET1 and VNET2).

The goal here is to enable traffic to flow from VNET1 to VNET3 (and vice-versa) and from VNET2 to VNET3. Hence, we would need to connect VNET3 to two different Vnets; VNET1 as well as VNET2. Something like this: VNET1 <--> VNET3 <--> VNET2.

Here is the configuration of VNET1:

You see that we use the address space 10.1.0.0/16 for this virtual network. The servers live in the Subnet-1 subnet; 10.1.0.0/19. We have created a Gateway Subnet called Gateway with IP network range 10.1.32.0/29.

The configuration for VNET2 is the same, except that we now use the 10.2.x.x address space:

For our last network, VNET3, where the database "lives", we use 10.3.x.x:

Please do keep in mind that connection Azure Virtual Networks to other Azure Virtual Networks ONLY works when the gateway has been setup using Dynamic Routing.

If we want to connect a Virtual Network to another network (whether it be a Virtual Network or an on-premises network) we will have to define the network address range(s) for these networks in Microsoft Azure, under Local Networks. In our demonstration, we will create a Local Network for VNET1, VNET2 and VNET3, with their corresponding network ranges. (If you have not already created your Gateways in the Virtual Networks, simply put a bogus VPN Address in the dialog. We can change that later.)

Now, from the Microsoft Azure Management Portal, we can connect VNET1 to VNET3 and VNET2 to VNET3.

If you need any assistance completing the previous steps, please consult Configure a VNet to VNet Connection. This will guide you through the process of creating the gateways, the local networks and connecting a Virtual Network to another Virtual Network.

Now, the real challenge starts when we want to configure VNET3 to connect to two other Vnets; VNET1 and VNET2. We cannot do this through the current Microsoft Azure Management Portal. Once we "connect" VNET3 to one of the other subnets, through the portal, we can no longer connect this VNet to another VNet. Apparently, what we want is not possible from the portal (currently).

To connect VNET3 to the remaining Vnet:

From the Microsoft Azure Management Portal, download the configuration for your Virtual Network:

Let's assume you save this file as vnet.xml on your local machine.

Alternatively, you can use PowerShell to export the configuration by using this command:

Get-AzureVNetConfig -ExportToFile C:\Temp\VNET.xml

Open the VNET.xml file using notepad (or similar text editor) and locate the VNet configuration part for the VNet that you want to connect to multiple other VNet's. In our example, that is VNET3.

Locate this section:

<VirtualNetworkSite name="VNET3" Location="Azure Datacenter">

Under that section, there should be a Gateway section, that shows you the current gateway configuration. This is where need to make our changes.

Locate the Gateway section in the VirtualNetworkSite section:

<Gateway>
<ConnectionsToLocalNetwork>
<LocalNetworkSiteRef name="VNET1">
<Connection type="IPsec" />
</LocalNetworkSiteRef>
</ConnectionsToLocalNetwork>
</Gateway>

In this case, our VNET3 already had a connection with VNET1, but we need to add a connection to VNET2. We add the appropriate section to this Gateway section. It should now look like this:

<Gateway>
<ConnectionsToLocalNetwork>
<LocalNetworkSiteRef name="VNET1">
<Connection type="IPsec" />
</LocalNetworkSiteRef>
<LocalNetworkSiteRef name="VNET2">
<Connection type="IPsec" />
</LocalNetworkSiteRef>
</ConnectionsToLocalNetwork>
</Gateway>

Save this modified xml file, and import it into Azure;

Set-AzureVNetConfig -ConfigurationPath C:\Temp\VNET.xml

Make sure that your command completes successfully:

OperationDescription       OperationId                OperationStatus
--------------------       -----------                ---------------
Set-AzureVNetConfig        01fc891b-c4a5-ceb3-9a70... Succeeded

The new configuration should now be applied to Azure. When you open the Azure Management Portal and navigate to Virtual Networks, select the network you just modified, you will see that the GUI for the Dashboard has changed. You see that your virtual network is trying to connect to two other virtual networks. From the Azure Management Portal, you are no longer allowed to make any changes: (this screenshot is from a different setup, with different VNet names, but you'll get the idea...)

Although we see that there are now two virtual network connections, Azure is unable to connect the two virtual networks. This is because the shared keys for the gateways have not been (properly) set. We need to fix this. (And we cannot do this through the Azure Management Portal.) So we fix these keys through PowerShell:

Set-AzureVNetGatewayKey -VNetName VNET3 -LocalNetworkSiteName VNET1 -SharedKey SuperSecretKey
Set-AzureVNetGatewayKey -VNetName VNET3 -LocalNetworkSiteName VNET2 -SharedKey SuperSecretKey
Set-AzureVNetGatewayKey -VNetName VNET2 -LocalNetworkSiteName VNET3 -SharedKey SuperSecretKey
Set-AzureVNetGatewayKey -VNetName VNET1 -LocalNetworkSiteName VNET3 -SharedKey SuperSecretKey

In this example, I set the keys for all Gateway connections but that is not required. You can use different keys for different networks and you don't have to change existing keys. Now give your gateways some time to bring up the connection, and check the Dashboard for the virtual networks to see if the connections work. You should see something resembling this:

If you have Virtual Machines in for example VNET1, you can now connect to other Virtual Machines in VNET3. From machines in VNET2 you can connect to machines in VNET3. Please do keep in mind that using this simple sample configuration will not allow you to connect from machines in VNET1 to machines in VNET2, or vice versa, directly. If that's what you want, you can setup a new network connection following the same procedure.

That's it! You've managed to connect multiple virtual networks to another virtual network in Microsoft Azure.

As an administrator, you might want to ease this process to the end-user and pre-provision Multi-Factor Authentication in Microsoft Azure Active Directory.

First, make sure that the users Mobile Phone Number is properly set in Microsoft Azure Active Directory. (If you are using the Directory Synchronization Tool (DirSync) or the Windows Azure Active Directory Connector for FIM 2010 R2, the user's mobile phone number will by synchronized from Active Directory automatically.)

If that's set, you can enable and configure Multi-Factor Authentication by using PowerShell:

$upn = "VOConner@contoso.com"


$st = New-Object -TypeName Microsoft.Online.Administration.StrongAuthenticationRequirement
$st.RelyingParty = "*"
$st.State = "Enforced"

$sta = @($st)

$sm1 = New-Object -TypeName Microsoft.Online.Administration.StrongAuthenticationMethod
$sm1.IsDefault = $true
$sm1.MethodType = "OneWaySMS"

$sm2 = New-Object -TypeName Microsoft.Online.Administration.StrongAuthenticationMethod
$sm2.IsDefault = $false
$sm2.MethodType = "TwoWayVoiceMobile"

$sm = @($sm1, $sm2)

Set-MsolUser -UserPrincipalName $upn -StrongAuthenticationRequirements $sta -StrongAuthenticationMethods $sm

By using this script, Multi-Factor Authentication for the user VOConner@contoso.com will be enabled for all applications in Azure Active Directory (this is the $st variable in the code). After we enable MFA, we need to provide Azure with the methods we want to use for MFA. In this case, we enable two methods; the PIN Text Message (OneWaySMS) and the voice call (TwoWayVoiceMobile). The default authentication method is OneWaySMS. These two methods are held in the $sm variable.

Last, we update the user using the Set-MsolUser command.

When you add Azure Active Directory as an Identity Provider, or Claims Provider, in Active Directory Federation Services, you get a defined set of claims from it. If you're not using the Premium version of Azure Active Directory, you won't for example get claims for group membership in Azure Active Directory. Other attributes that might be present in Azure Active Directory, like an alternate email address, are also not available as claims. There could be occasions where you need this information when a user authentications through an Azure Active Directory that you manage. (Now that is the keyword here; whatever we do in this article requires you to have proper permissions on the Azure Active Directory.)

In order to use attributes from Azure Active Directory users as claims in AD FS, we can create an Attribute Store that queries Azure Active Directory. This article explains just that. To get started, first create you Attribute Store as outlined on one of my earlier articles; How to create a Custom Attribute Store for Active Directory Federation Services 3.0. We'll focus on the code that you need to write in the class that you create.

Prerequisites

• Check How to create a Custom Attribute Store for Active Directory Federation Services 3.0
• Access to a Windows Azure Subscription with an Azure Active Directory provisioned. For a How To: https://msdn.microsoft.com/en-us/library/dn569294.aspx
• A working federation trust relationship with Azure Active Directory and Active Directory Federation Services (where Azure Active Directory is setup as a Claims Provider in AD FS and AD FS is setup as an application in Azure Active Directory).

Active Directory Authentication Library

First, we need to add the Active Directory Authentication Library. This is a NuGet package that can be installed by using the Package Manager Console (at the bottom of you Visual Studio screen) or through the Tools, Package Manager and then either Package Manager Console or Manage NuGet Packages for Solution...

If you're using the Package Manager Console type this command:

Install-Package Microsoft.IdentityModel.Clients.ActiveDirectory -Version 1.0.3

In this case, I'm adding version 1.0.3, but newer versions might be available. Please check https://www.nuget.org/packages/Microsoft.IdentityModel.Clients.ActiveDirectory/ to see what the latest version is.

If you're using the Manage NuGet Packages option, search for "Active Directory Authentication Library" and select the version you want from there.

After adding that NuGet package, download the Windows Azure AD Graph API Helper Library. Unpack the zip file, open the Solution in Visual Studio and compile it. Next, add a reference to the resulting DLL from you Attribute Store project. Now, the references in you Attribute Store project should resemble this;

Building the code

Now switch to the class file where you will build the Attribute Store in. In the example I referenced earlier, it's called Class1.cs, but I will give it a more meaningful name, like WAADAttributeStore.cs

Inspect the using statements, at the beginning of the code, and add these lines:

using Microsoft.IdentityServer.ClaimsPolicy.Engine.AttributeStore;
using Microsoft.WindowsAzure.ActiveDirectory;
using Microsoft.WindowsAzure.ActiveDirectory.GraphHelper;
using System.IdentityModel;

Make sure you properly paste this code as the Initialize method in the class:

        public void Initialize(Dictionary<string, string> config)
        {
            if (null == config)
            {
                throw new AttributeStoreInvalidConfigurationException("No configuration parameters passed.");
            }

            string tenantName;
            string clientId;
            string password;

            if (config.ContainsKey("TenantName"))
            {
                tenantName = config["TenantName"];
            }
            else
            {
                throw new AttributeStoreInvalidConfigurationException("TenantName configuration parameter not found.");
            }
            if (config.ContainsKey("ClientId"))
            {
                clientId = config["ClientId"];
            }
            else
            {
                throw new AttributeStoreInvalidConfigurationException("ClientId configuration parameter not found.");
            }
            if (config.ContainsKey("Password"))
            {
                password = config["Password"];
            }
            else
            {
                throw new AttributeStoreInvalidConfigurationException("Password configuration parameter not found.");
            }

            AADJWTToken token = DirectoryDataServiceAuthorizationHelper.GetAuthorizationToken(tenantName, clientId, password);
            this.graphService = new DirectoryDataService(tenantName, token);
        }

This Initialize method takes three parameters; TenantName, ClientId and Password. This information can be taken from the Azure management portal at https://manage.windowsazure.com after adding a custom application to your Azure Active Directory. (More information: https://msdn.microsoft.com/en-us/library/dn151791.aspx) Now, let's just finish the coding part. In this example, we going to extract group membership information from Azure Active Directory (which is not required if you use Azure Active Directory Premium, because group membership is available as claims in there).

Replace the BeginExecuteQuery method with this code:

        public IAsyncResult BeginExecuteQuery(string query, string[] parameters, AsyncCallback callback, object state)
        {
            if (String.IsNullOrEmpty(query))
            {
                throw new AttributeStoreQueryFormatException("No query string.");
            }
            if (null == parameters)
            {
                throw new AttributeStoreQueryFormatException("No query parameter.");
            }

            if (parameters.Length != 1)
            {
                throw new AttributeStoreQueryFormatException("More than one query parameter.");
            }

            string inputString = parameters[0];

            if (inputString == null)
            {
                throw new AttributeStoreQueryFormatException("Query parameter cannot be null.");
            }

            string[][] outputValues;

            switch (query)
            {
                case "GetGroupNamesByUserName":
                    {
                        string userPrincipalName = inputString;

                        User user = graphService.users
                            .Where(u => u.accountEnabled == true && u.userPrincipalName == userPrincipalName)
                            .AsEnumerable()
                            .SingleOrDefault();

                        var groupReferences = graphService.LoadProperty(user, "memberOf")
                            .OfType<Group>()
                            .Select(g => g.displayName)
                            .ToArray();

                        outputValues = new string[groupReferences.Length][];

                        for (int i = 0; i < groupReferences.Length; i++)
                        {
                            outputValues[i] = new string[1] { groupReferences[i] };
                        }
                        break;
                    }
                default:
                    {
                        throw new AttributeStoreQueryFormatException("The query string is not supported.");
                    }
            }

            TypedAsyncResult<string[][]> asyncResult = new TypedAsyncResult<string[][]>(callback, state);
            asyncResult.Complete(outputValues, true);
            return asyncResult;
        }

Our sample Attribute Store only supports one single query; GetGroupNamesByUserName. This method gets the users group membership, based on the username (where the username is a UPN). This UPN has to be provided by AD FS (and was originally provided by Azure Active Directory). We then take this UPN to lookup the user in Azure Active Directory, get the group membership and return these groups as claims. You can have AD FS decide what the exact claim type will be that AD FS will issue.

Last, check that the EndExecuteQuery method has the code we've seen before:

        public string[][] EndExecuteQuery(IAsyncResult result)
        {
            return TypedAsyncResult<string[][]>.End(result);
        }

Okay, that's it! Compile it, ship the resulting DLL to the AD FS server, add the Attribute Store and use these initialization parameters:

• TenantName
• ClientId
• Password

Then, configure a claim rule for a relying party to use the GetGroupNamesByUserName query for the attribute store, and pass a UPN as the parameter. Again, if you need more information on how to do this; consult my previous article; How to create a Custom Attribute Store for Active Directory Federation Services 3.0

Have fun!