SUDOERS.LDAP(5) | MAINTENANCE COMMANDS | SUDOERS.LDAP(5) |
名前¶
sudoers.ldap - LDAP を使った sudo の設定
説明¶
sudo は sudoers ファイルによって設定するのが標準だが、 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 エントリである。 それは以下の構成要素からできている。
- sudoUser
- 次のうちのいづれか。ユーザ名、uid ('#' が頭に付く)、 Unix グループ名 ('%' が頭に付く)、 ユーザのネットグループ名 ('+' が頭に付く)。
- sudoHost
- 次のうちのいづれか。ホスト名、IP アドレス、ネットワークアドレス、 ホストのネットグループ名 ('+' が頭に付く)。 ALL という特別な値はいかなるホストにもマッチする。
- sudoCommand
- Unix のコマンド。コマンドライン引数を付けてもよく、glob 文字 (ワイルドカードとも言う) を含んでいてもよい。ALL という 特別な値は、いかなるコマンドにもマッチする。コマンドに 感嘆符 '!' を接頭辞として付けると、ユーザに そのコマンドの実行を禁じることになる。
- sudoOption
- 働きは、前述のグローバルオプションと同じだが、それが属している sudoRole エントリに対してのみ効果がある。
- sudoRunAsUser
- 変身対象となるユーザ名か、uid ('#' が頭に付く)。 あるいは、変身対象ユーザをリストに含む Unix のグループ名か ('%' が頭に付く)、ユーザのネットグループ名 ('+' が頭に付く)。特別な値 ALL は、 いかなるユーザにもマッチする。
- sudoRunAsGroup
- 変身対象となる Unix グループ名 か gid ('#' が頭に付く)。 特別な値 ALL はいかなるグループにもマッチする。
上記の各構成要素が含む値は一個であるべきだが、同じタイプの構成要素が 複数回現れてもよい。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 が
何にでもマッチするのは、この場合も同様である)。
ユーザ名やグループに対応するエントリが得られなかった場合は、
三回目の問い合わせが行われ、ユーザのネットグループを含んでいる
すべてのエントリーを取得して、問題のユーザがそのどれかに属していないかを
チェックする。
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 で サポートされているオプションのみが使用される。設定オプションを 以下に大文字で列挙するが、解析されるときは大文字小文字は区別されない。
- URI ldap[s]://[hostname[:port]] ...
- 接続する一個以上の LDAP サーバ の URI を、空白 (whitespace) で 区切ったリストの形で指定する。プロトコルは ldap と ldaps の どちらでもよい。後者は TLS (SSL) 暗号化に対応している サーバの場合である。ポートを指定しないときのデフォルトは、 ldap:// では 389 番ポート、 ldaps:// では 636 番ポートである。hostname を 一つも指定しないと、 sudo は localhost に接続することになる。 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
- BIND_TIMELIMIT パラメータは、LDAP サーバに 接続しようとするときの待ち時間を秒数で指定する。URI や HOST が複数指定されている場合は、その時間だけ待ってから、 リスト中の次のサーバに接続を試みることを意味する。
- TIMELIMIT seconds
- TIMELIMIT パラメータは、LDAP 参照に対して応答が 返ってくるまでの待ち時間を秒数で指定する。
- SUDOERS_BASE base
- sudo が LDAP 参照を行うときに使用するベース DN を 指定する。ドメインが example.com ならば、 ou=SUDOers,dc=example,dc=com という形になるのが普通である。
- 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 が on, true, yes に なっていると、 LDAP サーバの TLS 証明書が有効かどうかチェックが行われる。 LDAP サーバの証明書が有効であることを確認できない場合 (たいていは、 署名している認証局が未知 (unknown) であることが理由だ)、sudo は そのサーバに接続することができない。 TLS_CHECKPEER が off などの場合は、 チェックが行われない。
- TLS_CACERTFILE file name
- 認証局の証明書を一つにまとめたファイルのパス。たとえば、 /etc/ssl/ca-bundle.pem といったファイルであり、有効であると クライアントが認識しているすべての認証局の証明書がそこに入っている。 このオプションをサポートしているのは、OpenLDAP ライブラリだけである。
- 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.pemNetscape 由来:
tls_cert /var/ldap/cert7.dbNetscape 由来のライブラリを使う場合は、このファイルに認証局の証明書も 入れることができる。
- TLS_KEY file name
- TLS_CERT
で指定した証明書に対応する秘密鍵が入っている
ファイルのパス。この秘密鍵はパスワードでプロテクトされていてはならない。
鍵のタイプは利用する
LDAP
ライブラリによって異なっている。
OpenLDAP:
tls_key /etc/ssl/client_key.pemNetscape 由来:
tls_key /var/ldap/key3.db - TLS_RANDFILE file name
- TLS_RANDFILE は、random デバイスを持っていないシステムの ためにエントロピー・ソースのパスを指定する。これは通例、prngd や egd と組み合わせて使用するものである。このオプションを サポートしているのは、 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 資格証明キャッシュのパス。
「用例」セクションにある
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.conf を nsswitch.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 を使用する 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 |