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

2017年2月12日日曜日

[告知]大阪と佐賀でエンタープライズID管理のトレンドの話をします

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

2月は大阪と佐賀でID管理、特にエンタープライズでの事情についてお話しさせていただく機会を頂きました。

お近くにお越しの方はぜひお立ち寄りください。(事前申し込みは必要みたいです)

1.三木会@大阪

 インサイトテクノロジーさんが定期的に開催している勉強会です。お酒を飲みながらざっくばらんに技術について語る会、ということです。インサイトテクノロジーさんというとデータベースの専業ベンダさんというイメージですが、過去のイベント情報を見るとたまにデータベース以外のテーマでも勉強会をやっているようです。

 今回はアイデンティティに関してはあまりご存知ない方もターゲットということで、エンタープライズにおいてアイデンティティ管理がどのような意味を持つのか、という基本的な部分から、技術トレンドまで広く・浅くお話しできればと思います。

 開催概要は以下の通りです。
  日時:2017年2月16日(木)18:30~20:30(受付開始18:15)
  場所:インサイトテクノロジー大阪支店(グランフロント大阪)
  タイトル:エンタープライズにおけるアイデンティティ関連技術のトレンド
  申し込み:http://www.insight-tec.com/events-seminars/20170216_3moku


2.統合認証シンポジウム@佐賀

 こちらは毎年佐賀大学で開催されている認証、ID連携に関する学術系のシンポジウムです。これまでは学術系ということでShibboleth/学認の話が中心だったようですが、たまにはエンタープライズの話も、ということでお声がけを頂きました。

 こちらもエンタープライズでのID事情やOpenIDファウンデーション・ジャパンのEnterprise Identity Working Groupでここ数年討議してきたOpenID Connect/SCIMのエンタープライズへの適用に関する話が出来ればと思います。

 開催概要は以下の通りです。
  日時:2017年2月28日(火)13:30~17:30(受付開始13:00)
  場所:佐賀大学本庄キャンパス
  タイトル:エンタープライズにおけるID管理/認証システムのトレンド
  申し込み:http://www.cc.saga-u.ac.jp/ias/#gsc.tab=0

 こちらはNIIの中村先生やマイクロソフトの中田さんなどお馴染みの方々をはじめ、色々な方が講演されるので、それぞれ違った視点でアイデンティティに関して話を聞くことが出来ると思うので、個人的にもとても楽しみです。



それぞれ場所が違うので参加のハードルが高いと思いますが、ご近所の方はぜひどうぞ。

尚、3月は東京で2回ほど登壇させていただく機会を頂きましたので、また日程が近づいたら告知させてもらおうと思います。

2017年2月7日火曜日

[Windows Hello]Yubikeyを使ってWindows 10 PCにサインインする

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

そう言えば昨年秋にYubikeyがWindows Helloに対応した、という話がアナウンスされましたが試していなかったので、やってみました。

 Yubicoからのアナウンス
  Yubikey Works With Windows Hello
  https://www.yubico.com/2016/09/yubikey-works-windows-hello/


流石にネイティブでは対応していないので、ストアから専用アプリ「Yubikey for Windows Hello」をダウンロードしてセットアップしてあげる必要があります。

中身はWindows Helloコンパニオン・デバイス・フレームワークを使っているみたいです。昨年のCIS(Cloud Identity Summit)Alex SimonsがデモしていたMicrosoft Band(死語)でのWindows 10へサインインするのに使うヤツです。

 Windows Helloコンパニオン・デバイス・フレームワーク
 https://msdn.microsoft.com/ja-jp/windows/uwp/security/companion-device-unlock


◆必要な物

とりあえず以下のものが必要です。

  • Windows 10 ver. 1607 / Build 14393.321以降
  • Yubikey 4 or Yubikey 4 nano, Yubikey NEO or Yubikey NEO-n

左がYubikey NEO、右がYubikey 4です。


ちなみに、私はYubikey 4とYubikey NEOの両方で試してみましたが、Yubikey NEOを使う場合はCCIDモードを有効にする必要があります。

CCIDモードを有効化するには、Yubikey NEO Managerを使ってYubikeyの設定する必要があります。

これがCCIDモードが無効な状態なので、「Change connection mode」をクリックして設定を変更します。

真ん中のCCIDにチェックを入れてOKをクリックします。
一旦Yubikeyを抜くように言われるので、抜いて指し直すとCCIDモードが有効になり、以下のような画面になります。


これでYubikey側の設定はおしまいです。ちなみにYubikey 4の方はこの操作は不要です。


◆Yubikey for Windows Helloを使ってYubikeyを登録する

先にも書いた通り、Yubikeyを使ってサインインするには、ストアから専用アプリをダウンロードしてYubikeyを登録する必要があります。

ストアで「Yubikey for Windows Hello」を検索し、インストールします。


インストールが完了したら早速アプリを開き、Yubikeyの登録を進めます。

「Register」をクリックし、登録開始です。

Yubikeyを差すように求められるので、USBポートにYubikeyを差します。

こんな感じです。
Yubikeyが正常に認識されると名前を付けるように言われるので適当に名前を付けます。

「Continue」をクリックすると認証を求められます。

これで完了です。



ちなみに、CCIDモードが無効なYubikeyを差すと、以下のエラーが出るので先にCCIDモードを有効にしておいてください。


◆サインインしてみる

一旦Windowsをロック(もしくはサインアウト)するとサインイン・オプションに「コンパニオン・デバイス」が出てくるようになります。



これを選択してYubikeyを差し込むと一瞬でサインインされます。
(ちなみにYubikeyをOTPデバイスとして使うわけではないので、タッチしてOTPを生成する必要はなく、差し込んだだけで認証されます)

こんな感じです。



指紋や虹彩など色々な認証デバイスもありますが、Yubikeyは比較的安価で手に入りますし、手軽に使うには良いかも知れませんね。

2017年2月3日金曜日

[Azure AD/Office365]自社のテナント以外のOffice365やアプリケーションへのアクセスを制限する

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

Office365など、Azure Active Directory(Azure AD)をID基盤として利用しているアプリケーションの良さはインターネット上に認証基盤があることにより、インターネット上のどこからでもセキュアかつ確実にアプリケーションを利用することが出来る、という点です。
(現実にAzure ADと同じレベルの可用性、堅牢性を持つ認証基盤を自前で構築しようとすると莫大な手間と費用が掛かります)


しかし、その反面で、例えば自前や他社のOffice365へのアクセスも出来てしまうことになるので、OneDriveやSharePoint、Exchangeへアクセスして自由に情報を書き込んだりメールを送信したりできてしまい、意図しない情報漏えいにつながってしまう可能性があります。

これまでIT管理者はURLフィルタ製品などを使って例えば、outook.comへの社内からのアクセスを遮断する、というような対策をしてきましたが、この対策だと自社もOffice365を使ってoutlook.comへアクセスをさせたい、という場合にURLフィルタによるドメイン名判別では対策出来ないため、結果として制限を緩めざるを得ない、という状況に陥ります。

そこでAzure ADで新たにリリースされたのが「テナントへのアクセス制限」機能です。

この機能を使うと特定のAzure ADテナントでしか認証が出来なくなるので、他社や自前のOffice365へのアクセスはNG、自社のOffice365へはアクセス可能、という状態を作り出すことが出来ます。

 公式Blogのアナウンス
  New enhanced access controls in Azure AD: Tenant Restrictions is now Generally Available!
  https://blogs.technet.microsoft.com/enterprisemobility/2017/01/31/new-enhanced-access-controls-in-azure-ad-tenant-restrictions-is-now-generally-available/

 関連ドキュメント
  Use Tenant Restrictions to manage access to SaaS cloud applications
  https://docs.microsoft.com/en-us/azure/active-directory/active-directory-tenant-restrictions


動作の仕組みは非常に単純です。

自社のProxyサーバ等でhttpヘッダに「Restrict-Access-To-Tenants」をセットし、テナント名を値として設定してあげるだけです。

動作概要図:公式Blogより


◆動作イメージ

早速試してみます。

手元にあったsquidを使って構成しようかと思いましたが、面倒なのでChromeのExtension「modHeader」を入れてみました。(fiddlerでもよかったんですが)



これを使うと自由にHTTPヘッダを追加することが出来るようになるので、先ほどの「Restrict-Access-To-Tenants」を追加してみます。
こんな感じで設定すると、pharaoh.onmicrosoft.comにしかアクセスできなくなります。(複数のディレクトリへのアクセスをさせたい場合はカンマ区切りでテナント名を複数記述可能です)


この状態でヘッダがどうなっているかサーバ側でリクエストを見てみます。単純なCGIを使いました。


ちゃんとヘッダが設定されていることがわかります。


この状態で別のテナントへアクセスしてみます。

まず、Access Panelへアクセスしてみます。


別のテナントのユーザでサインインした段階でエラーが表示され、アプリケーションへアクセスが出来ないことがわかります。

同じく、Office365ポータルです。


こちらも同じです。


情報漏えいを防ぎつつ、自社でもOffice365を使いたい企業・組織ではこの機能を上手く使って行けるといいですね。







2017年2月1日水曜日

スマートフォンを使ってマイクロソフトアカウント認証を行う

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

Windows 10へマイクロソフトアカウントでサインインして、IEもしくはEdgeしか使わない、という人はPCとブラウザのシングルサインオンが有効なので気にすることは無いかも知れませんが、一般人はChromeやFirefoxなども利用していると思いますので、MSDNやLive等のマイクロソフトの提供するサービスを利用する際がマイクロソフトアカウントとパスワードを使ってログインしていると思います。(そして、もちろん2段階認証も使っていると思います)

このように、パスワードをなるべく使わない方向に世の中シフトしてきてはいますが、なかなか一般人の利用方法だと完全にパスワードの利用を無くすのが難しいのも現実です。

※ちなみに以前紹介したWindows 10のPC自体へのログインをスマートフォンで行ったりWindows Helloを使った生体認証を使うと本当にパスワードを使うことなく日々の生活が送れてしまいます。


そこで本日はマイクロソフトアカウントでサインインする際に、パスワードの代わりにスマートフォンを利用する方法を紹介します。
(最近、iOS版アプリが更新されて使えるようになりました)

必要なもの

・マイクロソフトアカウント(~@live.jpなど)
・スマートフォン(iOS、Android、Windows Phone)
・Microsoft Authenticatorアプリ(スマートフォンにインストール)
 ※iTunesストアなどよりインストール

設定(利用の準備)

まず、マイクロソフトアカウントのページ(https://account.microsoft.com)へサインインします。




ログイン後、セキュリティのメニューを開きます。



次にセキュリティ情報の更新の「更新情報」を開きます。

「追加オプション」を開きます。なかなか深い階層に設定がありますね・・・


ここでようやく目的の認証アプリの設定項目が見つかりますので、「本人認証アプリをセットアップ」を開いて設定を行います。


設定画面を開くと、アプリケーションをインストールしたデバイスを選択することになるので、先にアプリをインストールしたデバイスの種類を選択して次へをクリックします。


スマートフォンアプリケーション側での設定を促されるので、アプリ側の設定を行います。この際、アプリ側の設定が終わるまではこの画面の「次へ」をクリックしないでください。




アプリを開くと設定するアカウントの種類を選択させられるので、「個人のアカウント」を選択します。


ここでマイクロソフトアカウントでのサインインを要求されるので、スマートフォンサインインを使いたいマイクロソフトアカウントでサインインします。さすがにここはパスワードでのサインインです。

設定が完了すると画面上にワンタイムパスワードが羅列された画面になるので、先のブラウザに戻って「次へ」をクリックします。

これで設定は完了です。


サインインしてみる

サービスはなんでもいいです。MSDNやOutlook、Azure Portalなどでも大丈夫です。



アカウント名を入れると通常のパスワード入力画面に飛びますが、設定がうまくいっていればこの際「代わりにアプリを使用する」というリンクが出てくるようになるので、このリンクをクリックします。



すると、アプリへ認証要求が飛び、ブラウザ側はアプリ側の承認を待機します。


アプリ側はこんな感じでサインイン要求が来るので、「承認」をタップします。
この際、TouchIDが使えるiPhone/iPadであればTouchを求められます。


上手くいくとブラウザ側でのログインが完了し、対象のサービスへ遷移します。※この例ではAzure Portalへアクセスしています。




これまで、Windows 10、Edge/IE、組織アカウントの組み合わせで限定的に使えていたパスワードレス認証の範囲が、他のブラウザへも広がってきており、いよいよパスワードを使うことなく生活できる日も近くなってきた感があり、今後の展開を含め非常に楽しみですね。