Provided by: manpages-ja_0.5.0.0.20140515+dfsg-2_all bug

名前

       sudoers.ldap - LDAP を使った sudo の設定

説明

       sudosudoers ファイルによって設定するのが標準だが、 LDAP を通して設定することも可能
       だ。この方法は、 大規模な分散環境で sudo の設定を同期させたい場合に、とりわけ便利かもしれ
       ない。

       sudo の設定に LDAP を使用すると、有利な点がいくつかある。

       •   sudo はもはや sudo の設定をまるまる全部読み込む必要がない。 LDAP を使用する場合
           は、sudo の実行ごとに、たった二、三回 LDAP に問い合わせを行うだけですむ。 そのた
           め、LDAP 環境は実行速度が非常に早く、たいへん使い勝手がよい。

       •   sudo の設定にタイプミスがあっても、もうそのために sudo が終了してしまうことがな
           い。LDAP のデータは、 sudo 用のスキーマに従っていなければ、サーバーにロードできない。
           結果として、正しいシンタクスが保証されるわけだ。 ユーザ名やホスト名をタイプミスするこ
           となら相変わらずあるだろうが、 そのために sudo が動かなくなることはない。

       •   エントリごとにオプションを指定して、 グローバルなデフォルト・オプションを上書きするこ
           とができる。 /etc/sudoers はグローバルなデフォルト・オプションと、ユーザ、ホスト、 コ
           マンド、変身対象に結びついた限定されたオプションしかサポートしていない。 ま
           た、/etc/sudoers の書式は複雑で、ユーザには理解しにくいかもしれない。 オプションをエン
           トリ内で直接指定する方が、ずっと自然である。

       •   visudo プログラムはもう必要がない。visudo の役割は /etc/sudoers ファイルのロッキングと
           シンタクス・チェックである。 LDAP のデータ更新はアトミック操作なので、 (訳注: それ
           故、データは更新されていないか、 すでに更新されたかのどちらかであって、中間状態がない
           ので)、 ロッキングはもはや必要がない。シンタクスは、 データが LDAP にインサートされる
           ときチェックされるから、 シンタクス・チェック用の特別なツールも不要になっている。

       LDAP による設定と sudoers ファイルによる設定との、 もう一つの大きな違いは、LDAP では sudo
       専用のエイリアスがサポートされていないことである。

       たいていの場合、sudo 専用のエイリアスは実のところ必要がない。 User_Aliases や
       Runas_Aliases の代わりに、 Unix のグループやユーザのネットグループが使用できる。 ま
       た、Host_Aliases の代わりには、ホストのネットグループが使える。 LDAP には Unix のグループ
       やネットグループも格納できるので、 sudo 専用のエイリアスがどうしても必要というわけではない
       のだ。

       Cmnd_Aliases もまったく必要がない。一つの sudoRole エントリに複数のユーザを登録できるから
       だ。複数のユーザが参照する Cmnd_Alias を定義する代わりに、複数のコマンドを含む sudoRole エ
       ントリを一つ作成して、そこに複数のユーザを割り当てればよい。

       [訳注]: 原文の著者は、sudo 設定の単位となる objectClass 属性が sudoRole の LDAP エントリの
               うち、/etc/sudoers の各ユーザ設定に相当するものを「a sudoRole」と呼んでいる。
               「sudoRole エントリ」という訳語を当てた。

   LDAP  SUDOers コンテナ
       LDAP では、sudo の設定は ou=SUDOers コンテナの下に配置されている。

       [訳注]: コンテナとは、データを格納するためにではなく、 下位のエントリをまとめておくために
               存在する上位エントリを言う。たとえば、 OpenLDAP 用の ou=SUDOers コンテナなら、こん
               なふうになる (sudo 同梱の README.LDAP から引用)。

                 dn: ou=SUDOers,dc=example,dc=com
                 objectClass: top
                 objectClass: organizationalUnit
                 ou: SUDOers

       sudo はまず最初に SUDOers コンテナ配下に cn=defaults のエントリを捜す。 見つかった場合
       は、複数回指定可能な sudoOption 属性が、/etc/sudoers のグローバルな Defaults 行と同じやり
       方で解析される。 以下の例では、環境変数 SSH_AUTH_SOCK がすべてのユーザの環境に保存されるこ
       とになる。

           dn: cn=defaults,ou=SUDOers,dc=example,dc=com
           objectClass: top
           objectClass: sudoRole
           cn: defaults
           description: Default sudoOption's go here
           sudoOption: env_keep+=SSH_AUTH_SOCK

       LDAP において /etc/sudoers の個々の「ユーザ設定」に相当するのは、 sudoRole エントリであ
       る。それは以下の属性からなっている。

       sudoUser
           次のうちのいづれか。ユーザ名、 ユーザ ID (接頭辞 '#' が付く)、 Unix グループ名 (接頭辞
           '%' が付く)、 Unix グループ ID (接頭辞 '%#' が付く。これが使えるのは、sudo-1.8.4 か
           ら)、 ユーザのネットグループ名 (接頭辞 '+' が付く)。

       sudoHost
           次のうちのいづれか。ホスト名、IP アドレス、ネットワークアドレス、 ホストのネットグルー
           プ名 (接頭辞 '+' が付く)。 ALL という特別な値はいかなるホストにもマッチする。

       sudoCommand
           Unix のコマンド。コマンドライン引数を付けてもよく、glob 文字 (ワイルドカードとも言う)
           を含んでいてもよい。ALL という特別な値は、いかなるコマンドにもマッチする。 コマンドに
           感嘆符 '!' を接頭辞として付けると、 ユーザにそのコマンドの実行を禁じることになる。

       sudoOption
           働きは、前述のグローバルオプションと同じだが、それが属している sudoRole エントリに対し
           てのみ効果がある。

       sudoRunAsUser
           変身対象となるユーザ名か uid (接頭辞 '#' が付く) を指定する。 変身対象ユーザをリストに
           含む Unix グループ名 (接頭辞 '%' が付く) や、 ユーザのネットグループ名 (接頭辞 '+' が
           付く) も使える。 特別な値 ALL は、いかなるユーザにもマッチする。

           属性 sudoRunAsUser は、 バージョン 1.7.0 以上の sudo でなければ、利用できない。 それ以
           前のバージョンの sudo では、 代わりに属性 sudoRunAs を使用している。

       sudoRunAsGroup
           変身対象となる Unix グループ名か gid (接頭辞 '#' が付く)。 特別な値 ALL はいかなるグ
           ループにもマッチする。

           属性 sudoRunAsGroup は、 バージョン 1.7.0 以上の sudo でなければ、利用できない。

       sudoNotBefore
           yyyymmddHHMMSSZ 形式のタイムスタンプ。 この属性を含む sudoRole エントリがいつから有効
           になるかという、 スタート日時を指定するのに使用する。 複数の sudoNotBefore が存在する
           場合は、 一番早い日時が採用される。 タイムスタンプは協定世界時 (UTC) によるものでなけ
           ればならず、 ローカル・タイムゾーンによるものではないことに注意してほしい。 分や秒の部
           分は省略できるが、LDAP サーバによっては (RFC の規定とは逆に) 分や秒の指定を必須にして
           いることもある。

           属性 sudoNotBefore は、 バージョン 1.7.5 以上の sudo でなければ、利用できない。 ま
           た、/etc/ldap.confSUDOERS_TIMED オプションで明示的に有効にする必要がある。

       sudoNotAfter
           yyyymmddHHMMSSZ 形式のタイムスタンプ。 この属性を含む sudoRole エントリがもはや有効で
           はなくなる、 失効日時を示している。 複数の sudoNotAfter が存在する場合は、 一番最後の
           日時が採用される。 タイムスタンプは協定世界時 (UTC) によるものでなければならず、 ロー
           カル・タイムゾーンによるものではないことに注意してほしい。 分や秒の部分は省略できる
           が、LDAP サーバによっては (RFC の規定とは逆に) 分や秒の指定を必須にしていることもあ
           る。

           属性  sudoNotAfter は、 バージョン 1.7.5 以上の sudo でなければ、利用できない。 ま
           た、/etc/ldap.confSUDOERS_TIMED オプションで明示的に有効にする必要がある。

       sudoOrder
           LDAP から取り出される sudoRole エントリには、 固有の順番というものがない。 そこで、整
           数の値を取る sudoOrder 属性を使用して (浮動小数点値をサポートする LDAP サーバでは、浮
           動小数点値が使える)、 マッチするエントリの順番付けを行う。 そうすることによって、LDAP
           による sudo 設定のエントリが、 sudoers ファイルの動作をより忠実に真似られるようになる
           のだ。 sudoers ファイルではエントリの順番が結果に影響を及ぼす。 sudoOrder 属性を使用す
           ると、 複数のエントリがマッチする場合は、一番大きな sudoOrder 属性を持つエントリが選ば
           れることになる。この動作は、 sudoers ファイルの「最後にマッチしたものが選ばれる」動作
           に相当するわけだ。 sudoOrder 属性が指定されていない場合は、 値が 0 であると見なされ
           る。

           属性 sudoOrder は、 バージョン 1.7.5 以上の sudo でなければ、利用できない。

       上記の各属性は単一の値を持つべきだが、同じタイプの属性が複数回現れても構わない。 sudoRole
       エントリは、sudoUser、 sudoHost、sudoCommand を、 少なくともそれぞれ一個は含んでいなければ
       ならない。

       次の例では、wheel グループのユーザに sudo 経由でいかなるホストでも任意のコマンドの実行を許
       可している。

           dn: cn=%wheel,ou=SUDOers,dc=example,dc=com
           objectClass: top
           objectClass: sudoRole
           cn: %wheel
           sudoUser: %wheel
           sudoHost: ALL
           sudoCommand: ALL

   LDAP を使って sudo の設定を検索するときの詳細
       LDAP を使ってユーザの sudo 設定を検索するとき、LDAP の問い合わせは sudo の実行ごとにたった
       二回か三回行われるだけである。一回目の問い合わせは、 グローバル・オプションを解析するため
       に行われる。二回目の問い合わせは、 sudo を実行するユーザのユーザ名や、 所属グループに対応
       するエントリを見つけるためだ (特別なタグ ALL が何にでもマッチするのは、この場合も同様であ
       る)。 ユーザ名やグループに対応するエントリが得られなかった場合は、 三回目の問い合わせが行
       われ、 ユーザのネットグループを含んでいるすべてのエントリーを取得して、 問題のユーザがその
       どれかに属していないかチェックする。

       /etc/ldap.conf の設定オプション SUDOERS_TIMED を有功にして、 日時制限があるエントリを使え
       るようにしている場合は、 LDAP の問い合わせにサブフィルターによる選別が伴うことになる。 そ
       のサブフィルターが、日時制限が存在するエントリについては、 その制限を満たしているエントリ
       のみに、情報の取り出しを限定するのである。

   LDAP を使う場合と使わない場合の sudo 設定の相違点
       LDAP を使用する場合、sudo の設定の処理方法に /etc/sudoers の場合とは微妙な違いがいくつかあ
       る。 たぶん最大の違いは、RFC に書いてあるとおり、 LDAP の順序づけは不定なので、 属性やエン
       トリが何らかの決まった順序で返されることを期待できないことだろう。

       それでも、個々のエントリに割り振る順番については、sudoOrder によって決めることができる。
       だが、ある特定のエントリ内での属性の順番を決める、確実な方法は存在しないのだ。 もっと
       も、あるエントリーにコマンドに関して相反するルールがある場合は、 否定する方が優先され
       る。いわゆるパラノイア的動作である (それが一番明示的なマッチだとはかぎらないが)。

       例を挙げてみよう。

           # /etc/sudoers の場合:
           # shell 以外のすべてのコマンドを許可する
           johnny  ALL=(root) ALL,!/bin/sh
           # 次の設定は、ALL が最後にマッチするので、常にすべてのコマンドを
           # 許可することになる
           puddles ALL=(root) !/bin/sh,ALL

           # 上記の johnny に相当する LDAP のエントリ:
           # shell 以外のすべてのコマンドを許可する
           dn: cn=role1,ou=Sudoers,dc=my-domain,dc=com
           objectClass: sudoRole
           objectClass: top
           cn: role1
           sudoUser: johnny
           sudoHost: ALL
           sudoCommand: ALL
           sudoCommand: !/bin/sh

           # 上記の puddles に相当する LDAP のエントリ:
           # ALL が最後に指定されているが、LDAP のコードはよりパラノイア的な
           # 設定になっているため、これもまた role1 と同じように動作する
           # ことに注意してほしい
           dn: cn=role2,ou=Sudoers,dc=my-domain,dc=com
           objectClass: sudoRole
           objectClass: top
           cn: role2
           sudoUser: puddles
           sudoHost: ALL
           sudoCommand: !/bin/sh
           sudoCommand: ALL

       もう一つの相違は、Host、User、Runas についての否定は、 現在のところ無視されるということ
       だ。 たとえば、以下に挙げるような属性は期待どおりに動作しない。

           # joe 以外の全員とマッチしないどころか、
           # 誰にもマッチしない
           sudoUser: !joe

           # joe 以外の全員とマッチしないどころか、
           # joe を含む全員にマッチしてしまう
           sudoUser: ALL
           sudoUser: !joe

           # web01 以外のすべてとマッチしないどころか、
           # web01 を含むすべてのホストにマッチしてしまう
           sudoHost: ALL
           sudoHost: !web01

   sudo 用のスキーマ
       sudo の LDAP サポートを利用するためには、 お使いの LDAP サーバに sudo 用のスキーマをインス
       トールしなければならない。 さらに、'sudoUser' 属性の索引も必ず作成する。

       たぶん、sudo の配布物中に三種類のスキーマが入っていると思う。 すなわち OpenLDAP サーバ用
       (schema.OpenLDAP)、 Netscape ディレクトリサーバの流れを汲むサーバ用 (schema.iPlanet)、
       Microsoft Active Directory 用 (schema.ActiveDirectory) のスキーマである。

       OpenLDAP 用の形式にした sudo のスキーマは、 「用例」セクションにも記載しておいた。

   ldap.conf の設定
       sudo は LDAP に関する設定を知るために /etc/ldap.conf を読み込む。 通例、このファイルは、
       LDAP に対応しているさまざまなクライアントの間で共有されている。 それ故、設定の大部分は
       sudo 専用ではない。 注意すべきは、sudo/etc/ldap.conf を独自に解析しており、
       ldap.conf(5) のマニュアルで説明されているものとは 異なるオプションをサポートしていることが
       あるということだ。

       もうひとつ注意してほしいのは、OpenLDAP ライブラリを使っているシステムで、
       /etc/openldap/ldap.conf やユーザの .ldaprc ファイルで指定しているデフォルト値が使用されな
       いことである。

       すなわち、/etc/ldap.conf に明示的に記載され、かつ sudo でサポートされているオプションのみ
       が使用される。 設定オプションを以下に大文字で列挙するが、 解析されるときは大文字小文字は区
       別されない。

       URI ldap[s]://[hostname[:port]] ...
           接続する一個以上の LDAP サーバ の URI を、空白 (whitespace) で区切ったリストの形で指定
           する。プロトコルは ldapldaps のどちらでもよい。 後者は TLS (SSL) 暗号化に対応して
           いるサーバの場合である。 ポートを指定しないときのデフォルトは、 ldap:// では 389 番
           ポート、 ldaps:// では 636 番ポートである。 hostname を一つも指定しないと、 sudolocalhost に接続することになる。 URI の行が二行以上ある場合は、 URI の行に複数のエント
           リがあるときと同様に処理される。 OpenSSL ライブラリを使用しているシステムのみ
           が、ldap:// と ldaps:// 両方の URI を混ぜて使うことに対応している。 たいていの商用
           Unix では Netscape 由来のライブラリが使用されているが、 そうしたライブラリはどちらか一
           方に対応することしかできない。

       HOST name[:port] ...
           URI パラメータが指定されていない場合は、 HOST パラメータで指定する空白 (whitespace) で
           区切ったリストが、接続する LDAP サーバである。 各ホストにはコロン (':') に続けて、ポー
           ト番号を書いてもよい。 HOST パラメータは非推奨であり、URI で指定する方が望ましい。この
           パラメータがあるのは、後方互換のためである。

       PORT port_number
           URI パラメータが指定されず、HOST パラメータでもポートが指定されていないときは、PORT パ
           ラメータが LDAP サーバに接続するときのデフォルトのポートを指定する。 PORT パラメータが
           使用されていない場合、デフォルトのポートは LDAP では 389 番、LDAP over TLS (SSL) では
           636 番である。PORT パラメータは非推奨であり、 URI で指定する方が望ましい。 このパラ
           メータがあるのは、後方互換のためである。

       BIND_TIMELIMIT seconds
           接続しようとするときの待ち時間を秒数で指定する。URIHOST が複数指定されている場合
           は、その時間だけ待ってから、 リスト中の次のサーバに接続を試みることを意味する。

       NETWORK_TIMEOUT seconds
           BIND_TIMELIMIT の別名。OpenLDAP との互換のためにある。

       TIMELIMIT seconds
           TIMELIMIT パラメータは、 LDAP 参照に対して応答が返ってくるまでの待ち時間を秒数で指定す
           る。

       TIMEOUT seconds
           TIMEOUT パラメータは、 様々な LDAP API から応答が返ってくるときの待ち時間を秒数で指定
           する。

       SUDOERS_BASE base
           sudo が LDAP 参照を行うときに使用するベース DN を指定する。ドメインが example.com なら
           ば、 普通 ou=SUDOers,dc=example,dc=com という形になる。 SUDOERS_BASE を複数回指定して
           もよい。その場合は、 指定された順番で参照されることになる。

       SUDOERS_SEARCH_FILTER ldap_filter
           sudo が LDAP 参照を行うとき、どんな情報を返すかを限定する LDAP のフィルター。 普通これ
           は、attribute=value とか (&(attribute=value)(attribute2=value2)) という形を取る。

       SUDOERS_TIMED on/true/yes/off/false/no
           属性 sudoNotBefore や sudoNotAfter を評価するか、しないかを指定する。 この二つの属性に
           よって日時制限のある sudo 設定のエントリを実現している。

       SUDOERS_DEBUG debug_level
           sudo が LDAP 参照をするときのデバッグレベルを決める。 デバック情報の出力先は標準エラー
           である。値を 1 にすると、 多からず少なからずほどほどのデバック情報が表示される。 値を
           2 にすると、マッチの結果そのものも出力される。 実用環境では、このパラメータを設定する
           べきではない。 ユーザが余計な情報に混乱しかねないからだ。

       BINDDN DN
           BINDDN パラメータは、誰の名前で LDAP の操作を行うかを、 識別名 (DN) を使って指定す
           る。これが指定されていない場合、 LDAP の操作は anonymous の名前で実行される。LDAP サー
           バは、 たいていデフォルトで anonymous によるアクセスを許可しているものである。

       BINDPW secret
           BINDPW パラメータは、 LDAP の操作を行うときに使用するパスワードを指定する。 通例、この
           パラメータは、BINDDN パラメータと組み合わせて使用する。

       ROOTBINDDN DN
           ROOTBINDDN パラメータは、sudo 設定の参照のような、 特権的な LDAP 操作をするとき、誰の
           名前で行うかを識別名 (DN) を使って指定する。その名前に対応するパスワードは
           /etc/ldap.secret に書き込んでおくべきだ。このパラメータが設定されていない場合は、
           BINDDN で指定した名前があるならば、それが使用される。

       LDAP_VERSION number
           サーバに接続するときに使用する LDAP プロトコルのバージョン。 デフォルトの値は、プロト
           コルバージョン 3 である。

       SSL on/true/yes/off/false/no
           SSL パラメータが on, true, yes になっていると、LDAP サーバと通信する際に、常に TLS
           (SSL) の暗号化を使用することになる。 通例、それは 636 番ポート (ldaps) を通してサーバ
           に接続することである。

       SSL start_tls
           SSL パラメータを start_tls に設定すると、 LDAP サーバへの接続を平文で開始し、 バインド
           操作のために認証情報を送信する直前に、 TLS の暗号化を始めることになる。 これには、暗号
           化された通信のために専用のポートを必要としないという長所がある。 このパラメータをサ
           ポートしているのは、 OpenLDAP サーバのような start_tls 拡張に対応している LDAP サーバ
           のみである。

       TLS_CHECKPEER on/true/yes/off/false/no
           TLS_CHECKPEER が有効になっていると、 LDAP サーバの TLS 証明書が正当かどうかチェックが
           行われる。 LDAP サーバの証明書が正当であることを確認できない場合 (たいていは、 署名し
           ている認証局が未知 (unknown) であることが理由だ)、 sudo はそのサーバに接続することがで
           きない。 TLS_CHECKPEER が無効になっている場合は、チェックが行われない。 気をつけてほし
           いが、このチェックをやらないことにすると、 サーバーの身元確認を行わないので、中間者攻
           撃の可能性が生じる。 可能ならば、認証局の証明書は、その正当性をチェックできるように、
           手元のマシンにインストールしておくべきである。

       TLS_CACERT file name
           TLS_CACERTFILE の別名。OpenLDAP との互換のためにある。

       TLS_CACERTFILE file name
           認証局の証明書を一つにまとめたファイルのパス。たとえば、 /etc/ssl/ca-bundle.pem といっ
           たファイルであり、 正当なものだとクライアントが認識している、すべての認証局の証明書が
           そこに入っている。 このオプションをサポートしているのは、OpenLDAP ライブラリだけであ
           る。 Netscape 由来の LDAP ライブラリは、認証局とクライアント、 両方の証明書に対し
           て、同一の証明書データベースを使用する (TLS_CERT を参照)。

       TLS_CACERTDIR directory
           TLS_CACERTFILE に似ているが、ファイルではなく、たとえば /etc/ssl/certs といったディレ
           クトリであり、認証局の証明書が 1 認証局 1 ファイルの形でそこに入ってい
           る。TLS_CACERTDIR で指定したディレクトリは、TLS_CACERTFILE の後でチェックされる。 この
           オプションをサポートしているのは、OpenLDAP ライブラリだけである。

       TLS_CERT file name
           クライアントの証明書が入っているファイルのパス。この証明書は、 LDAP サーバに対するクラ
           イアントの認証に使用できる。 証明書のタイプは、利用する LDAP ライブラリによって異なっ
           ている。

           OpenLDAP:
               tls_cert /etc/ssl/client_cert.pem

           Netscape 由来:
               tls_cert /var/ldap/cert7.db

           Netscape 由来のライブラリを使う場合は、このファイルに認証局の証明書も入れることができ
           る。

       TLS_KEY file name
           TLS_CERT で指定した証明書に対応する、 秘密鍵が入っているファイルのパス。 この秘密鍵は
           パスワードでプロテクトされていてはならない。 鍵のタイプは利用する LDAP ライブラリに
           よって異なっている。

           OpenLDAP:
               tls_key /etc/ssl/client_key.pem

               tls_key /var/ldap/key3.db

       TLS_RANDFILE file name
           TLS_RANDFILE は、random デバイスを持っていないシステムのために エントロピー・ソースの
           パスを指定する。 これは通例、prngdegd と組み合わせて使用するものである。 このオプ
           ションをサポートしているのは、OpenLDAP ライブラリだけである。

       TLS_CIPHERS cipher list
           管理者は TLS_CIPHERS パラメータによって、TLS (SSL) 接続に使用可能な暗号アルゴリズムを
           限定することができる。 有効な暗号のリストについては OpenSSL のマニュアルを参照してほし
           い。 このオプションをサポートしているのは、OpenLDAP ライブラリだけである。

       USE_SASL on/true/yes/off/false/no
           LDAP サーバが SASL 認証をサポートしているなら、 USE_SASL を有効にすること。

       SASL_AUTH_ID identity
           LDAP サーバに接続するときに使用する SASL ユーザ名。 デフォルトでは、sudo は anonymous
           接続を使用する。

       ROOTUSE_SASL on/true/yes/off/false/no
           ROOTUSE_SASL を有効にすると、 sudo のような特権的なプロセスから LDAP サーバに接続する
           ときに SASL 認証が可能になる。

       ROOTSASL_AUTH_ID identity
           ROOTUSE_SASL が有効なとき使用する SASL ユーザ名。

       SASL_SECPROPS none/properties
           SASL セキュリティ・プロパティを指定する。プロパティなしならば、 none である。 詳細につ
           いては、SASL プログラマーズ・マニュアルを参照すること。

       KRB5_CCNAME file name
           リモート・サーバに対して認証をするときに使用する Kerberos 5 資格証明キャッシュのパス。

       DEREF never/searching/finding/always
           検索を行うときに、alias の参照をどうするかを指定する。 このオプションについての詳しい
           説明は、ldap.conf(5) のマニュアルにある。

       「用例」セクションにある ldap.conf のくだりも参照してほしい。

   nsswitch.conf の設定
       ビルド時に無効にしないかぎり、sudo はネームサービス・スイッチ・ファイル /etc/nsswitch.conf
       を調べて、sudo の設定を参照する順番を決める。 すなわち、/etc/nsswitch.conf で sudoers: と
       いう文字列に始まる行を探し、 その行によって参照順を決定するのである。 気をつけてほしいの
       は、sudo は参照中、 マッチする項目に一度出会ったからと言って、そこで参照を終わりにしないこ
       とだ。 後でマッチしたものが前にマッチしたものよりも優先されるのである。

       以下の参照元が有効である。

           files       /etc/sudoers から sudo の設定を読み込む
           ldap        LDAP から sudo の設定を読み込む

       なお、[NOTFOUND=return] の記述があると、 先行する参照元にユーザが見つからなかった場合、参
       照を中断することになる。

       最初に LDAP を参照し、その後で (もし存在するならば) ローカルマシン上の sudoers ファイルを
       調べるには、次のように指定する。

           sudoers: ldap files

       ローカルマシン上の sudoers ファイルをまったく無視するには、 次のようにする。

           sudoers: ldap

       /etc/nsswitch.conf ファイルが存在しなかったり、存在しても sudoers の行がなかったりした場合
       は、次のデフォルト設定が使用される。

           sudoers: files

       基盤となるオペーレーティング・システムが nsswitch.conf ファイルを使用しない場合でも、sudo/etc/nsswitch.conf をサポートしていることに注意してほしい。

   netsvc.conf の設定
       AIX システムでは、/etc/nsswitch.conf ではなく、 /etc/netsvc.conf ファイルを調べに行
       く。sudo としては、 netsvc.confnsswitch.conf のバリエーションとして扱うだけだ。 それ
       故、上のセクションの記述のうち、ファイルの書式に関係のないものは、 ここでも当てはまること
       になる。

       最初に LDAP を参照し、その後で (もし存在するならば) ローカルマシン上の sudoers ファイルを
       調べるには、次のように指定する。

           sudoers = ldap, files

       ローカルマシン上の sudoers ファイルをまったく無視するには、 次のようにする。

           sudoers = ldap

       LDAP を正式の参照元と見なし、 LDAP にユーザが見つからなかったときのみ、 ローカルの sudoers
       ファイルを使用する。

           sudoers = ldap = auth, files

       上記の例において、auth 修飾子が影響を及ぼすのは、 ユーザを照合するときだけであることに注意
       してほしい。 Defaults エントリについては、 LDAP と sudoers の両方が参照される。

       /etc/netsvc.conf ファイルが存在しなかったり、存在しても sudoers の行がなかったりした場合
       は、次のデフォルト設定が使用される。

           sudoers = files

ファイル

       /etc/ldap.conf          LDAP の設定ファイル

       /etc/nsswitch.conf      sudo の設定の参照元の順番を決める

       /etc/netsvc.conf        AIX で sudo の設定の参照元の順番を決める

用例

   ldap.conf の一例
         # URI か host:port の組み合わせを一つ以上指定する。
         # どちらも指定されていない場合、sudo は localhost と 389 番
         # ポートを使用する。
         #
         #host          ldapserver
         #host          ldapserver1 ldapserver2:390
         #
         # host がポートなしで指定されている場合のポート番号。
         # デフォルトは 389 である。
         #port          389
         #
         # URI の指定は、host と port による指定に優先する。
         uri            ldap://ldapserver
         #uri            ldaps://secureldapserver
         #uri            ldaps://secureldapserver ldap://ldapserver
         #
         #  LDAP サーバに接続しようとしているときの、秒単位の待ち時間。
         bind_timelimit 30
         #
         # LDAP の参照を行っているときの、秒単位の待ち時間。
         timelimit 30
         #
         # 必ず設定すること。さもないと、sudo は LDAP を無視することになる。
         # 複数回指定してもよい。
         sudoers_base   ou=SUDOers,dc=example,dc=com
         #
         # LDAP を参照したとき、sudo 設定のマッチングについて詳細情報を
         # 表示する。
         #sudoers_debug 2
         #
         # sudo 設定中で日時制限のあるエントリのサポートを有効にする。
         #sudoers_timed yes
         #
         # LDAP の操作を行う者の認証情報 (設定する、しないは任意)。
         #binddn        <who to search as>
         #bindpw        <password>
         #rootbinddn    <who to search as, uses /etc/ldap.secret for bindpw>
         #
         # LDAP プロトコルのバージョン。デフォルトは 3 である。
         #ldap_version 3
         #
         # LDAP 接続を暗号化したいなら、on にする。
         # 通例、ポートを 636 (ldaps) にすることも必要。
         #ssl on
         #
         # ポート 389 を使用し、バインド操作のために認証情報が
         # 送信される前に、暗号化セッションに切り替えたい場合に設定する。
         # これをサポートしているのは、OpenLDAP のような start_tls 拡張に
         # 対応している LDAP サーバだけである。
         #ssl start_tls
         #
         # さらに以下の TLS 関連オプションを使うことで SSL/TLS 接続を
         # 微調整できる。
         #
         #tls_checkpeer yes # サーバの SSL 証明書の正当性をチェックする。
         #tls_checkpeer no  # サーバの SSL 証明書の正当性をチェックしない。
         #
         # tls_checkpeer を有効にするときは、 tls_cacertfile か
         # tls_cacertdir のどちらかを指定すること。tls_cacertfile や
         # tls_cacertdir は OpenLDAP の使用時のみ使える。
         #
         #tls_cacertfile /etc/certs/trusted_signers.pem
         #tls_cacertdir  /etc/certs
         #
         # /dev/random がないシステムでは、下記の設定を PRNGD、あるいは
         # EGD.pl と一緒に使用すれば、暗号セッション用の鍵を生成するための
         # 乱数プールの種を供給できる。このオプションが使えるのは、
         # OpenLDAP を使用しているときだけである。
         #
         #tls_randfile /etc/egd-pool
         #
         # 使用する暗号を限定することができる。どの暗号が使えるかに
         # ついては、SSL の文書を参照してほしい。このオプションが
         # 使えるのは、OpenLDAP を使用しているときだけである。
         #
         #tls_ciphers <cipher-list>
         #
         # sudo は LDAP サーバと交信するときに、クライアントの証明書を
         # 提示することができる。
         # 注意:
         #   * 両方の行を同時に有効にすること。
         #   * キーファイルをパスワードでプロテクトしてはいけない。
         #   * キーファイルが読めるのは root だけにするのを忘れずに。
         #
         # OpenLDAP の場合:
         #tls_cert /etc/certs/client_cert.pem
         #tls_key  /etc/certs/client_key.pem
         #
         # SunONE や iPlanet LDAP の場合:
         # こちらの場合は、tls_cert や tls_key で指定するのは、
         # 証明書やキーファイルの入っているディレクトリでもよく、
         # ファイルそのもののパスでもよい。
         # 前者の場合、ディレクトリ中のファイルは、既定の名前 (たとえば
         # cert8.db と key4.db) でなければならない。もっとも、ファイルの
         # パスを指定した場合は、バージョン 5.0 の LDAP SDK にはバグが
         # あるので、ファイル名によってはうまく動作しないことがある。
         # この理由から、tls_cert や tls_key には、ファイル名ではなく、
         # ディレクトリを指定する方をお薦めする。
         #
         # tls_cert で指定した証明書のデータベースには、認証局の証明書と
         # クライアントの証明書が、どちらか一方だけ入っていてもよく、
         # 両方入っていてもよい。クライアントの証明書が入っている場合は、
         # tls_key も指定するべきである。
         # 後方互換のため、tls_cert のかわりに sslpath を使うこともできる。
         #tls_cert /var/ldap
         #tls_key /var/ldap
         #
         # LDAP に SASL 認証を使用する場合 (OpenSSL)
         # use_sasl yes
         # sasl_auth_id <SASL user name>
         # rootuse_sasl yes
         # rootsasl_auth_id <SASL user name for root access>
         # sasl_secprops none
         # krb5_ccname /etc/.ldapcache

   OpenLDAP 用の Sudo のスキーマ
       下記のスキーマは OpenLDAP 用の形式になっており、 sudo のソースやバイナリの配布に含まれる
       schema.OpenLDAP と同じものだ。 このとおりの内容のファイルをスキーマ・ディレクトリ (たとえ
       ば、 /etc/openldap/schema) に作成し、適切な include 行を slapd.conf に追加して、slapd をリ
       スタートすればよい。

        attributetype ( 1.3.6.1.4.1.15953.9.1.1
           NAME 'sudoUser'
           DESC 'User(s) who may  run sudo'
           EQUALITY caseExactIA5Match
           SUBSTR caseExactIA5SubstringsMatch
           SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

        attributetype ( 1.3.6.1.4.1.15953.9.1.2
           NAME 'sudoHost'
           DESC 'Host(s) who may run sudo'
           EQUALITY caseExactIA5Match
           SUBSTR caseExactIA5SubstringsMatch
           SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

        attributetype ( 1.3.6.1.4.1.15953.9.1.3
           NAME 'sudoCommand'
           DESC 'Command(s) to be executed by sudo'
           EQUALITY caseExactIA5Match
           SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

        attributetype ( 1.3.6.1.4.1.15953.9.1.4
           NAME 'sudoRunAs'
           DESC 'User(s) impersonated by sudo'
           EQUALITY caseExactIA5Match
           SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

        attributetype ( 1.3.6.1.4.1.15953.9.1.5
           NAME 'sudoOption'
           DESC 'Options(s) followed by sudo'
           EQUALITY caseExactIA5Match
           SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

        attributetype ( 1.3.6.1.4.1.15953.9.1.6
           NAME 'sudoRunAsUser'
           DESC 'User(s) impersonated by sudo'
           EQUALITY caseExactIA5Match
           SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

        attributetype ( 1.3.6.1.4.1.15953.9.1.7
           NAME 'sudoRunAsGroup'
           DESC 'Group(s) impersonated by sudo'
           EQUALITY caseExactIA5Match
           SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

        attributetype ( 1.3.6.1.4.1.15953.9.1.8
           NAME 'sudoNotBefore'
           DESC 'Start of time interval for which the entry is valid'
           EQUALITY generalizedTimeMatch
           ORDERING generalizedTimeOrderingMatch
           SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )

        attributetype ( 1.3.6.1.4.1.15953.9.1.9
           NAME 'sudoNotAfter'
           DESC 'End of time interval for which the entry is valid'
           EQUALITY generalizedTimeMatch
           ORDERING generalizedTimeOrderingMatch
           SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )

        attributeTypes ( 1.3.6.1.4.1.15953.9.1.10
            NAME 'sudoOrder'
            DESC 'an integer to order the sudoRole entries'
            EQUALITY integerMatch
            ORDERING integerOrderingMatch
            SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )

        objectclass ( 1.3.6.1.4.1.15953.9.2.1 NAME 'sudoRole' SUP top STRUCTURAL
           DESC 'Sudoer Entries'
           MUST ( cn )
           MAY ( sudoUser $ sudoHost $ sudoCommand $ sudoRunAs $ sudoRunAsUser $
                 sudoRunAsGroup $ sudoOption $ sudoNotBefore $ sudoNotAfter $
                 sudoOrder $ description )
           )

関連項目

       ldap.conf(5), sudoers(5)

警告

       LDAP を使用する sudo の設定と sudoers ファイルによる sudo の設定では、 設定を解析する仕方
       に相違があるので、注意してほしい。詳細については、 「LDAP を使う場合と使わない場合の sudo
       設定の相違点」のセクションを参照すること。

バグ

       sudo にバグを発見したと思ったら、下記ページにアクセスして、 バグレポートを提出していただき
       たい。
       http://www.sudo.ws/sudo/bugs/

サポート

       ある程度の無料サポートが sudo-users メーリングリストを通して利用できる。 購読やアーカイブ
       の検索には、下記 URL をご覧になること。
       http://www.sudo.ws/mailman/listinfo/sudo-users

免責

       sudo は「現状のまま」提供される。 明示的な、あるいは黙示的ないかなる保証も、 商品性や特定
       目的への適合性についての黙示的な保証を含め、 またそれのみに止まらず、これを否認する。詳細
       な全文については、 sudo と一緒に配布されている LICENSE ファイルや、 下記 Web ページをご覧
       いただきたい。
       http://www.sudo.ws/sudo/license.html