◆ユーザーの課題◆清水建設は,WindowsやUNIXなど複数のOSで構成されるシステムの刷新と拡張を計画した。各システムは独自にアカウント情報を管理する仕組みだった。そのままでは管理負荷が増大する恐れが出てきた。

◆選んだ解決策◆ユーザー・アカウント情報をノベルのディレクトリ・サービスであるNDSに統合。各システムが持つアカウント・データベースが自動的に同期する仕組みを構築した。

◆結果と評価◆追加した各システムのアカウント情報は,管理者がNDSの情報を更新するだけで一括更新できるようになり,管理負荷の増大を回避できた。

 複数のOSから成るシステムを構築する際,そのアカウント情報の管理は悩みのタネだ。Windows 2000はアカウントを一元管理する仕組みActive Directoryを持つが,適用範囲はWindowsに限られる。大手ゼネコン清水建設が2001年4月に稼働させたUNIXとWindows混在システムでも,アカウント情報の管理方法改善が大きなポイントとなった。

 同社では,従来も独自にアカウント管理を行う複数のシステムがあった。全社システムでは,グループウエアを兼ねた電子メール・システムと社内システムの使用許可を与える本人認証システムを利用していた。

 これに加え,支店や部門では4年前からWindows NT Serverを導入してファイル共有などに活用していた。ドメインを構築していたものの,部門単位で構成されており,人事異動でユーザー・アカウント情報を変更するときなどは,各部門にいる管理者の作業が煩雑になりがちだったという。

アカウント管理の負荷が増大する恐れ

 2000年夏に開発に着手した新システムでは,こうしたアカウント管理の問題が深刻になることが予想された。

図1●アカウント管理の負荷が増大するのを避けたい
従来システムではアカウント情報を各システムが独自に持っていた。そのため,Active Directoryや新しいメール・システムを追加導入すると,アカウント管理の手間が増大することが予想された
 全社システムは,まず数を増やす予定だった。グループウエアを兼ねた電子メール・システムを刷新するほか,文書などの承認を処理するためのワークフロー・システムの新規稼働が計画された。

 今まで部門で管理していたドメイン・ユーザー・アカウントの統合管理には同時に着手することになっていた。クライアントのWindows 2000への移行に合わせて,Windows 2000 Serverを導入し,シングル・ドメインのActive Directoryを構築して対応する。Windowsのファイルやフォルダのアクセス権などをActive Directoryのユーザーで設定する。

 ところが,Active Directoryでは,OSが違う全社システムのアカウントまでは管理できない。これを解決するには一層の工夫が必要だった(図1[拡大表示])。

個別管理から統合管理へ

 そこで同社が選んだのは,各システムのユーザー・アカウント情報を1つにまとめたアカウント・データベース「全社メタディレクトリ」を構築し,統合管理する方法だ。

 メタディレクトリのシステムに必要な要件は,管理下の各システムが持つアカウント・データを自動同期できる,WindowsとUNIXの混在環境で使えるというものだ。ノベルのディレクトリ・サービスであるNDSはこれに合致した。

 ディレクトリ・サービスは,NDS以外に,Active DirectoryやiPlanetのDirectory Serverなどがある。調査段階ではこれらの製品も検討した。

 すでに導入が決まっているActive Directoryですべてのユーザー・アカウントを管理するのが手っ取り早そうだが,採用されなかった。電子メール・システムなどをSolarisで動かす予定だったことが原因だ。

図2●アカウント情報をNDSに統合し,各システムに必要な情報を送信して解決
DirXMLで自動更新させることで,手間が増えないようにした
 iPlanetのDirectory Serverは,Windows NT/2000や各種商用UNIXといったマルチ・プラットフォーム環境で使える点では合格した。だが,変更したアカウント情報を他のシステムのアカウント・データベースと同期させるには,その機能を作り込まなければならず,採用には至らなかった。

 NDSを採用したのは,他のシステムが管理しているアカウント・データベースを自動で同期させるDirXMLを使えるのが決め手だった。全社メタディレクトリに集められている情報は,メインフレームで管理している人事情報や組織情報が中心。社員番号やパスワード,氏名,所属,職位などだ。ユーザー・アカウントに関するほぼすべての情報をNDSに記録し,新しく追加したシステムごとに必要な情報を送信している(図2[拡大表示])。

 管理者は,NDSに保存されているアカウント情報を変更するだけでよい。変更が入ったタイミングで,他のシステムが管理するアカウント・データベースの内容が更新される。各システムを個別に更新するより格段に管理負荷は小さくなる。

Active DirectoryとNDSを連携させるのが難しかった

 NDSとDirXMLの導入から本番稼働までスムーズにできたかというと,そうではなかった。DirXMLはXML(Extensible Markup Language)形式で各システム間とアカウント情報をやり取りする。そのため,設計段階で,スキーマとよぶデータ構造を定義しなければならない。

 DirXMLは2001年2月に出荷された製品で,清水建設は,早期導入ユーザーである。DirXMLの導入はシステム企画部主導で行われたが,当然ながら製品のノウハウがなかった。「DirXMLでどれだけのことができるのかも分からなかった」(清水建設のシステム企画部の伊藤健司インフラ企画グループ長)と,先行者であるがゆえの苦労を味わった。スキーマ設計に要した期間は3カ月弱。システム企画部の6人で設計した。システムごとに決められた担当者が設計を行った。

図3●Active DirectoryとNDSの連携では苦労
ツリー構造やオブジェクトの名称が異なるため,送信データの構造を決定するのが難しかった
 「一番苦労したのはActive Directoryとの連携」(同氏)という。同社のActive DirectoryとNDSは,ツリー構造が異なっていたため簡単にスキーマを設計できなかった。NDSは同社全体の組織構造を忠実に反映している。一方,アクセス権の設定などに使っているActive Directoryは,組織構造を詳細に反映する必要がなかった。Active Directoryを構築するのに,企業の部や課に当たるものを組織単位(OU)として設定できるが,同社では,一般企業での課に当たるグループをOUとして設定していない(図3[拡大表示])。アクセス権をグループより上位の階層である部門単位で設定しているからだ。

 さらに,Active DirectoryとNDSで同じ物を示すオブジェクトに異なる名称を設定したこともスキーマ設計を困難にした要因だった。NDSでは部門を部門コードという数字で表現していたが,Active Directoryではユーザーが見て分かるような具体的な部門名に設定していた。

 また,Active Directoryに登録している内容は,ユーザーが検索して参照することがある。NDSはユーザーに公開していない人事情報などを保管しており,このようなデータをActive Directoryに送信しないようにスキーマを設計する必要があった。詳細なところで考慮しなければならない問題が発生していた。

 テスト段階に入ると,例外的な処理が必要なことが判明した。例えば,社外に出向した社員は,機密保持のためグループウエアを使えないようにしなければならないが,実際にはDirXMLが動いたときにグループウエアのアカウント・データベースにユーザー・アカウントが作成されてしまうなどだ。全社メタディレクトリの情報を単に送信するだけで済まないところに設計の苦労があった。

当初の目的を達成

 苦労しながらも,最終的にはシステム構想の段階で挙がっていた機能を実現できた。現在は安定稼働している。新システムの導入効果は,「サブシステムが増えたため従来と比較はできないが,DirXMLを導入していなかったら,どれくらいの運用負荷になっていたのか想像できない」(同氏)という。

 同社は,今回の新システムの開発を通して,DirXMLのノウハウを蓄積した。スキーマ設計の注意点を知り,DirXMLで実現できることが見えてきた。今後は携帯電話のメール・アドレスなどを管理して,社外にいるユーザーに直接メールを送る仕組みを構築していくという。

(伊藤 康生=yaitou@nikkeibp.co.jp)