2017年3月21日火曜日

[小ネタ]NAT構成のVMに構成されたAD FSへiOSデバイスを登録する

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

今回は完全に小ネタというか自分用のメモです。

普段、BootcampなMacbook AirにWindows 10を入れ、その上でVMware Workstationを動かして、AD FSやMIMを動かして検証してるんですが、VMやAzureだけでクローズできないネタを検証する場合です。

具体的にはiOSやAndroidデバイスなどをAD FSへデバイス登録してデバイス認証をしたい場合、以下が困ります。
・JailbreakしていないiOSだとhosts登録が出来ない
・色々と事情があってVMをNAT構成で動かしているので母艦PC以外からVMへアクセスできない

ということで、対処してみます。

と、言ってもやることは母艦にApacheを立ててForward Proxyにするだけなんですが。

◆Apacheをダウンロードして構成する

Apacheの本家からWindows用のbinaryのダウンロードは出来なくなっているので、本家からリンクされているサイトからダウンロードをして使います。
 http://httpd.apache.org/docs/current/platform/windows.html#down

母艦がWindows 10 Pro x64なので、64bit版をダウンロードしてきました。バージョンは現時点の最新版な2.4.25です。

zipアーカイブを解凍したら少々コンフィグをいじくります。(conf\httpd.confを編集します)
ポイントは、

  1. パスを合わせる
  2. Proxyに必要なモジュールをロードする
  3. Forward Proxyとして構成する
  4. ServerNameをつける

の4点です。

では順番に。

1.パスを合わせる

 変更箇所はServerRoot、DocumentRoot、ScriptAlias、cgi-binのディレクトリ設定の4か所です。単にForward Proxyとして使うだけなので変更しなくても問題はありませんエラーが出るので。以下の5行が変更対象です。今回、C:\Tools\Apache以下にモジュールを展開したので環境に合わせて編集します。
ServerRoot "C:/Tools/Apache/Apache24"
DocumentRoot "C:/Tools/Apache/Apache24/htdocs"

    ScriptAlias /cgi-bin/ "C:/Tools/Apache/Apache24/cgi-bin/"

2.Proxyに必要なモジュールをロードする

 必要なモジュールのLoadModule行のコメントアウトを外します。今回AD FSを使うのでhttpsのフォワードも必要なのでmod_proxy_connectも使います。
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_connect_module modules/mod_proxy_connect.so
LoadModule proxy_http_module modules/mod_proxy_http.so

3.Forward Proxyとして構成する

 非常に雑な構成ですが、httpd.confの最後に以下を追記します。

  ProxyRequests On
  ProxyVia On
  Listen 8080
  AllowCONNECT 443
 
    Order deny,allow
    Deny from all
    Allow from all
 

4.ServerNameをつける

 これはしなくてもいい設定ですが、Apacheの起動時にワーニングが出るのでとりあえず設定しておきます。

ServerName hoge:80

取り敢えずここまで設定したらOKなので、起動しておきます。
私の場合は検証したい時だけ立ち上げれば良いので、サービス化はせずにコマンドプロンプトから直接起動します。

binディレクトリ配下でhttpd.exeを起動するだけです。


◆母艦からアクセスできるようする(hostsファイルの構成など)

母艦経由でVMへアクセスさせたいので、まずは母艦からアクセス出来るようにネットワークを構成をしてあげる必要があります。

多くの場合、適当な名前(.localとか)でドメインを構成していたりするので、母艦のhostsファイルを使って適切にアクセスできるように構成する必要があります。

後は、念のため母艦からAD FSへアクセスできることを確認しておきましょう。


◆iOS側のProxy設定をする

最後にiOSのWifi設定でProxyサーバに母艦PCを指定します。
尚、当然の事ながら母艦PCへの8080ポートの通信をWindows Firewallで開放しておく必要があります。

iPhoneの設定からWifiを開き、母艦PCと同じアクセスポイントへ接続していることを確認したら、母艦PCのIPアドレスとProxyサーバとして指定した8080番を指定します。


設定はこれで終了です。

◆DRSへアクセスしてデバイス登録する

この状態でiPhoneからAD FSのデバイス登録サービス(DRS)へアクセスして、プロファイルがインストールされるか確認してみます。

DRSのアドレスは
 https://ADFSServer/EnrollmentServer/otaprofile
ですが、当然インターネットにしか繋がっていないiPhoneからVMで動いているAD FSへアクセスは出来ず、DRSへ到達できません。

しかし、今回母艦に立てたProxyを経由することでVM上のAD FSへアクセスでき、無事にプロファイルがインストールできます。



当然、デバイスクレームの取得もできるので、手元でアクセス制御のテストも行うことが出来ます。



まぁ、Azure上にIaaSを立ててインターネットからもアクセス出来るようにすればいいんでしょうが、iOSからアクセスできるようにちゃんとDNS登録が必要だったり、特にDRSの場合はenterpriseregistrationの名前が解決できる証明書を用意しなければいけなかったりするので、手元で済ませられれば手軽なのでこういう方法もありかな~と思っています。

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

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を使いたい企業・組織ではこの機能を上手く使って行けるといいですね。