Herb’s Kingdom

Possible to Transit Traffic through Dynamic Gateway of Azure Virtual Network?

HerbChung — Fri, 17 Apr 2015 01:10:00 GMT

One of my customer give me this scenario:

Customer have three sites and they plan to use Azure IaaS
There is no WAN/VPN between their sites
They want to leverage Azure Site-to-Site VPN with following architecture

But their intention is: They want to leverage the Dynamic Gateway on Azure to establish the network connection between sites. That is the machine in Site A can visit the machine in Site B and Site C….etc

If you have tried this architecture before, you will find it will not just happen. Also, in our Virtual Network FAQ, you will find:

It seems like the only way is to establish the Site-to-Site VPN between customer’s sites. But wait, you see a hope from the FAQ:

You see that although it’s not recommended, you can configure NETCFG to achieve their target. But how? That is this article talking about:

First, let me introduce my LAB environment:

I create 3 Virtual Network on Azure, and simulate Vnet2 as Site A; Vnet3 as Site B
Vnet1’s IP range is 192.168.1.0/24. Vnet2’s IP Range is 192.168.2.0/24. Vnet3’s IP Range is 192.168.3.0/24.
I establish Vnet-to-Vnet VPN between Vnet1 and Vnet2; Vnet1 and Vnet3. Please note there is NO VPN connection between Vnet2 and Vnet3.

For Vnet-to-Vnet configuration, you could check for detail steps: https://msdn.microsoft.com/en-us/library/azure/dn690122.aspx

But there are few things need to take care.

For the routing setting, our intention is to leverage Dynamic Gateway. So the relationship will be like this:

	192.168.1.0/24	192.168.2.0/24	192.168.3.0/24
Vnet1	Itself	Vnet2	Vnet3
Vnet2	Vnet1	Itself	Vnet1
Vnet3	Vnet1	Vnet1	Itself

For Vnet1, it will route 192.168.2.0/24 to Vnet2 and 192.168.3.0/24 to Vnet3.

For Vnet2, it will route 192.168.1.0/24 and 192.168.3.0/24 to Vnet1.

For Vnet3, it will route 192.168.1.0/24 and 192.168.2.0/24 to Vnet1.

Therefore, the local network setting in virtual network will be

We will assign Local Network Vnet2 and Local Network Vnet3 to Virtual Network Vnet1.

We will assign Local Network Vnet13 to Virtual Network Vnet2.

We will assign Local Network Vnet12 to Virtual Network Vnet3.

2. We use NETCFG to change the network configuration rather than GUI. Please export NETCFG from Azure Management Portal. You will get a file name “NetworkConfig.xml”. Here, I suppose you should already complete the gateway creation and local network setup before export.

3. Open NetworkConfig.xml with Notepad. You will find some information from my example. The Green part is the local network configuration. It should be already there if you complete the previous steps. The Red part is the gateway configuration. You need to manual insert the configuration.

192.168.1.0/24

192.168.2.0/24

191.234.22.183

192.168.1.0/24

192.168.3.0/24

191.234.22.183

192.168.2.0/24

104.46.234.89

192.168.3.0/24

104.41.179.89

192.168.1.0/24

192.168.1.0/27

192.168.1.32/29

192.168.2.0/24

192.168.2.0/27

192.168.2.32/29

192.168.3.0/24

192.168.3.0/27

192.168.3.32/29

4. After complete the NETCFG, you can import the settings into Azure Virtual Network

5. Finally, you need to connect the gateway, please check for detail steps: https://msdn.microsoft.com/en-us/library/azure/dn690122.aspx#BKMK_PreSharedKeys
You need to create sharedkey for each VPN. In my example, I used the following powershell cmd.

Set-AzureVNetGatewayKey -VNetName VNet1 -LocalNetworkSiteName VNet2 -SharedKey herbchung
Set-AzureVNetGatewayKey -VNetName VNet1 -LocalNetworkSiteName Vnet3 -SharedKey herbchung

Set-AzureVNetGatewayKey -VNetName Vnet2 -LocalNetworkSiteName Vnet13 -SharedKey herbchung

Set-AzureVNetGatewayKey -VNetName Vnet3 -LocalNetworkSiteName Vnet12 -SharedKey herbchung

6. After the setup, you should find the Vnet has connected by our architecture design.

Now, the virtual network has been set up. Let’s do an experiment to create VM in Vnet2 and Vnet3 and see if they can communicate with each other.

The IP Address of VM in Vnet2 is 192.168.2.4

The IP Address of VM in Vnet3 is 192.168.3.4

We try to ping from Vnet2 to Vnet3 and try to ping from Vnet3 to Vnet2. The ping is successful.

How to Export/Import the Identity from Azure AD to Local AD

HerbChung — Tue, 14 Apr 2015 01:38:08 GMT

DirSync or AAD Sync supports you can sync from local AD to Azure AD no matter for Office 365, Intune or Azure RMS. But in a Cloud First World, customer might also experience a Cloud First IT environment. That is, customers might have Azure AD first than they want to build their on-premise AD. They will face a challenge that current tool do not support two-way sync. There is only one-way sync from on-premise to Azure AD. Although we have this feature roadmap on Azure AD Connect, it still takes time to wait until General Available. We need a temporary solution for now and that's what this post for.

But I would like to address first that there are also some limitations in my methodology:

The password cannot be exported from Azure AD. Therefore, you might need to recreate the password and ask users to change password after migration.
If you want to sync on-premise AD and Azure AD, the user password will follow on-premise AD.

The high level steps are:

Export the user list from office 365 via PowerShell
Generate random password for each user
Import the user list to local AD via PowerShell

Tools will be included:

Azure AD Powershell

https://msdn.microsoft.com/en-us/library/azure/jj151815.aspx#bkmk_installmodule

Notice:

The export/import user data is in C:\temp\o365UserData.csv
The password policy set password never expire, you could change it in the ImportUserToAD.ps1.
The script will generate a random 8 digit password for each user, and user need to use this NEW password at first logon. You will find this password for each user in the .csv file.
Assuming Users created from Azure AD, user should have first name and last name to make the scripts work.

Steps:

1. Create C:\Temp Folder

2. Execute Powershell ExportOffice365user.ps1 on a machine with Azure AD PowerShell installed. During the scripts, you might need to enter the Office 365 administrator credential two times.

3. After the scripts, you should find o365UserData.csv in C:\Temp, move it to the same location of AD Server (C:\Temp)

4. Execute PowerShell ImportUserToAD.ps1 on AD Server. After the scripts, you should find the users have been created in AD.

5. Now, your AD is ready to sync. The email property should be in user property. You could check the soft match for more detail but I already complete most steps in the script. (http://support.microsoft.com/kb/2641663)

6. Once you Force Sync on-premise AD into Azure AD, the on-premise password will overwrite Azure AD password.

You could also try AAD Connect: https://connect.microsoft.com/site1164/program8612 which will have similar result.

ExportImportPS.zip