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

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

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にステップ分割してシステムを構成しています。

STEP１）
　フロントでとりあえず認証基盤を作ってクラウドサービス利用を開始
　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台設定する場合はセカンダリドメインコントローラとして設定をすることも可能
ユーザー検索の開始 DN	OU=Users,OU=Managed Objects,DC=eidentity,DC=adfs20,DC=net	ユーザを格納していると思われるコンテナ
バインドユーザー DN	CN=test user01,OU=Users,OU=Managed Objects,DC=eidentity,DC=adfs20,DC=net	接続するユーザのDN。一般ユーザで問題なし
ユーザープロファイルの取得に使用する属性	sAMAccountName	後述するデータストアとのマッチングに使用する属性名
認証するユーザーの検索に使用する属性	sAMAccountName	OpenAMでのログイン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」というメッセージが表示されます。

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