2016年12月26日月曜日

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

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

引き続き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へ一本化していきますが、利用者がほぼ気が付かない状態で移行していくのが大きなポイントとなります。

2016年12月25日日曜日

[資料&動画公開]Japan Web API Community #1 での Azure AD/OAuth2.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系へコードを書き直しています。

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


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

◆スライド



◆動画




2016年12月20日火曜日

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

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

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

今回はユーザにとっての利便性をあげるため、PCへのログインとOpenAMのログインをシングルサインオンする「Desktop SSO」の構成を行います。このことにより、OpenAMと連携されているG SuiteへもOpenAMのログイン画面を見ることなくアクセスをすることが可能になります。



◆デスクトップ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の情シスとの連携開始です。

2016年12月19日月曜日

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

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

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

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

◆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です。



2016年12月16日金曜日

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

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

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

今回はOpenAMのデータストアとして社内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と連携してみます。

2016年12月14日水曜日

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

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

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

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



また、当日およびデモ動画では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」というメッセージが表示されます。



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