Microsoft Authenticatorアプリが設定のバックアップ・リカバリをサポート、しかし・・・

こんにちは、富士榮です。

みなさん、多要素認証してますか？
アイデンティティは不正利用されている、という前提で運用しないといけない世の中になってきているので、IDとパスワードが盗難されても不正にログインされない様に多要素認証を有効にするのは大人のマナーです。もしくは、少なくともログイン・アラート（知らないログインがあったら通知してくれる機能）が使える認証システムを使う、くらいはいしないとダメな世の中です。
そういえば昨年のde:codeでもこんな話をしてました。

結局、ID盗難って本人が気が付きにくいところが一番の問題なんですよね。


と、言うことでMicrosoftもAuthenticatorアプリをiOS/Android/Windows Mobile向けに提供しており、私もAzure ADアカウント、Microsoftアカウントに加えてGoogleやFacebook、Amazonなどのアカウントの多要素認証をこのアプリでやっています。

が、機種変更などでアプリを再インストールすることになると実は非常に面倒です。全ての多要素認証設定を再度１からやり直さないといけないので、このアプリがないとログインできないような状態になってしまっているサービスがあると詰みます。

そこで登場したのが、ずっとリクエストが上がっていた多要素認証設定のバックアップとリカバリ機能です。

公式Blogでのアナウンス
　Microsoft Authenticator Account Backup and Recovery: Coming soon to an iOS device near you!
　https://cloudblogs.microsoft.com/enterprisemobility/2018/04/24/microsoft-authenticator-account-backup-and-recovery-coming-soon-to-an-ios-device-near-you/


機能を有効化するためには以下の条件を満たす必要があります。
・iOS版であること（残念ながらまだAndroid版では使えません）
・Authenticatorアプリのバージョンが5.7.0以降であること
・Microsoftアカウント（個人アカウント）があること


早速使ってみましょう。
と、その前に本ポストのタイトルに書いた「しかし・・・」の部分が気になりますよね？そう、実は組織アカウント（Azure AD/Office365）の多要素認証はリカバリできないんです。結局は再度QRコードの読み込みから開始なので、管理者にリセットしてもらう必要があります。
また、多要素認証設定済みのMicrosoftアカウントで設定をバックアップすると、リカバリ時に当該のMicrosoftアカウントでログインを求められますが、当然そのMicrosoftアカウントの多要素認証は今からリカバリしたい設定の中に入っているので、アプリで多要素認証は出来ません。他の方法（メールとかSMSでの回復）を設定していないとこれも詰みます・・・


こんな罠だらけの新Authenticatorですが、Googleなどの他の多要素認証はちゃんとリカバリしてくれる（はず）なので一応便利です。（Googleしか試してないのでAmazonとかFacebookが大丈夫かどうかは知りません）


とは言え、気を取り直して試してみます。
アプリを起動して、設定メニューを開くと「バックアップ」という項目が増えています。

おもむろに自動バックアップをONにするとMicrosoftアカウントが求められます。

この画面だけを見るとバックアップはOneDriveとかに保存されるのかな？と思うんですが、アプリを英語モードで起動すると実はこの画面の前にiCloudに保存する、というメッセージが出てきます。

これを見るとバックアップはiCloudにされ、リカバリする時にMicrosoftアカウントで認証することで保険をかけてる、ということなんだと思います。

Microsoftアカウントを追加すると回復アカウントとして表示されます。

後は、おもむろにアプリを消して再インストールしてみます。

まっさらの状態で起動してくるので、「回復の開始」からリカバリをしてみます。

回復に使うMicrosoftアカウントを選択し、ログインしましょう。
ここではアプリ内ブラウザが前に設定した時のMicrosoftアカウントを覚えてくれていたので選択するところから始まっていますが、機種変更などの場合はアカウントを追加するところからスタートですね。

と、ここで先ほど書いた通りのハマりポイントその１です。
このMicrosoftアカウントに多要素認証の設定をしていたので、ログイン時に多要素認証を要求されます。
運良く、実験した時は別のデバイスで多要素認証する様に構成していたので、難を逃れました。

しかし、別のデバイスで認証する構成にしていたが故に不思議なことが起きてしまいます。発生した現象は後述するとして先に進めましょう。

アカウントの回復完了、と表示されるのですが「セキュリティ上の理由から、一部のアカウントで追加の検証が必要です」と出て、Azure ADのアカウントに！マークがついています。

これが先ほど書いた微妙な点です。
Azure AD/Office365のアカウント（組織アカウント）のリカバリは出来ないんです。
回復するには再度QRコードをスキャンする必要があるので、別の方法で何とかログインするか管理者に多要素認証設定をリセットしてもらうしかありません・・・

今回は管理者でリセットしました。Azure ADのポータルからMFA設定を開いてユーザを検索、Manage user settingsを開きます。

再度ユーザが多要素認証設定を設定する様に要求します。

これで再設定をすると一応リカバリされます。
ちゃんとAzure ADアプリへの多要素認証ログインもできました。もちろんGoogleについてはGoogle側で何のリカバリ処理も必要なく、ちゃんと多要素認証ログインできます。

ちょっとおかしなことになってますよね？
気が付いた方いますか？




そうです、リカバリした端末側の多要素認証設定に、リカバリに使ったMicrosoftアカウントのエントリが勝手にできています。
私は別の端末でこのMicrosoftアカウントの多要素認証をしていますので、2つの端末に同じMicrosoftアカウントの多要素認証エントリが存在している状態になります。

試しに、このMicrosoftアカウントでサービスにログインしてみます。

すると、なんと2つの端末に通知が来ます・・・

はい、バグだと思います。
（と思いましたが、Microsoftアカウントの場合は複数の端末で多要素認証をさせることができるので、こういう仕様なんだと思います）

ちなみに、どちらで承認してもちゃんとログインできます。

うーむ・・・



と、若干微妙な感じではありますが、少なくともGoogleの多要素認証はちゃんとリカバリできたので、楽にはなりました。
皆さんも使ってみましょう。

[Azure AD]Duo Securityを使った3rdパーティ多要素認証を行う

こんにちは、富士榮です。

昨年10月に公表されてから時間が経ってしまいましたが、Azure Active Directory（Azure AD）でマイクロソフト純正の多要素認証プロバイダ（いわゆる買収したPhoneFactorですね）ではなく、サードパーティの多要素認証プロバイダ（今のところ、RSA、Duo、Trusonaの3社）を使って多要素認証が出来るようになっています。（現在、Preview）
※ちなみにAzure AD Premium P2のライセンスが必要な機能です。高いので私はトライアル版を使っています。

公式ブログ
　Azure AD + 3rd party MFA = Azure AD Custom Controls
　https://blogs.technet.microsoft.com/cbernier/2017/10/16/azure-ad-3rd-party-mfa-azure-ad-custom-controls/


ようやく試してみましたので、簡単に紹介して行きます。
ちなみに今回はDuoを試してみました。
（RSAはトライアル版がなかったのと、Trusonaは個別に設定をしてもらわないとダメらしく断念しました）

後、ちなみに自前でカスタムMFAプロバイダを作ってAzure ADと連携させるってこともプロトコル上は可能になっていますが、現状はマイクロソフトに承認を受けたプロバイダしか登録が出来ないということなので、こちらはもし調整がついたらやってみたいと思います。

では早速。

◆Duoのアカウントを作る

まずはココからです。
Duoのサイトへアクセスし、右上にあるStart Trialをクリックすると無償トライアルへのサインアップが出来ます。

登録を進めると、アカウントのアクティベーションを行う場面が出てきます。

ここではDuo MobileというモバイルアプリをインストールしてQRコードを読み込む必要があります。

早速インストールしてADD AccountでQRコードを読み込みます。
うまく追加できるとこんな感じでアカウントが表示されます。

横道にそれますがDuo Mobileは端末の状態を確認して問題があると警告を出してくれます。問題があると画面の下部に表示されるのでFix Nowをタップすると詳細が見れます。

今回はiOSが最新でない、という警告でした。他にもTouch IDが有効になっているか、とか脱獄していないか、などについて確認が行われます。

なんだかんだでセットアップが完了するとDuoの管理コンソールへたどり着きます。

ひとまずこれでDuoのアカウント作成は完了です。

◆Azure ADと接続するためのアプリケーション設定を行う

ややこしいんですが、Azure ADから見てDuoはIdentity Providerです。ということは、Duoから見るとAzure ADはRP、つまりアプリケーション（OAuthクライアント）となります。
（ちなみにAzure ADとDuoの間はOpenID Connectで繋がります）

ということで、Duo上にAzure ADをアプリケーションとして登録する必要があるのですが、DuoではプリセットでAzure ADと接続するための設定が入っていますので、こちらのテンプレートを使っていけば非常に簡単にセットアップが出来ます。

アプリケーションの検索画面に「Microsoft」とキーワードを入れるとAD FSやOWAなどと共にAzure ADが出てきますので、こちらを選択します。

アプリケーション設定画面に行くとシンプルに「Authorize」というボタンが現れますので、こちらをクリックしていきます。

するとAzure ADのログイン画面が出てきますので、管理者でログインします。するとAzure ADのディレクトリへの読み取り権限などを要求されるので認可を行います。
ちなみに、DuoでMFAしてログインする通常の流れにおいてはDuoがIdP、Azure ADがRPという構成ですが、ここではディレクトリの情報を読み出すためにDuoがRP、Azure ADがIdPという構成になります。ややこしいですね。

上手くいくと、Duoの管理画面にAzure ADに設定するための構成情報（json）が表示されます。

ここで表示されるjsonは後でAzure AD側に設定するのでコピーしておきます。

これでDuo側の設定は完了です。
非常にシンプルです。

◆Azure AD側にDuoをカスタムMFAプロバイダとして登録する

DuoのようなカスタムMFAプロバイダは条件付きアクセスの一つの条件として扱われます。そのため、設定は条件付きアクセスの中のCustom controlsというメニューから行います。（Azure AD Premium P2のライセンスが割り当たっていないとこのメニューは出てきません）

ここでNew custom controlをクリックすると、いきなり巨大なテキストボックスが現れるので、先ほどのjsonを貼り付けてCreateをクリックします。

これで完了です。
上手くいけば、こんな感じで一覧にDuoが出てきます。

後は、普通の条件付きアクセスと同じです。
ポリシーを書く時のControlとしてDuoMFAを要求する、という形で設定すると条件に当てはまったアクセスだとDuoのMFAが要求されます。

◆テストしてみる

ポリシーの作成が終わったら念のためポリシーの適用が正しく行われるか確認してみます。
　※事前に確認するには先日紹介したWhat Ifを使うと便利です。
　http://idmlab.eidentity.jp/2018/01/azure-adwhat-if.html

該当のユーザでの初回アクセスだとMFA設定を促されますので、画面に従いMFA設定を進めます。

利用するMFAの方法を選択します。

モバイルを選択したので、携帯の番号は入れさせられます。この辺りはAzure AD純正のMFAと一緒ですね。

何故かモバイルの種類を選択させられます。アプリのインストールを促すためでしょう。

既にインストール済みなのでI have Duo mobile installedを選んでスキップします。

ここでようやくQRコードが出てくるので先ほど管理者がやったのと同じくアプリを使ってアクティベーションを行います。

上手くアクティベーションが終わると、認証の方法を指定します。
毎回方法を聞いてくるか、PUSH通知 or ワンタイムコードの表示をあらかじめ指定しておくことが出来ます。
ここでは毎回方法を聞いてくるように指定しました。

ここで設定が終わったので、ようやく実際のMFAです。（次からはこの画面がスタート地点になります）
毎回聞いてくるように指定をしたので、方法を選択する画面が表示されます。

PUSHを選択するとモバイルアプリに通知がされてきます。

この辺りは純正と同じですね。
ここでApproveをするとログインが完了します。

◆補足（id_token_hintの利用について）

ちなみに、アプリ⇒Azure AD⇒Duoという流れでFederationが連鎖している状態でのMFAをやろうと思うと、セッション管理をちゃんと実施しないといけません。通常はAzure ADのIdPがDuo、という構成だとDuoで認証されたらそのままAzure ADでも認証されたことにしてしまうためです。
Azure ADが外部MFAプロバイダ連携をする際、セッションをコントロールするためにid_token_hintというものを使っています。

OpenID Connect coreのスペックではid_token_hintについて以下のように記載されています。

Authorization Server が以前発行した ID Token. Client が認証した End-User の現在もしくは過去のセッションに関するヒントとして利用される. もしこの ID Token に紐づく End-User が認証済, もしくはこのリクエスト中で認証された場合, Authorization Server はポジティブレスポンスを返す. さもなければ, Authorization Server は login_required のようなエラーを返す (SHOULD).

つまり、最初にAzure ADでID/PWDで認証された結果の情報をid_token_hintに入れた状態でDuoへ渡し、Duoで追加の認証が上手く行われたらポジティブレスポンス（何を返すか、についてはjsonの中に書いてある通りで、Duoの場合はMfaDoneというメッセージを返します）をAzure ADへ返します。

Azure ADからDuoへPOSTされるid_token_hint。認証されたユーザの情報が入っています。

これに対してDuoからの返事となるid_token。成功したのでMfaDoneが返っています。

細かくはスペックを読みましょう。
http://openid-foundation-japan.github.io/openid-connect-core-1_0.ja.html

[Azure AD]条件付きアクセスの信頼済みネットワークが拡張されてました

こんにちは、富士榮です。

永らく条件付きアクセスの信頼済みIPの上限数（50レンジ）に悩まされてきた管理者の皆さんに朗報です。（といってもしばらく前に拡張されていたので、既に気が付いた人は使っていると思いますが）

これまでは、旧MFAポータルで信頼済みIPを設定していたのですが、登録可能な数は50レンジまででした。

この上限で困るケースが社内からのネットワークの出口が事業所毎にあったり、クラウドベースのプロキシサービスを使っているようなケースです。

以前、マイクロソフト・コーポレーションの開発チームとのディスカッションの場でもこの制限に関しては私を含め複数の人から改善リクエストが出ており、名前付きネットワーク・オブジェクトとの統合のロードマップが示されていましたが、条件付きアクセスの設定が正式に新ポータルへ移行されたタイミングで信頼済みIPについても移行されました。

尚、現段階では以下の注意点があります。
・過去に作成したアプリケーションの条件付きアクセスの構成は新ポータルからは見えないので、構成し直す必要があります
・再構成しない場合、過去に作成したアプリケーションについては旧ポータルの信頼済みIPが使われます
・新しくアプリケーションを作成する場合、旧ポータルからアプリケーションを作成する場合でも、条件付きアクセスは旧ポータルからは構成できなくなっています。条件付きアクセスの構成は新ポータルから実施してください


早速ですが、構成を見てみます。

新ポータルの条件付きアクセスの構成にNamed Locationsという項目が存在するので、New locationをクリックしてネットワークの場所を定義していきます。

IPレンジをどんどん追加できます。（画面からの直接入力の場合は10個単位で保存をしないとダメですが、保存した後に再度ネットワーク構成を開いて追加していけばどんどん追加できます）また、テキストファイルにネットワークレンジの一覧を書いてUploadすることで一気に追加することが出来ます。

次はこれを使って条件付きアクセスのルールを構成してみます。

まずは対象のユーザ・グループを選択します。ここでは全員を対象としています。

次に対象とするアプリケーションを選択します。ここでは「pharaoh1234」という名前のアプリケーションを対象としています。

次に、条件を設定します。今回信頼済みIPに設定されていないネットワークからのアクセスの場合は多要素認証を要求しようと思うので、ここのLocationsにInclude：All locations、ExcludeにAll trusted IPsを指定します。

条件に一致した場合のアクションとして多要素認証を要求したいので、以下の通りRequire multi-factor authenticationにチェックを入れます。

後は、ルールをEnableにして保存すると完了です。


この状態で信頼済みIP以外のネットワークからアプリケーションにアクセスすると以下のように多要素認証が要求されます。

Azure MFA Serverを使ってLinuxへのログオンに多要素認証を使う

こんにちは、富士榮です。

PhoneFactor改めAzure MFA ServerってAD FSの2段階認証をオンプレで構成する場合くらいでしか利用されているのを見たことがないのですが、実はものすごく器用なプロダクトなので、色々と活用して行こう、というのが今回の主旨です。

そもそもAzure MFA Serverはがどう言うものかを一言で説明すると、「多要素認証付きのマルチプロトコル対応の認証サーバ」です。例えば、LDAPやRadius、Windows認証などに対応しています。

今回はタイトルに書いた通り、その中のRadiusサーバとしての機能を使って、LinuxへのSSHでのログインの時の認証の2要素目としてMicrosoft AuthenticatorアプリやSMS通知などを使えるようにしてみます。

以下の様な環境です。

ちなみに、Azure MFA ServerをLDAPサーバとして構成してLinux側はpam_ldapを使う、という選択肢もなくはないのですが、レポジトリにActive Directoryを使ったのでpam_ldapが認証対象のユーザのDNを取得する前に行うbindの段階で2要素認証が走ってしまうので、実際は使えないなぁ、ということで辞めました。匿名bindに対応したLDAPサーバを使えば行けるかもしれません。（Active Directoryを匿名bind化することも可能ではありますが、お奨めできないので）


早速やってみましょう。

◆Linux側の準備物

今回はAzure IaaS上のCentOS 7.3イメージを使いました。

追加で必要なパッケージは以下の通りです。
・LDAPクライアント
　・openldap-clients
　・nss-pam-ldapd
・Radiusクライアント
　・pam_radius-1.4.0.tar.gz
・Radiusクライアントをビルドするための環境
　・gcc
　・pam-devel

◆LDAPクライアントの設定

まず、LDAPクライアントをインストールします。
　sudo yum install openldap-clients nss-pam-ldapd

次に/etc/passwdの代わりにLDAPサーバを使うようにOSを構成します。
　sudo authconfig-tui
を叩くと設定画面が開くので[User Information]の[Use LDAP]にチェックを入れます。認証側は後からRadiusを構成するのでここでは何も触りません。

Nextを叩くと、LDAPサーバへの接続設定が出てきますので、ServerのURIとBaseDNを設定します。

ここでOKをクリックすると設定は完了しますが、先に書いたようにActive DirectoryをLDAPサーバとして利用する場合は匿名bindが使えないので、バインドユーザの設定を直接設定ファイルを編集して登録します。

対象のファイルは/etc/nslcd.confで、binddnとbindpwというパラメータがデフォルトではコメントアウトされているので外して、必要な値を設定します。

次に同じく/etc/nslcd.confへ属性マッピング設定を追加します。これは例えばuidNumberやgidNumber、homeDirectoryなどLinuxへログインするために必要な属性が当然Active Directoryにはないので、それぞれ必要な値をActive Directory上のどの属性からとってくるか、という設定です。また、取得してくるobjectClassのフィルタリングも指定をしておかないとActive Directory上のユーザを適切にとって来れないので、filterの設定もしておきます。

最低限必要なのは以下の設定です。
filter passwd (&(objectClass=user)(!(objectClass=computer)))
map    passwd uid              sAMAccountName
map    passwd homeDirectory    "/home/$sAMAccountName"
map    passwd uidNumber employeeId
map    passwd gidNumber "1000"
map    passwd loginShell    "/bin/bash"
※uidNumberはActive Directory上のemployeeId属性に対応する値をあらかじめ入れます。また、今回gidNumberは固定にしていますがこれもActive Directory上の別の属性とマッピングすることで制御することが可能です。

◆ホームディレクトリの自動作成設定（pamの設定）

これでログインするユーザの情報をActive Directoryからとってくることは出来るようになりますが、Linuxではログインする際にホームディレクトリが存在しないと怒られますので、ログイン時に自動的にホームディレクトリが作成されるようにpamの設定を行います。

2つのファイルを編集する必要がありますので順番に。

まずは/etc/pam.d/password-authに以下の2行を追記します。
session     optional      pam_ldap.so
session     optional      pam_mkhomedir.so skel=/etc/skel umask=022

同じく、/etc/pam.d/system-auth-acにも以下の2行を追記します。（同じ内容です）
session     optional      pam_ldap.so
session     optional      pam_mkhomedir.so skel=/etc/skel umask=022

こんな感じになります。

◆Radiusクライアントの導入

いよいよ認証側の設定です。
デフォルトでRadiusクライアントが入っていないので、freeradiusと一緒に配布されているpam_radiusを使います。

まずはダウンロードします。現在1.4.0が最新版の様です。
wget ftp://ftp.freeradius.org/pub/radius/pam_radius-1.4.0.tar.gz

解凍します。この辺りまでは一般ユーザで十分です。
tar -xzvf pam_radius-1.4.0.tar.gz

ここで、configureしてmakeしたいところなんですが、必要な開発パッケージが入っていない場合はgccとpam-develをインストールしておきます。
sudo yum install gcc
sudo yum install pam-devel


そして、ビルドします。
configure
make

すると、pam_radius_auth.soが出来上がるので、必要なディレクトリへコピーします。（64bit環境であれば/usr/lib64/security/）

sudo cp pam_radius_auth.so /usr/lib64/security/

◆Radiusクライアントの設定

これで導入は完了なので、次は設定です。
必要なのは、
・認証にRadiusを使うための設定
・使用するRadiusサーバの設定
の2点です。

まずはRadiusを使って認証をするための設定です。
/etc/pam.d/password-authに以下の行を追記します。
auth sufficient pam_radius_auth.so use_first_pass

こんな感じで、authのブロックに挿入してあげてください。

次にRadiusサーバへの接続設定です。
/etc/raddb/serverというファイルを作り、その中にサーバのアドレスと共有シークレットを書き込むのですが、FreeRadiusを入れていない環境だと/etc/raddbディレクトリやファイルが存在しないので、ディレクトリとファイルは新規に作る必要があります。

こんな感じです。
sudo mkdir /etc/raddb
sudo vi /etc/raddb/server

serverファイルの中は非常にシンプルで、「サーバアドレス 共有シークレット タイムアウト（秒）」を記載するだけです。尚、この共有シークレットはRadiusサーバ（今回はAzure MFA Server）に設定する文字列と同じものを指定するので覚えておいてください。

ファイルは作成後、パーミッションを600に指定しておいてください。
sudo chmod 600 /etc/raddb/server

これでクライアント側は終わりです。

◆Azure MFA Serverの設定

いよいよAzure MFA ServerをRadiusサーバとして動かします。
詳細なインストール手順やAzure MFA ServerがActive Directoryをレポジトリとして利用するための構成手順、ポータルの設定手順などは今回は省き、単純に構成済みのAzure MFA ServerにRadiusクライアントの設定を行う方法を紹介します。

Azure MFA Serverの管理コンソールを開き、RADIUS Authenticationを開きClientsタブで[Add]をクリックします。

するとRADIUSクライアントを登録する画面が出てくるので、以下を設定します。
IP Address : クライアントのIPアドレス（LinuxのIPアドレス）
Application name : 任意の名前
Shared Secret : 先にLinuxに設定した共有シークレットの値
Confirm shared secret : 確認用
Require Mutlti-Factor Authentication user match : ON
Enable fallback OATH token : ON（今回は使わないのでOFFでもよい）

これでAzure MFA Serverの設定もおしまいです。

◆SSH接続許可設定

これで認証自体は通るようになるはずですが、SSHサーバの認可設定が必要です。クローズな環境ではあまり気にしなくても良いとは思いますが、今回Azure VMでCentOSを構成しているので、認証に加えて接続出来るユーザをある程度制限しておこうと思います。

以下のファイルへ接続しても良いユーザ名を明記しておきます。
/etc/ssh/sshd_config

ここにAllowUsersパラメータを指定します。
構文は「AllowUsers ユーザ名をスペース区切りで列挙」なので、以下のような感じになります。ちなみに間違えると誰もつなげなくなるので別のコンソールを一枚あげておいた上で設定する様にしましょう。

※後で使うユーザはtestuser05なのでこの行にtestuser05を追記することでログイン可能になります。

編集が完了したらsshdに設定ファイルをリロードします。
sudo systemctl reload sshd

設定に失敗していると本当に誰もSSH接続できなくなりますので、端末のクローズは全部動作確認が出来た上でしてください。

◆ユーザの準備

いよいよ動作確認と行きたいと所ですが、その前にユーザの準備です。

先ほどLDAPクライアントの設定でActive Directory上のユーザの属性のマッピングを行ったと思うので、必要な属性（今回はuidNumber）をActive Directory上のユーザのemployeeIdに登録しておく必要があります。

employeeIdはデフォルトではユーザのプロパティからは見えないので、拡張表示設定をしたうえで、属性エディタを開き、値を直接セットします。

そして、最後に多要素認証設定です。
今回はアプリを使って認証する様に設定します。

Azure MFA Serverのユーザポータルへアクセスし、Active Directoryのユーザ名/パスワードでログインします。

初回アクセスだと、認証方法を選択する画面になるので、「モバイルアプリ」を選択し、「アクティブ化コードの生成」をクリックします。

するとQRコードが表示されるので、Authenticatorアプリケーションで読み込んでアカウントが登録されるのを確認して、「今すぐ認証」をクリックします。

上手くいけば秘密の質問への回答の登録などの画面に遷移しますが、ここは直接は関係ないので割愛します。適当に登録しておきます。

◆動作確認

ようやく動作確認です。

今回はTeraTerm Proを使ってSSH接続をします。

アドレスを入れて接続をするとユーザ名とパスワードを入れるダイアログが出るので、先のActive Directory上のユーザIDとパスワードでログオンを試みます。

すると、Authenticatorアプリに承認要求が届くので確認を行います。

ここまでの設定が上手くいっていればちゃんとログインできるはずです。

この様に、Azure MFA ServerはRadiusなど一般的な認証サーバとして振舞うことが出来、かつ間に多要素認証を挟み込むことが出来るので、応用範囲はかなり広いと思います。例えばVPN装置などこれまでクライアント証明書や個別に管理されているID/パスワードで認証していたものが運用上の問題になったり、セキュリティ上の弱点になったりするケースもあったと思いますが、このような工夫を組み合わせることにより少しでも楽にセキュリティレベルを向上することが出来る可能性がありますので、検討してみてください。