カテゴリ:Identity Management( 22 )

私はほとんど無意識にですが、

「ユーザIDは8文字以内の英数字にすべし」

というのが暗黙の考え方としてありました。

--
実際、海外の数万人規模の巨大企業でも、単一のディレクトリサービスでその様な ユーザアカウントの Naming Standard (命名規則) で運用している所をよく見ました。近年は、ユーザIDもパスワードも管理方法が複雑で、そのポリシーも複雑で統一性がないのでID管理に複雑な機能が要求されます。

- UNIX系 OS の場合 -

UNIX 系 OS のネーミングスタンダードでは、POSIX 準拠した場合、ユーザ ID は 9 バイトで、お尻の1バイトは NULL 文字で、実質8バイト、というのがヘッダファイルのソースでは宣言されており、一応それが「暗黙の決まり」となっているようです。

limits.h

{_POSIX_LOGIN_NAME_MAX}
The size of the storage required for a login name, in bytes (including the terminating null).
Value: 9

一応の決まりですが実際には、今のディストリビューションやメーカー独自の UNIX 系システムは、独自拡張されており、現在、販売もしくは配布されている多くの Linux ディストリビューションや Unix 系 OS では多くの場合 32 バイトです。ただし、 UID とユーザ名を関連付けるライブラリにバグがあったりすると、表示上 8文字以上のユーザ名が UID に化けてしまうと言った問題もでてきます。

アカウントと連動するアプリケーション側が、古い標準に従って8文字に制限している場合もあるので

「システム的には管理運用上ユーザアカウント名は8文字以内」が無難

であると考えます。

ps doesn't display usernames > 8 characters

ちなみに MySQL は 16 バイトでハードコードされているようで、デフォルトでは、ホストのユーザアカウントを参照するのですが、ユーザ名とパスワード自体が別に管理されているので、システムにログインしなくても使えるわけです。

6.3.1 ユーザー名とパスワード


- Windows の場合 -

Windows (2000/XP) のユーザアカウント文字数の最大長は20文字でした。

ユーザーアカウントとログオンパスワードの最大文字数について(Windows(R)2000/XP)

Windows10 に関しては情報がみつかりませんでしたが、Windows7 も20文字なので、恐らく最大20文字の制限は引きずっているでしょう。AD の場合も20バイトの様です。

Windows 10でユーザーアカウント名に使用できる文字の制限について


それにしても CON とか LPT とかの文字列が使えないってのもなんだか笑わせられます。こんな制限は、DOS 時代を知らない、若い方々には訳が分からないでしょう。俗にいう「CONCONバグ」 の残骸です。こんな制限は古いシステムでも、最新のシステムにも制限があるのですね。

特殊文字はハイフンやアンダースコアは OK の様です。文字間にドットが入っても問題ない様です。カンマは不可。

ちなみに、マイクロソフトアカウントでユーザ作成した際の文字数が5文字を超えると、\Users\xxxxx のユーザフォルダ名は5文字にトランケート(丸めて短くされる)されます。そのため、5文字を超えるユーザアカウントのホームフォルダに何かアプリケーションでアクションを行う場合、ユーザアカウントを参照するソフトウェアが5文字を超えると「色々と楽しくて痛ましい事故?」が起こるようです。例えば

robocopy c:\users\%login_name\*.* \\nas\backup

などとバックアップ用のバッチファイルを書いてユーザに配布すると失敗する訳です。困ったものです。

User folder name truncated

[Windows 10] ユーザー フォルダーの名前が Microsoft アカウントのアドレスの最初の 5 文字になっているのですが、なぜなのか分かりません。



- メールアドレス -

メールアドレスは、ドメイン名も含めた最大長 256 文字、@以前の、いわゆるローカルアカウント部分は最大64文字です。これに@以下のドメインを含めて最大 256 文字という事です。
ローカルなアカウントの部分はドット、ハイフン、アンダースコアは利用可、ただし一番先頭と末尾、連続する事はできません。RFCでは他の特殊文字も使える様ですが、契約先のISPや携帯メールとか、レンタルしたメールサーバー、メーラー(クライアント側)の制限により、その限りではありません。もっと制限がかかっている場合があります。

https://ja.wikipedia.org/wiki/メールアドレス

一般的なマルチユーザのシステム単体(Unix だの VAX だの)では、ローカルホスト内でメールが使えればよかったので「ログイン名=メールアドレス」です。今時はホスト外にメールを送るのが当然です。エイリアスを使っているので、ほとんど問題にはならないでしょう。管理上面倒と言えば面倒です。

- NetIQ eDirectory/LDAP の場合 -

ちなみに NetIQ eDirectory の CN (Common Name : UserID) は64 バイトまで許容しています。と言うより AD や Notes の認証のために LDAP 自体が x.500 の標準として 64 バイトに制限されているようで、eDirectory そのもの自体に制限は無いようです。


しかし、NetIQ のドキュメントではスタンダードな命名規則の事例として、8バイトの英数小文字と ”-” ( ハイフン ) を推奨しています。万物共用の命名規則として通用するわけです。

そこで eDirectory や LDAP でユーザアカウントを管理して、長いオブジェクト名や特殊文字を使用すると、マルチベンダーシステムで Windows や Linux のログインや動作で問題が起こります。LDAP との互換性のため、特殊文字にドットは使えません。ドットは、 eDirectory のコンテナ区切り文字です。特殊文字はハイフンだけ許可されます。LDAP サーチする場合は CN にカンマや@が入っているとURLと間違えられ問題があるからでしょう。

Sample Standards Document#

Tip: Valid Characters in eDirectory

GroupWise はデフォルトで eDirectory の CN (common name) がメールアドレスのローカル部分になります。

- という事で -

また、Unix 系システムであれば、大文字小文字はケースセンシティブなので、アカウント名に大文字小文字を混在させるのは好ましいものではありません。Windows 系システムではケースセンシティブではありません。

レガシーなホストコンピュータなどのプリケーションの一部では、やっぱり8バイトが最長ユーザアカウントというケースもあり、

どうも「ユーザアカウント長、文字制限は8文字以内の英数小文字とハイフン

というのが ID 管理を一般化した場合、一番確実なユーザ名を決めるネーミングスタンダード(命名規則)構築方法でしょう。

セキュリティ上、ユーザ名もパスワード同様に長ければ良いというご意見もありそうですが、、まずアカウント名を解析してからのパスワード解析はクラックするにはちょっと実際の現実感がありません。手元にアカウントリストとハッシュ化されたパスワードリストがあってこそクラックし甲斐があるでしょう。


- 文字数を8文字以内にする法則 -

- アカウントの長さは6~7文字の英数字 -

後に述べる「同姓同名問題」を解決させるため、8文字目は丸めて最大7文字とします。8文字使う場合は特例とします。もちろん、ユーザ名が"津・浦子"さんの場合 "tsuu" と短くなるのは構わないとは思いますが、必要に応じて文字を追加して6文字以上(tsuurrk)にする、と言った方法も良いと思います。8文字以上のIDを要求する場合、長ければトランケートして8文字に抑え、短すぎる場合、規則に従った文字列を加えると良いでしょう。

もちろん2バイト文字や特殊記号の利用は厳禁、特別に許されても”-”ハイフン位にしておきます。ただ ”-” 文字も検索のスクリプト条件で使われる可能性があるため、好ましいとは言えないという意見もあります。


- ファミリーネーム+ファーストネームイニシャル -

大規模な組織では、エンドユーザは相手のファーストネームを知らない事がほとんどです。したがって、ファミリーネームに識別子としてファーストネームのイニシャルを添付します。ファーストネームのイニシャルを1文字加えて「同姓異名」を区別します。

よく、イニシャル+ファミリーネームを使うところがありますが、本人や周囲の人には暗黙の了解ですが、初めて会ったあなたにメールで返事を書きたいと言った場合、ファーストネームを思い出せる人は少ないものです。ファミリーネームを優先的に使った方が良いでしょう。

- 同姓異名、同姓同名の区別 -

同姓同名、同姓異名で、ファーストネーム+イニシャルがダブる場合、後で追加するユーザは、ファミリーネームを一文字削除して、イニシャルの次の子音を一文字加えるのが一つのアイディアです。

Nakajima Kenji : nakajik
Nakajima Kensaku : nakajkn
Nakajima Kenichi : nakajkc
Nakajima Kenji(2): nakaknj

という感じです。

- 回避できない場合は8文字目を数値にする -

Nakakjik と nakajik2 ですね。これで例外があっても8文字に収まります。

- 表記はヘボン式 -

普段あまり意識しないのですが、日本語のユーザ名をローマ字化するための方法として、ヘボン式ローマ字と訓令式(日本式)ローマ字の二種類があります。一般的にパスポートなどの人名表記はヘボン式を基本としているので、ヘボン式に統一すべきでしょう。

ヘボン式ローマ字

東京都生活文化局 - ヘボン式ローマ字綴方表


また、外国人の場合、帰化しない限り日本の戸籍名がないので、原則として「通称」を使うことになります。その際も母語のスペルを使うのが原則でしょう。 Bob Smith さんの場合 "SmithB" であり "SuMiSuB" になってはいけないわけです。母語がアルファベットで表記できない場合もあるので、その例外措置も考慮すべきです。

まぁ、例外規則に命名規則+「本人の希望」というものがあってもいいわけです。


- 使ってはいけない文字(列)がある -

一般的にOSでファイル名として利用できない特殊記号や文字列、システム間で互換性のない文字(列)などは、or 条件の最大公倍数で禁忌とすべきです。

Unix 系OSでは "0","/" などが禁忌文字ですし、mac の場合は "/" だけ。":"や "|" とか "<>" もパイプに相当するためやめた方がいい。おそらく "Null" などの特殊なデバイスを意味するユーザIDもやめるべきでしょう。 Windows 系OSでは前述したように、特殊文字と "CON" とか "LPT1" とかのファイル名は使えません。ユーザアカウントはバッチやシェルで処理する場合もあるので、これらの全システムで禁忌文字は最大公約数として、使用してはいけないと思います。モノによっては "-" も文字列一括変換などのプログラムやシェル、バッチ処理で問題になるようです。たしかに「特殊文字が使えるシェルの書き方」というのがありますが、メンドクサイので禁忌文字とした方が無難でしょう。

また、当たり前ですが機種依存文字(○付数字やカッコつきの「株」「〒」)とかを含め、「ソ」「申」「表」などのシステム依存のいわゆる「5C文字」を含む。

つまりはすべての漢字を含め2バイトの文字は使うべきではありません

正しい日本語処理を行わないと想定外の動作をするアプリケーションやシェル、バッチファイルがあり得ます。
「英数小文字6~8バイト以内」とするのが && 条件で絞り込んだ最小公約数として命名規則に加えるべきです。


- 改姓をどうするか -

主に姓が変わるのは、お年頃の女性が多いと思いますが、男性でも次男坊、三男坊が一人娘を娶った場合なんかは、戸籍上「婿入り」するわけで、そのような場合はどうするのかという事も決めておかなければなりません。ユーザID=戸籍名なのか、ユーザID=通称名とするかですね。

「ユーザID=戸籍名」で、メールアドレスを決めてしまうと、幸か不幸か何度も結婚を繰り返しちゃった女性(男性も)、メールアドレスが頻繁に変わるわけですから、あまり好ましいものとは思えません。

本籍名を使うのか、通称を使うかの判断は「本人の希望があれば」認めるべきですが、業務上「頻繁に変更できない」というルールが必要です。


- 重要なのは文書化しておく事 -

忘れてならない事は、このような運用ルールを文書化し、担当課長のハンコを貰って、オーソライズしてもらう事です。後任者が誤って8文字以上のユーザアカウントを作ってトラブルって、後で仕様変更するような目にあっても、それはルールを超えた例外処理として余分な出費を認めてもらう十分なりゆうになるからです。

--
とまぁ、書いてみた訳ですが、実際に古くから運用しているディレクトリサービスで暗黙に8文字運用している現場で、たまたま9文字のユーザアカウントを作ってみると、システム全体に影響がでる現行システムの古い仕様上の互換性との問題点というのが見つかりました。新規登録のルーキーユーザなので、8文字に短くして問題が解決しています。

NetIQ の eDirectory を使ったID管理システム自体が、&& 条件で最小公倍数の 「8 文字英数子文字」をネーミングスタンダードのサンプルにしているので、どのシステムアカウントもこの文字数に従う事が無難です。

もっともこう言った問題点は社内システムでは問題になりますが、今時 google のアカウントを8バイトで確保するのは難しいので、一般的なインターネットサービスではあまり問題にならないかも知れません。ただウェブサービスの一部では、やはり文字数の制限がある訳でして、最低限8文字以上が必須だったりしますし。”8文字”(以下)が無難だ、というのはどこでもあり得る話なのです。

ログインIDが短いと、セキュリティ上問題があるんじゃないかとも思われますが、IDもパスワードもブランクで不明なアカウントをブルーフォートアタックかける場合、組み合わせは事実上無限なので、総当たり戦ではあまり関係ない、と思うのは私だけでしょうか。

ユーザのログインIDの文字数を調べてみると色々なことが解って勉強になりました。最低の「短過ぎるユーザIDは何文字が許されるか」も併せて調べるともっと面白いかも知れません。


PR 最後まで読んでくれてありがとうございます。お時間あればウィンドショッピングでも PR





by islandcenter | 2018-10-08 16:42 | Identity Management | Comments(0)

2018/1 より、gmail の認証方式が変わったらしく、Thunderbird からログインできなくなりました。




というより、昨年から、認証方式が変わったのですが、「Google アカウントで見つかった 1 件のセキュリティの問題を解決してください」との謎のメールが google 様から送り付けられ、通りにやったらログインできなくなってしまったという事。

a0056607_14542949.jpg

"Please login via your web browser"「ブラウザからログインしろ」、との事なので

a0056607_15030765.jpg


ブラウザから gmail.com にログインして、

右上の「アカウント」「ログインとセキュリティ」> 右のカラムの一番下にある「安全性の低いアプリの許可」: 「有効」に設定します。

a0056607_15063980.jpg

a0056607_14563357.jpg


次に Thunderbird 側の「ツール」「アカウント設定」から、gmail のアカウント名の下の「サーバー設定」から「認証方式」をトグルして "OAuth2" に変更してOKします。

a0056607_14570610.jpg

その後、Thunderbird 内部でブラウザが起動するので google のアカウントのパスワードを設定します。その後Thunderbird のマスターパスワードを問われるのでマスターパスワードで認証します。

安全性の低いアプリへのアクセスが有効になりました」というメールが google から届きます。

これで、gmail に Thunderbird からログインできるようになりました。

Oauth2 というのは、簡単に言うと ID/パスワード認証の仕組みではなく、「サービス vs. アプリケーション」の信頼関係、を作り出す仕組みだそうです。

この後、Thunderbird は、gmail にアクセスするために、google の パスワードではなく Thunderbird のマスターパスワードを要求するようになりました。


最後まで読んでいただきありがとうございます





サーバーをゴミ箱にしない工夫

Thunderbird, gmail, ログインできない, パスワードが間違っている, 認証されない, Windows, Linux, gmail にブラウザからログインできるが、Thunderbird からログインできない。


by islandcenter | 2018-01-28 15:01 | Identity Management | Comments(0)

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

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

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

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

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

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

このように一族郎党の中に「知り合い」(ここでは叔母さんの家)はあっても、その実情を知らない家(パーティションのレプリカ)があります。これをサブオーディネート(Sub Ordinate Reference) 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
by islandcenter | 2013-09-24 05:45 | Identity Management | 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管理のお話でした。
by islandcenter | 2013-09-23 14:08 | Identity Management | 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
by islandcenter | 2013-04-18 12:34 | Identity Management | Comments(0)

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

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

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

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

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

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

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

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

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

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

Novell ID Management

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

Novell セミナー情報

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

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

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

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

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

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

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

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

Novell Identity Management , Log management

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