Quantcast
Channel: IdM実験室
Viewing all 769 articles
Browse latest View live

Internet Weekの資料と動画を公開しました

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

遅くなりましたが、Internet Weekで使った資料を動画をアップロードしています。
(イベント直後にアップロードしてあったのですが、こちらに告知するのを忘れていました)


また、デモ環境の構築手順もまとめたので明日から順番に書いていこうと思います。


まずは資料です。



続いてデモの動画です。


内容は

  • OpenAMと社内ADをこっそり連携
  • OpenAMでデスクトップSSO
  • OpenAMとG Suite(Google Apps)を連携
  • OpenAMと連携したG SuiteをAzure ADと連携
  • G Suiteの連携を利用者に知られずにOpenAMからAzure ADへ切り替え

という内容です。

当日のデモとこの動画はOpenAM 12.0ベースで作っていますが、明日から公開する予定の環境構築手順はOpenAM 13.0ベースで作り直していますので、また参考にしてもらえればと思います。



[Internet Weekフォローアップ]デモ環境の作り方①

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

Internet Weekの資料と実施したデモの完成形の動画を先日公開させてもらいましたが、今回はデモ環境の作り方の説明です。

長いので以下のように分割してお届けしたいと思います。

  • 第1回(今回):環境の説明、OpenAMの認証を社内ADで行う
  • 第2回:OpenAMのデータストアとして社内ADを利用する
  • 第3回:OpenAMとG SuiteのID連携を行う
  • 第4回:OpenAMでDesktop SSOを設定する
  • 第5回:Azure ADとOpenAMと連携したままのG Suiteを連携する
  • 第6回:G SuiteのID連携先をOpenAMからAzure ADへ切り替える


また、当日およびデモ動画ではOpenAM 12.0を使いましたが、さすがに古いので今回の手順はOpenAM 13.0をベースに再構成しています。(ほとんど手順は変わりませんが)

◆環境の説明

OpenAMサーバ)
 CentOS 7
 OpenAM 13.0 ※Forgerock社のサイトよりダウンロード
 その他ミドルウェア:
  Apache : yum install httpd
  Apache mod_ssl : yum install mod_ssl
  tomcat : OSバンドル
  OpenJDK : OSバンドル

ドメインコントローラ)
 Windows Server 2016

PC)
 Windows 10 Pro
 ブラウザ : Internet Explorer 11


◆デモシナリオとゴール

これは当日お話ししましたが、

  • 現場はSaaS(今回はG Suite。旧Google Apps)を導入したい
  • 情シスは人手が足らないのでダメ

とういう対立構造の中で、現場が勝手(なるべく情シスにばれないように)にSaaS契約するが、なるべく管理の手間を減らしたい、というシナリオです。(今考えると酷いシナリオですね)

このシナリオでは現場の要件は、現場の担当者の少しの良心の元、以下の通りです。

  • 利用者の利便性を上げたい
    • IDとパスワードは情シスで管理しているADと合わせたい
    • 出来るなら統合Windows認証でDesktopSSOしたい
    • 後々情シスへ管理を移管する際に利用者の切り替えが発生しないようにしたい
  • 退職者は使えないようにしたい
    • IDの管理は情シスで管理しているADと合わせたい
    • Google側のIDは個別で作っても良いが、最低限退職したら使えなければよい


これを実現するために今回のデモでは次の1~3にステップ分割してシステムを構成しています。

STEP1)
 フロントでとりあえず認証基盤を作ってクラウドサービス利用を開始
 OpenAMを構築、社内AD連携
 G Suiteを連携


STEP2)
 情シスがAzure ADを契約
 G SuiteをAzure ADへ追加
 SSOは既存認証システム(OpenAM)を利用する様に構成


STEP3)
 アプリを情シスが巻き取る
 G SuiteのSSOをAzure ADへ切り替え




では、早速始めていきます。

<STEP 1>

◆OpenAMの導入

まずはOpenAMを構築します。今回はデモなので雑に構成をしましたが、本番環境で使うときはちゃんと可用性なども考えて構成しましょう。

ダウンロードしてきたOpenAMのwarファイルをopenam.warというファイル名に変更してtomcatのwebappsディレクトリへ配置すると自動的にデプロイしてくれます。

デプロイ完了後、ブラウザで「http://openamserver:8080/openam」へアクセスするとセットアップ画面が表示されるので、デフォルト設定を作成してしまいましょう。




途中、デフォルトユーザのパスワードを設定するところでは管理者(amAdmin)のパスワードとポリシーエージェントユーザ(UrlAccessAgent)のパスワードは別のものを設定する必要があります。今回ポリシーエージェントは使わないので、こちらのパスワードは忘れてしまっても大丈夫です。


しばらくすると設定が完了するのでログインへ進みます。非常に簡単です。


管理者(amAdmin)でログインできればOKです。



◆社内ADを使った認証設定

社内のADで認証をするためには、OpenAMに以下の設定を行う必要があります。

  • OpenAMが社内ADで認証する(認証モジュール設定)
  • OpenAMが社内ADのユーザを参照する(データストア設定)


その前に、今回は情報システム部門と交渉が決裂しているので、なるべく情シスに知られることなく、上記を達成する必要があります。

となると、

  • 自社のADサーバのホスト名
  • ユーザ情報の格納場所

など一般に公開されていない事項も多々あります。

まずはそれらの情報を探索するところから作業を開始する必要があります。

・社内ADのFQDNを知る

社内ドメインに参加しているPCであればコマンドプロンプトから以下の環境変数の値からホスト名とドメイン名が取得できるので、ドメインコントローラのFQDNを知ることが出来ます。

  • ホスト名:LOGONSERVER
  • ドメイン名:USERDNSDOMAIN



この例では、FQDNが「dc.intra.ems.adfs20.net」であることが上記の結果よりわかります。


ただし、この方法では自分のPCがたまたまログインに使用していたドメインコントローラのホスト名しかわからないので、DNSを参照することにより他のドメインコントローラについても取得することが可能です。

具体的には、nslookupを利用してLDAPサービスを提供しているサーバをSRVレコードから探すことでドメインコントローラの一覧を割り出します。

検索対象のSRVレコードは「_ldap._tcp.DomainDnsZones.<先のドメイン名>」です。下記のスクリーンショットでは1台しかドメインコントローラがない環境なので1レコードしか出ていませんが、通常の環境であれば複数台のドメインコントローラが出てきます。


また、他の方法として探し出した最初の一台のドメインコントローラへLDAP検索をかける、という方法もあります。

通常のActive Directoryドメインであれば、ドメインコントローラのコンピュータオブジェクトは「OU=Domain Controllers,DC=ドメイン名」というコンテナ配下に配置されているはずなので、ここをBaseDNとしてobjectClass=computerフィルタをつけてオブジェクト一覧を探しだします。

使うクエリは以下の通りです。
注意点としてLDAPにsimple bindで接続するユーザのIDはAD上のDNではなく、userPrincipalNameを使う必要があります。(username@domainname形式)
 ldapsearch -h dc.intra.ems.adfs20.net -p 389 -D "naohiro.fujie@intra.ems.adfs20.net" -w P@ssw0rd -b "ou=Domain Controllers,dc=intra,dc=ems,dc=adfs20,dc=net" objectClass=computer cn


ここでコンピュータオブジェクトのDNおよびCNが取得でき、CNがコンピュータ名です。


・ユーザ情報の格納場所を探す

次に、認証する対象のユーザがドメインツリー上のどの場所(OU)に格納されているのかについて情報を収集します。

先のドメインコントローラを探す方法の最後に紹介したLDAPクエリをかける方法を使います。
今回はBaseDNに先ほど取得したドメイン名をドメインコンポーネント(DC)毎に分割した値を指定します。例えば、intra.ems.adfs20.netだったらdc=intra,dc=ems,dc=adfs20,dc=netとなります。

次に、コンテナの階層が下位に存在することを想定して検索Scopeにsubを指定し、下位のコンテナ(OUなど)の下も検索する様にします。

最後にfilterとして、自分自身のユーザ名(sAMAccountName)を指定します。今回はユーザオブジェクトが格納されているOUを探すことが目的なので、全てのユーザを取得しなくても自分だけわかればある程度推測できるためです。

例えば、以下のようなクエリを使います。
 ldapsearch -h dc.intra.ems.adfs20.net -p 389 -D "naohiro.fujie@intra.ems.adfs20.net" -w P@ssw0rd -b "dc=intra,dc=ems,dc=adfs20,dc=net" -s sub sAMAccountName=naohiro.fujie cn



この結果、自分自身のDNがわかりますので、格納されているコンテナが推測できます。上記の図の例だと、「OU=User,OU=AADObjects,DC=intra,DC=ems,DC=adfs20,DC=net」がユーザオブジェクトが格納されているコンテナだと思われます。


・OpenAMの認証モジュールとして社内ADを指定する

ここまでくれば後は、OpenAMに取得した社内ADの情報を指定していくだけです。ちなみに、OpenAMはADに対して検索さえできればドメイン管理者権限などは無くても認証設定を行うことが出来ます。(AD側でアクセスの監査などをしていると怪しいアクセス記録が残るので疑われはすると思いますが)

ということで、パスワードの有効期限さえ気を付けていれば利用部門の管理者の方の個人ユーザ権限でADに接続する様にOpenAMを構成してしまっても問題はありません。


まず、先にセットアップを行ったOpenAMへ管理者でログオンし、[New Realm]をクリックしてレルム(認証領域)を作成します。トップレベルのレルムに設定を行っても問題はありませんが、管理者ページへのアクセスを除外するなど設定が面倒になるので、新規にレルムを構成する方が後から楽です。


レルム名は任意のもので大丈夫ですが、ここでは[AD]という名称を付けています。


作成が終わるとレルムが表示されるので、クリックして開いて詳細な設定を入れていきます。


左側のナビゲーションから[Authentication]-[Modules]を開き認証モジュールの構成を行います。



ここでもモジュール名は任意で構いませんので、[AD]という名称を付けていますが、Typeの項目では[Active Directory]を選択する様にします。


ここで、先に取得したADの情報を入力していきます。


設定項目設定値備考
プライマリ Active Directory サーバーdc.eidentity.adfs20.netドメインコントローラのFQDN。2台設定する場合はセカンダリドメインコントローラとして設定をすることも可能
ユーザー検索の開始 DNOU=Users,OU=Managed Objects,DC=eidentity,DC=adfs20,DC=netユーザを格納していると思われるコンテナ
バインドユーザー DNCN=test user01,OU=Users,OU=Managed Objects,DC=eidentity,DC=adfs20,DC=net接続するユーザのDN。一般ユーザで問題なし
ユーザープロファイルの取得に使用する属性sAMAccountName後述するデータストアとのマッチングに使用する属性名
認証するユーザーの検索に使用する属性sAMAccountNameOpenAMでのログインIDとして使用するAD上の属性名



次に認証チェインの設定を行います。OpenAMは認証モジュールを複数指定するプラグインモデルを採用しているので、実際に認証を行うためにどのモジュールを使うのかを認証チェインとして指定します。

左側のナビゲーションからChainsを開くと初期状態でldapServiceという認証チェインが設定されているので、ペンのアイコンをクリックして編集を行います。


初期状態でDataStoreが指定されているのですが、遠慮なく編集をしてしまいます。



設定画面の[Select Module]という項目で認証モジュールを選択することが出来るので、ここに先ほど作成した認証モジュール[AD]を指定して保存します。


これで認証設定は完了です。



いったんテストをしてみたいので、[Settings]-[ユーザプロファイル]を開き、ユーザプロファイルとの紐づけを[無視]に設定をします。まだデータストア設定をしていないので、認証後のデータストア内のユーザと紐づけることが出来ないためです。


ここまで来たら、ブラウザで
  http://openamserver:8080/openam/XUI/#login/&realm=AD
へアクセスし、AD上のユーザ名とパスワードでログイン出来るかどうかの確認ができます。(URLの最後にrelam=ADという形で作成したレルム名をつけます)


うまくいくと画面上部に「You have been successfully logged in」というメッセージが表示されます。



長くなってきたので、今回はここまでです。
次回はデータストアの設定を行うところから開始します。

[Internet Weekフォローアップ]デモ環境の作り方②

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

前回に引き続きInternet Weekのフォローアップです。

今回はOpenAMのデータストアとして社内ADを使えるようにしてみます。
  • 第1回:環境の説明、OpenAMの認証を社内ADで行う
  • 第2回(今回):OpenAMのデータストアとして社内ADを利用する
  • 第3回:OpenAMとG SuiteのID連携を行う
  • 第4回:OpenAMでDesktop SSOを設定する
  • 第5回:Azure ADとOpenAMと連携したままのG Suiteを連携する
  • 第6回:G SuiteのID連携先をOpenAMからAzure ADへ切り替える

◆OpenAMのデータストアとして社内ADを指定する

前回までで認証は出来るようになりましたので、ユーザデータの格納場所(データストア)として社内ADを参照する様に設定を行います。この設定を行うことにより、認証が完了したのち、ユーザの属性を取得してSAMLアサーションに乗せる、などということが可能になります。(G Suiteとの接続時、メールアドレスをNameIdとして指定するので、この設定を入れておく必要があります)


実施することは先の認証モジュールに対して社内ADの情報を設定していったのとほぼ同様です。

まずは、左側のナビゲーションから[Data Stores]を開きます。データストアの設定画面はOpenAM 13からのモダンなUIではなく12までのクラシックなUIになっており、いきなり古臭い感じの設定画面が表示されます。

ここで、[新規]をクリックして新規データストアを作成してきます。


データストア名称は任意で問題ありませんが、タイプには[Active Directory]を選択しておきます。


認証モジュールの時と同じように社内ADに関する情報を設定していきます。



設定項目設定値備考
LDAP サーバーdc.eidentity.adfs20.netドメインコントローラのFQDN。複数台設定することも可能
LDAP バインド DNCN=test user01,OU=Users,OU=Managed Objects,DC=eidentity,DC=adfs20,DC=net接続するユーザのDN。一般ユーザで問題なし
LDAP 組織 DNOU=Users,OU=Managed Objects,DC=eidentity,DC=adfs20,DC=netユーザを格納していると思われるコンテナ
LDAP ユーザー検索属性sAMAccountName認証モジュールに指定した「ユーザープロファイルの取得に使用する属性」と同じ値
LDAP ピープルコンテナネーミング属性空白デフォルトの値を消す
LDAP ピープルコンテナ値空白デフォルトの値を消す
認証ネーミング属性sAMAccountNameログインIDとして使用するAD上の属性名
LDAP グループ検索属性sAMAccountNameグループへの所属を探す際に利用する属性名(使用しないが、ログインIDの属性と合わせておく)
LDAP グループコンテナネーミング属性空白デフォルトの値を消す
LDAP グループコンテナ値空白デフォルトの値を消す
持続検索ベース DNOU=Users,OU=Managed Objects,DC=eidentity,DC=adfs20,DC=netユーザを格納していると思われるコンテナ


ここまで設定が出来たら元から存在している[embedded]というデータストアを削除してしまいます。



対象のタブを開き、AD上のユーザ一覧が取得できていることを確認します。



ここで再度テストをしてみたいので、認証されたユーザとデータストア上のユーザが紐づいているかどうか確認するためにプロファイルの紐づけ設定を行います。

先に[無視]と設定したAuthenticationのSettingsのプロファイルタブです。


先ほどと同様にAD上のユーザで以下のURLよりログオンします。
 http://openamserver:8080/openam/XUI/#login/&realm=AD

すると今度はログイン後にユーザのプロファイルが表示されます。


これでOpenAMへのログインとユーザデータの取得を社内ADと連携することが出来ましたので、一旦先ほどのプロファイル紐づけを解除しておきます。G Suiteへのログイン時のアサーション取得を行う際にプロファイル紐づけをしておくとエラーが起きることがあるためです。単に属性のマッピングをさぼっているだけなんですが・・・



◆OpenAMをSSL化する

少し寄り道です。

ここまでのOpenAMの設定はデフォルトの8080番ポートでのhttpでtomcatへ直接接続してきました。ところが、後々一般ユーザへOpenAMの利用を開放しようとするとhttpsでのアクセスをきちんとさせておきたいところです。

そこで、OpenAMの前段にApacheのHTTPサーバを置き、mod_sslでhttps化を行った上で、mod_proxyを利用してOpenAMに対するリバースプロキシを構成します。

やることはいたってシンプルで、「yum install mod_ssl」でmod_sslを組み込み、証明書と秘密鍵をしかるべき手法で取得、サーバ上へ配置してssl.confの設定をしてhttpdへ読み込ませます。

ファイルを配置したのち、ssl.confに以下を設定しています。
 サーバ証明書
  SSLCertificateFile /etc/pki/tls/certs/server.crt
 秘密鍵
  SSLCertificateKeyFile /etc/pki/tls/private/server.key

また、リバースプロキシはhttpd.confに以下の設定を入れてすべての通信を単純にOpenAMへ流しています。
 ProxyRequests Off
 ProxyPass / http://openam.adfs20.net:8080/
 ProxyPassReverse / http://openam.adfs20.net:8080/

上手く設定できていれば、http://openamserver:8080/openamではなく、https:/openamserver/openam」でもログイン画面が表示されるようになるはずです。



次回はいよいよG Suiteと連携してみます。

[Internet Weekフォローアップ]デモ環境の作り方③

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

前回に引き続きInternet Weekのフォローアップです。

今回はいよいよG Suite(Google Apps)とID連携を行い、SSO出来るようにしてみます。
  • 第1回:環境の説明、OpenAMの認証を社内ADで行う
  • 第2回:OpenAMのデータストアとして社内ADを利用する
  • 第3回(今回):OpenAMとG SuiteのID連携を行う
  • 第4回:OpenAMでDesktop SSOを設定する
  • 第5回:Azure ADとOpenAMと連携したままのG Suiteを連携する
  • 第6回:G SuiteのID連携先をOpenAMからAzure ADへ切り替える

◆G Suite(旧Google Apps)とのID連携を設定する

いよいよ佳境です。
利用部門で勝手に契約したG Suiteを、勝手に立てたOpenAMと接続していきます。

OpenAMでは初めからG Suiteとの接続が組み込まれているため非常に簡単です。
 手順としては、
 <OpenAM側>
  ・OpenAMをSAML IdPとして構成する
  ・トラストサークルを作成する
  ・G SuiteをSAML SPとして登録しトラストサークルへ組み込む
 <G Suite側>
  ・OpenAM側のSSOサービスのエンドポイントとアサーション署名用の証明書を登録する
という非常にシンプルなものです。
順番に実施していきます。

・OpenAMをSAML IdPとして構成する

作成したレルムのトップ画面から[Create SAMLv2 Providers]をクリックしてSAML関連の設定画面を開きます。



OpenAM自体をSAML IdPにしたいので[Create Hosted Identity Providers]をクリックして開きます。



メタデータ設定のレルムに先ほど作成したレルムを選択し、名前にはhttpdでリバースプロキシしたURL(実際は任意なのでなんでもよい)、署名鍵は[test]を選択します。
※実際は署名用の証明書をちゃんと作って設定してください。

また、トラストサークルには「新しいトラストサークル」の欄に任意の名前を設定し、トラストサークルを作成します。



SAML IdPの設定が完了するとGoogle Appsの設定が出来ますので、ここで[Google Appsを設定する]をクリックしてGoogle Apps用の設定を行います。

Google Apps側のドメイン名を指定する箇所がありますので、「google.com/a/ドメイン名」という形で契約したドメイン名を指定します。


するとGoogle Apps側に指定すべきURLと署名検証に利用する証明書のダウンロードが出来る画面へ遷移しますので、それぞれの項目をメモ、ダウンロードしておきます。



・G SuiteへOpenAMの情報を登録する

ここまで来たらもう一息です。
先ほどメモしたOpenAMの情報をG Suite側のSSO設定画面へ登録していきます。

セキュリティの設定ページを開き、「サードパーティのIDプロバイダでSSOを設定する」にチェックを入れ、ログインページのURL、ログアウトページURL、パスワード変更URLのそれぞれに先にOpenAM上で取得したURLを設定していきます。

この際に注意なのですが、OpenAMはhttpdでSSL化およびリバースプロキシされているのでOpenAMのURLを読みかえてG Suite側へ設定する必要があります。

変更すべき点はhttp⇒https、およびポートが:8080⇒なしです。

例えば、
  http://openam.adfs20.net:8080/openam
  https://openam.adfs20.net/openam
となります。

また、[ドメイン固有の発行元を使用]にはチェックを入れておいてください。



・OpenAMで発行されるSAMLアサーションのNameIDをGoogle向けにカスタマイズする

ここまででID連携の設定は完了しているのですが、シングルサインオンを実現するには、社内ADから取得したID情報と、Google上のID情報のマッチング(紐づけ)が出来る必要があります。

Googleは識別子としてメールアドレスを要求していますので、社内AD上の属性よりメールアドレスを取得してGoogle向けの識別子(NameID)としてSAMLアサーションを構成してあげる必要があります。


OpenAMの管理画面の上部より[FEDERATION]メニューを開きます。



すると先に設定したSAML IdPがエンティティプロバイダとして出てきますので、クリックして設定を変更します。


具体的な変更箇所は[NameID値マップ]で初期状態では
  urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified=uid
となっている行を削除して、
  urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified=mail
を追加します。

これは、Googleからの認証要求としてNameIDのフォーマットがunspecifiedという指定が来るので、OpenAMはunspecifiedのフォーマットで値を返そうとします。その際に設定する値としてuidではなく、mail属性の値を入れてあげる、という設定です。



・G SuiteへOpenAMを使ってログインする

ここまでくるとG SuiteへのログインはOpenAMへリダイレクトされるようになっていますので、例えば「https://mail.google.com/a/カスタムドメイン名」へアクセスするとOpenAMのログイン画面が表示されます。



ここで社内ADのユーザ名とパスワードを入力すると認証が行われ、G Suiteのサービスが利用できるようになります。




ここまでで、野良認証システムと野良クラウドが情シスの全く感知しないところで構成できたわけです。

次回は後々情シスへ巻取りをしてもう、そして利用者が利便性高く使うためにはもう一工夫しておきます。テーマはDesktop SSOです。



[Internet Weekフォローアップ]デモ環境の作り方④

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

前回に引き続きInternet Weekのフォローアップです。

今回はいよいよG Suite(Google Apps)とID連携を行い、SSO出来るようにしてみます。



◆デスクトップSSOを有効にする

最終的に情シスの管理するAzure ADへG Suiteとの連携・管理を移管していくことを考えると、利用者に対してOpenAMの存在が見えてしまうは得策ではありません。

ここは少しだけ情シスの人にも協力してもらって、統合Windows認証を有効にしてPCへのログインとOpenAMへのログインをシングルサインオン出来るように構成してみます。

この情シスの人への「少しだけ」のお願い事項は以下の2点です。
1.ドメインコントローラでktpassコマンドを実行してキータブファイルを作成してもらう
2.(オプション)パスワードが無期限のサービスアカウントを作成してもらう

※2番目についてはOpenAMがADへ問い合わせをするためのユーザのパスワードを無期限にしてもらった方が後々面倒が少ないから、という理由うなのでどちらでも構いません。

いずれにしてもドメイン管理者権限など情シスの人が嫌がりそうな手間は取らせません。

早速やってみましょう。

・キータブファイルを作成してもらう
以下のコマンドをドメインコントローラで実行してもらいます。

ktpass -out [ファイル名] -princ HTTP/[OpenAMサーバのFQDN]@[ADのドメイン名] -ptype KRB5_NT_PRINCIPAL -pass [OpenAM用ユーザのパスワード] -mapuser [OpenAM用ユーザ名] -target [ドメインコントローラのコンピュータ名]

例えば、以下のようなコマンドです。
ktpass -out desktopsso -princ HTTP/openam.adfs20.net@EIDENTITY.ADFS20.NET -ptype KRB5_NT_PRINCIPAL -pass P@ssw0rd -mapuser openam -target dc



結果、出来上がるファイル(例では、desktopsso)を入手してください。
このファイルをOpenAMがアクセスできる場所へ配置し、tomcatユーザで読み込めるように権限を設定します。

以下の例では、/usr/share/tomcat/openam/openam/へコピーし、chown tomcat:tomcat ./desktopssoでオーナーをtomcatユーザへ変更しています。




・認証モジュールを追加する
第1回で実施したのと同様に認証モジュールを追加します。

前回はTypeにActive Directoryを選びましたが、今回は[WindowsデスクトップSSO]を選択します。



各種設定項目には先ほどktpassコマンドで指定した項目をセットします。


先のコマンド例に従うと以下の表のような設定となります。

設定項目設定値
サービス主体HTTP/openam.adfs20.net@EIDENTITY.ADFS20.NET
Keytab ファイル名/usr/share/tomcat/openam/openam/desktopsso
Kerberos レルムEIDENTITY.ADFS20.NET
Kerberos サーバー名dc.eidentity.adfs20.net



ここまでで認証モジュールの設定は完了です。


・認証チェインの設定を行う
これも第1回で設定したのとほぼ同じ手順です。
新しく認証モジュールを設定したので、このモジュールを使って認証を行うように認証チェインの設定を行います。

新規に認証チェインを作成し、任意の名前を付けます。



認証モジュールに先に作成したデスクトップSSOのモジュールを、クライテリアには[Sufficient]を設定します。



こんな設定になるはずです。



後は、一般ユーザを認証するときにこのチェインを使うように設定するだけです。
Authentication Sttings -> Coreより組織認証設定(一般ユーザ向けの認証設定)に先ほど作成した認証チェインを指定します。


これでOpenAM側の設定は完了です。
念のため以下のコマンドでtomcatを再起動しておきます。

/bin/systemctl restart  tomcat.service


・OpenAMのサーバをイントラネットゾーンへ入れる
後はクライアント側の設定です。
IEやEdge、Chromeを使っている場合はインターネット設定のゾーン設定でOpenAMサーバをイントラネットゾーンへ配置します。FireFoxの場合はFirefox自体の詳細設定でゾーン設定を行います。(この辺りは適当に検索して方法を探してください)

ただ、個々にブラウザへ設定するのは結構手間なので、もう一つだけ情シスの人にお願いが出来るならば、グループポリシーで一括設定をしてもらうのも手段の一つです。
その場合は、
 ユーザーの構成
  ポリシー
   管理用テンプレート
    Windowsコンポーネント
     Internet Explorer
      インターネットコントロールパネル
       セキュリティページ
の中の[サイトとゾーンの割り当て一覧]でOpenAMサーバを値[1]で登録してください。



上手くポリシーがあたっていれば、ブラウザのゾーン設定でOpenAMサーバが確認できます。


・テストする
上手く設定できているか確認するために、OpenAMのログイン画面へアクセスしてみます。
https://openamserver/openam/XUI/#login/&realm=AD

先ほどはログイン画面が表示されましたが、今回はいきなりプロファイルが表示されるはずです。




もし上手くいかない場合は、OpenAMのデバッグログを確認してみてください。
デフォルトでは以下のディレクトリにあります。
/usr/share/tomcat6/openam/openam/debug


これが上手くいけば、当然G Suiteへのログインも出来ますので、PCへログインしてそのままブラウザを開き、Gmailへアクセスしてみてください。

ID、パスワードを入力することなくログインできるはずです。




ここまでで、Step 1のフロント部門で勝手にOpenAMを構築してG Suiteと連携する、という姿を実現することが出来ました。

次回からはいよいよStep 2の情シスとの連携開始です。

[資料&動画公開]Japan Web API Community #1 での Azure AD/OAuth2.0の話

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

先日の告知させていただきました通り、12/21に第1回が開催されたJapan Web API Communityで、私はAzure ADのOAuth 2.0の話をしてきました。


内容的には、先日監訳させていただいた「脱オンプレミス! クラウド時代の認証基盤 Azure Active Directory 完全解説」の第9章のAzure ADによるWeb APIの保護の部分のおさらいなんですが、書籍が出た時はADAL(Active Directory Authentication Library)のバージョンが2.xだったので、今回の資料・デモではADAL3.x系へコードを書き直しています。

スライド内にコードも記載しているので、書籍を読まれた方も参照いただけると良いと思います。(そのうち、変更点についてはまとめます)


ということで、スライドと動画です。
(時間とネットワークの帯域不足でデモはグダグダですみません)

◆スライド



◆動画




[Internet Weekフォローアップ]デモ環境の作り方⑤

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

引き続きInternet Weekのフォローアップです。ようやく残り2回です。

いよいよStep 2の情シスとの連携開始です。


前回まではあくまで利用部門で野良ITとしてG SuiteとOpenAMを構成し、利用者が社内ADのアカウントでシングルサインオン出来るようにしてきました。

今回は情報システム部門が重い腰をようやく上げ、Azure Active Directory(Azure AD)を契約し、これまで利用部門が独自で管理していたG SuiteのID管理やSSOを順番に巻き取っていきます。



では、早速始めていきましょう。

<Step 2>


◆Azure AD上にG Suiteを登録する

何はともあれ、情報システム部門がG Suiteを巻き取るにはAzure ADを使ってG Suiteを管理する必要があります。

そのためにはAzure AD上のエンタープライズアプリケーションとしてG Suiteを登録する必要があります。

AzureポータルよりActive Directoryを開き、エンタープライズアプリケーションの追加を選択するとギャラリーが開くので、Google Appsを選択して[作成]をクリックします。



◆既存OpenAMと連携したシングルサインオン設定を行う

最終的にはAzure ADを使ってシングルサインオンも行うように構成しますが、現在はOpenAMが存在しますので、十分なテストが完了するまでは、引き続きOpenAMを使っておきたいところです。

ただ、情シスが管轄している他のアプリケーションと同列で管理をしていきたいので、Azure ADでG Suite自体の管理を行うために既存OpenAMと連携する形でシングルサインオン設定を行っておきます。

クリックスタートより[シングルサインオンを構成する]を開きます。


シングルサインオンのモードとして、

  • Azure ADシングルサインオンが無効
  • SAMLベースのサインオン
  • パスワードベースのサインオン
  • リンクされたサインオン

がありますので、[リンクされたサインオン]を選択します。


サインオンURLにG SuiteのURLを入れることで既存でG Suiteに設定されているシングルサインオン(OpenAM)をそのまま使い続ける形でAzure ADと連携を行うことが出来ます。


取り敢えずこれでシングルサインオン設定は完了です。


◆ID管理(プロビジョニング)をAzure ADから行うように設定する

次はプロビジョニングです。これまで利用部門が手動でG Suite上のIDの作成、削除をしてきましたが、この部分をAzure ADから自動的に行います。(もちろんAzure ADは社内のADとAzure AD Connectを経由して同期されているので、社内ADのIDの作成・更新・削除がそのままAzure ADを経由してG Suiteまで反映されるようになります)

この部分が利用部門の一番の負荷となっていた部分なので、これをやるだけでも相当大きなメリットがあります。

まず、Azure AD上の対象となるユーザに対してG Suiteを割り当てる必要があります。
Azure AD Premiumのライセンスがあるとグループベースでの割り当てが出来るのですが、今回用意したテナントは無償版なので、個別にユーザを割り当てる必要があります。

具体的には[ユーザとグループにシングルサインオンをデプロイする]というよくわからないメニューで割り当てを行います。




対象のユーザを選択します。


次に、G Suiteに対するプロビジョニングを有効にします。

まず、G Suite側でAPI管理を有効にしておきます。この設定を行うことでDirectory APIなどを使ってG Suite上のユーザやグループを外部から操作することが可能になります。


ここまでできたらAzure ADにG Suiteに対するプロビジョニング設定です。
今回行いたいのは、
・プロビジョニングの実行(作成・更新・削除)
・プロビジョニング属性のカスタムマッピング
です。

特に今回はAzure ADのドメイン名とG Suiteのドメイン名が異なっているので、デフォルトのマッピングだとAzure ADのuserPrincipalNameとG SuiteのLoginIDがアンマッチとなり正常にプロビジョニングされません。

そこで、社内のADのmail属性にG Suiteで使うメールアドレスをセットし、その値をAzure AD経由でG SuiteのLoginIDとマッピングすることで連携を行います。

まずは、プロビジョニングの有効化です。
これまたわかりにくいメニュー名[Google Appsでテストユーザを作成する]を開いてプロビジョニングモードを[自動]に設定します。

ここでG Suiteとの連携を行うためにAzure ADに対して管理権限を委譲します。


ここで[承認する]をクリックするとポップアップでG Suiteに対する管理権限の委譲に同意を求められるので、同意します。(G Suiteの管理権限を持つユーザでログインをします)


これで一旦保存をすると属性のマッピングを変更できるようになります。

ユーザの属性マッピングを開き、userPrincipalNameをLoginIDにマッピングしている行を選択して、ソース属性をuserPrincipalNameからmail属性に変更し保存をします。


尚、新ポータルでマッピングを変更しようとするとエラーが起きることがあります。その場合はクラシックポータルを使ってマッピングを変更してください。


これで設定は完了です。


◆プロビジョニングを実行する

プロビジョニングを[オン]にしてG Suiteへプロビジョニングを実行します。
少し時間がかかるので、ゆっくり待ちましょう。


上手くいくとG Suite上にユーザが新規に作成されます。
尚、一度もログインしたことのない新規ユーザは[停止中のユーザ]として作成され、初回ログインを行うとアクティブに変更されます。



これでID管理とシングルサインオンの両方がそろったことになりますので、テストをしてみます。

◆Azure ADを経由してアクセスしてみる

Azure ADにG Suiteを登録したとはいえ、実際にシングルサインオンを行うのはOpenAMです。しかし、Azure ADに登録したことにより、Azure ADに登録された他のアプリケーションと同列でアプリケーションへのアクセスを管理することが可能になります。

具体的には利用者からアクセスできるアクセスパネル(https://myapps.microsoft.com)から利用可能なアプリケーションとして参照・アクセスすることが可能になります。



情シスが管理している他のアプリへのシングルサインオンは当然可能です。



同じようにG Suiteへアクセスすると一瞬OpenAMへアクセスしますが、Desktop SSOが有効なのでそのままシングルサインオンされ、シームレスにログインすることが可能です。



もちろんこれまで通り、G Suiteへ直接アクセスした場合はOpenAMでシングルサインオンされますので、利用者から見た使い勝手は全く変化ありませんが、これでID管理の統合、およびほかのアプリケーションとのシングルサインオンなど、少し幅が広がりました。


次回は野良ITだったOpenAMをいよいよ撤廃してAzure ADへ一本化していきますが、利用者がほぼ気が付かない状態で移行していくのが大きなポイントとなります。

MVP Renewal 8th!!

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

長いもので、8年目です。
引き続きEnterprise Mobilityという分野での受賞となります。



昨年は「日本におけるIDaaS元年」を目指し、書籍の監訳や各種カンファレンスやコミュニティ・イベントへ参加・登壇など様々な活動をさせていただき、かなり忙しい一年となりました。

今年はもう少し範囲を広げてグローバルに活動できるといいなぁ、と思っていますので皆様引き続きよろしくお願いいたします。

手始めに、英語版のBlogも始めてみます。コンテンツはこれから充実させていきたいと思います。

IdM Laboratory
http://idmlab-e.eidentity.jp/



[Internet Weekフォローアップ]デモ環境の作り方⑥

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

引き続きInternet Weekのフォローアップです。いよいよ最終回です。

利用部門で勝手に構築したOpenAMを完全に撤廃して、情シス管理のAzure Active Directory(Azure AD)にすべてをゆだねます。


すでに前回、G SuiteへのID管理(プロビジョニング)はAzure ADで実施する様に構成し、シングルサインオンについても経過期間ということでOpenAMと連携する様に設定を行いました。

今回はG SuiteとOpenAMの連携を解除し、Azure ADと直接連携することでOpenAMを使わないようにします。

では、早速初めて行きます。

<Step 3>

◆G SuiteとAzure ADのシングルサインオン設定をSAMLベースへ変更する

前回は、既存のOpenAMを活用するためにAzure AD上に登録したG Suiteのシングルサインオン設定に「リンクされたサインオン」を選択しましたが、今回からはG SuiteとAzure ADを直接連携させるため、ここの設定を「SAMLベースのサインオン」へ変更します。


SAMLを使って連携する属性を編集します。
今回、メールアドレス属性にGoogleで使うログインIDが入っていますので、ユーザ識別子として「user.mail」を指定します。


また、デフォルトでgivenNameやsurNameなどがAttributeStatementに含まれるように構成されますが、日本語の値が入っているとGoogle側でエラーになるので、不要な属性は削除しておきます。

この辺りは以前紹介した注意事項を参照してください。




次にSAMLアサーションに署名するための証明書を作成します。


注意)ここで証明書をダウンロードしてG Suiteへアップロードするのですが、現在新ポータルでダウンロードした証明書をアップロードするとG Suiteがエラーを出しますので、ここだけクラシックポータルへアクセスして証明書をダウンロードしてください。

G Suiteの出すエラー

クラシックポータルでの証明書ダウンロード

後は、G Suiteへ設定するAzure AD側のエンドポイント情報を確認します。
Google Appsの構成メニューを選択すると右側に設定すべきエンドポイントの情報が出てきますので、これをコピーしておきます。



◆G Suite側の設定を更新する

ここまでくればあとは、G Suite側へ設定を入れるだけです。
先ほどメモしたログインページのURL、ログアウトページのURL、パスワード変更URLを入力し、証明書をアップロードします。



尚、この設定を行っている間(Azure ADで設定変更~保存、G Suite側の保存)はシングルサインオン設定がAzure ADとG Suite側でズレているので利用者へ影響が出ますので、事前にアナウンスをしてから実施する様にしましょう。


◆動作確認を行う

これで、設定は完了です。
後は動作確認をしてみます。

ドメイン参加したPCでアクセスパネル(https://myapps.microsoft.com)へアクセスします。
Azure ADと連携されたドメインに参加しているので、Desktop SSOが有効なのでAzure ADのログイン画面が表示されることなくパネルへアクセスできます。


ここでGoogle Appsをクリックし開くとシングルサインオンされます。この際、前回までの構成だと一旦OpenAMへアクセスしていましたが、今回からは直接Azure ADと連携しているのでOpenAMを経由することなくG Suiteへアクセスしていることがわかります。

※もちろん、アクセスパネルを経由せずに直接G SuiteへアクセスしてもDesktop SSOが実行されるので、ユーザは何も意識することはありません。



後は、OpenAMを停止するだけです。
ようやく利用部門が抱えていた認証基盤およびアプリケーションの管理がすべて情報システム部門へ移管されました。

めでたし、めでたし。

◆最後に

今回、Internet Week向けのデモということであまり情シス目線だけに閉じたものはやめておこうというコンセプトで今回のコンテンツを作成しました。
また、オーディエンスが技術者の方が中心ということもあり、家に帰ってすぐに試せるもの、というのも大きなテーマでしたので、あえてOpenAMを引っ張り出してきました。


なかなか実世界では考えにくいシナリオだったかもしれませんが、技術要素としてのSAMLやKerberosを使ったDesktop SSOなどは覚えておいても損はありませんので、少しでもエッセンスが伝われば幸いです。






CentOS+Apacheの認証をAzure AD/OpenID Connectで行う

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

某普通な人がnode.jsとPAMを使ったApache+Azure ADの認証(Basic認証)の記事を書いていたので、そういえばPingIdentityの人が作ってるmod_auth_openidc使ってなかった事を思い出したのでやってみました。

 参考)割と普通なブログ
  Linux+Apache の認証で Azure Active Directory を利用する
  http://normalian.hatenablog.com/entry/2017/01/08/031209


やりたいことは、CentOSにホストされたApache上のWebコンテンツへのアクセスAzure ADで保護する、という非常にシンプルなシナリオです。
※意外と実案件でもこの手の引き合い多いんですよね。オンプレのWebサーバでスタティックコンテンツの場合はAzure AD WAP(Web Application Proxy)で提案しちゃうことが多いんですけどね。

◆環境(必要なもの)

CentOSは手元に転がっていたVMをそのまま流用しました。
uname -aの結果はこんな感じ。ちなみに面倒なのでSELinuxとFirewallは無効にしてあります。
[root@oidc conf]# uname -a
Linux oidc.eidentity.local 3.10.0-514.2.2.el7.x86_64 #1 SMP Tue Dec 6 23:06:41 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

mod_auth_openidcは最新版(2.1.3)のrpmが以下からダウンロードできますが、色々と前提となるパッケージなどを入れる必要があったので、ついでにソースからコンパイルしてしまいました。
 https://github.com/pingidentity/mod_auth_openidc/releases

以下が必要となるパッケージ群です。

yumでインストールするもの。(*-develがこんなに必要だったのはコンパイルしたからです)

  • git
  • httpd-devel
  • curl-devel
  • jansson-devel
  • openssl-devel
  • autoconf
  • automake

rpmでインストールするもの
  • cjose-0.4.1-1.el7.centos.x86_64.rpm
    • mod_auth_openidcと同じくここからダウンロードできます。
ソースからコンパイルするもの

  • hiredis
  • mod_auth_openidc


◆モジュールの導入手順

上記に記載したyumでインストールするものをyum installでまずはインストールします。
手順は書くまでもありませんが、以下の通りです。(だいぶ省略してます)
#yum install git
# yum install httpd-devel
# yum install curl-devel
# yum install jansson-devel
# yum install openssl-devel
# yum install autoconf
# yum install automake

同様にrpmでインストールするcjoseについても導入します。
# rpm -i cjose-0.4.1-1.el7.centos.x86_64.rpm


最後にコンパイルするモジュール群です。
まずはHiredisです。githubのレポジトリをクローンしてmakeします。
適当なディレクトリで以下のコマンドを実行します。
# git clone http://github.com/redis/hiredis
# cd hiredis
# make
# make install


そして、本命のmod_auth_openidcです。こちらもHiredisと同じくgit cloneして最新のソースを元にインストールしていきます。
git clone https://github.com/pingidentity/mod_auth_openidc/releases
cd mod_auth_openidc
./autogen.sh
./configure
make
make install

これで、/etc/httpd/modulesにmod_auth_openidc.soが出来上がります。


◆設定手順

設定は大きくは2つに分かれます。
 1つ目は、Apache自体にmod_auth_openidcを組み込む
 2つ目は、mod_auth_openidc自体の設定と対抗となるAzure ADへのクライアント登録
です。

順に解説していきます。

1.Apache自体にモジュールを組み込む

単純に出来上がったモジュールをロードします。
今回は認証関係のモジュールを読み込んでいる/etc/httpd/conf.modules.d/00-base.confへ以下を追記しました。
LoadModule auth_openidc_module modules/mod_auth_openidc.so



次に、保護対象とするコンテンツを決めていきます。
今回は単純にOpenID Connectを使ってAzure ADからアイデンティティ情報が取れていれば良いので、cgi-binディレクトリを保護対象として、環境変数にid_tokenの中身がちゃんと入ってきているかどうかを確認したいと思います。

/etc/httpd/conf/httpd.confに以下を追記します。
<Location /cgi-bin/>
AuthType openid-connect
Require valid-user
</Location>


もちろん、/var/www/cgi-binへテスト用のcgiファイルを置き、実行権限を付ける必要はあります。
今回は単純に環境変数を見たいだけなので、以下のスクリプトを置いています。
#!/bin/perl
print "Content-type: text/html\n\n";
print "<TABLE BORDER=\"1\">\n";

for $key (sort(keys(%ENV))) {
print "<TR><TD><TT>$key</TT></TD><TD><TT>$ENV{$key}</TT></TD></TR>\n";
}

print "</TABLE>\n";
exit;


2.モジュールの設定(RPとしての設定)とAzure ADの設定(IdPとしての設定)

まず、Azure ADへクライアント登録を行います。

RPへ登録するために欲しい情報は、

  • client_id
  • client_secret

の2点で、これらはAzure ADへアプリケーション登録をすることにより取得が可能になります。

また、Azure ADへアプリケーション(つまりはOAuthクライアント)を登録する際に必要なのは、redirect_uri(アプリケーションのURL)です。

アプリケーションの追加をすると以下のパラメータを聞いてきますので、それぞれを設定します。

  • アプリケーション名: 任意の名前
  • アプリケーション・タイプ: Web app / APIを指定
  • サインオンURL: アプリケーションのURL(今回はhttp://oidc.eidentity.local/cgi-bin/にしています)
登録が終わると以下のダッシュボードが表示され、この中にあるアプリケーションIDがApache側へ設定するclient_idとなりますので、コピーしておきます。


次はclient_secretです。
ダッシュボードのAll settingsからキーを選択して新規にキーを生成し、保存をクリックすると表示されるのがclient_secretです。画面を遷移すると二度と表示できないので、ちゃんとコピーしておきます。


基本的にこれで情報はそろうのですが、最後にもう一つ。
mod_auth_openidcがリダイレクトしたり通信するIdPのエンドポイント情報を取得するためのメタデータURLが必要となりますので、これを確認しておきます。

以下のURLなので特に気にすることもありませんが、覚えておきます。
 https://login.windows.net/{ドメイン名}/.well-known/openid-configuration


では、最後となるhttpd.confへの設定追加をしていきます。
必要なのは以下のパラメータです。

  • OIDCProviderMetadataURL: Azure ADのメタデータURLを指定
  • OIDCClientID: Azure ADに登録したクライアントIDを指定
  • OIDCClientSecret: Azure ADに登録したクライアントシークレットを指定
  • OIDCRedirectURI: Azure ADに登録したアプリケーションのURLを指定
  • OIDCScope: スコープを指定。openid email profileあたりで問題なし
  • OIDCCryptoPassphrase: 必須なので適当にしてい


こんな感じになります。

OIDCProviderMetadataURL https://login.windows.net/pharaoh.onmicrosoft.com/.well-known/openid-configuration
OIDCClientID 0fa5bfc6-61da-47c1-9223-02f136594d09
OIDCClientSecret 6/2TYCeboBUgDB7rluxFmpLE8fYL45zgwhk38RTY5/E=
OIDCRedirectURI http://oidc.eidentity.local/cgi-bin/
OIDCScope "openid email profile"
OIDCCryptoPassphrase Password



これで設定は完了です。
早速テストしてみます。

◆動作確認

単純に先ほどAzure ADで保護したcgiにアクセスしてみます。

いきなりAzure ADのログイン画面へリダイレクトされますので、ログインします。

するとプロファイルへのサインインとアクセスに関する同意が求められるので同意します。


同意すると、cgiへリダイレクトされ、正しくアイデンティティ情報が取得できているのがわかります。
(OIDC_CLAIM_*という環境変数がid_tokenから取得された情報です)



かなり構成も簡単なので、レガシーなWebコンテンツやCGIなどが残っている場合は、今回紹介した方法でAzure ADとの連携を導入してみてはいかがでしょうか?


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

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

OneDrive for Business上のコンテンツやSharePoint Onlineのチームサイトを他組織のユーザと共有をするB2Bシナリオで利用している企業・組織が増えている中、Office365(およびそのID基盤であるAzure AD)の構造上の問題により、意図しないアクセス権を外部ユーザへ付与してしまう場合があるので、注意喚起の意味で本エントリを書きます。

現在、この課題については米国マイクロソフトのAzure AD開発チームへエスカレーションしており早期の改善を求めていますが、場合によっては長期化する可能性もあるため、自組織でOffice365を管理しており、外部ユーザとのコンテンツ共有をエンドユーザへ開放している管理者は一読の上、対応を行うことをお勧めします。
(いわゆる製品やサービスの脆弱性の類ではないため)


◆課題の概要

OneDrive for Business上のコンテンツ共有やSharePoint Onlineのチームサイトへの招待を受けた外部ユーザは、共有されたコンテンツ以外にも、「Azure AD上ですべてのユーザに対して割り当てを行われたアプリケーションや、Azure Portalを経由したディレクトリ情報へのアクセスが許可されてしまいます。かつ、事前に共有した本人および管理者がこのことに気が付くことはほぼ不可能です(どこにもそのような記述はないため)」。

これは招待されたユーザが自組織でOffice365やAzure ADを使っておらず個人でマイクロソフトアカウントを使っている場合においても発生します。


◆実際の動き

実際にどのような動きになるのか、動画を撮っていますので、まずはこちらをご覧ください。
わかりにくいですが、以下が環境です。

<組織「eIdentity」:招待する側>
・Office365を運用しています
・一般ユーザ「test001@ems.adfs20.net」でOneDrive for Businessで外部ユーザ「test001@gapps21.adfs20.net」に対してコンテンツを共有します
・Azure AD上で「ts2016」というアプリケーションをAll Usersグループに対して公開しています

<組織「InternetWeek」:招待される側>
・Office365は使っていませんが、Azure ADを利用しています
 (マイクロソフトアカウントの場合も同じ動きになります)
・「test001@gapps21.adfs20.net」という一般ユーザが所属しています




単純にeIdentityテナントのユーザでOneDrive for Businessでフォルダを共有しただけなのに、共有前はInternetWeekテナントのユーザがアクセス出来なかったts2016アプリへアクセスが出来てしまい、かつAzure Portal経由でeIdentityディレクトリの構成情報(ドメイン一覧)が参照できてしまっています。
※アプリケーションのURLを知らなくてもアクセスパネル(https://myapps.microsoft.comへアクセスすると利用できるアプリケーション一覧が表示されてしまいます。
※SharePoint Onlineのチームサイトへの招待の場合は、アプリケーションアクセスは出来ませんが、Azure Portal経由でのディレクトリ情報の参照は可能な状態になります。
(「All Usersグループ」へ自動追加されないため)


ディレクトリ上(ドメイン一覧)の参照


アプリケーションへのアクセス

上記のスクリーンショットはいずれもゲストユーザによりアクセスした状態で撮っています。


管理者としては、特定のコンテンツのみの共有なら、、という気持ちで許可した外部共有がこのような形で他の情報へのアクセスへ影響を与えるということは意図していないことが多いと思われるため、非常に大きな問題となる可能性があります。


◆なぜ発生するのか

OneDrive for BusinessやSharePoint Onlineで外部ユーザを招待すると、招待されたユーザが招待したOffice365側のAzure AD上にゲストユーザとして登録されます。
これはAzure AD B2Bで外部ユーザを招待するのと同じ動作であり、Office365が内部的にAzure AD B2Bの機能を利用しているために発生しています。

そして現状では、ゲストとして登録されたユーザは、
1.ディレクトリへのサインイン(認証)
2.ディレクトリ上の自プロファイルへのアクセス
に加えて、
3.ディレクトリ構成情報へのアクセス(少なくともドメイン一覧の参照)
4.(場合により)All Usersグループへの自動登録
が行われてしまいます。

1、2については本来のゲストユーザとしてアクセスを行うために最低限必要な機能なので、仕方がありませんが、問題は3、4です。


◆Office365/Azure ADの内部構造の課題

ここまで見てきたとおり、Azure ADにゲストとして登録された外部ユーザが想定以上に権限を持ってしまっていることが根本的な課題です。
少なくとも、
・自プロファイル以外のディレクトリ情報へのアクセス
・ディレクトリに登録されたアプリケーションへのアクセス
はデフォルトでは禁止されるべきでしょう。

早々にマイクロソフトが対応してくれることを望みます。


◆推奨される対応

このような状況なので管理者が出来ることと出来ないことがあるのですが、少なくとも以下の対応をしておくべきでしょう。

1.ゲストユーザが自ディレクトリ上に存在するかどうかの確認

まず、自ディレクトリ上にゲストユーザが存在しているかどうかは定期的に確認をしておくべきでしょう。
以下のAzure Active DirectoryのPowerShellを使い、以下のコマンドレットを実行することでゲストの存在を確認できます。
Get-MsolUser | Where-Object { $_.userType -eq 'Guest' }



2.All Usersではなく、自ディレクトリ上の本来のメンバだけが含まれるグループの作成

動的メンバシップグループをカスタムで作成し、userType=Memberのユーザだけが所属する様に構成することで自ディレクトリ上で作成されたユーザのみが含まれるグループを作成することが可能です。


逆にuserType=Guestだけが含まれるグループを作成するとゲストだけが含まれるグループを作成することが出来ます。



3.All Usersグループへ割り当てられているアプリケーションの割り当て変更

All Usersグループへのアプリケーション割り当ては非常に便利なので使ってしまいがちなのですが、ここは先の2で作成したメンバだけが所属しているグループへの付け替えを検討しましょう。

こうしておけば、Azure ADからプロビジョニングを行っているアプリケーションであっても、ゲストユーザはプロビジョニングされませんし、アクセスパネル(https://myapps.microsoft.com)にもアプリケーションは出てきませんので安心です。

<変更前>

<変更後>



4.アプリケーション側でしっかり認可を行う

この問題は最終的にはアプリケーションの作りに依存するので、認証されただけでは利用できないようにアプリケーションを構成する(きちんと認可する)ことが最も大切です。

例えば、今回の動画の中でアクセスしている「ts2016」というアプリケーションはディレクトリ上にユーザが存在していれば使える、という簡易な実装にしてしまっているためゲストであっても使えてしまいます。

しかし、アプリケーション側の実装で、認証されてアクセスしてきたユーザへのアクセス制御を他の属性(所属など)を用いてしっかりと管理を行うことで、少なくとも重要なデータへのアクセスを防ぐことが出来ます。

5.ポータルへのアクセスを禁止する(要注意:影響度大)

設定を間違えると管理者でさえ管理ポータルへアクセスできなくなったり、他のAPIを使うアプリケーションへのアクセスが一切できなくなるので、この設定を行う場合は十分にテストを行った上で慎重に実施してください。著者は一切責任をとれません。

かなり強引なやり方ですが、条件付きアクセスを利用してゲストユーザからWindows Azure Service Management APIへのアクセスをブロックしてしまえば管理ポータルへのアクセスが出来なくなります。

以下の条件付きアクセスポリシーを作成します。
・Users and groups:All Guests(先ほど作成したゲストだけのグループ)
・Cloud apps:Windows Azure Service Management API
・Grant:Block access
・Enable policy:On






このポリシーを有効にすると、管理ポータルへアクセスしようとするとアクセスがブロックされます。

ディレクトリを切り替えようとすると、

アクセスがブロックされます。

◆今後の対応

現状、この動作はサービスの仕様の問題であり、いわゆるバグ等の不具合には該当しないためサービスのエンハンス要求を挙げている状態です。

この状態で出来ることは管理者の自衛が中心となりますので、動作および自テナントの状態をよく理解して運用をしていってください。

今後、動作に変更などあれば本ブログでも更新情報を発信していきたいと思います。

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

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

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

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

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

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







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

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

そう言えば昨年秋に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は比較的安価で手に入りますし、手軽に使うには良いかも知れませんね。

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

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

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回ほど登壇させていただく機会を頂きましたので、また日程が近づいたら告知させてもらおうと思います。


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

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

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

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

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

明治大学の情報セキュリティ研究室が公開している「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ですが、上手に使えば便利で安全な仕組みなのできちんと理解をして使っていきたいですね。

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

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

先日のポストで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/

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

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

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

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

普段、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の名前が解決できる証明書を用意しなければいけなかったりするので、手元で済ませられれば手軽なのでこういう方法もありかな~と思っています。

[Azure AD]PingAccess連携でオンプレ資産へのアクセスを拡張する

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

待ちに待ったPingAccess+Azure AD連携のパブリック・プレビューが始まりました。
昨年のTechSummitで少しだけ紹介しましたが、当時はプライベート・プレビュー段階だったのでお見せ出来ず。。。

アナウンス
 公式blog
 PingAccess for Azure AD: The public preview is being deployed!
 https://blogs.technet.microsoft.com/enterprisemobility/2017/03/22/pingaccess-for-azure-ad-the-public-preview-is-being-deployed/


簡単に言うと、Azure AD Web Application Proxy(Azure AD WAP)を経由してPingAccessのサーバをインターネットへ公開、PingAccessのリバースプロキシ配下のアプリケーションへアクセスを可能にする、という構成が取れるようになります。

このことにより、これまでAzure AD WAPではバックエンドのアプリケーションは統合Windows認証が前提だったのが、HTTPヘッダ認証のアプリケーションなどPingAccessが対応している認証方式のアプリケーションであれば外部に公開することが出来るようになります。


とりあえず今回はHTTPヘッダ認証を使ったアプリケーションとの連携を公式ドキュメントの手順+αでやってみたいと思います。
(ちなみに公式ドキュメントが一部間違っているので・・・)

参考手順はこちら
 Azure AD側
 https://docs.microsoft.com/en-us/azure/active-directory/application-proxy-ping-access

 PingAccess側
 https://docs.pingidentity.com/bundle/paaad_m_ConfigurePAforMSAzureADSolution_paaad43/page/pa_c_PAAzureSolutionOverview.html


では早速。

◆Azure AD WAP経由で公開するオンプレミスアプリケーション定義を作成する

通常のAzure AD WAPでオンプレミスアプリケーションを公開するのと同じ手順で、PingAccessサーバを公開します。この段階ではPingAccessはまだダウンロード・インストールはしていないので内部URLなどは適当なものを設定しておき、あとで修正しても問題ありません。

Azure ADポータルよりエンタープライズアプリケーションの登録を行います。アプリケーションの種類は「オンプレミスのアプリケーション」を指定します。

内部URL、公開URL、認証方式などの設定を以下の通り行います。

  • 内部URL
    • Azure AD WAP ConnectorからアクセスできるPingAccessサーバのURLです。今回はPingAccessとConnectorを同じサーバにインストールしたので、https://localhost:3000としています。
    • 尚、公式ドキュメントでは内部URLにもアプリケーションパスを追加する、とありますが、Azure ADで認証された後、認可コードをPingAccessサーバのコールバックエンドポイントへGETで渡す必要があるので、アプリケーションパスを追加するとコールバックエンドポイントへアクセスできず、うまく動かないのでパスを追加してはいけません。
    • また、PingAccessサーバがhttpsで動いているので、Connectorサーバからのアクセス時に証明書エラーが起きないように、一旦ConnectorサーバでPingAccessサーバへアクセス、証明書をインストール、エラーが起きない状態にしておく必要があります。
    • 公開URL
      • ここは適当に設定します。後で使うので値は覚えておきましょう。
    • 事前認証
      • Azure ADで認証するので当然Azure ADを選択します。
    • ヘッダーのURL変換
      • 「いいえ」を選択します。
    • コネクタグループ
      • PingAccess用のAzure AD WAP Connectorが属しているコネクタグループを選択します。
    こんな感じです。


    次にシングルサインオン設定を行います。
    これまで出てこなかった、「Header-based Sign-on」が認証方式として選択できるようになっているので、これを設定します。
    ※ちなみにテナントによっては出てこない場合があるので、その場合はPreview版のAzure ポータルからAzure ADにアクセスしてみてください。私の環境では一度Previewポータルで設定をしたら次からは現ポータルでも出てくるようになりました。
     Preview版ポータルは
     もしくは、
     あたりからアクセスできます。

    Header-based Sign-onを選択するとPingIdentityのロゴとともに、PingAccessのダウンロードサイトへのリンクが出てきますので、アクセスします。

    リンクを開くとPingIdentityの登録サイトへ行くので名前などを登録します。

    登録するとメールが届き、その中にモジュールとライセンスのダウンロードページへのリンクが入っているのでアクセスします。リンクは7日間有効だそうです。

    ここで各プラットフォーム用のモジュールとライセンスのダウンロードができます。
    ちなみに、普通のPingAccessのサイトからダウンロード(現時点では4.2.2)できるモジュールとこのサイトからダウンロードできるモジュール(4.3.0BETA)は別物なのでここからダウンロードしてください。(そのうち統一されるとは思いますが)

    ◆PingAccessがAzure ADからid_tokenをするためクライアント登録を行う

    PingAccessはAzure ADから渡されたid_tokenの中のClaimをヘッダにマッピングするだけなので、先ほど作成したアプリケーションにscopeの設定、client_idとclient_secretの取得をしておく必要があります。

    先ほどはエンタープライズアプリケーションの設定メニューでしたが、この設定を入れるにはアプリの登録メニューから操作を行う必要があります。
    アプリの登録メニューから先ほど作成したエンタープライズアプリケーションを探して開きます。

    まずはAPIアクセスの許可です。
    • 対象API
      • Windows Azure Active Directory
    • 必要なスコープ
      • アプリケーションへのアクセス許可
        • Read and write all applications
      • 委任されたアクセス許可
        • Sign in and read user profile

    次にclient_secretの作成です。Azure AD用語ではキーですので開いて作成・保存します。

    保存するとキーが表示されるので、控えておきます。
    同様にclient_idはアプリケーションIDなのでこの値も、そしてディレクトリID(Active Directoryのプロパティから確認できます)を控えておきます。

    ここまででPingAccessの設定に必要な情報はそろいました。
    尚、公式手順を見るとReply UrlにAzure AD WAPの外部URLが設定されていることを確認し、必要に応じて手動設定すること、という説明がありますが特に問題なく自動設定されました。

    ◆PingAccessのインストールとライセンス設定

    いよいよPingAccessのインストールと設定です。先ほどのPingIdentityのページよりダウンロードしたモジュールを使います。
    今回はWindows Server 2016のサーバにAzure AD WAP Connectorと同居する形でインストールしました。

    MSIモジュールを実行すると以下の通りインストールが走ります。基本的には次へ、次へでOKです。ちなみに事前にJRE1.8以降がインストールされておりJAVA_HOMEが環境変数に設定されている必要があります。

    とりあえずスタンドアロン版にしていますが、プロダクション環境ではクラスタを作ることになると思います。







    取り敢えずインストールは簡単ですね。
    次は設定を行います。

    まずはブラウザで管理コンソールへアクセスします。デフォルトインストールだと
     https://サーバ:9000/
    でアクセスできます。

    初回アクセスの場合、ライセンスのアップロードが求められるので先にダウンロードしたライセンスファイル(zip)を解凍して出来るlicファイルを選択してアップロードします。

    上手くライセンスが登録されると、管理者でログインが求められます。
    初期状態ではID:Administrator、パスワード:2Accessでアクセスできます。

    初回ログインが成功するとパスワード変更が求められますので適当に変更しておきましょう。

    これでようやく管理コンソールが開きます。


    ◆PingAccessとAzure ADの連携設定、バックエンドアプリへのプロキシ設定を行う

    いよいよAzure ADとの連携設定です。

    まず、SystemメニューよりTOKEN PROVIDERを開きます。

    流石専用版、ISSUERに最初からAzure ADのURLが固定で入っているので、先ほど確認したディレクトリIDを設定してSAVEします。

    次に、VirtualHostの設定です。要するにAzure AD WAPからアクセスが来た場合の挙動の設定をするための入れ物です。

    HOSTに先ほどAzure AD WAPの設定の時に指定した外部URLのホスト名パートを設定し、PORTには443を設定しておきます。

    次は、WEB SESSIONの指定をします。Azure ADから取得したid_tokenを使ってセッションを生成するので、先に取得したclient_id、client_secretはここで使います。


    NAMEは適当に、COOKIE TYPEはSigned JWT、AUDIENCEはCookie名になるのでそれなりの値を設定します。

    次に先ほどAzure ADで取得したclient_idとclient_secretを指定します。


    次は、id_tokenから取得したClaimをヘッダへ変換するためのマッピング設定を行います。IDENTITY MAPPINGから設定していきます。

    TYPEにHeader Identity Mappingを設定して、、

    id_tokenの中のClaim名とヘッダ名をマッピングしていきます。


    ここまででAzure ADとの連携部分は終わりなので、後はバックエンドサーバの設定をしていきます。まずはSite設定です。Sitesメニューを開き、Add Sitesをクリックします。

    ここが実際のバックエンドサーバのアドレスやURLを入れる部分なので、今回は手元にあったCentOSのApache CGIを指定してみたいと思います。
    適当な名前を設定して、TARGETSにサーバアドレスを指定します。


    最後にここまでに設定してきた内容を組み合わせてPingAccess上でApplicationとして定義を行います。Applicationsメニューを開き、Add Applicationをクリックします。

    名前は適当に。CONTEXT ROOTにはリバースプロキシとしてのパス設定なので、バックエンドアプリケーションのパスを指定します。今回はcgiを動かしてみようと思うので、/cgi-binを公開します。

    後は、VIRTUAL HOST、WEB SESSION、SITEなどここまでに定義したものを設定していきます。

    同様にIDENTITY MAPPINGも選択し、最後に「ENABLED」にチェックを入れてSaveします。

    これで設定は完了です。

    早速テストしてみましょう。

    ◆動作確認

    Azure AD WAPに設定した外部URLに、今回PingAccessで公開しているバックエンドサーバのパスを付けたものへアクセスしてみます。
     今回だとこんな感じです。
     https://pingaccess-pharaoh.msappproxy.net/cgi-bin/

    すると、Azure AD WAPに事前認証として指定した通り、Azure ADのログオンがおこなわれ、PingAccessからAzure ADへのアクセスに関する許可が求められます。(初回のみ)

    そして、うまくいくとPingAccess配下のアプリケーションが表示され、ヘッダにマッピング設定した通りに値が表示されます。

    もちろんテスト前にAzure ADでアプリケーションへユーザの割り当てをしておいてください。



    今回はPingAccessのリバースプロキシ配下のアプリケーションへHTTPヘッダでAzure ADのClaimを渡すというシナリオだったので、mod_auth_openidcとmod_proxyを使って同じような環境は割と簡単に作れるとは思います。
     参考)CentOS+Apacheの認証をAzure AD/OpenID Connectで行う
       http://idmlab.eidentity.jp/2017/01/centosapacheazure-adopenid-connect.html

    PingAccess連携を使うメリットは既にPingAccessで構成されたアプリケーション資産が存在していたり、Agent型でPingAccessが構成されているような場合に最大化されます。また、PingAccess自体が他のWAM製品との連携(というか他製品のフリをする)が得意な製品なので、Oracle Access ManagerやIceWallなどが既存で入っている環境をAzure ADへシームレスに移行する際には本領を発揮することになると思います。

    このあたりのシナリオもまた検証してみたいと思いますので、またそのうち公開するかも知れません。




    Viewing all 769 articles
    Browse latest View live