この 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
...
グローバル設定でも各バックエンド固有のセクションでもアクセス権情報を 設定できます。 バックエンド固有のアクセス制御ディレクティブは、そのバックエンドに 属するエントリ、すなわちそのネーミングコンテキストにしたがって適用 されます。バッグエントについて定義されたアクセス制御ディレクティブ が何も無い場合、グルーバル設定セクションの適切なディレクティブが 適用されます。
アクセス制御を指定しない場合、デフォルトのポリシーにより 誰もがどれでも読み取れるようにし、更新は rootdn にだけ 許可されます("access to * by * read" と同等)。 rootdn は常に「すべて」の読み書きが可能です。
どのバックエンドにも属しないエントリ(rootDSE など)については 先頭のバックエンドのディレクティブ(とグローバル設定ディレクティブ) が適用されます。
以降の説明で、実際のテキストで置き換える引数はブラケット <> で示します。
[dn[.<dnstyle>]=]<dnpattern>
filter=<ldapfilter>
attrs=<attrlist>[ val[/matchingRule][.<attrstyle>]=<attrval>]
この中で使われているものは次の形式を持ちます。
<dnstyle>={{exact|base(object)}|regex
|one(level)|sub(tree)|children}
<attrlist>={<attr>|[{!|@}]<objectClass>}[,<attrlist>]
<attrstyle>={{exact|base(object)}|regex
|one(level)|sub(tree)|children}
dn=<dnpattern> は、そのネーミングコンテキストを基にしてエントリを選択します。 dn= の部分は省略可能です。 <dnpattern> はエントリの DN の文字列表現です。 ワイルドカード * はすべてのエントリを表し、 dn の形式で指定しないことを示します。
<dnstyle> も省略可能ですが、あいまいさを避けるために dn= と <dnstyle> の両方とも指定することを勧めます。 base ( baseObject の同義語)、 デフォルト、 exact ( base の別名) であった場合には <dnpattern> と同じ DN のエントリを示します。スタイル修飾子が one ( BR onelevel の同意語)であった場合には <dnpattern> の直下のエントリすべてを示します。スタイル修飾子が sub ( BR subtree の同意語)であった場合には、 <dnpattern> のエントリ自体を含むサブツリーのエントリすべてを 示します。スタイル修飾子が children であった場合には、 <dnpattern> のエントリ自体を含まないサブツリーのエントリすべてを 示します。
スタイル修飾子 <dnstyle> が regex であった場合、 <dnpattern> は regex(7) や re_format(7) に詳説されている POSIX (''拡張'')正規表現パターンであることを意味します。 この正規表現パターンがエントリの DN の正規化された文字列表現と一致するか比較します。 パターンの正規表現形式は(まだ) UTF-8 をサポートしていません。
filter=<ldapfilter> は RFC 2254 に定義されている適正な LDAP フィルタを基にエントリを 選択します。 filter を指定しない場合は、 (objectClass=*) を指定したものとみなします。
attrs=<attrlist> は、アクセス制御規則を適用する属性を選択します。 これは、属性型に加えて、エントリ自体へのアクセス権を示す entry 、エントリの子へのアクセス権を示す children をカンマで区切って並べたものです。このリストには objectClass 名も 指定でき、この objectClass によって要求/許可される属性すべてに 影響します。実際には <attrlist> 中の名前のうち前に @ の付いたものがオブジェクトクラス名として扱われます。前に ! の付いたものもオブジェクトクラス名として扱われますが、 この場合アクセス制御はそのオブジェクトクラスの必須でも オプションでも無い属性に作用します。 attrs を指定しない場合には attrs=@extensibleObject を指定したものとみなします。すなわち、すべての属性が対象となります。
形式 attrs=<attr> val[/matchingRule][.<attrstyle>]=<attrval> による指定は、単一の属性の特定の値へのアクセスを示します。 この場合には単一の属性型のみを与えられます。 <attrstyle> が exact (デフォルト)である場合には、異る(および互換の) 一致規則が指定されていない限り、 値の比較に属性の等価性の一致規則を適用します。 <attrstyle> が regex である場合は、指定の値を POSIX (''拡張'')正規表現パターンとして扱います。 属性が DN 構文を持つ場合、 <attrstyle> には base, onelevel, subtree, children のいずれかを指定でき、それぞれ base, onelevel, subtree, children 一致の結果になります。
引数 dn, filter, attrs については必要に応じて付加します。 これらはネーミングコンテキスト、値、属性型を基にしてアクセス規則を 適用するエントリを選択した結果に適用されます。
*
anonymous
users
self[.<selfstyle>]
dn[.<dnstyle>[,<modifier>]]=<DN>
dnattr=<attrname>
realanonymous
realusers
realself[.<selfstyle>]
realdn[.<dnstyle>[,<modifier>]]=<DN>
realdnattr=<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>]
dynacl/name[/<options>][.<dynstyle>][=<pattern>]
<style>={exact|regex|expand}
<selfstyle>={level{<n>}}
<dnstyle>={{exact|base(object)}|regex
|one(level)|sub(tree)|children|level{<n>}}
<groupstyle>={exact|expand}
<peernamestyle>={<style>|ip|path}
<domainstyle>={exact|regex|sub(tree)}
<setstyle>={exact|regex}
<modifier>={expand}
これらを組み合わせて指定することも可能です。
ワイルドカード * はあらゆるものを示します。
先頭が real で始まるキーワードは、
キーワード anonymous は、認証されてないクライアントにアクセス権を与えることを意味します。 これはたいてい、認証のためのリソース(たとえば userPassword 属性)に対する非認証クライアントのアクセスを認証目的に限るために利用されます。
キーワード users は認証されたクライアントにアクセス権を与えることを意味します。
キーワード self は、エントリへのアクセスをそのエントリ自体に与えることを意味します (たとえばアクセスされるエントリと要求するエントリが同じでなければ ならない)。 このキーワードには level{<n>} スタイルを指定できます。 ここで <n> は DN のどの祖先が一致の中で使われたかを示します。 正の値は、ユーザの DN の <n> 番目の祖先であることを示します。 負の値は、アクセス対象の <n> 番目の祖先であることを示します。 たとえば "by self.level{1} ..." 節は "cn=User,dc=example,dc=com" がアクセスするオブジェクト "dc=example,dc=com" に一致します。 "by self.level{-1} ..." 節は "cn=User,dc=example,dc=com" が "ou=Address Book,cn=User,dc=example,dc=com" にアクセスする場合に一致します。
dn=<DN> は、一致する dn にアクセス権を与えることを意味します。 オプションのスタイル修飾子 dnstyle は、引数 <what> の dn 形式で指定できるものと同じです。 さらに regex スタイルでは、 <what> dn の部分一致を $<digit> で参照して部分文字列置換が可能です。 ここで digit は 0 から 9 までの数字です(0 は文字列全体に一致します)。 また ${<digit>+} という形式が 10 以上の部分一致で利用できます。 ドル記号は部分文字列置換を示すために使うので、 文字列の終端を示すのにドル記号を使う場合にはドル記号を2つならべる 必要があります。たとえば次のように指定します。
access to dn.regex="^(.+,)?uid=([^,]+),dc=[^,]+,dc=com$"
by dn.regex="^uid=$2,dc=[^,]+,dc=com$$" write
スタイル修飾子にはオプションの modifier を付加できます。これに指定できる唯一のものは expand であり、 dnstyle が regex で無くとも 部分一致の部分文字列置換が起きるようにします。 先に示した例での regex の dnstyle は <by> 節が正規表現である必要がある場合のみの利用であることに注意してください。 DN の(右から)２番目の部分の値 dc= が固定であるならば、次のような形式で指定できます。
access to dn.regex="^(.+,)?uid=([^,]+),dc=example,dc=com$"
by dn.exact,expand="uid=$2,dc=example,dc=com" write
また、 <what> の中の値に一致するものがあるのであれば、次のようにも指定できます。
access to dn.regex="^(.+,)?uid=([^,]+),dc=([^,]+),dc=com$"
by dn.exact,expand="uid=$2,dc=$3,dc=com" write
正規表現ではない <what> 節の形式でも部分一致を利用できます。 base(object), sub(tree), one(level), children 形式では、文字列全体の一致を示す $0 が使えます。 sub(tree), one(level), children 形式では、 <what> 節に定義した DN の最も右側の部分を示す $1 も使えます。 これは、たとえば 次に示す定義でユーザの祖先すべてのアクセスを許すような場合に使えます。
access to dn.subtree="dc=com"
by dn.subtree,expand="$1" read
この定義では <by> 節の DN の中に現れるエントリへのアクセスだけを許可します。
形式 level{<n>} は拡張であり、 onelevel 形式を一般化したものです。 これは <n> 番目の祖先がパターンとなる DN すべてに一致します。 したがって、level{1} は onelevel と同等であり、 level{0} は base と同等です。
データベースの rootdn に完全一致する DN に ACL でアクセス件を与えるのは全く無駄なことです。 rootdn には暗にデータベース中のツリー全体について write 権限があります。 実際のところ、 rootdn についてはアクセス制御を無視します。 これは本質的な「鶏と卵」問題を解決するためです。
dnattr=<attrname> は、dn がアクセスされるエントリの属性 <attrname> に格納されているものの要求にアクセス権を与えることを意味します。
group=<group> は <group> によって指定された dn のグループエントリに格納された ものの要求にアクセス権を与えることを意味します。 オプションのパラメータ <objectclass> と <attrname> は、グループエントリの objectClass とメンバ attributeType を定義します。 デフォルトはそれぞれ groupOfNames と member です。 オプションのスタイル修飾子 <style> には expand を指定でき、 <group> が regex(7) や re_format(7) にしたがって(正規表現としてではなく)置換文字列として 展開されることを意味します。スタイル修飾子には exact も指定でき、厳密一致が利用されることを意味します。 <what> 節の DN 部分のスタイルが正規表現である場合、 regex(7) や re_format(7); にしたがった部分一致を利用できます。 他のスタイルでは、先に <by> 節の DN 形式で説明した、限定された部分一致を利用できます。
静的グループについて 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 と 正規表現一致を意味します。 <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 の値によって決定されることを意味します。 オプションの <attrname> は、エントリの中で ACI 情報を保持する属性型を示します。 デフォルトでは OpenLDAPaci 運用属性を使います。 ACI は実験用です。これはコンパイル時に有効にしなければなりません。
dynacl/<name>[/<options>][.<dynstyle>][=<pattern>] は <name> が示す管理者定義のメソッドにアクセス検査を委任します。 メソッドは moduleload ディレクティブで実行時に登録できます。 <options>, <dynstyle> , <pattern> は省略可能で、登録した分析ルーチンに直接渡されます。 dynacl は実験用です。これはコンパイル時に有効にしなければなりません。 dynacl と ACI の両方が有効になっている場合、ACI は dynacl スキームにキャストされます。 この場合、 <name>=aci となり、オプションで <patten>=<attrname> の形式を指定できます。 しかし、後方互換性のために元の ACI 構文は維持されます。
ssf=<n>, transport_ssf=<n>, tls_ssf=<n>, sasl_ssf=<n> は、アクセス権を与えるのに最低限必要となる Security Strength Factor (ssf) を設定します。値には正の整数を指定します。
<level> ::= none|disclose|auth|compare|search|read|write
<priv> ::= {=|+|-}{w|r|s|c|x|d|0}+
修飾子 self をつけると、操作がアクセスを要求しているユーザの名前に関する 場合だけに特定のアクセスレベルまたはアクセス権を持つような 特殊な操作を許します。 これは、要求のアクセスに認可されたユーザを暗示します。 修飾子 realself は self 修飾子の認可 DN に対する認証 DN であることを示します。 たとえば、 selfwrite では、グループのメンバ属性にアクセスにおいて、 グループのメンバリストから自分の DN の追加削除は 許されますが、他のメンバには何も影響を与えられません。
level のアクセスモデルでは、 アクセス権の追加解釈をします。 指定可能なレベルには none, disclose, auth, compare, search, read, write があります。各アクセスレベルはその前にあるアクセス権を含んでいます。 すなわち、 write アクセスレベルにはすべてのアクセス権があることを暗示します。
none アクセスレベルは、エラーの開示も含めてすべてのアクセスを禁止します。
disclose アクセスレベルは、エラーの情報の開示を許します。
auth アクセスレベルは、他のアクセス権なしで認証/認可操作( bind など)を行うための属性にアクセスを許すようにするものです。 これは、認証されていないクライアントにパスワードのような危険な情報への 最低限のアクセスレベルを与えるのに有用です。
priv アクセスモデルでは各節についてアクセス権を明示的に設定します。 記号 = は前に定義されたアクセス権をリセットします。 結果として最終的なアクセス権は、この節で定義したものだけになります。 記号 + と - は既存のアクセス権に対してアクセス権を追加/除去します。 アクセス権は w が書込み権、 r が読取り権、 s が検索権、 c が比較権、 x が認証権、 d が開示権です。 １つの文には上記のアクセス権を複数個指定できます。 0 はアクセス権の無いことを示し、それ単独でのみ指定できます(すなわち +0)。 アクセス権を指定しない場合、デフォルトで +0 になります。
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
これはすべてのものに検索権と比較権を与え、これに加えて認証されたクライアント には読取り権を与えています。
有用な応用のひとつとして、 rootdn と異る updatedn に容易に書込み権限を与えることがあります。 この場合、 updatedn は(ほとんど)すべてのデータに対する書込みアクセス権を必要とするので、 先頭のアクセス規則として次のものを使えます。
access to *
by dn.exact="cn=The Update DN,dc=example,dc=com" write
by * break
結果として、 updatedn で実行する操作でなければ、 アクセス制御は直接に後続の規則に移ります。
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 操作は、検索ベースの entry 疑似属性に対する search (=s) 権限を必要とします(注記：これは 2.3 で導入されました)。 そして各エントリについて、 フィルタに指定する属性に対する search (=s) 権限を必要とします。 結果のエントリについては最終的に 、(エントリ自体に対する読み取りアクセスのために)疑似属性 entry に対する read (=r) 権限と、要求した各属性に対する read (=r) 権限を検査します。 また、紹介の生成で使われる各 referral オブジェクトについて search 操作は、 (referral オブジェクト自体に対する読み取りアクセスのために)疑似属性 entry に対する read (=r) 権限、referral 情報を保持する属性(一般には ref 属性)に対する read (=r) 権限を必要とします。
内部操作や control により、特定の権限が必要となることもあります。 authzID マッピングと proxyAuthz 制御は、URI 正規表現マッピング( authz-regexp ディレクティブの右側)の検索フィルタに指定したすべての属性に対して auth (=x) 権限を必要とします。 また、認可する ID の authzTo 属性や、認可される ID の authzFrom 属性に対して auth (=x) 権限を必要とします。
エントリ検索のアクセス制御はフロントエンドで検査するので、 すべてのバックエンドで完全に有効です。その他の操作と 検索操作の発見フェーズについて、完全な ACL セマンティクス がサポートされるのは週ようなデータベースのみです。すなわちそれは back-bdb(5), back-hdb(5), back-ldbm(5) です。
他のバックエンドでも back-sql(5) のように完全にサポートしているものもありますが、それ以外では 上記のセマンティクスの一部だけをサポートしていたり、いくかの点で違って いたりすることもあります。そのような違いについて詳しくは、 それぞれのバックエンドの man ページに記述されています。
管理者は次の形式の規則を設定したとします。
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=$2,dc=example,dc=com$$" write
by ...
しかし <by> 節については部分文字列置換があればよいので、 次のように指定したほうがより効率的です。
access to dn.regex="^(.+,)?uid=([^,]+),dc=example,dc=com$"
by dn.exact,expand="uid=$2,dc=example,dc=com" write
by ...
実際のところ regex の <dnstyle> は、部分文字列置換、 exact 、その他 DN 固有の <dnstyle> を暗に適用しますが、さもなければ明示する必要があります。
"OpenLDAP 管理者ガイド" (http://www.OpenLDAP.org/doc/admin/)