LINEログインの2要素認証の強制とamrクレーム

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

ものすごく久しぶりに書いている気がしますが、本当は4月ごろに書きたかったネタです。

簡単にいうと、

「LINEログイン（Webログイン）で２要素認証を要求するかどうかLINEアプリ側で設定できるようになりました。」

という話です。

アナウンス（4月26日付け）

https://developers.line.biz/ja/news/2022/04/26/2fa-switch-function/

そして、今回は

「LINEログイン（Webログイン）で２要素認証を要求するかどうかを管理者がコンソール側で設定できるようになりました。」

というアナウンスがありました。

アナウンス（6月28日付け）

https://developers.line.biz/ja/news/2023/06/28/require-2fa-on-channels/

まぁ、ここまではいいんですが実際２要素認証をした場合としなかった場合でid_token（特にamr=Authentication Method Reference Values。要は認証手段）がどう変わるのか？がアプリケーション開発者側の関心事項だと思うので確認しました。

結果、「２要素認証しても何も値が変わらない」ので非常に残念なんですが一応記録として残しておきます。

設定方法（コンソールで強制する設定）

LINE開発者コンソールからLINEログインを開くと２要素認証を要求する、というトグルスイッチがあります。現在初期値はOFFですが7月下旬ごろから初期値がONになるそうです。

この設定を入れると、Webログインをする際に２要素認証（実際はスマホのLINEアプリ側で画面に表示される4桁の数字を打ち込む）が求められます。

ちなみに、LINEアプリ側でも設定ができるので、先のコンソール側の設定とアプリ側の設定によって挙動が変わります。

ドキュメントにはこのように関係性が整理されています。まぁ、違和感はありません。

で、amrはどうなるのか？

本題ですが、そもそもLINEログインで想定されている認証手段は

• パスワード
• QRコード
• シングルサインオン
• 自動ログイン（スマホのみ）

の4種類です。

それぞれについてamrの値が以下の通り設定されています。

• パスワード：pwd
• QRコード：lineqr
• シングルサインオン：linesso
• 自動ログイン（スマホのみ）：lineautologin

今回は自動ログイン以外のWebシナリオで２要素認証を強制する機能なのでlineqrとかlinessoがIANAに登録されているのか？（いやされていない）という話は置いておいて、RFC8176的には「mfa」とか素敵な値が返ってくることを期待するんですが、結果何も変わらずpwd/lineqr/linesso（まぁSSOの場合は２要素認証は求められないって仕様なのでいいとして）がそのまま返ってきてしまいました、というオチです。

ということでLINEログイン（Webログイン）を組み込むアプリケーション開発者の皆さんはLINEログイン側で２要素認証が行われているかどうかを判別する手段は今のところ提供されていないので、センシティブな処理を行う場合は独自でセキュリティ強化の対策を行う必要がまだまだありそうです。

ちょっとLINEさんにはフィードバックしておいた方が良さそうかな、と思います。

TechSummitのおさらい③：Azure AD + Auth0 で条件付きアクセスを構成する

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

そろそろディープになってきました。公式イベントで話すにはかなり気が引けるネタ度Maxです。

今回はAuth0（おーすぜろ）とAzure ADを組み合わせることで複雑なことをやろう！という話です。

もちろんAzure ADにはPremium P1/P2という複雑なことをやりたい人向けのプレミアなライセンスがありますので、お金に余裕のある方、一気通貫でサポートを頼みたい方は迷わずそちらを選んでください。

Auth0とは？

Auth0もMicrosoftやOkta、PingIdentity、OneLoginなどと同様にIDaaS（Identity as a Service）を提供しているサービスプロバイダです。jwt.io辺りで有名ですね。
ちなみにFounderは元マイクロソフトのEugenio Paceです。「A Guide to Claims-Based Identity and Access Control」をVittorio Bertocciと一緒に書いた人ですね。まだ彼がMSにいる時代にやり取りをしてサイン本をもらったりしたもんです（遠い目）。最近は共著のVittorioもAuth0へ移ったのが個人的なビッグニュースでした。

少し特徴的なのは「開発者向け」である、という売り出し方をしているところですね。開発者向けたる所以は、ひたすらかゆいところに手が届くから、というのが最大の理由だと思います。

このAuth0、実は別のサービスとしてWebtaskというFaaS（Function as a Service）を提供しており、ID関連の機能の各所にこのWebtaskをどんどん差し込んでいくことが出来るんです。このことにより、例えばid_tokenの中身を見て処理を実行したり、ID登録直後に別の処理を走らせたり、など開発者がやりたい放題出来てしまいます。

Azure AD + Auth0？

さて、Azure ADとAuth0を組み合わせると何が出来るのか？という話に移りたいと思います。
Auth0はAuth0自体にIDを保持して自身がIdPとして振舞う以外に、外部のIdP（Connectionと呼んでいます）とID連携する機能を持っています。また、当然のごとく外部のSPとID連携することもできます。
このことを使い、IDの保持とベーシックな認証機能はAzure ADで、複雑な処理（今回は条件付きアクセスと多要素認証）はAuth0で担当、というようなことを実現することが出来ます。
使えるプロトコルも多様なので、アプリ（今回はG Suite）とAuth0の間はSAML、Auth0とAzure ADの間はOpenID Connect、という構成を組んでみました。

Azure ADのアプリ（RP）としてAuth0を登録

早速構成していくわけですが、まずはAuth0の外部IdPとしてAzure ADを構成するためには、Azure ADのRelying Party（RP）としてAuth0を登録してあげる必要があります。具体的には、ReplyUrl（応答URL）にAuth0のエンドポイント（Callback）を登録し、Auth0側に設定するためのClient IDとClient SecretをAzure ADから払い出します。

Azure ADのアプリ登録メニューより登録を行います。
　Azure ADに登録するAuth0のCallback URLは以下の通りです。
　　https://{テナント名}.auth0.com/login/callback

Auth0の外部IdPとしてAuth0を登録

次は、逆側の設定なので、Auth0にAzure ADの情報を登録していきます。
ちなみにAuth0はビルトインのConnectorとしてAzure ADが用意されているので、こちらを使ってもいいですし、OAuthを使ってカスタム接続するためのExtensionもあるのでこちらを使って接続しても問題はありません。

こちらがビルトインのAzure ADとの接続Connector

こちらがOAuthを使うExtension

私は後者のExtensionを使っています。（というかビルトインでAzure ADが存在しているのを知らなかった・・・）
Azure ADの認可エンドポイント、トークンエンドポイントと先ほどアプリ登録した際に取得したClient IDとClient Secretを登録します。

ちなみに、例のWebtaskを使ってGraph APIでAzure AD上のユーザ情報を取得することが出来ます。SAML Assertionに属性を入れてアプリに渡す必要があるので、必要な属性を取得する様にスクリプトを作ります。

function(accessToken, ctx, cb) {

  request.get('https://graph.microsoft.com/v1.0/me', {
      headers: {
        'Authorization': 'Bearer ' + accessToken,
      },
      json: true
    },

    function(e, r, u) {
      if (e) return cb(e);
      if (r.statusCode !== 200) return cb(new Error('StatusCode: ' + r.statusCode));
      var profile = {
        user_id: u.userPrincipalName,
        name: u.displayName,
        email: u.mail
      };
      cb(null, profile);
    });
}

直観的にわかりやすいスクリプトだと思うので、あまり解説する必要もないとは思いますが、トークンエンドポイントから取得したアクセストークンがコンテキストとコールバック先のオブジェクトと一緒に渡ってくるので、Graph APIにアクセスして必要な情報を取得、Profileとして設定して返却してあげる、という流れです。

G SuiteとAuth0をID連携

ここはこれまで何度となく解説してきたG Suiteのシングルサインオン設定の世界なので、G Suite側は目をつぶっていても構成できてしまう世界だと思いますので、Auth0側の設定を中心に。

ちなみにAuth0にはApplicationギャラリー的なプリセット・アプリのリストは存在しません。めちゃくちゃシンプルにNative App、SPA、Regular Web App、Machine to Machine Appの4種類しかありません。

G Suiteなど通常のアプリを使う場合はRegular Web Appを選びましょう。

また、Regular Web Appを選んだとしてもデフォルトではアプリと言っても単純なOAuthのクライアント登録しか出来ないので、AddOnという形でSAML等のプロトコルを設定してあげる必要があります。
SAMLの設定もかなりプログラマブルなので、Assertion内の各種パラメータをガリガリと書いていきます。本当に痒い所に手が届きます。ほぼ出来ないことは何もないので、Assertionの書き方の方言でうまくアプリと繋がらない、というトラブルとは無縁だと思います。その代わりSAML Assertionの中身の仕様について熟知している必要はありますが。

この構成のページからIdP MetadataやAssertion署名用の証明書のダウンロードなども可能なので、エンドポイントや証明書をG Suite側に設定してあげれば完了です。

これで一通り単純なシングルサインオンについて出来るようになっています。

条件付きアクセスを構成する

ここまでだとAuth0がG SuiteとAzure ADの間に挟まっている必要性が全くないので、最初に書いた通り、条件付きアクセスを構成してみます。
本来Azure ADではPremium P1のライセンスが必要な機能です。

Auth0での条件付きアクセスを構成するには、Rulesメニューよりルールを構成します。
このルールもJavascriptでガリガリと書いていくことが出来るので、ものすごく柔軟です。アクセス元の状態はContextから取得できるので、ソースIPやUser Agentなど様々な情報を見て多要素認証の適用の有無など各種条件を設定することが可能です。

function (user, context, callback) {
  const ipaddr = require('ipaddr.js');
  // 社内ネットワーク
  const corp_network = "x.x.x.x/16";
  // 対象のアプリケーションのclient_id
  const CLIENTS_WITH_MFA = ['G SuiteのClient Id'];

  // 接続元のソースIP
  const current_ip = ipaddr.parse(context.request.ip);
  if ((!current_ip.match(ipaddr.parseCIDR(corp_network)) && (CLIENTS_WITH_MFA.indexOf(context.clientID) !== -1))) {
      context.multifactor = {
        provider: 'google-authenticator',
        allowRememberBrowser: false
      };
  }

  callback(null, user, context);
}

ここまで構成すると社内アドレス以外からG Suiteを使おうとすると多要素認証（今回はGoogle Authenticator）を要求される様になります。

こんな感じでAzure AD+Auth0で見た目はぼぼAzure AD Premiumの条件付きアクセス、ということが実現できてしまいました(笑)。

まだまだネタは続きます。では次回！

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の多要素認証はちゃんとリカバリできたので、楽にはなりました。
皆さんも使ってみましょう。

[告知]統合認証シンポジウム@佐賀大学で大学におけるSNSの活用について話します

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

昨年に引き続き今年も佐賀大学で開催される統合認証シンポジウムに登壇させていただくことになりました。

第11回統合認証シンポジウム
https://www.cc.saga-u.ac.jp/ias/#gsc.tab=0

日時：2018年3月1日（木）13:30～17:30
場所：佐賀大学教養教育大講義室


思えばLINEとAzure AD B2Cを組み合わせて学生や保護者などへのリーチャビリティの高いコミュニケーション基盤とそれを支えるID基盤のアイデアは昨年度の統合認証シンポジウムの後の宴会の場で産まれたものでした。最初は半分酔っ払いの思いつきでしたが、色々やってみると応用の範囲が思いのほか広くビジネスになってしまうのが面白いところです。

と、言うことで昨年度はエンタープライズID管理のトレンドの話をしましたが、今年は大学におけるSNS IDの活用についてお話しします。
他にも著名な先生方が大学における業務改善のお話しをしてくださったり、お馴染み日本マイクロソフトの中田さんがOffice365の多要素認証についてお話ししてくださるそうですので、大学だけでなく一般企業においても有益な内容になると思います。

既に申込みも始まっていますので、是非お申込みください。

[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/パスワードで認証していたものが運用上の問題になったり、セキュリティ上の弱点になったりするケースもあったと思いますが、このような工夫を組み合わせることにより少しでも楽にセキュリティレベルを向上することが出来る可能性がありますので、検討してみてください。