Scroll to navigation

SUDOERS.LDAP(5) MAINTENANCE COMMANDS SUDOERS.LDAP(5)

名前

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=default の エントリを捜す。見つかった場合は、複数回指定可能な 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 エントリである。 それは以下の構成要素からできている。

次のうちのいづれか。ユーザ名、uid ('#' が頭に付く)、 Unix グループ名 ('%' が頭に付く)、 ユーザのネットグループ名 ('+' が頭に付く)。
次のうちのいづれか。ホスト名、IP アドレス、ネットワークアドレス、 ホストのネットグループ名 ('+' が頭に付く)。 ALL という特別な値はいかなるホストにもマッチする。
Unix のコマンド。コマンドライン引数を付けてもよく、glob 文字 (ワイルドカードとも言う) を含んでいてもよい。ALL という 特別な値は、いかなるコマンドにもマッチする。コマンドに 感嘆符 '!' を接頭辞として付けると、ユーザに そのコマンドの実行を禁じることになる。
働きは、前述のグローバルオプションと同じだが、それが属している sudoRole エントリに対してのみ効果がある。
変身対象となるユーザ名か、uid ('#' が頭に付く)。 あるいは、変身対象ユーザをリストに含む Unix のグループ名か ('%' が頭に付く)、ユーザのネットグループ名 ('+' が頭に付く)。特別な値 ALL は、 いかなるユーザにもマッチする。
変身対象となる Unix グループ名 か gid ('#' が頭に付く)。 特別な値 ALL はいかなるグループにもマッチする。

上記の各構成要素が含む値は一個であるべきだが、同じタイプの構成要素が 複数回現れてもよい。sudoRole エントリは sudoUsersudoHostsudoCommand を 少なくとも一個づつ含んでいなければならない。

以下の例では、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 が 何にでもマッチするのは、この場合も同様である)。 ユーザ名やグループに対応するエントリが得られなかった場合は、 三回目の問い合わせが行われ、ユーザのネットグループを含んでいる すべてのエントリーを取得して、問題のユーザがそのどれかに属していないかを チェックする。

LDAP と non-LDAP の sudo 設定の相違点

LDAP を使用する場合、sudo の設定の処理方法に /etc/sudoers の場合とは 微妙な違いがいくつかある。たぶん最大の違いは、RFC に書いてあるとおり、 LDAP の順序づけは不定なので、属性やエントリが何らかの 決まった順序で返されることを期待できないということだろう。ただし、 あるエントリーにコマンドに関して相反するルールがある場合は、否定する方が 優先される。これはパラノイア的動作と言われるものだ (もっとも、それが 一番明示的なマッチだとはかぎらないのだが)。

例を挙げてみよう。

    # /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 で サポートされているオプションのみが使用される。設定オプションを 以下に大文字で列挙するが、解析されるときは大文字小文字は区別されない。

接続する一個以上の LDAP サーバ の URI を、空白 (whitespace) で 区切ったリストの形で指定する。プロトコルは ldapldaps の どちらでもよい。後者は TLS (SSL) 暗号化に対応している サーバの場合である。ポートを指定しないときのデフォルトは、 ldap:// では 389 番ポート、 ldaps:// では 636 番ポートである。hostname を 一つも指定しないと、 sudolocalhost に接続することになる。 OpenSSL ライブラリを使用しているシステムのみが、ldap://ldaps:// 両方の URI を混ぜて使うことに対応している。 たいていの商用 Unix では Netscape 由来のライブラリが使用されて いるが、そうしたライブラリはどちらか一方に対応することしかできない。
URI パラメータが指定されていない場合は、 HOST パラメータで指定する空白 (whitespace) で 区切ったリストが、接続する LDAP サーバである。 各ホストにはコロン (':') に続けて、ポート番号を書いてもよい。 HOST パラメータは非推奨であり、URI で 指定する方が望ましい。このパラメータがあるのは、後方互換のためである。
URI パラメータが指定されず、HOST パラメータでも ポートが指定されていないときは、PORT パラメータが LDAP サーバに接続するときのデフォルトのポートを指定する。 PORT パラメータが使用されていない場合、デフォルトのポートは LDAP では 389 番、LDAP over TLS (SSL) では 636 番である。PORT パラメータは非推奨であり、 URI で指定する方が望ましい。このパラメータがあるのは、 後方互換のためである。
BIND_TIMELIMIT パラメータは、LDAP サーバに 接続しようとするときの待ち時間を秒数で指定する。URIHOST が複数指定されている場合は、その時間だけ待ってから、 リスト中の次のサーバに接続を試みることを意味する。
TIMELIMIT パラメータは、LDAP 参照に対して応答が 返ってくるまでの待ち時間を秒数で指定する。
sudo が LDAP 参照を行うときに使用するベース DN を 指定する。ドメインが example.com ならば、 ou=SUDOers,dc=example,dc=com という形になるのが普通である。
sudo が LDAP 参照をするときのデバッグレベルを決める。 デバック情報の出力先は標準エラーである。値を 1 にすると、 多からず少なからずほどほどのデバック情報が表示される。値を 2 にすると、 マッチの結果そのものも出力される。実用環境では、このパラメータを 設定するべきではない。ユーザが余計な情報に混乱しかねないからだ。
BINDDN パラメータは、誰の名前で LDAP の操作を行うかを、 識別名 (DN) を使って指定する。これが指定されていない場合、 LDAP の操作は anonymous の名前で実行される。 LDAP サーバは、たいていデフォルトで anonymous によるアクセスを 許可しているものである。
BINDPW パラメータは、LDAP の操作を行うときに 使用するパスワードを指定する。通例、このパラメータは、BINDDN パラメータと組み合わせて使用する。
ROOTBINDDN パラメータは、sudo 設定の参照のような 特権的な LDAP 操作をするとき、誰の名前で行うかを識別名 (DN) を 使って指定する。その名前に対応するパスワードは /etc/ldap.secret に 書き込んでおくべきだ。これが指定されていない場合は、BINDDN で 指定した名前が (もし、あるならば) 使用される。
サーバに接続するときに使用する LDAP プロトコルのバージョン。 デフォルトの値は、プロトコルバージョン 3 である。
SSL パラメータが on, true, yes に なっていると、LDAP サーバと通信する際に、常に TLS (SSL) の暗号化を使用することになる。通例、それは 636 番ポート (ldaps) を通してサーバに接続することである。
SSL パラメータを start_tls に設定すると、 LDAP サーバへの接続を平文で開始してから、バインド操作のために 認証情報を送信する前に TLS の暗号化を始めることになる。 これには、暗号化された通信のために専用のポートを必要としないという 長所がある。このパラメータをサポートしているのは、 OpenLDAP サーバのような start_tls 拡張に対応している LDAP サーバのみである。
TLS_CHECKPEERon, true, yes に なっていると、 LDAP サーバの TLS 証明書が有効かどうかチェックが行われる。 LDAP サーバの証明書が有効であることを確認できない場合 (たいていは、 署名している認証局が未知 (unknown) であることが理由だ)、sudo は そのサーバに接続することができない。 TLS_CHECKPEERoff などの場合は、 チェックが行われない。
認証局の証明書を一つにまとめたファイルのパス。たとえば、 /etc/ssl/ca-bundle.pem といったファイルであり、有効であると クライアントが認識しているすべての認証局の証明書がそこに入っている。 このオプションをサポートしているのは、OpenLDAP ライブラリだけである。
TLS_CACERTFILE に似ているが、ファイルではなく、たとえば /etc/ssl/certs といったディレクトリであり、認証局の証明書が 1 認証局 1 ファイルの形でそこに入っている。TLS_CACERTDIR で 指定したディレクトリは、TLS_CACERTFILE の後でチェックされる。 このオプションをサポートしているのは、OpenLDAP ライブラリだけである。
クライアントの証明書が入っているファイルのパス。この証明書は、 LDAP サーバに対してクライアントの認証をするときに使用できる。 証明書のタイプは、利用する LDAP ライブラリによって異なっている。

OpenLDAP:
tls_cert /etc/ssl/client_cert.pem

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

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

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

OpenLDAP:
tls_key /etc/ssl/client_key.pem

Netscape 由来:
tls_key /var/ldap/key3.db

TLS_RANDFILE は、random デバイスを持っていないシステムの ためにエントロピー・ソースのパスを指定する。これは通例、prngdegd と組み合わせて使用するものである。このオプションを サポートしているのは、 OpenLDAP ライブラリだけである。
管理者は TLS_CIPHERS パラメータによって、 TLS (SSL) 接続に使用可能な暗号アルゴリズムを限定する ことができる。有効な暗号のリストについては OpenSSL のマニュアルを 参照してほしい。このオプションをサポートしているのは、OpenLDAP ライブラリ だけである。
LDAP サーバ が SASL 認証をサポートしているなら、 USE_SASL を有効にする。
LDAP サーバに接続するときに使用する SASL ユーザ名。 デフォルトでは、 sudo は anonymous 接続を使用する。
ROOTUSE_SASL を有効にすると、sudo のような 特権的なプロセスから LDAP サーバに接続するときに SASL 認証が可能になる。
ROOTUSE_SASL が有効なとき使用する SASL ユーザ名。
SASL セキュリティ・プロパティ。プロパティなしのときは none を 指定する。詳細については、SASL プログラマーズ・マニュアルを見ること。
リモート・サーバに対して認証をするときに使用する Kerberos 5 資格証明キャッシュのパス。

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

nsswitch.conf の設定

ビルド時に無効にしないかぎり、sudo はネームサービス・スイッチ・ ファイル /etc/nsswitch.conf を調べて、sudo の設定を 参照する順番を決める。すなわち、/etc/nsswitch.confsudoers: という文字列に始まる行を探し、 その行によって参照順を決定するのである。 気をつけてほしいのは、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
  #
  # 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 で指定するのは、
  # ディレクトリでもよく、cert や 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 username>
  # rootuse_sasl yes
  # rootsasl_auth_id <SASL username for root access>
  # sasl_secprops none
  # krb5_ccname /etc/.ldapcache

OpenLDAP 用の Sudo のスキーマ

下記のスキーマは 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 )
 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 $ description )
    )

参照

ldap.conf(5), sudoers(5)

警告

LDAP を使用する sudo の設定と sudoers ファイルによる sudo の設定では、設定を解析する仕方に相違があるので、注意して ほしい。詳しくは、「LDAP と non-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

June 11, 2009 1.7.2p1