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=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.conf の
SUDOERS_TIMED
オプションで明示的に有効にする必要がある。
- sudoNotAfter
- yyyymmddHHMMSSZ
形式のタイムスタンプ。
この属性を含む sudoRole
エントリがもはや有効ではなくなる、
失効日時を示している。
複数の sudoNotAfter
が存在する場合は、
一番最後の日時が採用される。
タイムスタンプは協定世界時
(UTC)
によるものでなければならず、
ローカル・タイムゾーンによるものではないことに注意してほしい。
分や秒の部分は省略できるが、LDAP
サーバによっては (RFC
の規定とは逆に)
分や秒の指定を必須にしていることもある。
属性 sudoNotAfter は、
バージョン 1.7.5 以上の
sudo
でなければ、利用できない。
また、 /etc/ldap.conf の
SUDOERS_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)
で区切ったリストの形で指定する。プロトコルは
ldap と ldaps
のどちらでもよい。
後者は TLS (SSL)
暗号化に対応しているサーバの場合である。
ポートを指定しないときのデフォルトは、
ldap:// では 389 番ポート、
ldaps:// では 636
番ポートである。
hostname
を一つも指定しないと、
sudo は localhost
に接続することになる。
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
- 接続しようとするときの待ち時間を秒数で指定する。URI
や HOST
が複数指定されている場合は、その時間だけ待ってから、
リスト中の次のサーバに接続を試みることを意味する。
- 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
デバイスを持っていないシステムのために
エントロピー・ソースのパスを指定する。
これは通例、 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
資格証明キャッシュのパス。
- 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.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
#
# 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