AWS環境のPaloaltoを本格導入した＆ハマッたこと

現職で、AWS環境にPaloaltoVMを構築し、オンプレミスのPaloaltoからのリプレイスを図ったのですがその時ハマったことを自分用のメモとして記載します。
本エントリに書いてあることが意外とドキュメントとして探しづらいので情報をまとめました。この情報が誰かの役にたてばこれ幸いです。

前提

このエントリは下記の方向けに記載しています。

1. Paloaltoの構築・運用経験がある。 ※オンプレミスでも可。
2. AWS環境でEC2インスタンスを作成したことがある。

そもそもなぜ移行を検討したか

主にBCP目的です。
データセンターではなく、社内環境にPaloaltoを用意してあり、各支社からは本社のPaloaltoを経由して各種通信をするスター型のネットワークトポロジになっていました。
要は 本社のPaloaltoが停止すると全社のネットワークが止まる という。。
例えば、本社が大規模災害になったとすると 支社含めて会社業務がほぼ止まる という全く笑えない事態となってました。 (実際に本社の法令停電で支社がネットワーク接続できなくなる、という事態もおきてました)

どういう形で移行したの？

AWS側にPaloaltoVMを構築し、社内環境からはAWS側に構築したPaloaltoとIPSec接続しました。
そして、社内からのInternet接続は全てAWS環境のPaloaltoを通過するような構成にしました。
図にすると↓みたいな感じ。

[オンプレ]社内PC→[オンプレ]IPSecルータ→[AWS]Paloalto→[AWS]Internet Gateway

AWS環境じゃなくて、データセンターに置けば良くない？

データセンターに置くことも考えましたが、データセンターに置くことによるメリットがコストメリットくらいしか無く、 「Paloalto物理マシンのメンテ」 など余計な運用コストが発生することを懸念し、クラウドに移行しました。
※予算がシビアな会社はデータセンターにPaloaltoを置いて、そことIPSEC接続するのも悪い選択肢ではないとは思います。現社の場合は「運用コスト＞費用」だったので。

そもそもPalo Alto VM必要？AWS側の機能だけで良くない？

と、最初考えたのですが、AWS側ですべて完結しようとすると、「セキュリティグループの管理が大変」だったり、「トラフィックログを見るのが大変」だなと考えたのでPalo Alto VMを導入することを決めました。

• セキュリティグループの管理
  • AWSだけで頑張ると1インスタンス事にセキュリティグループを"適切"にアタッチすることが必要になるので、インスタンスが増えていくと管理が大変...。その点、EC2インスタンスの通信をPalo Alto VMを経由するように(0.0.0.0/0の通信をすべて、Palo Alto VMのENIにルーティング)してしまえば、Palo Alto側で一元的にセキュリティポリシーを制限できる。
• トラフィックログの管理
  • AWS側でも「VPCフローログ」等を設定すればトラフィックログを追えるのですが、もっとライトに「〇〇のインスタンスが△△に通信できない」といったちょっとしたログを追うのに適していないと感じてます。その点、Palo Alto VMならば簡単にトラフィックログが見れるので楽。

ハマったこと

ここからが本題。ハマったこと一覧です。

InterfaceのIPアドレスはDHCPではなく、スタティックで構築すべし

当初はclassmethodさんの下記記事を参考にPaloaltoVMへのIPアドレスアサインを「DHCPクライアント」として登録して、AWS側のDHCPサーバ側からIPを取得させていました。

dev.classmethod.jp

ところが、しばらくすると通信が不通になりPaloaltoVM自体を再起動しないと、再度通信ができなくなる自体に。 (恐らく、DHCPリース期限が切れたタイミングでこういった事象になるのですが真の原因は不明です。 )

そこでIPアドレスをDHCPではなくスタティックで設定しました。そうすることで通信が切れることはなくなりました。
ちなみに、どういったIPアドレスを設定すればいいか(≒AWS側からアサインされたIPアドレスをどうやって確認すればいいか)はPaloalto管理コンソールから対象のインタフェースを選択し、「DHCPクライアントランタイム情報の表示」 を選択すれば確認できます。

---

Gatewayアドレス・NextHopアドレスはグローバルIPではなく、ローカルIPアドレスで指定すべし

GatewayアドレスやNextHopアドレスをElastic IP(AWSで用意したグローバルIPのこと)で設定しがちなのですが、これはNGです。
設定するIPアドレスは AWS側の「プライベートIPアドレス」 を設定します。
(グローバルIPのアタッチはAWS側で勝手に実施します。Paloalto側ではできません。)

オンプレミスで構築をしてきた人だとグローバルIPを設定しがちなんですよね。。(私もそうでした)

---

インスタンスタイプによるInterface数の制限に注意

PaloaltoVMを構築する際にEC2インスタンスのインスタンスタイプが一番最低限のものにする場合、現時点(2019年5月時点)では「m4.xlarge」を選択することになります。 mx4.largeではENI(インタフェース)を4つまでしか作成できず、かつ、PaloaltoVM側でマネージメントインタフェースとして1つENIを使用するので、 実質、インタフェースは３つまでしか作成できません というわけで、3つ以上のインタフェースを作成したい人はインスタンスタイプをm4.xlarge以上のものにする必要があります。

詳細は下記URLの「各インスタンスタイプのネットワークインターフェイスあたりの IP アドレス数」-「ネットワークインターフェイスの最大数」でご確認ください。

docs.aws.amazon.com

※単純に「グローバルIPを複数使いたい」という場合は上記ENIの最大数の制限を回避する方法があります。詳細は後述の「１つのインタフェースにグローバルIPを複数割り当てする方法」を参考にしてください。

---

１つのインタフェースにグローバルIPを複数割り当てする方法

ちょっとややこしいですが、、下記手順で構築すれば可能です。

1. EC2管理コンソールから「IPアドレスの管理」を選択。「新しいIPの割り当て」で新たなプライベートIPを割り当て。
   • 
2. EC2管理コンソールから新たに割り当てたプライベートIPにEIPを割り当て。
3. PaloaltoVMの管理コンソールにて「Policies」タブ-「NAT」にて新たに割り当てたEIPを適用したいNATルールを作成。

※ENIの割り当てもインスタンスタイプによって上限はあります。m4.xlargeでも上限15個なので、まあ使い切ることは無いかもですが。 こちらも詳細は(https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/using-eni.html の「インターフェイスあたりの IPv4 アドレス」を参考にしてください。)

---

swapインタフェース

PaloaltoVMを冗長化する場合の選択肢の一つとして、「AWS側のNLBにぶら下げる」という方法があります。
が、しかし。 PaloaltoVMのデフォルトでは「プライマリのインタフェースがマネジメントインタフェース」となります。
マネジメントインタフェースのままでは、ALBにぶら下げることができないので、下記方法でeth0とeth1を交換(swap)するようにPaloaltoVMを起動するようにすればNLBにぶら下げることができるようになります。
なので、私はインスタンス作成時に下記のように構築し、インスタンス作成後にswapして構築しました。

• eth0
  • Internet Gatewayと通信できるENI(PaloaltoでいうUntrust側インタフェース)
• eth1
  • マネジメントインタフェースのENI

ご参考までに： https://docs.paloaltonetworks.com/vm-series/7-1/vm-series-deployment/set-up-the-vm-series-firewall-in-aws/use-the-vm-series-firewall-cli-to-swap-the-management-interface

---

冗長化の組み方

Palo Alto VMの冗長化構成として私が調べた限りでは一般的には下記の２つのいずれかの方法を取るようです。

1. 同一AZ内に配置し、HA構成を組む。 ※オンプレミスでHA構成を構成するときと同じやり方。
2. NLBにPalo Alto VMをぶら下げる

ただし、現職では上記いずれの方式も採用しませんでした。
理由は下記。

• 「同一AZでHA」
  • そもそもPalo Alto VMが使用不可になるのは「AWS側の定期メンテナンスによる個別のインスタンス停止」と「AZ全体の障害」だという風に考えています。前者の"メンテナンス"はAWS側から事前に「そろそろインスタンスを停止/起動してね」と告知されるのでそれに従えば良い、"AZ全体の障害"の場合、同一AZで構成したら両方死ぬので意味が無い。ということで、全く旨味ゼロ。
• 「NLB」
  • 悪くない選択肢なのですが、諸事情により「ロードバランシングではなく常にプライマリ側で通信させたい」という要件があり、これも旨味がない。
  • 諸事情とは：VMを常時２台起動していると当然ですが、２台分のインスタンス費用が発生するのでこれを避けたかった。(節約したかった)

では、冗長化についてはどのようにしたかというと、「Lambdaによる監視・冗長化」で対応することにしました。(まだ実装はできてませんが。。)

具体的にはLambdaにて下記方法で冗長性を確保することにしました。

1. LambdaにてプライマリVMのダウンを検知。
2. LambdaにてセカンダリVMの起動。
3. LambdaにてRoute53上のDNSエントリ(例えば、Global Protectなど)をプライマリVMからセカンダリVMのものに書き換え。

上記のような構成にすることで、2号機側は普段はインスタンス停止している状態となるのでインスタンス費用が節約可能にもなってます。

ご参考までに： knowledgebase.paloaltonetworks.com

VM構築時に参考にしたサイト

■リファレンスアーキテクチャ。先ずはこれを熟読しました。 www.paloaltonetworks.jp

■実際の構築HowTo docs.paloaltonetworks.com

実際使ってみてどう？

多少の通信遅延を覚悟していましたが、結構快適です。 WANインタフェースが1GBpsの回線ですが60Mbpsとかでます。 (全社展開はまだできておらず、一部環境での展開しかできておりませんので引き続き要検証)

現社の場合、Paloalto移行に伴い、AD環境や認証環境も全てAWS側に移行したので、仮に本社が壊滅しても事業継続が可能になりましたとさ。

WindowsServer2019で公開鍵認証でscpする

たいした話じゃないですが、ちょっとビックリしたのでメモ。

Windows Server 2019でOpenSSHが使えるようになったことを知ったので、scpが使えるのか試してみました。 結果としては 使えた のですが、公開鍵認証しようとしたときに、下記のようなエラーが。

回避策は 対象の鍵ファイルが 「Users」の権限を剥奪すればOK。 Linuxとここらへんは考え方が同じですね。

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions for 'C:\hogehoge\hoge.pfx' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "'C:\hogehoge\hoge.pfx": bad permissions
hoge-user@xx.xx.10.187's password:

ご参考までに： Windows Server 2019でOpenSSHを有効化するには下記をご参照。

forest.watch.impress.co.jp

[SAML]Amazon ConnectにAzureADからSSOしてみた

Amazon Connectに対してシングルサインオンを設定したのでその備忘録です。

シングルサインオンすると何が嬉しいのか

• ユーザ側
  • 普段ログインしているID/PASSでログインできる。
• 管理者側
  • Amazon Connectへアクセス可能なグローバルIPなどを制限できる。
    • 外からアクセスさせずに、社内からのみアクセスしたいというニーズはあるかなと。

詳細

①AzureAD側作業 その１：SSO用のアプリケーション作成

1. Azure Portalにログインして、 「アプリケーションの追加」を選び、「ギャラリーから追加する」からAWSを選ぶ。
2. 適当な名前をつけて「追加」と選択する。
3. シングルサインオン - SAML を選択する。
4. 任意の(なんでもいい)識別子を設定する。
5. 証明書(フェデレーション メタデータXMLの方)をダウンロードする。
6. ユーザーの追加で、SSOアクセスさせたいユーザ名、もしくは、グループ名を選択しておく。

②AWS側作業その１： Amazon Connectインスタンスの用意

1. Amazon Connectを開き、「インスタンスを追加する」を選択し、「SAML2.0～」を選択する。
2. ユーザーは後で作るので、一旦スキップにしておく。
3. 以降はデフォルトのまま選択し、インスタンスを作成する。
4. 「今すぐ始める」でAmazon Connectインスタンスに一旦ログインし、ユーザ作成画面を開き、「Add New User」でSSO連携したいユーザを登録しておく。
5. 一旦、Amazon Connectインスタンスからはログアウト。Amazon Connectを再び開き、インスタンス一覧から作成したインスタンスを選択し、概要を確認。あとで使うので、「インスタンスARN」の値を控えておく

③AWS側作業 その２：SSO用設定

1. IAM画面から「ID プロバイダー」を選択する。
2. プロバイダーのタイプを「SAML」にして、AzureADからダウンロード済みのXMLをアップロードする。
3. IAM Roleを作りたいので、「ロール」を選択する。
4. SAML2.0フェデレーションを選び、SAMLプロバイダーには上記で作成したIDプロバイダ名を指定して、「プログラムによるアクセスとAWSマネジメントコンソール～」を選択する。
5. 何も設定せず、「次のステップ」へ。
6. ロール名にわかりやすい名前をつけて、ロールの作成をする。
7. 作成したロールに対してAmazon Connectを利用する権限を付与する。
8. 「JSON」タブを選択して、下記のように記載。　　

{
    "Version": "2012-10-17",
   "Statement": [
        {
            "Sid": "Statement1",
            "Effect": "Allow",
            "Action": "connect:GetFederationToken",
            "Resource": [
                "＜AWSを側作業その一で事前に確認したARN値＞/user/${aws:userid}"
            ]
        }
    ]
}

1. 下記のように表示されるので「Create policy」する。
2. 作成したIDプロバイダとロールのARNをあとで使うので控えておく。

④AzureAD側作業 その２：Azure側にAWS側に施したSSO用の設定を追加。

1. 再び、Azure Active Dirctoryを選択して、「シングルサインオン」 - 「ユーザ属性と要求」を選択して、下記のような値を入力する。 ※基本的にはRoleとRoleSessionNameだけ追加すればいいだけのはず。

名前	名前空間	ソース属性
nameidentifier	http://schemas.xmlsoap.org/ws/2005/05/identity/claims	user.userprincipalname
emailaddress	http://schemas.xmlsoap.org/ws/2005/05/identity/claims	user.mail
givenname	http://schemas.xmlsoap.org/ws/2005/05/identity/claims	user.givenname
name	http://schemas.xmlsoap.org/ws/2005/05/identity/claims	user.userprincipalname
surname	http://schemas.xmlsoap.org/ws/2005/05/identity/claims	user.surname
Role	https://aws.amazon.com/SAML/Attributes	[AWS側作業その２のロールのARN],[AWS側作業その２のID ProviderのARN]
RoleSessionName	https://aws.amazon.com/SAML/Attributes	user.userprincipalname

1. 続いて「基本的な SAML 構成」を選択して、リレー状態に下記URLを入力する。
2. 入力するURLは https://ap-northeast-1.console.aws.amazon.com/connect/federate/<インスタンスID> を入力する。

3. インスタンスIDはAWS側作業その１で確認したAmazon Connect インスタンスのARNから「instance/」以降の値を入力する。(例：arn:aws:connect:ap-northeast-1:276429087547:instance/hogepiyoの場合、hogepiyoがインスタンスID)

4. アクセス先を制限するため、「条件付きアクセス」を選択。要件に合ったアクセス条件を設定する。

参考にさせて頂いたURL

dev.classmethod.jp

Single Sign-On With Amazon Connect And Azure Active Directory - Perficient Blogs

blogs.perficient.com

Office365のライセンス割り当てがグループ単位でできるようになったらしい

https://blogs.technet.microsoft.com/enterprisemobility/2017/02/22/announcing-the-public-preview-of-azure-ad-group-based-license-management-for-office-365-and-more/

これは朗報。

今まで、Powershellで自動的に割り当て、割り当て解除なんてやってたけどそんなことが不要になるー！

Amazon LinuxでAzure Active DirecoryのMFAを使った多要素認証を実装

参考にしたサイト

• https://social.technet.microsoft.com/wiki/contents/articles/33678.secure-ssh-access-using-azure-multi-factor-authentication.aspx
• http://www.ironwifi.com/ssh-authentication-ironwifi-radius/
• http://nolabnoparty.com/en/setup-nps-for-radius-authentication-in-active-directory/

ご参考までに

下記サイトのようにお手軽にMFA認証を実装する方法もありますが、接続元ユーザを細かく指定できなかったりしますし、AzureADのログインページの認証方法が変わったときに対応できるのか不安なところがあります。

• https://channel9.msdn.com/Blogs/Open/Using-Azure-AD-for-Linux-logins
• http://www.cloudou.net/azure-active-directory/aad009/

前提

• オンプレミスのActive DirectoryにLinuxインスタンスが参加されていること。(クラウドベースのADでも大丈夫だと思います)
  詳細はこちらを確認ください

• 後述するNPSサーバにLinuxインスタンスが接続可能であること。

• 接続に使用するユーザはAzureADのMFA設定済みであること。

基本的には前回の記事の応用です。

おおまかな構成

登場人物は３つ。

1)Linuxインスタンス(RADIUSクライアント)
2)NPSサーバ(RADIUSサーバ)
3)Active Directoryサーバ

• LinuxインスタンスがNPSにRADIUS認証をしにいく。
• NPSの許可ポリシーに合致したID/PASS(AD認証)の場合は、AzureADに認証要求を投げる。
• 認証要求を受け取ったAzureADは事前に登録されたMFA設定にもとづき、モバイルデバイスなどにMFA認証要求を投げる。
• 全ての認証が通れば、SSHログイン可。

おおまかな流れ

1. NPSサーバの設定。(RADIUSサーバとして構築)
2. LinuxインスタンスがRADIUSクライアントとして動作するように設定。
3. AzureADのMFA導入前に、認証ができるかテスト。
4. NPSサーバにAzureADのMFA導入するためにNPS拡張エクステンションをインストール。
5. MFAが動作することをテスト

手順

今回の構成でMFAを構成した事例が他になさそうなので詳細に記載します。

NPSの設定

1. RADIUSクライアントの設定
   
   
2. RADIUSサーバーの設定(負荷分散タブはデフォルトのままなので割愛)
   
   
   
   
3. 接続要求ポリシーの設定
   
   
   
   
   
   
   
   
   
   
4. 下記状態になっていればOK。処理順序は1番目にする(認証を無視する/OKは表示されていてもされていなくてもOK)
   
5. もう一つ接続要求ポリシーを設定
   
   
   
   
   
   
   
6. 下記状態になっていればOK。処理順序は2番目にする。
   
7. ネットワークポリシーの設定
   
   
   
   
   
   
   
   
8. 下記のような状態になっていればOK。処理順序は1番目にする。
   

Linuxインスタンスの設定。

1. 下記パッケージをダウンロード。 yum -y install gcc freeradius pam pam-devel make
2. pam_radius_authモジュール(RADIUSクライアント化するためのモジュール)をwget
   wget ftp://ftp.freeradius.org/pub/freeradius/old/pam_radius-1.3.17.tar.gz
3. ダウンロードしたモジュールを展開して、make。
   tar xvzf pam_radius-1.3.17.tar.gz
cd pam_radius-1.3.17
make
4. makeが完了するとカレントディレクトリに「pam_radius_auth.so」が出来上がっているので、「 /lib64/security」配下にコピー。
   cp -p ./pam_radius_auth.so /lib64/security/
5. /etc/pam.d/sshdを開き、authで始まるところをすべてコメントアウトする。
6. 2行目(#%PAM-1.0と書いてあるところの次の行)に「auth sufficient pam_radius_auth.so」と追記する。
7. /etc/raddb/serverというテキストファイルを作成し、下記内容を記載する。
   <NPSサーバのIPアドレス> <NPSサーバで設定した共有シークレット> 60
   例：192.168.150.150 sharedkey 60
8. sshdの再起動
   /etc/init.d/sshd restart

接続テスト

ターミナルをもう一つ立ち上げて、Linuxインスタンスに接続し、下記内容を確認。

• NPSサーバで許可されたユーザだけがログインできている。
• NPSサーバのイベントログ(セキュリティ)に認証拒否のログが出ていないこと。

NPS拡張モジュールのインストール

前回の記事の「NPS拡張モジュールのインストール」と同じなので割愛。

接続テスト

Linuxインスタンスに接続し、MFA認証が走ればOK!

最後に

意外なことに、LinuxをRADIUSクライアントとして登録する手順があまり無いためそこに手間取りました。 今回はLinuxでしたがRADIUSが喋れる機器なら全てAzureのMFA認証が上記手順で実装できるかと思われます。

Amazon LinuxでオンプレミスADのユーザ情報を使ってログインする

AWS上のLinuxインスタンスでオンプレのAD認証をする必要に迫られたのでそのメモ。

参考にしたサイト

https://docs.microsoft.com/en-us/azure/active-directory-domain-services/active-directory-ds-admin-guide-join-rhel-linux-vm

http://jshimazu.hatenablog.com/entry/2014/02/05/165058

前提

LinuxインスタンスがVPN接続でオンプレのADと接続可能な状態になっていること

手順

1. Linuxインスタンスにログイン
2. 必要なパッケージをインストール。
   sudo yum -y install realmd sssd krb5-workstation krb5-libs
3. DNS参照でオンプレADが見つからないといけないので、resolv.confを修正。(普通はADサーバのIPアドレスを指定すれば良いと思います。)
   vi /etc/resolv.conf
nameserver <参照先DNSサーバ名> ※既存のnameserverの箇所はコメントアウトしておく
4. AD参照できるか確認
   sudo realm discover <ドメイン名>
5. kerberosの初期化
   kinit <ユーザー名>@<ドメイン名>
6. ドメイン参加
   sudo realm join --verbose <ドメイン名> -U '<ユーザー名>@<ドメイン名>' ubuntuの場合は上記に--install=/も追記する。
7. デフォルトだとSSH接続が鍵認証なので、パスワード認証に変更する。
   sudo vi /etc/ssh/sshd_config
PasswordAuthentication no の箇所を PasswordAuthentication yes に修正
   AuthorizedKeysFile の箇所をコメントアウト
   PubkeyAuthentication の箇所を PubkeyAuthentication no に修正
8. ADが死んでしまったとき用にec2userだけは証明書認証をできるようにする。
   sudo vi /etc/ssh/sshd_config 下記２行を追記。
   Match User ec2-user
PubkeyAuthentication yes
9. AmazonLinuxの場合、インスタンス再起動時にsshdが鍵認証に戻されてしまうのでそれを無効化。
   sudo vi /etc/cloud/cloud.cfg.d/00_defaults.cfg
ssh_pwauth: false の箇所を ssh_pwauth: true に修正。
10. sshdの再起動
    /etc/init.d/sshd restart
11. 以上

動作検証

対象のLinuxインスタンスにSSH接続。そのとき、ユーザ名はUPN('<ユーザー名>@<ドメイン名>')で、パスワードはADのものを使ってアクセス。 ログインできれば成功。

その他

管理者権限を与えたいユーザには/etc/sudoersを編集し、よしなにやってください。 グループに与える場合は「%<ドメイン名>\<グループ名> ALL=(ALL) ALL」とかすればOK

その他2(2017.6追記)

ログインする際に@<ドメイン名>でログインするのが面倒なときは /etc/sssd/sssd.confに下記修正を加えればOK。

1. [sssd]セクションに default_domain_suffix = <ドメインサフィックス(@以降のところ)>

2. use_fully_qualified_names をコメントアウト。

3. systemctl restart sssd でSSSDを再起動。 参考にしたURL：

ubuntu - SSSD Authentication to Windows Domain without @domain.com everywhere - Server Fault

リモートデスクトップ接続でMFA認証(多要素認証)を実装。しかもクラウドベース(Azure Active Directory)のMFAで。

2/6にクラウドベースのMFA認証ができるようになったので試してみる。 ＃いままではAzure Multi-Factor Authentication Serverなるものをオンプレに構築する必要があった。かつ、その場合、Azure ADのMFAとは別ユーザ(オンプレ側のみ有効なユーザ)を作る必要があったので不便でした。

はじめに

参考にさせて頂いたサイトです。(感謝)

• http://blog.engineer-memo.com/2012/12/31/windows-server-2012-%E3%81%AE-rd-%E3%82%B2%E3%83%BC%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A4%E3%81%AE%E5%B0%8E%E5%85%A5/
• http://www.rdsgurus.com/step-by-step-using-windows-server-2012-r2-rd-gateway-with-azure-multifactor-authentication/

前提

接続に使用するユーザはAzure ADでMFA設定が済んでいるものとします。

構成

下記サーバが必要になります。

• Active Directory(※Azure ADとAD Connectで同期済み)
• Remote Desktop Gateway
• Network Policy Server

おおまかな手順

1. Remote Desktop Gateway(便宜上、以降はRDPGWsvと記載します)の構築 & Let’s Encryptで証明書の作成(任意)
2. Network Policy Server(便宜上、以降はNPSsvと記載します)の構築
3. クラウドベースのAzure MFA認証を実装するまえに、オンプレだけで接続テスト
4. NPS拡張モジュールのインストール(クラウドベースのAzure MFA認証に必要)
5. 接続テスト

RDPGWsv(Remote Desktop Gateway)の用意

1. 機能と追加からリモートデスクトップゲートウェイとリモートデスクトップWebアクセスを選択。勝手にNPSとIISもインストールされるがそれも必要なのでインストール。(リモートデスクトップWebアクセスは要らないかも) 

   

2. Let’s Encryptで証明書を作成。
   参考：https://undersooon.hatenablog.com/entry/2017/02/12/042838 
3. インストールが完了したらリモートデスクトップゲートウェイマネージャを起動。サーバ名を右クリックして「プロパティ」を表示。事前に作成した証明書をインポート(証明書を用意していない場合は自己証明書でもOK) 

   

   
   https://cdn-ak.f.st-hatena.com/images/fotolife/a/atsuokun/20170214/20170214223924.png
4. [RD CAPストア]にNPSsvのIPアドレスorホスト名を指定(NPSsvのIPアドレスを振っていない場合は振っておいてください。)
5. [SSLブリッジ]は下記図の通り。 

   

   
   
6. プロパティから抜けて、[リソース承認ポリシー]の編集。許可設定なのでよしなにやってください。下記はサンプル。 
   
   
7. 次はネットワークポリシーサーバの設定。※RDPGWsv側の設定です。NPSsv設定では無いので間違えないように。
8. [RADIUSクライアント]は下記図のように設定。フレンドリ名/共有シークレットは任意。IPアドレスはNPSsvのものを指定。 

   

9. [リモートRADIUSサーバ]はデフォルトの設定から下記の赤枠の箇所を60秒に設定。(デフォルトだと短すぎてMFA応答が間に合わないため) 

   

10. [接続要求ポリシー]は元々設定されている「TS GATEWAY AUTHORIZED POLICY」を2つ複製し、元々の「TS GATEWAY AUTHORIZED POLICY」自体は無効化する。 

    

11. 複製したポリシーのうち、一つを下記図のように設定する。ポリシー名は任意。クライアントのフレンドリ名は[RADIUSクライアント]で設定したものと同じにしください。※処理順序は1番目にしてください。 

    

12. 複製したポリシーのうち、もう片方を下記図のように設定する。こちらもポリシー名は任意。※処理順序は2番目にしてください。 

    

13. 最後に「NPS(ローカル)」を右クリックして、「Active Directoryにサーバーを登録を選択」 

    

NPSsv(Network Policy Server)の用意

1. 役割と機能の追加からネットワークポリシーサーバを選択。 

   

2. [RADIUSクライアント]は下記図のように設定。IPアドレスはRDPsrv。こちらもフレンドリ名/共有シークレットは任意。 

   

3. [リモートRADIUSサーバ]の設定を新規に作成。設定は下記図のように設定。グループ名は任意。 

   

4. [接続要求ポリシー]で設定を新規に作成。設定は下記図のように設定。ポリシー名は任意。クライアントのフレンドリ名は[RADIUSクライアント]で設定したものと同じにしください。※処理順序は1番目にしてください。 

   

5. [接続要求ポリシー]で設定をもう一つ新規に作成。こちらもポリシー名は任意。※処理順序は2番目にしてください。 

   

6. [ネットワークポリシー]の設定も必要なので設定。こちらも全体的に任意なのですが私が設定した内容をサンプルで下記図に貼ります。(制約タブは認証方法以外はデフォルトなので割愛。設定タブは全てデフォルトのままだったのでそこも割愛。) 

   

   
   

   

   

   
   
   
   
7. 最後に「NPS(ローカル)」を右クリックして、「Active Directoryにサーバーを登録を選択」 

   

Remote Desktop Gatewayが機能するかテスト

以上で、MFAしない状態の環境が構築できたのでMFAを実装する前に動作テスト。 ※この状態で動作しないとMFAも動作しないので必ずテストしてください。

1. mstsc.exeを起動し、[任意の場所から接続する]の[設定]を選択。 

   

2. サーバー名にRDPGWsvのFQDNを入力、[ローカルアドレスにはRDゲートウェイサーバを使用しない]のチェックをはずす。
   

   

   
   
   
3. 以上の状態で任意の接続先に接続し、接続できることを確認。※もちろん接続先側でリモートデスクトップの設定が許可されていることが必要です。

NPS拡張モジュールのインストール

ここまできたらいよいよクラウドベースのAzure MFA認証の実装です。

1. 下記３つをNPSsvで、上から順番にインストールする。
   • Download Visual C++ Redistributable Packages for Visual Studio 2013 from Official Microsoft Download Center
   • Download Details | Microsoft Connect
   • Download NPS Extension for Azure MFA from Official Microsoft Download Center
2. 管理者権限でPowershellを起動。下記コマンドを入力。
   • cd “C:\Program Files\Microsoft\AzureMfa\Config”
   • .\AzureMfaNpsExtnConfigSetup.ps1
   • Directory IDを聞かれるのでAzure新ポータルを起動し、[Active Directory] - [Propertys] - [Directory ID]から値を取得し、入力。
   • 認証ダイアログがポップアップされるのでAzure ADの全体管理者のユーザID/パスワードを入力。

接続テスト

以上で構築完了なので、前述した手順と同じ通り、Remote Desktop Gateway経由でmstsc.exeから接続する。今度はAzure ADで設定されたMFA認証が走り、それを許可しないかぎり、リモートデスクトップ接続ができないことを確認する。

最後に

とても簡単にリモートデスクトップ接続にMFA認証を追加することができました。AzureAD最高！ そしてAzureサポートの方が親切に教えてくれたのでそこまで困らずに構築できました。

ちなみにNPSが２つあるのは、NPS拡張モジュールをインストールしたサーバ側が強制的にAzure ADに認証をかけにいくようになってしまうので、オンプレ側の認証とクラウド側の認証を分ける必要があるためです。

あと、IISの設定が素のままなので、セキュリティが気になる方はよしなにいじってください。 (IISで頑張るんじゃなく、外部ファイアウォールかなんかで許可されたIP以外は接続しない、とかが無難なんじゃないかと。)