ラベル 認証 の投稿を表示しています。 すべての投稿を表示
ラベル 認証 の投稿を表示しています。 すべての投稿を表示

2024年2月13日火曜日

Authentrendのカード型のPasskeyを試す

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

なんだかステマっぽいですがそういう訳ではありません。

昨年末のFIDOアライアンスのイベントでAuthentrendの方から最新のカード型のパスキー「ATKey.Card NFC Bio-ID」をいただいたので試してみます。(いただいた段階では管理用のアプリがストア公開されていなかったので試せずにいたのですが2月に入りようやく公開されたので試せるようになりました)

こちらが製品のページです。

https://authentrend.com/atkey-card-nfc/

 こんなやつです。


バッテリーなしで動作するICカードタイプのセキュリティキーで、インターフェイスはNFCなのでパスキーとしての利用以外にも扉の開閉などにも使えます。(もちろん扉側の管理システムがNFCに対応していてカードを登録すれば、ですが)

パスキーとしてみた場合は単なるNFCタイプの指紋センサー付きの外部セキュリティキーとして使えます。

早速試してみましょう。


カードのセットアップ

カードをアクティブ化するにはiOS版かAndroid版の管理アプリをインストールする必要があります。(現状、Android版はベータ版です)
アプリケーションは先述の製品ページのQRコードからマーケットを開くとダウンロードできます。


こちらはiOS版ですが、初回起動するとカードをかざすように求められるのでNFCリーダーで読み取らせます。

こちらが初期状態なので、PINと指紋を登録していきます。
ちなみにSign-in Dataに38leftとあるように38サイト分のサインインデータの登録ができるようです。

こちらが指紋登録をしているところですが、iPhoneのリーダーにカードをかざして指紋にタップを繰り返すことで指紋が登録されます。


パスキーとして登録する

カードのセットアップが終わったら、普通にパスキーとして使えるようになっています。
いつものwebauthn.ioで試してみます。

いつも通り適当にユーザ名を入れてregisterからキー登録を行います。
ただし、デフォルトだとFaceIDが優先されてしまうので、Advanced SettingsでRegistration HintsとしてSecurity Keyを設定します。この設定によりセキュリティキーを使った登録が行われます。
この状態でRegisterをタップするとセキュリティキーを使ったパスキーの登録が始まります。

先ほどの指紋登録時と同じくカードをかざして指紋をタップすれば登録が完了します。

ちなみに管理アプリでカードを読み込ませてみるとSign-in Dataにwebauthn.ioのサインインデータが登録されたことがわかります。


サインインする

次にサインインしてみます。Authenticateボタンをタップするとサインインが求められるのでセキュリティキー・NFCを選択、先ほどと同じくカードをかざして指紋をタップします。
これで完了です。
正常にサインインできました。



という感じで簡単ですが試してみました。
セキュリティキーのネックレス問題が起きているので、カード型だと省スペースになるな〜というのと扉の開閉や身分証明書とのハイブリッド利用ができるようになると便利だと思います。


2024年2月4日日曜日

OpenID Providerを作る)ユーザ認証方式について考える

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

いよいよユーザの認証について実装を考え始めているのですが、最大の考慮ポイントはパスワードを使ったユーザの認証を実装するかどうか?です。

その前にこれまでのおさらいです。


問題はパスワード認証を許容するかどうか

モダンな認証基盤を作ろうと思うとパスワードを使った知識認証は極力省きたくなります。しかしながら実際に認証基盤を導入していくと必ず出てくるのが認証画面はアプリ側で実装したい、OpenID Providerへのリダイレクトはさせたくない、という要件です。

もちろんこれは集中的にOpenID Providerでアイデンティティを守る、特にログイン画面をフィッシングから守るという主旨と相入れないものなのですが、一貫したUXを守りたいというアプリ側の意見も一定理解できます。

そのため、OpenID Providerの中にはネイティブアプリからバックエンドで呼び出す認証エンドポイントを独自に実装したりしているケースも存在しますし、安直にOAuth2.0のリソースオーナーパスワードグラントを利用しよう、という話になってしまうケースも存在します。

なお、リソースオーナーパスワードグラントについては明確に注意点が記載されているので、どうしても使わないとダメなケース(主にはシステム移行)以外では採用すべきではありません。

リソースオーナーパスワードクレデンシャルグラントタイプは, リソースオーナーがクライアントと信頼関係にある場合, 例えばリソースオーナーの所有するデバイスOSや特別許可されたアプリケーションなどに適している. 認可サーバーはこのグラントタイプを有効にする際は特に注意するべきである. また他のフローが利用できない場合にのみ許可するべきである.

このグラントタイプは, リソースオーナーのクレデンシャル (通常は対話型入力フォームにて取得するユーザー名とパスワード) を取得できるクライアントに適している. また, 保存済みのクレデンシャルをアクセストークンへ変換できるため, Basic認証やDigest認証のような直接的な認証スキームを利用している既存のクライアントをOAuthへ移行する際にも利用できる.


こう考えると新規でOpenID Providerを作る場合はTokenエンドポイントがサポートするgrant_typeからpasswordは落としてしまっても良さそうではあります。


その場合の考慮点

しかし、安直にパスワード認証をなくしてしまうと何が起きるのか?も考慮しておかないといけません。

先のユースケースのようにネイティブアプリケーションへのバックエンドAPI経由でのインテグレーションをしたいケースへの対応、そしてパスワード以外の認証手段のみしか提供しなかった場合のアカウントリカバリの方式をどうするか?などセットで考えなければならないことが出てきます。

ネイティブアプリへの認証APIの提供

  • ここは個人的な意見としては落としてしまっても良いかとは思いますが、アプリケーションチームとの力関係もあると思うので十分な話し合いや安全性に関する検証が必要な領域です。

リカバリ方法

  • 安全なアカウントリカバリ方法が提供できない場合は、いくらデフォルトの認証手段を強固にしたとしても、そこから突破されるので意味がありません。そのため認証手段を強くする際はリカバリ手段もしっかりと固める必要があります。(最近某C2C取引アプリでdiscoverable credentialが実装される前のWebAuthnが実装された状態からパスキーへ移行したことにより、過去にデバイスにバウンドされた鍵しか登録しなかったユーザがログインできなくなるという事件もありましたので、場合によっては過去の経緯やユーザの状態を含め分析をしないといけません)


今回はせっかく新規で作るのでやっぱりパスキーをデフォルトにしてしまうのが良いのかなぁ、、と思案中です。(ここまでくるとOpenID Connectの仕様のスコープ外なのですが)



2023年6月29日木曜日

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

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

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


簡単にいうと、

「LINEログイン(Webログイン)で2要素認証を要求するかどうかLINEアプリ側で設定できるようになりました。」
という話です。

アナウンス(4月26日付け)

そして、今回は
「LINEログイン(Webログイン)で2要素認証を要求するかどうかを管理者がコンソール側で設定できるようになりました。」
というアナウンスがありました。

アナウンス(6月28日付け)

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

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

設定方法(コンソールで強制する設定)

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

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

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

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


で、amrはどうなるのか?

本題ですが、そもそもLINEログインで想定されている認証手段は
  • パスワード
  • QRコード
  • シングルサインオン
  • 自動ログイン(スマホのみ)
の4種類です。

それぞれについてamrの値が以下の通り設定されています。
  • パスワード:pwd
  • QRコード:lineqr
  • シングルサインオン:linesso
  • 自動ログイン(スマホのみ):lineautologin
今回は自動ログイン以外のWebシナリオで2要素認証を強制する機能なのでlineqrとかlinessoがIANAに登録されているのか?(いやされていない)という話は置いておいて、RFC8176的には「mfa」とか素敵な値が返ってくることを期待するんですが、結果何も変わらずpwd/lineqr/linesso(まぁSSOの場合は2要素認証は求められないって仕様なのでいいとして)がそのまま返ってきてしまいました、というオチです。

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

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


2017年12月16日土曜日

疑似指紋とWindows Helloを対決させてみた ~パート2

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

先日、疑似指紋でWindows Helloの指紋認証を突破できるか?を試してみて結果惨敗したんですが、別の指紋認証デバイスを入手したので、再度対決させてみました。

結果、「突破できました!!!

今回試したのは、PQI JapanのMy Lockeyです。FIDOのUAFにも対応している優れモノです。以下の画像をクリックするとAmazonの商品ページへ飛びます。


Amazonで4290円で売っています。

大きさなどはMouse Computerのヤツより若干大きいくらいですが、仕上げはMy Lockeyの方が高級感があります。


感度はMy Lockeyの方が格段にいいです。

Macbook Airに挿すとこんな感じです。指紋認証するときにMagsafeがかなりの確率で外れます。



まぁ、良し悪しはおいておいて、指紋がない人とかには有効なんじゃないでしょうか。

2017年12月1日金曜日

疑似指紋とWindows Helloを対決させてみた

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

まもなく冬がやってくる、ということで疑似指紋が話題ですね。

これからの季節にピッタリ!手袋をしたままiPhoneで指紋認証ができる「疑似指紋 Diper ID」が便利 - Engadget日本語版
http://japanese.engadget.com/2017/11/24/iphone-diper-id/ 


話題になるのと同時に当然ですが、なんだか香ばしい感じもしますが・・・。ポイントは3万パターン(も?しか?)あることと、あくまで疑似指紋なので自分の指紋のコピーを作るわけじゃない、というあたりらしいです。

ということでとりあえず近所のロフトで買ってきました。


1パッケージに3枚入っていて1580円(税別)という微妙な値付けです。

Touch IDに特化した、とありますが今回はWindows Helloを対決してみたいと思います。

試してみたのは、

  • Surface Pro4の指紋センサー付きType Coverキーボード
  • マウスコンピュータのUSB指紋リーダー
の2つです。

マウスコンピュータのやつはこれですね。



結論から言うと、ダメでした。

2017/12/16続報。別の指紋センサーで試したら突破できました。
http://idmlab.eidentity.jp/2017/12/windows-hello_16.html

指紋センサー付きType CoverではWindows Helloへの指紋登録までは何とか出来るのですが、いざログインしてみようとすると上手く認識をしてくれませんし、マウスコンピュータの方は指紋登録の段階でうまく認識してくれませんでした。
もしかして単純に向きが悪かっただけなのかも知れませんが、iPhoneのTouch IDでは全然問題なく使えるので、やはり「Touch IDに特化」というのはあながち嘘ではないのかも知れません。


とりあえず対決の記録を残しておきます。

まずは開封の儀です。
開封すると台紙に3枚の疑似指紋シールが入っています。

でっぱりがある方を先端にして手袋などに張り付けます。


まずは、Surface Pro4+Type Coverです。
Windows Helloの設定で指紋を登録していきます。認識率はあまり良くないものの何度もリトライしつつ指紋登録を完了することが出来ました。



登録が出来たので、早速ログインをしてみます。

うーむ。全然認識してくれずリトライ回数オーバーです。



次にマウスコンピュータの指紋センサーです。
こちらはUSBタイプでPCの横に飛び出る感じになりますので、ここをタッチしてみます。

全く反応しません・・・・


素手だとちゃんと反応するので、センサーが悪いわけじゃなさそうです。



と、言うことで疑似指紋 vs Windows Helloの対決結果は「Windows Helloの圧勝!」ということでした。残念。

2017年3月7日火曜日

[続報]Office365管理者は要対応。外部共有により不要なアクセス権が付与される

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

先日のポストでOffice365の外部共有を有効にした場合に意図しないアクセス権限がゲストユーザに付与されてしまう、という注意喚起をさせていただきました。

 Office365管理者は要対応。外部共有により不要なアクセス権が付与される
 http://idmlab.eidentity.jp/2017/01/office365.html


ポスト後も米国マイクロソフトの開発チームへフィードバックをしていたのですが、他の国でも同じ意見の管理者・技術者の方も多く、Azure Portalのディレクトリ構成情報へのアクセスに関するセキュリティ設定が追加されました。

このことにより、前回紹介した条件付きアクセスを使いAzure Portalへのゲストユーザのアクセスを拒否する対策(Azure AD Premium P1ライセンスが必要)を行う必要がなくなりました。

ただ、アクセスパネル経由のアクセスでディレクトリを切り替えることによりAll Usersへ割り当てられたアプリケーションが見えてしまったり、認可設定が不適切なアプリケーションへのアクセスを防ぐことはできないので、こちらは引き続き対応が必要です。


では、早速Azure Portalでディレクトリ構成情報へのゲスト・アクセスを防ぐ方法を紹介します。ちなみに今回さらに新たな設定項目が追加されており、自ディレクトリ内のユーザでも非管理者によるアクセスを防ぐことも可能になっています。

◆ゲストユーザによるディレクトリ構成情報へのアクセスを防止する

まずはゲストユーザがディレクトリ構成情報へのアクセスを防止するための設定です。

管理者がAzure Portalへアクセスし、Active Directoryを開き、[ユーザー設定]を開くと、外部ユーザの設定の中に「ゲストのアクセス許可を制限する」という設定項目が追加されています。デフォルトで[はい]が設定されており、既定でアクセス制限が有効な状態となっています。


同様に管理ポータルの設定に「Azure AD管理ポータルへのアクセスを制限する」という項目も追加されており、こちらの設定では非管理者ユーザが自ディレクトリであってもディレクトリ構成情報へアクセスすることを防ぎます。(こちらの初期値は[いいえ]なので必要であれば設定変更を行います)こちらは後述します。


前回のポストをした際は初期状態ではゲストユーザがAzure Portal経由でディレクトリ構成情報(ドメイン情報など)へアクセスできましたが、現在は初期状態でアクセス制限がかかっているため、同じようにアクセスすると以下の様なエラーが表示されてディレクトリ構成情報を開くことが出来ません。(Azure Portalまでは開きます。Active Directoryメニューを開くとこの状態になります)


前回紹介した条件付きアクセス機能を使ってAzure Portal自体へのアクセス拒否をした場合は以下のように認証後すぐにエラーが出るので若干動作が異なります。


◆非管理者ユーザによるディレクトリ構成情報へアクセスを防止する

次は、非管理者ユーザがディレクトリ構成情報へアクセスできないように設定を行います。先に書いた通り、今度は管理ポータルの項目の「Azure AD管理ポータルへのアクセスを制限する」を[はい]に設定します。


この状態で非管理者でAzure Portalへアクセス、Active Directoryを開くと先のゲストユーザによるアクセスの際と同様に以下のエラーが表示されアクセスがブロックされます。



◆とりあえずは安心?

これで一応最低限のLeast Privilegeの法則は守られてきていますが、冒頭にも述べた通り、アクセスパネル(https://myapps.microsoft.com)へのアクセスによりAll Usersに割り当てられたアプリケーションは見えてしまい、かつ認可設定が不十分だと使えてしまうので、こちらは引き続き注意をして行く必要があります。

日々設定項目が進化していくAzure ADですが、項目が増えていき複雑性が増していくことにより、自社にとって最適な設定が変化していくことにもなりますので、管理者の方は継続的にフォローアップをしていく必要がありそうです。


◆最後に告知

前回のポストや本ポストに記載したOffice365やAzure AD管理者が考えるべきセキュリティ設定について、3/11に開催されるOffice365勉強会でお話しします。

 案内・告知
 Japan Office365 User Groupのページ
 http://jpo365ug.com/o365-meeting/meeting-18/

今週末の開催となり、既にキャンセル待ちの状態ですがよろしければどうぞ。

2017年3月3日金曜日

「OAuthの仕組み丸分かり体験サイト」に見るOAuthとアイデンティティの関係

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

明治大学の情報セキュリティ研究室が公開している「OAuthの仕組み丸分かり体験サイト」が話題になっているので、少し内容を見ていこうと思います。
※決してディスっている訳ではありません。敬遠されがちなOAuthなどの仕組みを簡易に解説しようとする取り組みは非常に大切だと思いますし、私も常に悩むポイントの一つです。

 OAuthの仕組み丸分かり体験サイト
 https://www.saitolab.org/oauth/

尚、最初の公開後、かなり修正が入っていて誤解を招く部分はかなり減っており、投稿するのをやめようかと思ったのですが、逆に課題認識の部分がぼやけてしまったところもあるので、あえて投稿してみます。


中身ですが、元々は所謂OAuth認証問題です。一番残念なところはFacebookをOAuthの利用例に挙げてしまったところです。公開当初はユーザがIDやパスワードを覚えなくても良くなるので、OAuthでFacebook上のアイデンティティ情報を引っ張ってくれば認証の代わりに出来るのでとっても便利!という文脈でした。(現在はソーシャルログインはオマケ的な紹介にとどまっています)


[OAuth認証問題]
簡単に言うと、アクセストークンなどのBearerトークン(本来の持ち主かどうかは関係なく、持参した人に対して認可をするもの。合鍵ですね)を使ってユーザ認証をしてしまう問題。その名のとおり本来の持ち主以外でもトークンを持ってくることが出来てしまうので認証として使うのは危ない、という話です。

詳しくは崎村さんのblogを。
 http://www.sakimura.org/2012/02/1487/
 http://www.sakimura.org/2011/05/1087/


Bearerトークンについてはこちら。
 http://idmlab.eidentity.jp/2013/09/bearer-token.html


全体を通して軽く読み流した感想としては「なぜOAuthの話なのにfacebookログインをユースケースとして選んじゃったのかな・・・」というのが正直なところです。ログインじゃなくて、Graph APIでタイムラインを引っ張ってくるくらいの方が本来のOAuthの目的である「認可」を理解してもらうには適していると思うのですが。
(もしくは写真共有などのサイトを例にした方がわかりやすかったと思います)

結局のところ、根底には「認証」とか「認可」とかというキーワードが「アイデンティティ」と「なんとなく」関係があるのかな?というもやっとした共通認識が根底にあるような気がしてなりません。


現在はオマケとして紹介されているソーシャルログインの部分にも書かれている、Facebookで認証されたブラウザ「だけ」が認可コードをクライアントに渡すことが出来る、ことを前提とした認証は、ユーザの認証になっていない点が大きな問題点です。
(注意点として認可コードの置き換えに関して記載がありますが)

例えば、「ナンバープレート」だけを見て「運転者が車の持ち主である」と決めつけることが出来ないのと同じ理屈だと思います。駐車禁止の罰金もナンバープレートだけでは特定できないことから減点ではなく罰金だけに変わりましたよね?


以下、引用です。
免許証作成サイトにとって,「OAuth認証」が成立するための前提は以下となります:
Facebookがきちんと「あなた」本人であることを確認(=認証)していて,Facebook上で「あなた」がプロフィール情報(名前と写真)を利用する「許可証(=認証コード)」を発行できること
最初にアクセスしたブラウザと「許可証(=認可コード)」を提示したブラウザが同じであること(これはクッキーを利用します)
「許可証(=認可コード)」は有効期限内あること
最初に「許可証(=認可コード)」を提示したら,Facebook上で認証された「あなた」以外は「許可証(=認可コード)」を提示できないので,登録後に同じものを提示できるのは「あなた」だけであると判断できます.これは,最初の登録後,「許可証(=認可コード)」を次回以降の接続時に提示できることにより,本人性の確認を実現しています.いわゆる,TOFU (Trust On First Use) と呼ばれる仕組みです.
しかしながら,OAuth認証における「許可証(=認可コード)」は,通信路が無防備なので,「許可証(=認可コード)」が盗まれたり,書き換えられたり,でっち上げられたりしてしまいます.OAuth認証は,安全性より,手軽さを優先する実現と言えるでしょう.

では、どうすれば良かったのか、について個人的な意見を。

<課題の設定>
現在は免許証サイトへ個人情報(名前など)を入力するのが面倒くさい、というのが課題として挙げられており、そのためにOAuthを使ってFacebookから情報をとってくる、というのが解決策として挙げられています。

しかし、本来は、
・リソースオーナーの所有しているデータへ
・クライアント(今回でいうところの免許証サイト)が
・リソースオーナーの望んだ範囲(スコープ)で同意の上で
・クライアントにリソースオーナーのIDやパスワードを伝えることなく
・アクセスされることが出来るか?
というのが一番の関心事であるはずです。



Japan Web API Communityのプレゼン資料より
https://www.slideshare.net/naohiro.fujie/oauth20web-api


<取り上げるべきポイント>
上記の課題をOAuthがどうやって解決していくのか?を中心に解説し体験してもらえるようにすればより理解が進むはずなので、アクターの整理をまずはすべきだと思います。


その上で、
・リソースオーナーが望んだ範囲(スコープ)の定義の仕方
・同意の取り方
・クライアントへリソースオーナーのID/パスワードを登録する必要がないこと
を解説することで理解が進むと思います。

全てを解説はしていませんが、こんな感じです。



他にも認可コードの置き換えの可能性について記載するのであればPKCEについても解説してもらった方がOAuthを使う開発者が安全性を気にする一つのきっかけになったかも知れません。

PKCEについてはこちらから。
 OAuth PKCEがRFC7636として発行されました
 https://www.sakimura.org/2015/09/3206/


<OAuthとアイデンティティの関係>
結局はOAuthとアイデンティティは直接関係はなく、アイデンティティをOAuthの仕組みを使って上手にやり取りしたのがOpenID Connectです。当該のサイトの主旨とはズレてしまいますが、ソーシャルログインや認証の話を取り上げるのであればOpenID Connectの話を本来は取り上げても良かったのかな?とも思います。

 このあたりです。
 アイデンティティ、認証+OAuth=OpenID Connect
 http://www.sakimura.org/2013/07/2048/


冒頭にも書きましたが、利用が進んでいる割に汎用的であるが故に本来の目的からズレた使い方がされてしまいがちなOAuthですが、上手に使えば便利で安全な仕組みなのできちんと理解をして使っていきたいですね。

2017年2月13日月曜日

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