12/06/2013

Windows Azure Active Directory 多要素認証プロバイダーとディレクトリの連携

 

はじめに

今年ももうすぐ終わりですね。今回はWindows Azure Advent Calender 2013に参加した投稿となっています。

 

Windows Azure Active Directory多要素認証プロバイダーとディレクトリ

以前、Windows Azure Active Directory多要素認証プロバイダーの電話メッセージを紹介しました。当時は、プレビューでしたので、Multi-Factor Authentication Serverによるオンプレミス側のWindows Severと、クラウド側の多要素認証プロバイダの連携しかできませんでした。現在はクラウド側の多要素認証プロバイダーとディレクトリの連携も可能になっていますので、本投稿ではそちらを紹介します。

 

structure

 

ディレクトリと多要素認証プロバイダーのリンク設定

ディレクトリと多要素認証プロバイダーのリンクは、ポータルのActive Directory内の多要素認証プロバイダーか、ディレクトリの、どちらかの設定から行います。

 

多要素認証プロバイダーから設定は、多要素認証プロバイダーを作成する時に設定します。

01

 

ディレクトリから設定は、Enable Multi-Factor Authenticationから設定を行います。

03

 

ユーザ設定

Active Directoryのディレクトリのユーザからユーザを作成します。多要素認証プロバイダーとディレクトリのリンクにより、ユーザのロールがUserでも多要素認証できるようになりました。(多要素認証プロバイダーが提供されていなかった時は、ディレクトリ内で多要素認証の設定が可能でしたが、管理者である必要がありました)

04

電話メッセージを利用しますので、電話番号を設定します。

05

 

アプリケーションの準備

Office365など利用している人はそちらを利用することができますが、Windows Azure Active Directoryを使用したWebアプリケーションを作成することができます。興味がある方は、以下のURLを参考にしてください。(スライドですいません。。。。)

 

Windows Azure Active Directoryを利用したアプリケーション

http://kentablog.cluscore.com/2013/04/windows-azure-active-directory.html

 

アプリケーションを登録すると以下のようなディレクトリの画面になります。以下の画面では3つのテスト用アプリが登録されています。

13

 

動作確認

登録しているWebアプリケーションにアクセスすると、以下のようなログイン画面が表示されます。ユーザ名とパスワードを入力した後に、電話がかかってきます。

なお、電話番号が設定されたいない場合や初めてログインする時に、電話番号の入力と確認が行われる場合があります。

06

ユーザ名とパスワードが正しい場合は、電話を呼びます。

07

そして、登録した電話に、海外(US)からの呼び出しがきます。

photo 1

メッセージに従って#(デフォルト設定)を押します。

photo 2

#を押した後、ログイン画面から、Webアプリケーションにリダイレクトされてアプリケーションが表示されます。

 

電話メッセージをカスタマイズ

多要素認証プロバイダーの管理画面では、電話メッセージをカスタマイズすることができます。認証に成功した場合に、好きなMP3の音声メッセージを再生するなど条件の設定ができます。

 

音声ファイルの登録

多要素認証プロバイダ管理画面の左メニューのConfigure Voice MessageのManage Sound Fileより 、音声ファイルをアップロードして登録します。

08

09

10

11

12

音声ファイルの登録が完了しました。

 

登録した音声ファイルで認証するアプリケーションの設定

多要素認証プロバイダ管理画面の左メニューのConfigure Voice Messageより、登録した音声ファイルを再生する条件の設定をします。

ここで入力するアプリケーション名は、以前紹介したMulti-Factor Authentication Serverと異なり、”SAS Login"という固定の名前になります。ディレクトリで登録したアプリケーション名ではないので注意が必要です。(ディレクトリで登録したアプリケーション名が使えると便利なのですが、残念です)

次に条件としてMessage Typeを”Authentication Successfulに設定します。これにより認証成功時に指定した音声ファイルが再生されます。

22

登録を確認します。

23

 

認証レポートの確認

認証レポートは、多要素認証管理画面から確認することができます。左メニューのView a ReportのUsageを選択します。

24

Queuedを選択した後に、Usage Authentication User Detailsを選択します。

25

多要素認証のログが確認できます。

26

 

さいごに

多要素認証プロバイダーとディレクトリをリンクした時の雰囲気を感じていただけたらと思います。それではまたー。

10/12/2013

Windows Azureのリージョン間でVPN接続してみた

 

前回「Windows Azureの地域間VPNを試してみた(始めの調査編)」では、Windows Azureのデータセンター間で双方向に通信することができませんでしたが、今回は双方向通信を実現する構成の紹介です。(2013年10月7日のWindows Azure機能で構築してます)

1.構成

Windows AzureのEast Asia、West Asiaにそれぞれ仮想ネットワークのゲートウェイを作成しています。それぞれのデータセンタからは、Linux(Ubuntu)で相互に各地域のゲートウェイにVPNトンネルを接続しています。

network-design01

前回の調査結果からこのような構成になりました。現段階ではVPNトンネルを2つ用意して確認しています。

また、Linux(Ubuntu)のVPNゲートウェイで、相手のネットワークからの通信をNAT(MASQUERADE)しています。例えば、vn-asia-vmからvn-us-vmへの通信は、vn-us-gwでNATされています。

network-design02

 

2.作成した仮想ネットワーク

仮想ネットワークは構成の通り、East AsiaとWest USの2つです。

network

それぞれの仮想ネットワークに存在するゲートウェイに接続するローカルネットも作成します。これらのローカルネットは仮想ネットワークのネットワークアドレスと同じ範囲になってしまいますが問題ありません。

localnetwork

3.各地域の仮想マシン

始めに作成した仮想マシンは構成と同じように4台作成しました。この4台はLinux(Ubuntu)のVPN2台(vn-asia-ge, vn-us-gw)と、通信テスト用の仮想マシン2台(vn-sia-vm, vn-us-vm)です。

vms

East Asiaのゲートウェイ

エンドポイントでは、IPSec NAT Traversal用のUDPポートの設定を行います。ISAKMPのUDP 500ポートと、IPSec NAT TraversalのUDP 4500ポートを、vn-asia-vmに向けています。

vn-asia-gw

East Asiaの通信テスト用仮想マシン

vn-asia-vm

West USのゲートウェイ

エンドポイントでは、IPSec NAT Traversal用のUDPポートの設定を行います。ISAKMPのUDP 500ポートと、IPSec NAT TraversalのUDP 4500ポートを、vn-us-vmに向けています。

vn-us-gw

West USの通信テスト用仮想マシン

vn-us-vm

4.各地域の仮想ネットワーク

East Asiaの仮想ネットワークです。仮想マシンがネットワーク上にいることが確認できます。作成したゲートウェイはStatic Routingです。

vn-asia-dashboard

West USの仮想ネットワークです。仮想マシンがネットワーク上にいることが確認できます。作成したゲートウェイはStatic Routingです。

vn-us-dashboard

5.各地域のLinux(Ubuntu)VPN仮想マシン設定

各地域の通信確認用仮想マシンの設定は特に説明しませんが、通信確認する際は下記のコマンドでファイアウォールのルールを削除しておくと便利です。

$sudo iptables –F

5.1.まずは、East Asia側のVPN仮想マシン

5.1.1.VPNの設定

Open Swanのインストール。

$sudo apt-get install openswan

IPSecの設定です。ipsec.conは変更箇所だけ編集して、最後の行にincludeの行を挿入します。

$sudo vi /etc/ipsec.conf
config setup
      protostack=netkey
      nat_traversal=yes
      virtual_private=%v4:10.20.0.0/16
      oe=off
include /etc/ipsec.d/*.conf

$sudo vi /etc/ipsec.d/azure-us.conf
conn azure-us
   authby=secret
   auto=start
   type=tunnel
   left=10.20.0.4
   leftsubnet=10.20.0.0/16
   leftnexthop=%defaultroute
   right=168.61.64.182
   rightsubnet=10.10.0.0/16
   ike=aes128-sha1-modp1024
   esp=aes128-sha1
   pfs=no

IPSecの鍵設定をします。鍵はWindows Azureの仮想ネットワークのダッシュボードから取得します。

$sudo vi /etc/ipec.secrets
10.20.0.4 168.61.64.182 : PSK "krOurXxXX6XxXXX7xxxwnXXXXXaLkXXX"

$sudo vi /etc/sysctl.conf
net.ipv4.ip_forward=1
$sudo sysctl -p /etc/sysctl.conf
$sudo service ipsec restart

5.1.2.ファイアウォールとNATの設定

VPNの設定が終わったら、ファイアウォールとNATの設定をします。今回使用しているLinuxはUbuntuですので、Ubuntuのお作法にのっとってiptablesの設定をします。

https://help.ubuntu.com/lts/serverguide/firewall.html

まずは、ファイアウォール設定から。SSH用のポート設定は重要です。この設定をしないとLinux(Ubuntu)にアクセスできなくなります。(一回やってしまった)

$sudo ufw allow proto tcp to any port 22
$sudo ufw allow proto udp to any port 500
$sudo ufw allow proto udp to any port 4500

つぎにNAT(MASQUERADE)の設定です。VPNの設定でOSのIPフォワード設定をしましたが、ここではファイアウォール側のフォワード設定を行います。

$sudo vi /etc/default/ufw
DEFAULT_FORWARD_POLICY="ACCEPT"

次にNATの設定を行います。以下の設定をファイルのトップに書いてください。

$sudo vi /etc/ufw/before.rules

# nat Table rules
*nat
:POSTROUTING ACCEPT [0:0]

# Forward traffic from eth1 through eth0.
-A POSTROUTING -s 10.10.0.0/16 -o eth0 -j MASQUERADE

# don't delete the 'COMMIT' line or these nat table rules won't be processed
COMMIT

さいごにファイアウォールを有効にします。

$sudo ufw disable && sudo ufw enable

5.2.次に、West USの設定


5.2.1.VPNの設定


Open Swanのインストール。


$sudo apt-get install openswan


IPSecの設定です。ipsec.conは変更箇所だけ編集して、最後の行にincludeの行を挿入します。


$sudo vi /etc/ipsec.conf
config setup
      protostack=netkey
      nat_traversal=yes
      virtual_private=%v4:10.10.0.0/16
      oe=off
include /etc/ipsec.d/*.conf


$sudo vi /etc/ipsec.d/azure-asia.conf
conn azure-asia
   authby=secret
   auto=start
   type=tunnel
   left=10.10.0.4
   leftsubnet=10.10.0.0/16
   leftnexthop=%defaultroute
   right=207.46.137.55
   rightsubnet=10.20.0.0/16
   ike=aes128-sha1-modp1024
   esp=aes128-sha1
   pfs=no


IPSecの鍵設定をします。鍵はWindows Azureの仮想ネットワークのダッシュボードから取得します。


$sudo vi /etc/ipec.secrets
10.10.0.4 207.46.137.55 : PSK "krOurXxXX6XxXXX7xxxwnXXXXXaLkXXX"


$sudo vi /etc/sysctl.conf
net.ipv4.ip_forward=1
$sudo sysctl -p /etc/sysctl.conf
$sudo service ipsec restart


5.2.2.ファイアウォールとNATの設定


VPNの設定が終わったら、ファイアウォールとNATの設定をします。


まずは、ファイアウォール設定から。SSH用のポート設定は重要です。この設定をしないとLinux(Ubuntu)にアクセスできなくなります。


$sudo ufw allow proto tcp to any port 22
$sudo ufw allow proto udp to any port 500
$sudo ufw allow proto udp to any port 4500


つぎにNAT(MASQUERADE)の設定です。VPNの設定でOSのIPフォワード設定をしましたが、ここではファイアウォール側のフォワード設定を行います。


$sudo vi /etc/default/ufw
DEFAULT_FORWARD_POLICY="ACCEPT"


次にNATの設定を行います。以下の設定をファイルのトップに書いてください。


$sudo vi /etc/ufw/before.rules


# nat Table rules
*nat
:POSTROUTING ACCEPT [0:0]


# Forward traffic from eth1 through eth0.
-A POSTROUTING -s 10.20.0.0/16 -o eth0 -j MASQUERADE


# don't delete the 'COMMIT' line or these nat table rules won't be processed
COMMIT


さいごにファイアウォールを有効にします。

$sudo ufw disable && sudo ufw enable

6.Windows Azureの地域に分かれる仮想ネットワーク間で通信してみる


Pingで確認してみます。まずは、East Asiaのvn-asia-vmからWest USのvn-us-vmに通信します。


vn-asia-vm-ping


通信できますね。次はWest USのvn-us-vmからEast Asiaのvn-asia-vmに通信します。


vn-us-vm-ping


問題なく通信できますね。


7.最後に


Windows Azureの機能では、地域間VPNの機能がありませんが、自分でVPNを動かせばVPNトンネルを使った通信ができることがわかりました。次は、SQL ServerとかActive Directoryとかを拠点間で動かしてみたいですね。

10/06/2013

Windows Azureの地域間VPNを試してみた(始めの調査編)

 

Windos Azureの地域間VPN接続を試してみましたが、仮想ネットワークの動きを知らないと構築しにくいと思いますので、とりあえずメモしてきます。構成の設定を順に紹介していきます。

始めの調査ということで、今回は失敗した記事となっています。。。

 

1.始めに考えた構成

Windows AzureのEast AsiaにGatewayを作成し、West USからはlinuxのopenswanを使用したVPN GatewayでEast AsiaのGatewayにIPSecでVPN接続する構成です。

azurevpn

 

2.仮想ネットワーク設定


East Asia側の仮想ネットワークはvn-asiaとして作成ました。West US側の仮想ネットワークはvn-usとして作成しています。

nv-networks

また、vn-asiaとvn-usをサイト間接続するため、East Asia側ゲートウェイの先にあるWest USのネットワークを、ローカルネットワークとしてvn-local-usとして作成しています。

nv-localnetworks

 

East Asia側のネットワーク設定

East Asia側のネットワーク設定では、ゲートウェイ作成と、仮想ネットワークアドレス空間の設定、ローカルネットワークの指定を行います。ここで指定するローカルネットワークはWest US側のアドレス空間です。(構築後の設定を見ていますので、VPNとしては繋がってます)

nv-asia-dashboard 


nv-asia-config

 

West US側のネットワーク設定

West US側のネットワーク設定では、仮想ネットワークアドレス空間の設定だけを行っています。

nv-us-dashboard
nv-us-config

 

3.West US側VPN Gatewayの作成

VPN Gateway として利用するUbuntuのlinux仮想マシンをWest USの仮想ネットワークに作成します。

nv-us-vm-gw-os

nv-us-vm-gw

linuxにsshでログインした後に、openswanのインストールと設定をします。以下のコマンドでインストールおよび設定、サービスの起動を行います。viコマンドの下に書かれている行は変更内容です。/etc/ipec.secretsの設定には、East Asiaのゲートウェイアドレスとキーを設定します。

 

$sudo apt-get install openswan
$sudo vi /etc/ipsec.conf
config setup
      protostack=netkey
      nat_traversal=yes
      virtual_private=%v4:10.0.0.0/16
      oe=off
include /etc/ipsec.d/*.conf

$sudo vi /etc/ipsec.d/azure-asia.conf
conn azureasia
   authby=secret
   auto=start
   type=tunnel
   left=10.10.0.4
   leftsubnet=10.10.0.0/16
   leftnexthop=%defaultroute
   right=207.46.137.55
   rightsubnet=10.20.0.0/16
   ike=aes128-sha1-modp1024
   esp=aes128-sha1
   pfs=no

$sudo vi /etc/ipec.secrets
10.10.0.4 207.46.137.55 : PSK "krOurXxXX6XxXXX7xxxwnXXXXXaLkXXX"

$sudo vi /etc/sysctl.conf
net.ipv4.ip_forward=1
$sudo sysctl -p /etc/sysctl.conf
$sudo service ipsec restart

 

エンドポイントでは、IPSec NAT Traversal用のUDPポートの設定を行います。ISAKMPのUDP 500ポートと、IPSec NAT TraversalのUDP 4500ポートを、VPN Gatewayのlinuxの仮想マシンに向けます。

 

nv-us-vpngw-endpoint

 

4.通信確認


地域間でVPNを使用した通信に問題がないか確認してみます。今回はそれぞれの地域に確認用サーバのlinuxを作成してみました。East AsiaのUbuntuは以下のようになります。あと、標準でlinuxのファイアウォール設定がされているので注意してください。簡単に外す場合は、以下のコマンドです。

$sudo iptables –F

nv-asia-vm-srv

 

West USの確認用サーバのlinuxは以下のような感じです。East Asiaの確認用サーバと同じようにファイアウォール設定に注意してください。あと、VPN経由で通信するために、スタティックルートの設定をします。簡単に設定する場合は以下のコマンドです。

 

$sudo route add -net 10.20.0.0/16 gw 10.10.0.4

 

nv-us-vm-srv

 

 

West USのVPN GatewayからEast Asiaのサーバにアクセス

まずは、West USのlinuxのVPN GatewayからEast Asiaの確認用linuxにPingしてみます。

nv-asia-vpngw

  Pingの応答があるのですが念のためにEast Asiaの確認用linuxにPingのicmpパケットが届いているかtcpdumpで確認してみます。

問題なさそうですね。行きと帰りでパケットが通っているようです。

  nv-srv-asia-tcmdump

 

West USとEast Asia間のlinuxで通信確認

確認してみましたが通信できませんでした。以下はtcpdumpした内容です。

West USからEast Asiaに通信

West USのlinux

ua00

West USのVPN Gateway

ua01

East Asiaのlinux

ua03

 

East AsiaからWest USに通信

East Asiaのlinuxのtcpdump

au00

West USのVPN Gatewayのtcpdump

au01

West USのlinuxのtcpdump

au02

 

5.まとめ

West USのネットワークでは、設定したアドレスの範囲外アドレスがIPヘッダの送信元か送信先に含まれると、仮想ネットワーク内でドロップしています。ここからは推測ですが、これは仮想ネットワークで管理されていないIPアドレスが含まれているため、ホストの仮想スイッチでドロップしているのではないかと考えています。Hyper-Vのネットワーク仮想化と同じ動きだとも考えています。

East Asiaではローカルネットワークとして登録しているのでGatewayを通って、West USのVPN Gatewayまではパケットが流れていますね。AzureでNew-NetVirtualizationCustomerRoutのようなPSコマンドが欲しいです。

動きがわかれば、対策は立てられるので、次回は地域間で通信できる構成を紹介する予定です。

あと、Hyper-Vのネットワーク仮想化に関しては、後藤さんのnvgreの資料を参考にしました!ありがとうございます。