11. SASL の使用法
OpenLDAP のクライアントとサーバは
SASL では、いくつもの業界標準の認証機構を利用できます。その中には
OpenLDAP ソフトウェアで提供する ldapsearch(1) や ldapmodify(1) などの標準クライアントツールは、デフォルトで slapd(8) サーバに対するユーザの認証を SASL で行います。基本認証サービスは LDAP 管理者によるわずかな作業でセットアップできます。これによりユーザが自分の LDAP エントリとしてサーバに認証されるようになります。さらにもう少し作業すれば、ユーザとサービスが SASL の代理認可機能を利用できるようになります。これにより、認証されたユーザあるいはサービスの ID を別のユーザあるいはサービスに切替えられるようになります。
この章は Cyrus SASL パッケージに付属の文書 Cyrus SASL for System Administrators (doc/sysadmin.html) を既に読んでいて、Cyrus SASL のインストール作業を行ったことがあることを前提に説明します。OpenLDAP ソフトウェアで SASL を利用できるようにする前には Cyrus SASL の sample_client と sample_server を使って、SASL が適切にインストールされているかをテストするべきです。
以降の文においてユーザという用語は、 ldapsearch(1) などの LDAP クライアントで LDAP サーバに接続する人あるいはアプリケーション実体を指します。つまり、 ユーザという用語は LDAP クライアントを利用する個人だけでなく、人が直接扱うことなしに LDAP クライアント操作を発行するアプリケーション実体にも適用されます。たとえば、LDAP サーバに保持されている情報にアクセスするために LDAP 操作を利用する e-mail サーバはアプリケーション実体です。
11.1. SASL によるセキュリティ上の考慮事項
SASL は多くの認証機構を提供します。この節では、セキュリティ上の考慮事項について概説します。
PLAIN や LOGIN といった機構は、LDAP の簡易認証より優れたセキュリティを提供しません。 簡易認証と同様、そのような機構は適切な所に十分なセキュリティ保護をすることなしに使うべきでありません。これらの機構は
DIGEST-MD5 機構は、LDAPv3 において実現が必須の認証機構です。 DIGEST-MD5 は信頼できるサードパーティ認証システム(Kerberos や公開鍵システムなど)に比べて強力な認証機構とは言えませんが、多くの攻撃に対抗するのに効果的な保護を提供します。CRAM-MD5 機構と違って、DIGEST-MD5 機構は選択平文攻撃(chosen plaintext attack)を防ぎます。 DIGEST-MD5 は平文パスワード機構を利用するよりも勧められます。 CRAM-MD5 機構は、より優れた DIGEST-MD5 があるので推奨しません。 DIGEST-MD5 の利用法については後述します。
GSSAPI 機構は安全な認証サービスを提供するために Kerberos V を利用します。KERBEROS_V4 機構では Kerberos IV を利用した認証サービスを提供します。Kerberos は安全で、小規模と大規模の両方の企業システムに適した分散認証システムとみなされていています。 GSSAPI と KERBEROS_V4 の利用法については後述します。
EXTERNAL 機構は
他にも
11.2. SASL 認証
基本的な SASL による認証ができるようにするには、いくつかの段階をふみます。第一段階では、セキュリティシステムを使ってクライアントプログラムと通信できるように slapd サーバ環境を設定します。これには普通、サービス鍵、公開鍵、その他の秘密の形式の設定が関わります。第二段階では、認証 ID を LDAP の DN にマッピングします。これはエントリがディレクトリ内にどのように配置されているかによります。第一段階については、次の節で例として Kerberos V4 機構を用いて説明します。認証機構により必要となる設定はどれも似ていますが、 SASL で利用できる機構すべてについて説明することは、この節の範囲外です。第二段階については、認証 ID のマッピングの節で説明します。
11.2.1. GSSAPI
この節では OpenLDAP での SASL GSSAPI 機構と Kerberos V の利用法について説明します。この節の説明は、利用するサイトに Kerberos V がインストールされていて、管理者が Kerberos V システムの操作についてよく知っていて、ユーザが Kerberos V の利用法について教育されていることを前提にしています。この節はまた、管理者が Configuring GSSAPI and Cyrus SASL (Cyrus SASL の配布ソースに含まれているファイル doc/gssapi) を読んでいて、GSSAPI 機構の利用法についてよく知っていて、 Cyrus SASL の提供する sample_server と sample_client を使った動作検証に成功していることを前提にしています。 Kerberos についての一般的な情報は http://web.mit.edu/kerberos/www/ から入手できます。
slapd(8) で GSSAPI 機構を使うには、まず ldap サービスが動作するホストのレルムにおいて ldap サービスのためのプリンシパルを持ったサービス鍵を作成しなければなりません。たとえばホスト directory.example.com で slapd を動かしていてレルムが EXAMPLE.COM であるとすれば、次のプリンシパルを持ったサービス鍵を作成する必要があります。
ldap/directory.example.com@EXAMPLE.COM
slapd(8) が動作するには、このサービス鍵にアクセスできなければなりません。そのようにするには一般にサービス鍵を keytab ファイル /etc/krb5.keytab に置きます。keytab の位置設定についての情報は Kerberos と Cyrus SASL の文書を参照してください。
ディレクトリの認証に GSSAPI 機構を使う場合、ユーザは LDAP クライアントを起動する前に TGT (Ticket Granting Ticket)を取得しておきます。 OpenLDAP クライアントツールを使う場合、ユーザはコマンドオプションとして -Y GSSAPI を指定することにより GSSAPI 機構の利用を指示します。
認証と認可の目的のために slapd(8) は次の形式の認証要求 DN を生成します。
uid=<primary[/instance]>,cn=<realm>,cn=gssapi,cn=auth
たとえば Kerberos プリンシパル kurt@EXAMPLE.COM を持つユーザは次の DN を持つことになります。
uid=kurt,cn=example.com,cn=gssapi,cn=auth
プリンシパルが ursula/admin@FOREIGN.REALM であれば DN は次のようになります。
uid=ursula/admin,cn=foreign.realm,cn=gssapi,cn=auth
この認証要求 DN は適正な LDAP DN フォーマットにしたがっているので、そのまま ACL や groupOfNames の "member" 属性に指定できます。あるいは認証 DN は使う前にマッピングしておくこともできます。これについて詳しくは認証 ID のマッピングを参照してください。
11.2.2. KERBEROS_V4
この節では OpenLDAP での SASL KERBEROS_V4 機構の利用法について説明します。この節の説明は、Kerberos IV セキュリティシステムの動作についてよく知っていて、利用するサイトに Kerberos IV がインストールされていることを前提にしています。ユーザは、認証ポリシー、Kerberos チケットキャッシュにある証明書を受け取る方法、期限切れの証明書をリフレッシュする方法についてよく知っているべきです。
注記：KERBEROS_V4 と Kerberos IV は、より優れた GSSAPI と Kerberos V があるので推奨しません。
クライアントプログラムは、LDAP サーバへの接続に使うためのセッション鍵を得られる必要があります。これにより LDAP サーバはユーザの ID を知ることができ、クライアントは接続する適正なサーバを知ることができます。暗合化層を使うようにしているのであれば、そのオプションの協定を助けるためにセッション鍵を使うこともできます。
slapd サーバは "ldap" というサービスを動かし、サーバはサービス鍵を持つ srvtab ファイルを要求します。 SASL 対応のクライアントプログラムはユーザの TGT (Ticket Granting Ticket) を持つ "ldap" サービスチケッットを得ます。このチケットには OpenLDAP サーバのホスト名に一致するインスタンスが付きます。たとえばレルムが EXAMPLE.COM という名前であり、 slapd サーバが directory.example.com という名前のホストで動作しているならば、そのサーバの /etc/srvtab ファイルは次のサービス鍵を持ちます。
ldap.directory@EXAMPLE.COM
LDAP クライアントが KERBEROS_IV 機構を利用してディレクトリにユーザの認証をするときには、同じプリンシパルのセッション鍵を要求します。これはチケットキャッシュからか、kerberos サーバから新しいものを得ることにより達成されます。これは TGT が利用可能であり、キャッシュ中で有効であることを要求します。セッション鍵が得られないか期限切れの場合、クライアントは次のメッセージを出力します。
ldap_sasl_interactive_bind_s: Local error
サービスチケットを得ると、ユーザの身元の証明として LDAP サーバに渡されます。サーバは SASL ライブラリ関数を用いてサービスチケットから身元とレルムを抽出して、それらを次の形式の認証要求 DN に変換します。
uid=<username>,cn=<realm>,cn=<mechanism>,cn=auth
先の例のレルムで、ユーザ名が "adamson" であるとすれば認証要求 DN は次のようになります。
uid=adamsom,cn=example.com,cn=kerberos_v4,cn=auth
この認証要求 DN はそのまま ACL に指定できますし、使う前にマッピングしておくこともできます。これについて詳しくは認証 ID のマッピングを参照してください。
11.2.3. DIGEST-MD5
この節では SASL DIGEST-MD5 機構の利用法について説明します。この認証方式ではディレクトリ内あるいは Cyrus SASL 用のデータベースに格納されたシークレットを使います。 DIGEST-MD5 はシークレット(普通はパスワード)を共有するクライアントとサーバに依存します。サーバはチャレンジを作成し、クライアントは共有されたシークレットを知っていることを証明する応答を返します。これでシークレットを単純にネットワーク上に送るよりも安全性がかなり増します。
Cyrus SASL は共有シークレット機構をいくつかサポートしています。この機構では平文パスワードにアクセスする必要があります (この点はネットワーク上に平文パスワードを渡し、サーバがハッシュ化したパスワードを格納できる機構と違っています)。
サーバ側の共有シークレットは、Cyrus SASL 自身の saskdb データベース、saslauthd 経由でアクセスされる外部システム、 LDAP データベーズ自身に格納できます。いずれの場合にもファイルのアクセス権や LDAP のアクセス制御でパスワードが漏洩しないようにすることが極めて重要です。この節で説明する設定とコマンドは Cyrus SASL 2.1 の利用を前提にします。
シークレットを sasldb に格納するには、単純に saslpasswd2 コマンドでユーザを追加します。
saslpasswd2 -c <username>
このようなユーザのパスワードは saslpasswd2 で管理しなければなりません。
シークレットを LDAP ディレクトリに格納するには userPassword 属性に平文パスワードを置きます。また LDAP パスワード更新操作によるパスワード設定でも平文で格納されるよう slapd.conf に次のオプションを追加しておく必要があります。
password-hash {CLEARTEXT}
この手段で格納したパスワードはを管理するには ldappasswd(1) を使うか、単純に userPassword 属性を変更します。パスワードがどこに格納されているかにかかわらず、認証要求の DN からユーザの DN へのマッピングは必要となるでしょう。
DIGEST-MD5 機構は認証 ID から次の形式の DN を生成します。
uid=<username>,cn=<realm>,cn=digest-md5,cn=auth
デフォルトのレルムが使われるなら、次に示すように DN からレルムが省略されます。
uid=<username>,cn=digest-md5,cn=auth
このような認証 ID のオプションのマッピングに関する情報については後述の
適切にマッピングを行っておけば、ユーザは LDAP 操作の実行時に SASL ID を指定でき、sasldb やディレクトリ内に格納されたパスワードが認証を確認するために使われます。たとえばディレクトリエントリによって識別されるユーザが次のものであるとします。
dn: cn=Andrew Findlay+uid=u000997,dc=example,dc=com
objectclass: inetOrgPerson
objectclass: person
sn: Findlay
uid: u000997
userPassword: secret
この場合、次のような形式でコマンドを実行できます。
ldapsearch -Y DIGEST-MD5 -U u000997 ...
注記：上の例においては(-X で指定するなどした)認可 ID を与えていません。 SASL 代理認可を行うつもりが無いのであれば認可 ID は指定しません。サーバは(後述するように)認証 ID から認可 ID を推定します。
11.2.4. 認証 ID のマッピング
slapd サーバの認証機構は認証するユーザの「ユーザ名」を獲得するのに SASL ライブラリ関数を利用します。ユーザ名は基盤の認証機構が利用しているものを基にします。このユーザ名は認証機構の名前空間にあり、通常の LDAP の名前空間にはありません。上の節で説明したように、ユーザ名は次の形式の認証要求 DN に再構成されます。
uid=<username>,cn=<realm>,cn=<mechanism>,cn=auth
認証機構 <mechanism> がレルム(realm)の概念を利用しない場合には次の形式になります。認証でデフォルトのレルムを使うと、レルム部分は除かれます。
uid=<username>,cn=<mechanism>,cn=auth
ldapwhoami(1) コマンドは、ユーザに関連づけられた ID を決定するのに使えます。これはマッピングの適正な機能を決定するのに有用です。
これは、上の形式の LDAP エントリを LDAP データベースに入れておくということではありません。LDAP で認証しようとする人それぞれについて LDAP エントリがあって、ディレクトリツリーに配置されているでしょうが、ツリーは cn=auth から始まっていないでしょう。しかし「ユーザ名」とその人の LDAP エントリの間に明確な対応関係があれば、認証要求 DN をユーザの認証 DNに自動的にマッピングするように LDAP サーバを設定できます。
注記：認証要求 DN もマッピングの結果から得られるユーザの認証 DN も、対応するエントリがディレクトリ中に存在することを要求されません。しかし、ディレクトリ中に存在していれば追加の機能を利用できます(後述)。
LDAP 管理者は、認証要求 DN をユーザの認証 DN にどうマッピングするかを slapd サーバに伝える必要があります。これを行うには、一つ以上の authz-regexp ディレクティブを slapd.conf(5) ファイルに加えます。このディレクティブは次のように二つの引数をとります。
authz-regexp <search pattern> <replacement pattern>
認証要求 DN は、正規表現関数 regcomp() と regexec() を使って検索パターン <search pattern> と比較され、一致したら置換パターン <replacement pattern> で書き換えられます。複数の authz-regexp ディレクティブがあった場合には、認証 ID に一致する最初の検索パターンが使われます。置換パターンから出力された文字列はユーザの認証 DN あるいは LDAP URL となるべきです。置換文字列が DN を生成する場合、この DN を持つエントリがこのサーバに保持されている必要はありません。置換文字列が LDAP URL を生成する場合、その LDAP URL はこのサーバによって保持される１つのエントリに評価されなければなりません。
検索パターンには regexec(3C) で利用できる正規表現文字を含めることができます。中でもよく使う文字にはドット "."、アスタリスク "*"、左括弧 "(" と右括弧 ")" があります。基本的にドットは任意の１文字に一致し、アスタリスクは直前の文字あるいはパターンの０回以上の繰り返しに一致し、括弧で囲まれた語は置換パターンのために記憶されます。
置換パターンはユーザを示す DN あるいは URL を生成します。認証要求 DN の中で検索パターン中の括弧で囲まれた文字列に一致する部分は変数 "$1" に格納されます。変数 "$1" は置換パターン中に置くことができるので、認証要求 DN の部分文字列を使って置換することができるわけです。検索パターン中に括弧で囲まれたものが複数ある場合には、変数 $2, $3 と使われていきます。
11.2.5. 直接マッピング
可能であれば、認証要求 DN をユーザの DN に直接にマッピングすることを勧めます。ユーザの DN の検索にかかる負荷を回避できるという利点に加えて、利用するサーバが保持していないエントリを参照する DN へのマッピングも可能になります。
たとえば次の認証要求 DN があり
uid=adamson,cn=example.com,cn=gssapi,cn=auth
次のユーザの実際の LDAP エントリにマッピングするとします。
uid=adamson,ou=people,dc=example,dc=com
この場合、次のような sasl-regexp ディレクティブを slapd.conf(5) に指定します。
authz-regexp
uid=([^,]*),cn=example.com,cn=gssapi,cn=auth
uid=$1,ou=people,dc=example,dc=com
より緩やかな規則を使って次のようにも書けます。
authz-regexp
uid=([^,]*),cn=[^,]*,cn=auth
uid=$1,ou=people,dc=example,dc=com
しかし検索パターンの設定を緩やかにしすぎないよう注意してください。緩くしすぎると、誤ってアクセス件を持つべきでない人の DN を認証してしまうかもしれないからです。１つの緩いディレクティブでセキュリティホールを作ってしまうよりは、複数の厳しいディレクティブを書いたほうがよいです。利用するサイトに１つの認証機構しか無く、レルムも無いか使うとしても１つだけの場合、認証 ID と LDAP DN を１つの authz-regexp ディレクティブでマップできるかもしれません。
レルムを明示的に指定することもあれば省略することもあることを忘れないでください。このためには、それぞれの場合のために個別の authz-regexp ディレクティブを用意し、明示的なレルムを持つエントリ用を先に指定しておくことが求められるでしょう。
11.2.6. 検索を用いたマッピング
LDAP URL へマッピングすることが妥当な場合が多々あります。たとえばサイトにより ou=accounting ツリーもあれば ou=engineering ツリーもあるなど、LDAP ツリーが複数の領域に分かれていて、人々がそれらのツリーに散らばっている場合があります。また、適切なマッピングを行うためにユーザの情報を元にしなければならない場合があります。先の例であげた認証要求 DN を次に示すエントリにマッピングする必要がある場合を考えてみてください。
dn: cn=Mark Adamson,ou=People,dc=Example,dc=COM
objectclass: person
cn: Mark Adamson
uid: adamson
このような場合、認証要求 DN の情報だけではユーザの DN を直接に導き出すのに不十分であり、ユーザの DN 検索する必要があります。このような状況に対処するために {EX:authz-regexp ディレクティブの置換パターンに LDAP URL を指定できます。指定した URL は、人々の認証 DN を発見するために LDAP データベースを内部検索するのに利用されます。
LDAP URL は他の URL と同様に次の形式を持ちます。
ldap://<host>/<base>?<attrs>?<scope>?<filter>
これは LDAP 検索を行うのに必要な要素をすべて含んでいます。<host> はサーバの名前、<base> は検索ベースの LDAP DN、<attrs> は取得する LDAP 属性、<scope> は３つの選択肢 "base", "one", "sub" のいずれか、<filter> は LDAP 検索フィルタです。検索は当該サーバ内の LDAP DN が対象なので <host> 部分は空にすべきです。 DN だけが目的であるので <attrs> 部分も無視します。これら２つの要素は空ながらも、文字列中のどこに何の情報があるのかが明らかになるように、URL のフォーマットに残ります。
先の例にある人は実際に認証ユーザ名 "adamson" を持っていて、その情報は LDAP エントリの属性 "uid" に保持していたとします。この場合 authz-regexp ディレクティブは次のように記述できます。
authz-regexp
uid=(.*),cn=example.com,cn=kerberos_v4,cn=auth
ldap:///ou=person,dc=example,dc=com??sub?(uid=$1)
これではまず slapd サーバ内で LDAP データベースの内部検索を行います。検索が１エントリだけを返す場合、それがユーザ の DN となるよう受け付けられます。検索が複数のエントリを返す場合、もしくは該当するエントリが無い場合、認証は失敗して、ユーザの接続は認証要求 DN としての束縛が残ります。
URL の検索フィルタ <filter> で使う属性には、検索が速くなるように索引を付けておくべきです。もし索引が付いていなければ、認証ステップだけでかなり時間がかかってしまい、ユーザはサーバがダウンしていると思うかもしれません。
より込み入ったサイトでは利用形態の中に複数のレルムがあって、ディレクトリの異なるサブツリーにマッピングしているかもしれません。このような状況は、次の形式の文で処理できます。
# Match Engineering realm
authz-regexp
uid=([^,]*),cn=engineering.example.com,cn=digest-md5,cn=auth
ldap:///dc=eng,dc=example,dc=com??one?(&(uid=$1)(objectClass=person))
# Match Accounting realm
authz-regexp
uid=([^,].*),cn=accounting.example.com,cn=digest-md5,cn=auth
ldap:///dc=accounting,dc=example,dc=com??one?(&(uid=$1)(objectClass=person))
# Default realm is customers.example.com
authz-regexp
uid=([^,]*),cn=digest-md5,cn=auth
ldap:///dc=customers,dc=example,dc=com??one?(&(uid=$1)(objectClass=person))
ここでは、レルム名が UID の一部になっている可能性を考慮して、明示的に名前の付いたレルムを優先して処理するようにしています。また、妥当なエントリに絞りこめるようにスコープとフィルタを利用しています。
より詳しくは slapd.conf(5) を参照してください。
11.3. SASL 代理認可
SASL は代理認可 (proxy authorization)として知られる機能を提供します。これは、認証ユーザが他のユーザに代わって要求を行えるものです。このステップはユーザが認証 DN を得た後に起き、サーバへの認可 ID 送信を伴います。そしてサーバが認可するかしないかを決定します認可されれば、ユーザの LDAP 接続が認可 ID から生成されるバインド DN に切り替わり、LDAP セッションは新しい認可 DN のアクセスで先に進みます。
認可するかの決定は、LDAP が動作しているサイトの規則とポリシに依存するので、 SASL 単独ではこれを行えません。 SASL ライブラリは認可の決定をサーバに任せます。 LDAP 管理者は、LDAP データベースにあるエントリに情報を追加することにより誰がどの ID を認可するのかのガイドラインを設定します。デフォルトで認可機能は無効になっているので、これを利用する前に LDAP 管理者は明示的に設定しなければなりません。
11.3.1. 代理認可の用途
この種のサービスは、ある実体が多くの他のユーザに代わって何かを行うときに有用です。たとえば、ユーザが LDAP エントリにある個人情報を変更するための web ページに行くとします。ユーザは身分を証明するために web サーバに対して認証を行いますが、 web サーバ CGI は、目的の情報を変更するユーザとして LDAP サーバに対して認証できません。代わりに web サーバはそれ自体をサービス ID として LDAP サーバに認証します。たとえば次のような DN で認証します。
cn=WebUpdate,dc=example,dc=com
そして、ユーザの DN に SASL 認可します。このように認可された後、CGI はユーザの LDAP エントリの変更ができるとともに、slapd サーバが ACL を扱う限りにおいて、クライアントにユーザ自身がいるのと変わらなくなります。ユーザは直接に LDAP サーバに接続して認証することもできますが、 LDAP クライアントである Web ページが内部で何をしていたかについての情報を調べなければならないでしょう。
代理認可はまた、データベースへのアクセス権限のより大きなアカウントへのアクセスを制限するためにも使える。そのようなアカウントは(slapd.conf(5) に指定した root DN であっても) 自分の DN に認可できる人を格納した正格リストを持てる。 LDAP データベースの変更は、その DN によってのみ許可されるようにし、その DN になるためにユーザはまずリストにある人のいずれかとして認証しなければなりません。これにより LDAP データベースを変更した人をよりよく検査できます。ユーザが直接に権限のあるアカウントへの認証できるようであると、検査が難しくなります。
代理認可に成功すると、LDAP 接続に利用した元の DN は、認可要求に指定した新しい DN で置き換えられます。サービスプログラムが自分の認証 DN で認証を行った後に他の DN へ認可を行い、1 LDAPセッションの間に異なる複数の ID に切替えると、別の DN への認可(または別の代理認可機構の利用)の前にそれぞれ自分の DN で認証する必要があります。 slapd サーバは、他の DN への切替えにあたってサービスプログラムの能力を記録を保持しません。 Kerberos のような認証機構においては、チケットの有効期間である数時間の間、ユーザの TGT と "ldap" セッションキーが正当であるので、認証のやり直しは Kerberos サーバへの複数接続を必要としないでしょう。
11.3.2. SASL 認可 ID
SASL 認可 ID は ldapsearch(1) その他のツールの -X スィッチ、あるいは lutil_sasl_defaults() 関数のパラーメータ *authzid に指定することにより LDAP サーバに送られます。この ID は次の２つの形式のいずれかになります。
u:<username>
あるいは
dn:<dn>
１番目の形式の <username> は先の認証 ID と同じ名前空間のものになります。これは基盤の認証機構が参照するユーザ名です。この形式の認可 ID は、認証処理で使われていたのと同じ機能によって DN フォーマットに変換され、次の形式の認可要求 DNを作成します。
uid=<username>,cn=<realm>,cn=<mechanism>,cn=auth
次にこの認可要求 DN は、データベースにある正当な認可 DN に変換するために、認証と同様に authz-regexp の処理を行います。 LDAP URLの検索の失敗によって変換できなければ、認可要求は "inappropriate access" で失敗します。さもなければ、変換後の DN が承認を受けるための正当な認可 DN となります。
認可 ID に "dn:" を接頭辞に持つ２番目の形式を与えたならば、接頭辞の後の文字列が承認を受けるための認可 DN となります。
11.3.3. 代理認可規則
slapd が認可 DN を得ると実際の承認手続きが始まります。認可を可能にするために LDAP 管理者が LDAP エントリに置くことのできる次の２つの属性があります。
authzTo
authzFrom
この両方とも複数値をとることができます。属性 authzTo は認可元の規則です。認証 DN が許可する認可 DN が何であるかを、認証 DN のエントリの saslAuthzTo に設定します。属性 saslAuthzFrom は認可先の規則です。認可 DN がその認証 DN から許可されているかを認可 DN のエントリの saslAuthzFrom に設定します。
どちらの認可ポリシ属性を利用するかは管理者に委ねられています。認可元の規則が人の認証 DN エントリで最初に検査され、どの authzTo 規則も認可が許されるよう指定されていなければ、認可 DN エントリの authzFrom 規則が検査されます。要求を履行するためのどちらの指定もなければ、要求は拒否されます。デフォルトの振舞は認可要求を拒否するので、規則は要求を許可する指定となります。認可を取り消す指定はありません。
この２つの属性の値は authz-regexp ディレクティブの置換パターンと同じ形式で、 DN か LDAP URL のどれかになります。たとえば authzTo の値が DN であれば、その DN は認証するユーザが認可される先のものになります。authzTo の値が LDAP URL であれば URL を使って LDAP データベースの内部検索を行い、その検索の結果が 認証するユーザが認可される先の DN になります。次に示す LDAP エントリがあったとすると、 cn=WebUpdate,dc=example,dc=com として認証されるユーザは dc=example,dc=com を検索ベースとして、オブジェクトクラスが Person である任意の LDAP エントリに認可可能です。
dn: cn=WebUpdate,dc=example,dc=com
authzTo: ldap:///dc=example,dc=com??sub?(objectclass=person)
11.3.3.1. 代理認可規則についての注記
authzTo と authzFrom 属性に指定した LDAP URL は DN の集合を返します。返された各 DN が検査されます。検索結果が大きな集合となる場合、認可処理は待ちきれないほど長時間になる可能性があります。また、検索は slapd により索引付けられている属性について行うべきです。
authzFrom と authzTo のためのより高速な規則を作成するために、属性の値に正規表現文字を入れた DN を指定できます。つまり次に示すような規則を指定できます。
authzTo: uid=[^,]*,dc=example,dc=com
この指定は、認証ユーザが与えた正規表現パターンに一致する任意の DN に認可可能であることを意味します。この正規表現による比較は、 (uid=*) で検索するよりも高速に評価できます。
さらには認可規則の値は２つの形式のいずれかでなければなりません。つまり LDAP URL か DN (正規表現あり/なし)かです。 "ldap://" で始まらないものは DN として扱われます。認可規則として "u:<username>" 形式の認証 ID を入れることは許されていません。
11.3.3.2. ポリシの構築
authzFrom と authzTo のどの種の規則を使うかの決定は、利用するサイトのソリューションに依存します。たとえば与えた ID になる人の重合が検索フィルタで容易に書けるようであれば単一の認可先の規則を書けるでしょう。人の集合が検索フィルタで容易に書けず、人の集合が小さいなら、代理認可の実行が許される人のそれぞれのエントリに認可元の規則を書いたほうがよいでしょう。
デフォルトで代理認可規則の処理が無効になっています。認可を有効にするためには slapd.conf(5) ファイルに authz-policy ディレクティブを設定しなければなりません。このディレクティブには規則が無いことを意味する none (デフォルト)、認可元の規則を用いることを意味する from、認可先の規則を用いることを意味する to、認可元と認可先の両方の規則を用いることを意味する both を指定できます。
認証先の規則は非常に強力です。通常のユーザが自分のエントリの authzTo 属性を書くアクセス権を持っていれば、他のどんな人にも認可が許されるように規則を書けてしまいます。したがって、認可先の規則を用いる場合には、特権を持ったユーザにのみ authzTo 属性の設定を許すよう ACL で保護すべきです。