カテゴリ:Identity Management( 20 )

eDirectory の同期プロセス

eDirectory 同期のメカニズムの続きで、Novell の eDirectory を説明する試みです。


-外部参照(External Referrence)-

まず、外部参照 - External Referrence - について理解しておく必要があります。

外部参照(X-Ref)はパーティション化(分割)されたツリーのレプリカデーターベースにはないオブジェクト(ユーザなど)の情報です。

言わば「社内で出張してきた(ユーザなどの)オブジェクト」です。

例えばOU=Osaka が OU=Tokyo とは分割されたパーティション(オフィス)で OU=Osaka には CN=Maido.OU=Osaka さんがいるとします。OU=Tokyo にあるAsakusa サーバの、とあるファイルだとか「コピー機」にアクセス権限があったとします。Maido さんがこのリソースに接続しようとすると、このユーザの一時的な外部IDが作成されます。Asakusa オフィスでの、いわゆる「ゲスト入館カード」のようなものです。Maido さんはこのカードで出張中の必要な Asakusa オフィスの資源にアクセスできます。「コピー機を使うならその機械を使ってもいいよ」というような情報です。もちろん Maido さんが正規のユーザかどうかの認証は OU=Osaka パーティションに入館時にチェックされます。

eDirectory は「一枚のカードがあれば全てのどこのオフィスビルにでも自由に入館管理ができる」Windows Directory とは異なり、「オフィスビルごとに身分を確認して入館申請管理が必要」なディレクトリサービスなのです。この時に Maido さんが手に入れるIDカードが External Referrence というIDなのです。

多くの eDirectory の同期障害はこの X-Ref に関する情報交換の失敗によるものです。


-Flat Cleaner プロセス-

このプロセスは、External Referrence などの「無用になった」オブジェクトをクリーンアップするプロセスです。cn=Maido.OU=Osaka さんが退職したら、その情報は OU=Osaka パーティションデータベースの中で「即時」に削除されます。しかし、Asakusa オフィスではそのことは誰も知りません。「そういや大阪の Maido さんって元気かなぁ」みたいな状態ですね。
Maido さんに「コピー機を使ってもいいよ」という権限を与えたとしても、その権限を与えた「記憶」は Asakusa のオフィスにはそのまま残っています。

Flat Cleaner プロセスは 「Maido さんという人が Osaka オフィスから出張してコピー機を使う権限を与えた」という記録を消去するプロセスです。

-Janitor プロセス-

Janitor とは「門番」を意味します。

この同期プロセスは「各オフィス」が抱えているサーバーの最終同期状態などをチェックするもので、簡単に言うと「全社コンプライアンス委員会」の確認の為のプロセスのようなものでしょうか。このプロセスの中で、正しく情報のレプリケーションなどが行われているかをチェックします。関連子会社の誰が今度社長になった(マスターレプリカになったか)と言った情報を交換しあうわけです。

Slow Sync で定期的(Heart Beat)に実行されます。


-Replica Sync プロセス-

このプロセスは一番よく発行されるプロセスです。「ゴリさーん、電話だよ」「あ、ゴリさんなら今、トイレに出かけたよ」というような内容の会話がオフィス(パーティション)の中でよく交わされるわけですが、これが Replica Sync のプロセスです。ここで重要なのは、eDirectory によって同期される内容は「ゴリさんに電話があった」「ゴリさんはトイレにいる」という情報だけがサーバー間で交換されるということです。

Windows の Directory では cn=Gori さんのオブジェクト情報は全て筒抜けに全てのサーバに同期されます。「ゴリさんに電話があった」だけの情報に加えて、ゴリさんの本日の出社時間から、アクセス権限、ゴリさんの内線番号、メールアドレス、今朝食べたゆで卵が原因でお腹を壊したという下世話な話題まで全部の情報を同期します。

ちょっと想像しても解りますね、Active Directory を使っているネットワークはひどく「ウルサイ職場」です。しかもデータベースはパーティション化されないため、「ロケーションを超えて、全社で共有」されるという恐ろしいことをやっているわけです。

eDirecotry では最低限の情報交換だけを行い、ゴリさんの腹具合まで社内では交換しません。そんなことは別なオフィス(パーティションデータベース)では話題にすらならないのです。

また、総務部が3Fの大部屋から4Fに引っ越したとしましょう。これがいわゆる「ディレクトリのパーティション化」なのですが、その時、ぞろぞろと什器備品が移動します。この時、「総務部にプロジェクタがあったよなぁ」という情報や「営業部に新しい派遣社員が入った」などの情報はも Replica SYnc で同期されます。

即時同期 (Immedate Sync) です。


-Replica Purger プロセス-

このプロセスは、削除したオブジェクトの最終確認に使われる通信プロセスです。

あるオブジェクト OU=Maido さんが退職したためどこかのレプリカリングから「削除」した場合、Obituary (オビチュアリ:死亡通知)としてマークされます。このオビチュアリをレプリカリングから一斉に削除するために Replica Purger の通信が発生します。まず、オビチュアリは全てのパーティション内で共有されます。つまり Maido さんのIDカードは使えなくなった、という情報が共有されます。その後 Replica Purger は Maido さんが使っていたカードIDを全て破棄します。

即時同期(Immedate Sync)します。



-Limber プロセス-

この意味不明な通信プロセスは、Janitor プロセスに似ています。似ている作業をするために別な言葉 Limber プロセスと言われるのでしょうか。この通信プロセスも、それぞれのサーバー間、パーティションの整合性、レプリカリングのIP アドレスなどの整合性をチェックするプロセスです。東京本社では、別に関連子会社でオフィスのレイアウトが変更になって、内線番号(IPアドレス)が変更されたということはすぐに必要な情報ではありませんが、常に連絡先だけは確認しておく必要があるということです。

Limber Process は、お互いのIP情報の確認などを行います。

Slow Sync で定期的(Heart Beat)に実行されます。

そこで、あるサーバーの内戦番号(IPアドレス)を変更した場合、 DStrace コマンドで Limber Process を強制発行して、IP アドレスの変更を各サーバーに通知します。



-BackLinker プロセス-

このプロセスも External Referrence に関する情報交換です。まだ Maido さんというIDが OU=Osaka に居るかどうか、このX-Ref はまだ使われる必要があるかどうか、つまり「Maido さんは Asakusa オフィスのコピー機を使う権限を与えた」ことがまだ継続して必要かどうかを確認するプロセスです。



-Schema Sync プロセス-

ディレクトリスキーマというのは、データベースの「構造体」に関する情報です。C言語を習った方なら Structure/Union の宣言のようなものと理解するとわかり易いでしょう。

eDirectory のスキーマは「初期状態の基本情報で固定」されているわけではありません。eDirectory に新しい「属性」が加わることがあります。例えば、基本情報に加えて。「携帯電話も社内で管理しよう」というポリシーになった場合、ユーザオブジェクトの項目に「携帯電話番号」という属性が付け加わります。この情報は ディレクトリ[root] に権限がない限り変更は許可されません。

Schema プロセスは、このディレクトリスキーマが正しく同期されているか、あるいは項目や属性が追加されたり、削除する通信プロセスで、[root] の Master パーティションから下位へと行われます。

スキーマはデータベースの構造そのものですからスキーマの変更は大きな負担がかかります。スキーマの変更に不具合が発生した場合 reset schema を行ってデータベースの再構築を行います。

大抵大きな外資系企業でし連休明けに eDirectory の障害が発生した場合は、なんらかのスキーマの変更(例えば新しいディレクトリアプリケーションの導入)が行われたことによります。


-Time Sync プロセス-

このプロセスは NetWare 4/5/6x 時代のもので、OES Linux では NTP に取って代わりました。ただし、ディレクトリ同士が同期しているかどうかはタイムスタンプで管理されているため、OES Linux ではNTP サーバとの同期が取れているかをお互いに監視するために使われます。極端に時刻がズレている場合は同期エラーとなります。

また、オブジェクトのタイムスタンプが「遠い未来」の時間だった場合、 - これは date コマンドを間違って実行してタイムスタンプを「来年」にしてしまった、など - 同期は長時間の間、失敗します。

そこで、タイムスタンプをリセットするために「エポックの宣言(Declere Epoch)」を明示的に実行します。


-Sub Ordinate Referrence は叔母さんの連絡先-

eDirectory の同期プロセスと密接な関係ですが、プロセスとは違う情報の一つにサブオーディネートレプリカ(Sub-Ref)という機能があります。

Windows のディレクトリは「ドメイン」という巨大な一軒家に徳川一族の郎党が一つ屋根の下で暮らしているようなものです。ハトコが今トイレに居るとか、会ったこともない従兄弟の子が巨大な一軒家の裏庭今剣術の修行をしているという情報も全て知っています。というか強制的に知らされます。

一方、eDirectory のシステムは、徳川一族が「紀州」「名古屋」「水戸」に分家している様な形態だと考えれば良いでしょう。

私は独立して、貧乏長屋に両親と離れて暮らしています。両親はまた祖父母とは別な家に住んでいます。これが分割されたパーティションです。

ある日、私は従兄弟が家を新築し、叔母の家から独立したと新年の祝いの日に(Janitor のハートビートプロセスで)聞きました。これが叔母の一族(OU)でのパーティションの分割です。しかし、私は従兄弟がどこに家を新築して、新しい電話番号を使い始めたという情報を知りません。そこで、従兄弟に新築祝いも贈ることもできません。

しかし、両親を経由して、祖父母に連絡すると、おばの家に連絡が届き、従兄弟の新築した家(パーティション)の連絡先を知ることができます。これがディレクトリのツリーウォークです。

しかし私は叔母の家がどこにあって、叔母の家を訪れたこともなく、叔母の誕生日に花束を贈ることもない無精者です。ただ連絡先だけを知っています。それは私の両親も同じことです。

このように一族郎党の中に「知り合い」(ここでは叔母さんの家)はがあっても、その実情を知らない家(パーティションのレプリカ)があります。これをサブオーディネート(Sub Ordinate Referrence) Sub-Ref レプリカと言います。

私は従兄弟の家を訪れて、彼の家の間取りや家族構成をいつも連絡し合います。つまりこれは私が従兄弟の家の Read/Write レプリカを持っているということです。また、叔母さんは従兄弟の家族構成や家の間取り、果ては台所のどこに何があるかまで知っています。つまり叔母さんも従兄弟の家の R/W レプリカを持っているということです。

私は従兄弟の新築の家(パーティション)を訪問し、お茶をご馳走になり、新築祝いで花束をあげました。この情報は彼の家で X-Ref(外部参照)として彼の家庭の皆なが知っていることです。従兄弟の子供が挨拶に来て、私は彼に恥ずかしいほど少ない小遣い(ファイル)を残します。

しかし、私が東京に戻り、コーヒーカップが洗われ食器棚に片付けられ、花束が枯れてゴミ箱に捨てられると Flat Clear プロセスによってその記録(X-Ref)も消去されますが、私が渡したお小遣い(ファイル)には記録が残ります。

しかし、私の両親は叔母さんの家の実態を知りません。(まぁウチの一族の実際はそんな薄情な事はないのですがそう仮定しましょう)私の両親の家(パーティションのデータベース)は叔母の連絡先だけは知っているということです。これが「実体のないレプリカ」Sub Ordinate Referrenceです。私の両親はボクが従兄弟の家に行ってヨッパらってトイレを汚したとか、従兄弟の子供に小遣いを渡したという事実を知りません。また知る必要もありません。

もし叔母が引っ越した(IPアドレスが変わった)としたら、その情報は Limber Process で知ることができます。

このように、たとえ徳川一族のような巨大な郎党であっても、隅々まで家族構成だとか、(あればのことですが)抱えている家庭内の問題だとかを共有しあうことができます。巨大な組織であっても、途中の連絡先さえわかれば、一族の中のパーティション(家庭)内部の少ない情報量の交換だけで、全て「親戚である」という信頼(トラスティ)を得ることができますし、地の遠いハトコであっても「東京に下宿先を探してくれ」と言われれば紹介することができるのです。

※ eDirectory の実態では「親子」間でレプリカを共有しない場合は Sub-Ref が必要です。兄弟間でレプリカを共有しない場合は Sub-Ref は作られません。私は本家を知らなくて、両親の家の間取りや、食器棚のどこに醤油瓶があるかは知らなく(RWレプリカを持たない状態)ても、両親の住所は知っている( Sub Ordinate Referrence) を持っていなければなりません。

-eDirectory の同期状態を調べる-

eDirectory の同期状態を調べるコマンドは ndstrace と ndsrepair コマンドです。 

ndsrepair コマンドは、同期状態を調べ、修復を実行します。

ndstrace コマンドは同期プロセスをリアルタイムに表示し、必要に応じてプロセスを強制実行します。

Novell Open Enterprise Server の eDirectory 8.8 では現在 iMonitor によってブラウザから操作することができます。iMonitor の Trace コマンドで必要なプロセスだけをフィルターし
a0056607_2303059.jpg


トレースを実行します。
a0056607_2314577.jpg


これによってサーバー上での eDirectory の通信プロセスを確認することができます。


islandcenter.jp
[PR]
by islandcenter | 2013-09-24 05:45 | Identity Management | Trackback | Comments(0)

ユーザ管理とダンパー数

ダンパー数というものがあります。

社会学者ロビン・ダンパー (Wikipedia)が提唱したもので、

「霊長類は大体150人前後の人間関係が限度」

というものです。おおよそ150人以上の人間関係は、お互いを認知できないというものなのだそうです。

例として

- 従業員150人程度が中小企業の限界:これ以上社員がいると、社長は従業員一人ひとりを面倒見れない。企業が急激にこれ以上成長するには、優秀な「中間管理職」が必要となる。

- 歩兵部隊はおおよそ中隊規模が基本、これ私が大好きな戦争ドラマ「バンド・オブ・ブラザース」でもそうでしたが、ウィンタース中隊長が大隊長になった途端に書類仕事に忙殺されます。ウィンタース大尉は、中隊長時代に優秀な「現場指揮官」でした。

- 軍艦でもコルベット艦や小型駆逐艦などの艦艇の乗組員は150人程度。この程度であれば、艦長は水兵たちのことをよく把握している。私は英国の冒険小説が大好きなのですが、コルベット艦の面倒見がいい指揮官が出世して大型フリゲート艦の艦長などになると、途端に「冷酷な指揮官」になってしまいます。

- 古代ローマ軍では「100人隊長」という隊長が現場指揮官だったことが強さの秘訣だった。

- SNS で「友人」が何百人いても、本当の「知り合い」は200人程度らしい。
 「ダンバー数」にFacebookで挑戦 Wired.jp
--

なぜ私がダンパー数の事を思い出したかというと、どんな大企業でも多くの組織では、大体150人から250人程度を一つのユニットと見なして、ヘルプデスクを配置していた組織が多かったということです。また、ディレクトリサービスの設計でも、およそそのくらいの人数で OU が構成されていました。

こではヘルプデスクのための数字であるというより、組織そのものが「ダンパー数」に支配されていたことでもあるからなのかも知れません。

ここに eDirectory などのディレクトリサービスで管理する OU (部門オブジェクト)の設計のポイントがあると思います。1拠点に1、000人のユーザがいたとしても、実際にチームワークとして機能するのは200から250人程度が限界なのですね。それをシステム的に1,000ユーザをひとくくりに管理することには無理がありそうに思います。じゃぁ4、5人で面倒みれば良いじゃないか、というご意見もありそうですが、チーム内部で1,000人を4,5個のユニットに分けて分担し、管理したほうが良いのかもしれません。


ということでダンパー数のお話と、ID管理のお話でした。
[PR]
by islandcenter | 2013-09-23 14:08 | Identity Management | Trackback | Comments(0)

Organization CA はディレクトリツリー上の各サーバーで必要な公開鍵を自動的に作成するためのオブジェクトです。通常は eDirectory(8.x) を作った「最初のサーバー」がホストサーバーとして認証鍵を持ちます。この鍵を元に、全てのサーバーのキーが作成されます。

Organization CA の概要についてはこちら。(と逃げてみる)
Organization CA Overview
http://www.novell.com/documentation/crt32/?page=/documentation/crt32/crtadmin/data/a2ebon6.html

そこで、古くなった「最初のサーバー」を V2V する場合はあまり問題なく移行できますが、P2V移行などの場合、「サーバー丸ごと」移行に失敗するととんでもない問題になります。また、何らかの問題でホストサーバーに問題が発生すると、ディレクトリ全ての認証鍵を再作成する必要があり、大変な労力を必要としてしまいます。

この記事は「OES NetWare/Linux CA Authority サーバの移行
の iManager 版です。

この文書そのままの作業です。
http://www.novell.com/support/kb/doc.php?id=3618399

※ブラウザの設定は英語を優先言語に設定しています。優先言語を日本語にすると、ほぼ全てのメニューは日本語表示されます。
上の文書にもありますが、 CA のホストサーバーをexport キーなしで作り直した場合、全てのサーバーの認証局をアップデートしなければなりません。私はCA局を持ったサーバーは「小規模な仮想サーバー」を使い、定期的にシャットダウン、バックアップコピー、再起動するように運用することをお勧めしています。


-現行のホストサーバーからのエクスポート-

iManager > Directory Management > Modify Object > "Tree -> Security -> My-Tree CA"を選びます。

この画面は Tree ビューで表示した場合です。Tree オブジェクトの直下の "Security" コンテナに存在します。
a0056607_10535693.jpg

ツリービューで見てみます

Role(役割) 画面から操作する場合
Certificates > Self Signed Certificate(check) > "Export"
リンクをクリックします。
a0056607_11644100.jpg


ここでパスワードをセットします。
Enter Next
a0056607_11104056.jpg



Save Export リンクをクリックすると、鍵のダウンロードを行います。
a0056607_11123083.jpg


> save as "My-Tree.pfx

ここで保存したキー(デフォルトでは cert.pfx ) を安全な記憶媒体にパスワードと共に保管します。My-Tree(CApassword).pfx などの名前にしておけば便利でしょう。admin や root のパスワードを記したメモなどと一緒にUSB メモリなどの安全な記憶メディアに厳重に保存します。

万が一、CA オブジェクトのホストサーバーがクラッシュした場合はこのキーファイルとパスワードで復旧します。

-Organation CAの作成-

古い CA Object を削除します。

Delete My-Tree CA.Security
a0056607_11152270.jpg



pfx ファイルをインポートします。
Novell Certificate Server > Configure Certificate Server Authority > browse and set "New Destination Server" : "My-Tree CA" > Import
a0056607_11222555.jpg


エクスポートしたときのパスワードをセット
Chose "Your-Tree.pfx" and set password when set password ""YourNewSecretPassword" >
a0056607_11265095.jpg
"

作成されました。(たまにプラグインエラーが出ましたが無視)
OK > Next
a0056607_11314541.jpg


Next > Finish
a0056607_11343115.jpg


ホストサーバーが入れ替わっています
a0056607_11363398.jpg



islandcenter.jp

-Keyword-

Novell Netiq eDirectory Identitimanagement Organation CA How to move CA server into another Server iManager
[PR]
by islandcenter | 2013-04-18 12:34 | Identity Management | Trackback | Comments(0)

物流・機工サービスの山九、社員1万人の統合ID管理基盤を構築

製品の採用にあたっては、多数の導入実績に基づいた信頼性に加え、システム連携のためのドライバが豊富に提供されていることや、連携のためのドライバを独自に開発できるなど、拡張性も評価されたという。

islandcenter.jp
[PR]
by islandcenter | 2012-01-25 06:53 | Identity Management | Trackback | Comments(0)

Novell Sentinel Log Manager スタートアップキャンペーン

2012年3月31日までのキャンペーン期間中、Novell Sentinel Log Managerを約70%オフの90万円で購入することができます。

お兄さん、70%オフでっせ。どこか大企業ユーザでも見つけたのかしら....
[PR]
by islandcenter | 2011-11-11 06:26 | Identity Management | Trackback | Comments(0)

あずさ監査法人によるID管理の実情と問題点をテーマとした Novell のセミナーがあります。

日時: 2011年10月28日(金)  14:00~16:50(13:30受付開始)

申し込みはこちらから
ID統合管理システムの評価事例から考える 課題と解決策

監査法人は私たちシステム屋と同じくさまざまな企業とお付き合いがあります。「ウチの常識は世間の非常識」とならないためにも、さまざまな事例を研究してみてはいかがですか。

Novell ID Management

islandcenter.jp
[PR]
by islandcenter | 2011-09-27 14:55 | Identity Management | Trackback | Comments(0)

Novell セミナー情報

ID/ログ/アクセス認証管理の徹底

ノベルでは最新のアイデンティティ&セキュリティ製品群の紹介と動画デモがあるようです。

ガラパゴスID管理製品にお困りの方はどうぞ。
[PR]
by islandcenter | 2011-07-07 05:06 | Identity Management | Trackback | Comments(0)

ノベル、Novell Sentinel Log Managerスタートアップキャンペーンを展開

この種のログ管理製品は日本では圧倒的に「ガラパゴス国産品」のシェアが高く、高額なライセンス料と高額なサポート料金を払わないと利用できませんでした。不具合事例を解決するにもコミュニティは存在しないし、テクニカルサポートに有料のサポートリクエストを送っても「不具合」と認めたがらないことが多く、「導入」した事例はいくらでもあるのですが「使いこなしている」事例はあまり聞きません。

 Novell Sentinel Log Manager のスタートアップキャンペーンは来年3月までということなので、ゆっくり検証して稟議を通して導入するだけの十分な期間があります。

※従来はキャンペーン期間2ヶ月とか、どうやって稟議通すんだってキャンペーンが多かったのですが...

ついでに ID 管理の現状と解決に関するセミナーが開催されています。経験豊富なアクシオさんのセミナーです。

Novell Identity Management , Log management

islandcenter.jp
[PR]
by islandcenter | 2011-06-26 13:50 | Identity Management | Trackback | Comments(0)

日本のグローバル企業では海外の現地法人が Novell 製品を導入する事例をよく見ます。キヤノン、日産しかり、今回はソニーです。

Sony Italia社

イタリアでは新しいプライバシー保護が必要とされ、プライバシー情報にアクセスした記録を収集しレポートできる Novell Sentinel Log Managerを を Sony Italia が導入しました。

islandcenter.jp
[PR]
by islandcenter | 2011-05-06 14:20 | Identity Management | Trackback | Comments(2)

ID 管理とログ管理の新製品 - パッケージが販売されました。

ノベル、ID管理と連携できるログ管理の新製品--国内需要の高まり見込む



詳細はこちらから
Novell Sentinel Log Manager
[PR]
by islandcenter | 2009-12-02 13:57 | Identity Management | Trackback | Comments(0)