■ 更新オペレーション

おね〜さんと、

ほげたんのっ!!

3 Minutes Networking、

Supplement !!

さてさて〜、機能モデルの話の続きだったわね。
LDAPの機能には次のものがあるって話をしたんだけど。

うん。認証オペレーションと、検索・比較オペレーションが前回の話だったよね。

そうね。LDAPの操作をする場合必ず行う「認証」と。
ディレクトリサービスの根幹である「検索・比較」の2つを説明したわけ。

だったわけ。

さて、今回はまず最後の一つ、「更新オペレーション」をやりましょう。
え〜っと、まず「add」ね。

「追加」だね。

そうね、それ以外の解釈はしようがないしね。
え〜っと、DITにエントリを追加するオペレーションね。

そのまんまだね。

まぁ、それ以外にどうしようもないでしょ。指定した上位エントリの下に新規にエントリを追加するってことね。
なので、存在しない上位エントリを指定するとエラーになる、と。

そりゃそうだよ。

あと、DNが同じものを追加できない。まぁ、これも当たり前ね。

ですよね。

次行きましょう。次は「delete」ね。

「削除」だね。

DITのリーフエントリを削除するオペレーションってことね。

りーふえんとり？ リーフって、「葉」だっけ。

そう、下位エントリを持たないエントリのことね。つまり、下位エントリを持つ上位エントリは削除できないってことね。

それって不便じゃない？

それはLDAPクライアントソフトで対処すればいいんじゃない？ 「上位エントリ削除要求」→「上位エントリに含まれる下位検索」→「下位エントリ個別削除」→「上位エントリ削除」って手順踏めばいいでしょ。

あぁ、なるほど。

あと削除のポイントはもう1つ、別名エントリは別名エントリだけを削除ところね。

ん〜っと、参照先の実名エントリは削除しないってこと？

そういうこと。実名まで消しちゃったら困るからね。

次は…「modify」？ 「修正」？

「修正」、そうね。DITに存在するエントリの属性を変更することよね。
modifyにはさらに「add」「delete」「replace」の3つがあるの。

「追加」と「削除」と「再配置」？

「再配置」よりは「上書き」の方がしっくりくるかしら。指定したエントリの属性を追加・削除・上書きするオペレーションね。

んと、addとdeleteはともかく、modifyは複数の処理を一気に要求できるってことだね。

そうそう。で、そのうち1個でもできないと、処理自体が全部キャンセルされちゃう、と。

はー。

あと、ポイントとしては、DNの属性、まぁ正確にはRDNの属性なんだけど、RDN属性(識別属性)はdeleteでは変更できないってことかな。

ええっと、そのエントリの識別名として使われる属性は、削除できないってことでいいのかな？
まぁ、確かに。RDN属性削除しちゃったら、名前付けがおかしくなるもんね。

そういうこと。

でも、RDN属性が削除できないって、それを消したい場合はどうすればいいの？

そういう場合は違う属性をRDN属性にして、それから削除しちゃえばいいのよ。
そのための「modify-DN」なわけ。

「DN修正」ってことかな。

そうね。これは今説明したとある属性をRDN属性にするという意味と、もう1つ意味があるの。
DNを変更できるってことは、ほげたん、どういうこと？

識別名を変更できる？ 識別名を変更できると……どうなるんだろう？

DNってエントリと上位エントリのRDNを並べたものでしょ。つまり、上位エントリを変更できる＝エントリの位置を変更できるってことなのよ。

なるほど。

ちなみにこの上位エントリの変更は、LDAPv3からの操作ね。

DNはエントリで大事な属性だから、それ専用の操作があるんだね。

最後が「abandon」ね。

あばんだん？「放棄」？

そう。これは更新オペレーションからちょっと離れるけど。
直前のオペレーション要求をキャンセルする要求ってことね。

ん？ なんに使うの？

例えば、応答に時間がかかる検索要求をキャンセルさせたり、そういうことに使ったりとか。

ははぁ。なるほどだよ。

■ セキュリティモデル

さてさて〜、最後のモデルについて説明しましょ。セキュリティモデルね。
大雑把にわけて、次のセキュリティを考えてみると。

まず、認証のセキュリティ。これは認証オペレーションでやったわね。

bindだね。え〜っと、匿名認証と単純認証、SASL認証があったよね。

そうそう。ユーザ名なしの匿名認証、ユーザ名ありの単純認証、ユーザ名とパスワードの単純認証、SASLによるSASL認証、とあるわけね。

だったよね。

認証結果で、ユーザ名がわかるわけで、それによって「認可」を行うわけね。

認可はあれだよね。「認証によって判明したユーザの身元から、与える/与えないサービスを決定する」だったよね。

Kerberosのとこからそのまま引っ張ってきたわね。まぁ、その通り。つまり、ディレクトリにオペレーションが可能かどうか決定したりするわけね。

とあるユーザでは検索ができなかったり、検索はできても変更ができなかったり、そういうことだね。

そうそう。ただし、LDAPによってディレクトリに対する認可は設定されていないの。つまり、LDAPサーバの仕様で勝手にやれ、みたいな？
認証方式は決められてるんだけどね。

つまり、LDAPの認証方式によってユーザ名とパスワードは入手できるけど、それによってLDAPディレクトリがどうするかって決まってないってことかな？

そういうこと。例えば、LDAPディレクトリの代表例といえば、ActiveDirectoryだけど、そこでの認可はWindowsの方で決められてるわけね。

R2Nドメインでの、「Amino Emi」というエントリのセキュリティね。あ、ちなみに画面はWindows2000Serverでの画面ね。

ははぁ、上の画面だと、Account Operatorsだと、フルコントロールにチェック入ってるから、全部の操作が可能なんだね。

そゆことね。最後は通信路のセキュリティ。通信路のセキュリティといえば、暗号化なわけだけど。
LDAPはそーゆーの考えてないから。

考えてないんだ。

まぁ、だからTCP/IPで汎用的に使えるTLS/SSLに対応で暗号化しちゃえばいいんだけどね。
SSLを使用している場合のLDAPは、前も言ったけどLDAPSって呼ばれるから。

HTTPがHTTPSになるようなもんだね。

そゆことです。さて、LDAPも今回でいったん区切りかな。

え？そうなの？

うん。DITの複製とか、スキーマとか、オブジェクトクラスの話とかもしていいんだけど。
ま、LDAPの基礎はわかってもらえたかな、と。

そだね、基本的なところはわかった、のかな？

まぁ、ディレクトリサービスはわかってもらえたかもしれない、ってところで。
今回はこれでおしまい。

次回は？

どうしよっかな〜。
おね〜さんと、

ほげたんのっ!!

3分間ネットワーク、

サプリメントでした〜〜〜っ!!