OpenAMでWindowsDesktopSSO

OpenAM は、Sun Microsystemsを中心としてプロジェクトが進められていた 
Web上でSSO(シングルサインオン)を実現するためのソフトウェア OpenSSOの
後継にあたるもの。
中身としては、OpenSSOをそのまま引き継いでいるので安心して使えるのと
オープンソースなので中身をみれば何をしているか分かるという安心感もある。
日本語情報はまだ少ないですが、OpenSSOの資料をほぼそのまま流用
できるのであれば最低限は情報入手できると思います。

とりあえず、OpenAMでDesktopSSOによるシングルサインオンとかいうものに
チャレンジしてみました。
Windows Desktop SSO は、Windowsにログインするだけで、
Webアプリに対してシングルサインオンが可能になるような仕組みです。

設定を行って動作はしましたが、手順的に問題ないかまでは分かりません。
どうやら見ていると、Windows統合認証の仕組みを利用しているようで、
kerberos5あたり利用してそうです。

【準備】 
Active Directory, OpenAMサーバ、Windowsクライアントが最低必要です。

ADサーバ: Windows 20003 Server SP2  (VMPlayer上で動作)
OpenAMサーバ: Ubuntu 10.04.1 LTS    (物理環境)
Windowsクライアント: Windows XP SP3 (VMwareServer上で動作)

ubuntu のバージョンは以下で確認できます。
% lsb_release -a 
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 10.04.1 LTS
Release:        10.04
Codename:       lucid

まずは、ActiveDirectory環境の作成。

Windowsの環境作成のために
Windows 2003 Server 上に ActiveDirectory と DNSサーバを立てます。

<< Active Directory 及び DNS の構築 >>
(0). Active Directory を構築
 構築方法は割愛します。
 ちなみに ドメインとフォレストの機能レベルは、Windows Server 2003 で構築しました。
 ドメインの機能レベルが動作に影響するかまでは確認していません。
 
(1)
 DNSは、AD,DNSサーバとOpenAMサーバのA,PTRレコードを設定しておいて、 
 正引き、逆引き両方できるようにしておきます。
 
 今回は、ドメインopensso.test.local
 OpenAMサーバは、grape.opensso.test.local
 ADサーバは、adserver.opensso.test.local

(2)
  OpenAMサーバをインストールした ubuntu から名前が引けるか確認してみます。
  ・resolv.confを設定してみます。
  
  % sudo vim /etc/resolv.conf 
  domain opensso.test.local
  nameserver 10.1.1.24

  さて確認
  % dig grape.opensso.test.local
  ;; ANSWER SECTION:
  grape.opensso.test.local. 3600  IN      A       10.1.1.50
  
  % ping grape.opensso.test.local
  ping: unknown host grape.opensso.test.local
  
  あれれ、相手がわかんないと怒られてしまいました。
  おそらく、DNSに問いあわせがないんだろうなと予想。
  dig だと無条件に問い合わせにいくけど、
  ping だとかだと gethostbyname あたり利用しているだろうから、
  問い合わせ順序の設定が影響してそうかなとあたりをつける。
  
  裏づけとるために、port 53 でfilterかけてパケット確認。
  DNSの問い合わせが無いことを確認。
  
  nsswitch周りかなということで設定確認。
  ・sudo vim /etc/nsswitch
  #hosts:          files mdns4_minimal [NOTFOUND=return] dns mdns4
  hosts:          files dns m4_minimal [NOTFOUND=return] mdns4
  
  もともとのhostsの設定をコメントアウトして、
  dnsのエントリーを前にもってきます。
  
  % ping grape.opensso.test.local
  PING grape.opensso.test.local (10.1.1.50) 56(84) bytes of data.
  64 bytes from grape.opensso.test.local (10.1.1.50): icmp_seq=1 ttl=64 time=0.028 ms

  その後は、ADサーバにもping をうって名前が解決されることを確認。
  % ping adserver.opensso.test.local
  
  無事名前が引かれて動いているようです。

<< Windows Serve Support Tools インストール>>
  Windows 2003 Server に Support Tools  をインストールしておきます。
  以下から入手できます。(インストールCDにも入っているはずです。)
  http://www.microsoft.com/downloads/en/details.aspx?familyid=96A35011-FD83-419D-939B-9A772EA2DF90&displaylang=en
  
  supporttools.msi,support.cab を同じディレクトリに配置したら、
  supporttools.msi を実行して、インストールします。
  
<< Windows クライアントから ドメインに参加 >>
 [コントロールパネル] - [システム] で システムのプロパティを開きます。
 コンピュータ名のタブを選択して、変更ボタンをクリック。 
 画面下の次のメンバ パネルにある ドメインにチェックを入れて、
 ドメイン名を入力。ここでは、opensso.test.local を入力。
 問題なければ、OK ボタンをクリック。
 ユーザとパスワード要求があるので、ここでAD上のユーザとパスワードを入力。

【Disktop SSO のための設定 実施】
 手順は、http://wikis.sun.com/pages/viewpage.action?pageId=48115029 
        http://docs.sun.com/app/docs/doc/820-3885/gimtn?l=en&a=view を参考にしました。

(1) AD 上で「Active Directoryユーザーとコンピュータ」を設定
 シングルサインオン対象のマシンがComputersに登録されているか確認。
 (ドメインに参加しているなら、見えるはずです。)

「Users」に grape ユーザ(OpenAMのサーバ名)を登録する 
 ここではパスワードに、Secret99 を設定しました。

(2) ADサーバ上で、ktpassコマンドを使って、keytabファイルを作成

 キーバージョンを確認します。
 LinuxでADに対して、ldapsearch を行い確認します。
 % ldapsearch -x -h adserver.opensso.test.local -b "dc=opensso,dc=test,dc=local" \
 -D "cn=administrator,cn=users,dc=opensso,dc=test,dc=local" -w xxxxx "cn=grape" msDS-KeyVersionNumber
 # grape, Users, opensso.test.local
 dn: CN=grape,CN=Users,DC=opensso,DC=test,DC=local
 msDS-KeyVersionNumber: 18

 msDS-KeyVersionNumberの値が、18なので現在のバージョンが18であることが分かります。

 keytabファイルを作成します。
 C:\>ktpass -out grape.HTTP.keytab -mapuser grape -princ HTTP/grape.opensso.test.local:8080@OPENSSO.TEST.LOCAL 
 -crypto RC4-HMAC-NT -pass Secret99 -ptype KRB5_NT_PRINCIPAL -kvno 19

 コマンドで指定するパラメータは以下のようなもの
 ------------------------------------------------------------------------------
 ktpass /out 自由なファイル名 /mapuser (1)で追加したOpenAMサーバのホスト名ユーザ
 /princ HTTP/FQDN@ADのKerberosドメイン領域 (OpenAMサーバを指定 @以降は大文字で)
 /crypto RC4-HMAC-NT -pass (1)で指定したパスワード /ptype KRB5_NT_PRINCIPAL
 -kvno 確認したキーバージョン + 1
 ------------------------------------------------------------------------------

(3) keytabファイルをOpenAMサーバに配置します。
 配置場所は、OpenAMのプロセスから読める場所にします。

(4) ADサーバを再起動

(5) OpenSSO の管理コンソールに amAdmin ユーザでログイン

(6) 認証モジュールインスタンスを作成

「アクセス制御」タブ → 「/(Top Level Realm)」 → 「認証」タブ → 'モジュールインスタンス'の 「新規」
 → 名前として desktop と入力し、タイプから「Windows デスクトップ SSO」を選択し、「了解」を選択

(7)「desktop」インスタンスの設定

 認証モジュールインスタンスの一覧から、先ほど作成した「desktop」インスタンスを選択し、以下を入力
 以下は例なので実際設定する際は環境にあわせて設定してください。
    * サービス主体: HTTP/grape.opensso.test.local:8080@OPENSSO.TEST.LOCAL
    * Keytab ファイル名: /home/test/grape.HTTP.keytab
    * Kerberos レルム: OPENSSO.TEST.LOCAL
    * Kerberos サーバー名: adserver.opensso.test.local
    * ドメイン名を含む主体を返す: false
    * 認証レベル: 22

(8)「認証連鎖」の作成
 8.1 「認証連鎖」で「新規」を選択し、'名前' 欄に test と入力し「了解」をクリック
 8.2 「追加」をクリックし、'インスタンス' を desktop に、'条件' を「十分」にして、さらに「追加」をクリック
 8.3 'インスタンス' を DataStore に、'条件' を 十分 にして、「保存」をクリック
 8.4 認証の設定画面 (認証タブが選択された画面)に戻る

(9)「認証連鎖」の設定

 認証の設定画面で「デフォルト認証連鎖」(組織認証設定:)を test に設定し、「保存」をクリック。

(10) テスト用アカウントの作成

 Active Directoryと OpenAM の両方に同じ名前のアカウントを作成する。
 OpenAM のアカウントは「対象」タブで行う。

(11) OpenAM サーバ(アプリケーションサーバ) を再起動

 サーバサイドは以上で終了。

(12) クライアントでドメインからログアウトして、ログインしなおします。
 あとはシングルサインオン対象のURLにアクセスして、動作するか確認してみて下さい。 
 私は、Google Appsシングルサインオンを行い動作を確認しました。

<< クライアント設定 >> 

 Internet Explorer で以下の設定を行います。

 [ツール] - [インターネット オプション]  をクリックして、
 詳細設定タブを選択し、"統合 Windows 認証を使用する(再起動が必要)"
 にチェックが入っていることを確認。入っていない場合はチェックを入れること。

 セキュリティタブで、イントラネットを選択し、[サイト]ボタンをクリック
 [詳細設定]ボタンをクリックし、OpenAMサーバのサーバ名又はIPアドレスを登録する。

<< オマケ >>
 どうしても、Windows Desktop SSOが動かなかったが原因が分からなかった。
 その際に行ったことは以下のようなもの。

・OpenAMそのもののデバッグログ出力
 認証動作等の詳細を確認したい場合は、DebugログがOpenAMでは出せるよう。
 Tomcat で OpenAMを動かしていたので以下のような要領で設定を行った。

 % vim setenv.sh
 CATALINA_OPTS="-Dcom.iplanet.services.debug.directory=/tmp/debug -Dcom.iplanet.services.debug.level=message"

 設定して再起動すると、以下のようなログが出力されます。
 % ls /tmp/debug 
 Authentication  Configuration  CoreSystem  Entitlement  Federation  IdRepo  Policy  Session

 ・tcpdump,wiresharkで パケットキャプチャして、kerberos周りでエラーがないか確認
 port 88 ( Kerberos v5) で filter して確認しました。
 結果としては、エラーが発生していたのでそのエラー内容にあわせて対策をして動作させました。