この slapd.conf ファイルは、(すべてのバックエンドを含む) slapd 全般に適用する一連のグローバル設定オプションと、バックエンドの実体に 固有の情報を持つデータベースバックエンド定義が0個以上続いたものから成ります。
slapd.conf の一般的なフォーマットは次とおりです。
# comment - these options apply to every database
<global configuration options>
# first database definition & configuration options
database <backend 1 type>
<configuration options specific to backend 1>
# subsequent database definitions & configuration options
...
グローバル設定でも各バックエンド固有のセクションでもアクセス権情報を 設定できます。 バックエンド固有のアクセス制御ディレクティブは、そのバックエンドに 属するエントリ、すなわちそのネーミングコンテキストにしたがって適用 されます。バッグエントについて定義されたアクセス制御ディレクティブ が何も無い場合、グルーバル設定セクションの適切なディレクティブが 適用されます。
どのバックエンドにも属しないエントリ(rootDSE など)については 先頭のバックエンドのディレクティブ(とグローバル設定ディレクティブ) が適用されます。
以降の説明で、実際のテキストで置き換える引数はブラケット <> で示します。
<what> ::= *
| [dn[.<dnstyle>]=<DN>]
[filter=<ldapfilter>]
[attrs=<attrlist>[ val[.<style>]=<attrval>]]
ワイルドカード * はすべてのエントリを示します。
dn=<DN> は、そのネーミングコンテキストを基にしてエントリを選択します。
パターンはエントリの DN の文字列表現です。スタイル修飾子が base (デフォルト)または exact ( base の別名) であった場合にはパターンと同じ DN のエントリを示します。スタイル修飾子が one ( BR onelevel の同意語)であった場合には pattern の直下のエントリすべてを示します。スタイル修飾子が sub ( BR subtree の同意語)であった場合には、そのエントリ自体を含むサブツリーのエントリすべてを 示します。スタイル修飾子が children であった場合には、そのエントリ自体を含まないサブツリーのエントリすべてを 示します。
スタイル修飾子 <dnstyle> が regex であった場合、値は regex(7) に詳説されている正規表現パターンであることを意味します。 この正規表現パターンがエントリの DN の正規化された文字列表現と一致するか比較します。 パターンの正規表現形式は(まだ) UTF-8 をサポートしていません。
filter=<ldapfilter> は RFC 2254 に定義されている適正な LDAP フィルタを基にエントリを 選択します。
attrs=<attrlist> は、アクセス制御規則を適用する属性を選択します。 これは、属性型に加えて、エントリ自体へのアクセス権を示す entry 、エントリの子へのアクセス権を示す children をカンマで区切って並べたものです。このリストには objectClass 名も 指定でき、この objectClass によって要求/許可される属性すべてに 影響します。実際には <attrlist> 中の名前のうち前に @ の付いたものがオブジェクトクラス名として扱われます。前に ! の付いたものもオブジェクトクラス名として扱われますが、 この場合アクセス制御はそのオブジェクトクラスの必須でも オプションでも無い属性に作用します。
形式 attrs=<attr> val[.<style>]=<value> による指定は、単一の属性の特定の値へのアクセスを示します。 この場合には単一の属性型のみを与えられます。値のスタイル <style> が exact (デフォルト)である場合には、値の比較に属性の等価性の一致規則を適用します。 値のスタイル <style> が regex である場合は、指定の値を正規表現パターンとして扱います。 属性が DN 構文を持つ場合、値のスタイル <style> には base, onelevel, subtree, children のいずれかを指定でき、それぞれ base, onelevel, subtree, children 一致の結果になります。
引数 dn, filter, attrs については必要に応じて付加します。 これらはネーミングコンテキスト、値、属性型を基にしてアクセス規則を 適用するエントリを選択した結果に適用されます。
*
anonymous
users
self
dn[.<dnstyle>[,<modifier>]]=<DN>
dnattr=<attrname>
group[/<objectclass>[/<attrname>]]
[.<groupstyle>]=<group>
peername[.<peernamestyle>]=<peername>
sockname[.<style>]=<sockname>
domain[.<domainstyle>[,<modifier>]]=<domain>
sockurl[.<style>]=<sockurl>
set[.<setstyle>]=<pattern>
ssf=<n>
transport_ssf=<n>
tls_ssf=<n>
sasl_ssf=<n>
aci=<attrname>
<dnstyle>={{exact|base}|regex|sub(tree)|one(level)|children}
<groupstyle>={exact|expand}
<style>={exact|regex|expand}
<peernamestyle>={<style>|ip|path}
<domainstyle>={exact|regex|sub(tree)}
<setstyle>={exact|regex}
<modifier>={expand}
これらを組み合わせて指定することも可能です。
ワイルドカード * はあらゆるものを示します。
キーワード anonymous は、認証されてないクライアントにアクセス権を与えることを意味します。 これはたいてい、認証のためのリソース(たとえば userPassword 属性)に対する非認証クライアントのアクセスを認証目的に限るために利用されます。
キーワード users は認証されたクライアントにアクセス権を与えることを意味します。
キーワード self は、エントリへのアクセスをそのエントリ自体に与えることを意味します (たとえばアクセスされるエントリと要求するエントリが同じでなければ ならない)。
dn=<DN> は、一致する dn にアクセス権を与えることを意味します。 オプションのスタイル修飾子 dnstyle は、引数 <what> の dn 形式で指定できるものと同じです。 さらに regex スタイルでは、 <what> dn の部分一致を $<digit> で参照して部分文字列置換が可能です。 ここで digit は 1 から 9 までの数字です。 スタイル修飾子にはオプションの modifier を付加できます。これに指定できる唯一のものは expand であり、 dnstyle が regex で無くとも 部分一致の部分文字列置換が起きるようにします。 データベースの rootdn に完全一致する DN に ACL でアクセス件を与えるのは全く無駄なことです。 rootdn には暗にデータベース中のツリー全体について write 権限があります。
dnattr=<attrname> は、dn がアクセスされるエントリの属性 <attrname> に格納されているものの要求にアクセス権を与えることを意味します。
group=<group> は <group> によって指定された dn のグループエントリに格納された ものの要求にアクセス権を与えることを意味します。 オプションのパラメータ <objectclass> と <attrname> は、グループエントリの objectClass とメンバ attributeType を定義します。 オプションのスタイル修飾子 <style> には expand を指定でき、 <group> が regex (7) にしたがって(正規表現としてではなく)置換文字列として 展開されることを意味します。スタイル修飾子には exact も指定でき、厳密一致が利用されることを意味します。
静的グループについて attributeType には DistinguishedName か NameAndOptionalUID のどちらかの構文で指定しなければなりません。動的グループについて attributeType は labeledURI attributeType のサブタイプでなければなりません。 形式が ldap:///<base>??<scope>?<filter> である LDAP URI だけがローカルサーバ内での検索により、 動的グループで評価されます。
peername=<peername>, sockname=<sockname>, domain=<pattern>, sockurl=<sockurl> はアクセスを許可するために、 peername では接続してくるホストの IP アドレス(形式は IP=<ip>:<port> )またはホストの名付きパイプのファイル名(形式は PATH=<path> )、 sockname ではネームドパイプファイル名、 domain では接続してくるホストの名前、 sockurl では接続してくる URLと比較します。 group で説明したパターン一致のための style と同じものと regex スタイルを適用できます。 regex スタイルは、該当する接続パラメータの部分一致 expand と regex(7) 一致を意味します。 peername 節の exact スタイル(デフォルト)は クライアントの IP (接頭辞の IP= と末尾の :<port> も含む)、または名前付パイプでの接続の path (接頭辞の PATH= も含む) との完全一致です 特殊な ip スタイルは <peername>=<ip>[%<mask>][{<n>}], というパターンを解釈します。ここで <ip> と <mask> はドットで数字を区切った形式の IP とマスクであり、 <n> はブレース {} で囲った数字の形式で指定するオプションのポートです。 アクセス権の検査においては、 peername の IP 部分を抜き出し、接頭辞 IP= と :<port> 部分を取り除き、 <mask> でマスクした後にパターンの <ip> に対して比較します。 たとえば peername.ip=127.0.0.1 はローカルホストからの接続だけを許可し、 peername.ip=192.168.1.0%255.255.255.0 は 192.168.1 クラス C ドメインに属する IP からの接続を許可し、 peername.ip=192.168.1.16%255.255.255.240{9009} は同じドメインの 192.168.1.[16-31] からの接続でポート 9009 を使っている場合にのみ許可します。 特殊な path スタイルは名前付パイプでの接続の peername から PATH= を除いたものを解釈し、与えたパターンの完全一致を行います。 domain 節では subtree スタイルも適用できます。 これは完全修飾された名前が domain パターンと厳密一致するか、そのドットの後の修飾部が domain パターンと厳密一致すれば成功します。 expand スタイルを指定可能で、部分文字列置換したものとの完全一致比較を行います。 スタイル修飾子として expand を指定するほうが適切でしょう。 たとえば domain.subtree=example.com は www.example.com と一致しますが、www.anotherexample.com とは一致しません。 接続してくるホストの domain は、DNS の逆引によって判定します。 逆引は容易にだませるので、 As this lookup can easily be spoofed, use of the domain の利用はなるべく避けてください。デフォルトで逆引は無効になっています。 domain 節の オプションの修飾子 domainstyle には modifier オプションを付加できます。これに現時点で指定できる唯一のものは expand であり、 dn 節とほとんど同様に、 domainstyle が regex で無くとも 部分一致の部分文字列置換が起きるようにします。
set=<pattern> はまだ文書化されていない。
aci=<attrname> は、 アクセス制御がエントリ自体の attrname の値によって決定されることを意味します。 ACI は実験用です。これはコンパイル時に有効にしなければなりません。
ssf=<n>, transport_ssf=<n>, tls_ssf=<n>, sasl_ssf=<n> は、アクセス権を与えるのに要求する Security Strength Factor (ssf) を設定します。
<level> ::= none|auth|compare|search|read|write
<priv> ::= {=|+|-}{w|r|s|c|x|0}+
修飾子 self をつけると、操作がアクセスを要求しているユーザの名前に関する 場合だけに特定のアクセスレベルまたはアクセス権を持つような 特殊な操作を許します。 これは、要求のアクセスに束縛されたユーザを暗示します。 たとえば、 selfwrite では、グループのメンバ属性にアクセスにおいて、 グループのメンバリストから自分の DN の追加削除は 許されますが、他のメンバには何も影響を与えられません。
level のアクセスモデルでは、 アクセス権の追加解釈をします。 指定可能なレベルには none, auth, compare, search, read, write があります。各アクセスレベルはその前にあるアクセス権を含んでいます。 すなわち、 write アクセス権にはすべてのアクセス権があることを暗示します。 none は自明ですが、 auth アクセス権は、他のアクセス権なしで認証/認可操作( bind など)を行うための属性にアクセスを許すようにするものです。 これは、認証されていないクライアントにパスワードのような危険な情報への 最低限のアクセスレベルを与えるのに有用です。
priv アクセスモデルでは各節についてアクセス権を明示的に設定します。 記号 = は前に定義されたアクセス権をリセットします。 結果として最終的なアクセス権は、この節で定義したものだけになります。 記号 + と - は既存のアクセス権に対してアクセス権を追加/除去します。 アクセス権は w が書込み権、 r が読取り権、 s が検索権、 c が比較権、 x が認証権です。 １つの文には上記のアクセス権を複数個指定できます。 0 はアクセス権の無いことを示し、それ単独でのみ指定できます(すなわち +0)。
オプションの <control> はアクセス規則適用のフローを制御します。 これには次のものを指定できます。
stop
continue
break
stop はデフォルトで、一致した場合に後続のアクセス権設定の検査を行わない ことを意味します。他の２つの形式は access 節の処理を継続するために使います。 continue は同じ <access> 節の他の <who> の処理を継続し、結果としてアクセス権を徐々に変更していきます。 それに対して break は同じターゲットに一致する他の <access> 節を処理します。
(くだらない)例を次に示します。
access to dn.subtree="dc=example,dc=com" attrs=cn
by * =cs break
access to dn.subtree="ou=People,dc=example,dc=com"
by * +r
これは "dc=example,dc=com" 配下のエントリの検索と比較を許します。 これに加えて２番目の規則で "ou=People" サブツリーの読取りを許しています。 別の(さらにくだらない)例を次に示します。
access to dn.subtree="dc=example,dc=com" attrs=cn
by * =cs continue
by users +r
これはすべてのものに検索権と比較権を与え、これに加えて認証されたクライアント には読取り権を与えています。
add 操作は追加するエントリの疑似属性 entry に対する write (=w) 権限と、追加するエントリの親の疑似属性 children に対する write (=w) 権限を必要とします。
bind 操作は、ディレクトリに認証情報を持っている場合には、 認証情報を持つ属性(通常は userPassword )に対して auth (=x) 権限を必要とします。
compare 操作は、比較する属性に対する compare (=c) 権限を必要とします。
delete 操作は、削除するエントリの疑似属性 entry に対する write (=w) 権限と、削除するエントリの親の疑似属性 children に対する write (=w) 権限を必要とします。
modify 操作は、更新する属性に対する write (=w) 権限を必要とします。
modrdn 操作は、RDN を更新するエントリの疑似属性 entry に対する write (=w) 権限、RDN を更新するエントリの新旧の親の疑似属性 children に対する write (=w) 権限、新しい RDN に使う属性に対する write (=w) 権限を必要とし、 deleteoldrdn を 1 にする場合には旧 RDN に使っていた属性に対する Write (=w) も必要となります。
search 操作は、各エントリについて、 フィルタに指定する属性に対する search (=s) 権限、(エントリ自体に対する読み取りアクセスのために)疑似属性 entry に対する read (=r) 権限、要求した各属性に対する read (=r) 権限を必要とします。 また、紹介の生成で使われる各 referral オブジェクトについて search 操作は、 (referral オブジェクト自体に対する読み取りアクセスのために)疑似属性 entry に対する read (=r) 権限、referral 情報を保持する属性(一般には ref 属性)に対する read (=r) 権限を必要とします。
control により、特定の権限が必要となることもあります。 proxyAuthz control は、URI 正規表現マッピング( sasl-regexp ディレクティブの右側)の検索フィルタに指定したすべての属性に対して auth (=x) 権限を必要とします。 また、認可する ID の saslAuthzTo 属性や、認可される ID の saslAuthzFrom 属性に対して auth (=x) 権限を必要とします。
管理者は次の形式の規則を設定したとします。
access to dn.regex="dc=example,dc=com"
by ...
この設定によちサブツリー "dc=example,dc=com" の全エントリに一致することを期待しています。 しかし、この規則は実際には "dc=example,dc=com" を部分文字列に含むあらゆる DN に一致します。すなわち、この規則は "uid=joe,dc=example,dc=com" にも "dc=example,dc=com,uid=joe" にも一致します。
意図したように一致させるには次のように規則を明確に記述します。
access to dn.regex="^(.+,)?dc=example,dc=com$"
by ...
性能上の理由から次のように subtree スタイルを使うとより良くなります。
access to dn.subtree="dc=example,dc=com"
by ...
部分一致規則を記述する場合には、ムダな regex <dnstyle> を避けるようにしたほうがよいです。たとえば <what> 節に一致するユーザのサブツリーへのアクセスを許可する場合、 次のように指定きます。
access to dn.regex="^(.+,)?uid=([^,]+),dc=example,dc=com$"
by dn.regex="^uid=$1,dc=example,dc=com$$" write
by ...
しかし <who> 節については部分文字列置換があればよいので、 次のように指定したほうがより効率的です。
access to dn.regex="^(.+,)?uid=([^,]+),dc=example,dc=com$"
by dn.exact,expand="uid=$1,dc=example,dc=com" write
by ...
実際のところ regex の <dnstyle> は、部分文字列置換、 exact 、その他 DN 固有の <dnstyle> を暗に適用しますが、さもなければ明示する必要があります。
"OpenLDAP 管理者ガイド" (http://www.OpenLDAP.org/doc/admin/)