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”で検索し、
有意な設定箇所が無いことを確認しております。

回答No.1

anmochi

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

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

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

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

２．ディレクトリーサービスのルールの範囲内で実現可能な方法を検討する。
　属性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であるような属性にするという選択もあります。

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