みんなの「教えて(疑問・質問)」にみんなで「答える」Q&Aコミュニティ

こんにちはゲストさん。会員登録(無料)して質問・回答してみよう!

締切り済みの質問

OpenLDAPの”uid”属性について質問です。

OpenLDAPの”uid”属性について質問です。

【環境】
RHEL5(64-bit)
OpenLDAP2.3.43

【質問内容】
OpenLDAPを認証サーバとして、Webアプリケーションを構築しようと考えています。

ユーザID:オブジェクトクラスinetOrgPersonにおける”uid”属性
パスワード:オブジェクトクラスPersonにおける”userPassword”属性

で作成していますが、1点困っています。
ユーザIDに大文字小文字の区別がされないのです。

この件、調べてみたところ、

uid属性の等価比較する場合のルール(EQUALITY)が
、大文字/小文字を区別しない

状態になっているのでは?と考えました。
OpenLDAP(に標準添付されるスキーマ定義ファイル)のデフォルト値としても
EQUALITY caseIgnoreMatch
となっているようです。

そこで、/etc/openldap/schema/core.schema の内容を確認したところ、
該当箇所は以下のようになっていました。

#attributetype ( 0.9.2342.19200300.100.1.1
#NAME ( 'uid' 'userid' )
#DESC 'RFC1274: user identifier'
#EQUALITY caseIgnoreMatch
#SUBSTR caseIgnoreSubstringsMatch
#SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )

また、他のスキーマ定義ファイルを見ても属性uidを定義している箇所は
存在しておりませんでした。


ここで疑問なのは、
・属性uidの定義箇所はコメントアウトされており、未設定に見える
・ですが、大文字小文字の判断の問題はあれど、属性値としてのuidは
 登録できているように見える

です。

・未記載の場合に適用されるデフォルト値があり、そちらを参照している

等あるのでしょうか?


最終的に当方が実施すべきと考えていることは、属性uidに対し
EQUALITY caseExactMatch
を実施する、とかんがえておりますが、上記の通りその実施箇所が
わからなくなっております。


以上、ご存じの方がいらっしゃれば御回答頂きたく存じます。


(参考)
slapd.confにて以下のように定義しており、他のスキーマ定義ファイルを
参照していることは無いと認識しております。

include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/その他、独自スキーマ

また、全てのスキーマ定義ファイルについて、キーワード”uid”で検索し、
有意な設定箇所が無いことを確認しております。

投稿日時 - 2010-10-28 16:19:40

QNo.6281237

困ってます

このQ&Aは役に立ちましたか?

4人が「このQ&Aが役に立った」と投票しています

回答(1)

ANo.1

>uid属性の等価比較する場合のルール(EQUALITY)が、大文字/小文字を区別しない
 たしかにuid属性はRFCにおいて定義上そうなっていますね。
 そして、OpenLDAPサーバーソフトウェアの中で、core.schemaなどにコメントで記述されているものはプログラムの中にハードコーディングされている模様です。試してみると分かりますがコメントを外してサーバーを起動してみると重複するスキーマというエラーになって起動できません。

> 最終的に当方が実施すべきと考えていることは、属性uidに対し
> EQUALITY caseExactMatch
> を実施する、とかんがえておりますが、上記の通りその実施箇所が
> わからなくなっております。
 前述の通りuid属性の中身を書き換えてOpenLDAPサーバーを起動する事はできません。また、一応、なんといいますか、OIDを上書きするのはディレクトリーサービス上してはいけない事になっています。なので、実施すべきことは「スキーマの拡張」という作業になるのですが、ディレクトリーサービスというシステムの中で、スキーマはIANAで厳密に管理されており、いわば「オレオレスキーマ」というものは作ってはいけない決まりになっています。スキーマの拡張には最終的にIANAに届け出る必要があるのです。

 以上の事より、3つの道のいずれかで対処する事になるかと思います。

1.スキーマには一切手を加えずに、検索時にcaseExactMatchルールを使う。
 例えば、今使われているフィルターが、ユーザー名で置き換わる部分を%uと表現するとして &((objectClass=inetOrgPerson)(uid=%u)) などという場合、uidは定義の通りcaseIgnoreMatchになりますが、これを &((objectClass=inetOrgPerson)(uid:caseExactMatch:=%u)) とする事で、uidに対する条件としてcaseExactMatchマッチングルールを使用して検索を行う事ができます。

2.ディレクトリーサービスのルールの範囲内で実現可能な方法を検討する。
 属性uid(のEQUALITY)がcaseIgnoreMatchなのは動かしようが無い事なので、caseExactMatchである別の属性を使用する事になります。
 OpenLDAPのスキーマ定義ファイル(RHEL5であれば/etc/openldap/schemaの中にあるファイル)で言うと、core.schemaの中に入っているスキーマの中ではrefくらいでしょうか。java.schemaの中にはjavaClassNameなどの属性があります。それをMUST属性としているauxiliaryなオブジェクトクラスのjavaNamingReferenseなどを付与して、uid属性の変わりにjavaClassName属性を認証の名前として使用する事で、caseExactMatchルールを用いて検索する事ができます。
「ユーザー名なのに属性javaClassNameを使うのか?」という問いに対しては、こんな自由な事ができるのがLDAP(と言うかディレクトリーサービス)がLDAPたるゆえんであり、なおかつディレクトリーサービスの枠内で実現されています。他にも、(homeDirectoryなど)構文がIA5 StringでマッチングルールがcaseExactIA5Matchであるような属性にするという選択もあります。

3.あえてディレクトリーサービスのルールを破る。
 前述の通り、ディレクトリーサービスでは、自分勝手に定義済み属性の属性値を変更したり、付与されていないOIDで属性やオブジェクトクラスを定義する事は許されません。
 私も技術者の端くれでソフトウェアシステムのルールの中で生きている以上、積極的に賛成する事はできかねますが、閉じたシステム構築の中で属性の改ざんやオレオレスキーマを作成する事は技術的に不可能ではありません。自前でcaseExactMatchな属性myUidを作り、inetOrgPersonをスキーマ拡張してmyUid属性をMUSTに追加したmyInetOrgPersonオブジェクトクラスを作る事もできる訳です。
 ただ、やはり後で収集がつかなくなる危険性もあるため、あえてこの手を選ぶのはどうしても1か2の方法が使えなかったら、だけにとどめておくのが良いでしょう。

投稿日時 - 2010-11-26 02:31:44

あなたにオススメの質問