web-dev-qa-db-ja.com

Winbind / Kerberos LinuxAD統合でsuをドメインユーザーに制限する

Winbind/Kerberosを使用してADに参加しているRHEL5サーバーがいくつかあります。これは全体的にうまく機能しています。

PAMでADセキュリティグループを指定して、ログインできるドメインユーザーを制限しました。

 auth requisite pam_succeed_if.so user ingroup ad_group debug

また、sudoersで同じグループを指定して、rootアクセスを取得できるようにしました。

％ad_group ALL =（ALL）ALL

これらは期待どおりに機能します。

ただし、「su-」を使用すると、セキュリティグループに属していないドメインユーザーになることができます。

Jdoeが「ad_group」にないとしましょう。

 [kernelpanic @ server01〜] $ Sudo su --jdoe 
 [Sudo]ユーザーのパスワード：
ディレクトリ '/ home/jdoe'を作成しています。
ディレクトリ 'を作成しています/home/jdoe/.mozilla'。
ディレクトリの作成 '/home/jdoe/.mozilla/plugins'。
ディレクトリの作成'/home/jdoe/.mozilla/extensions'。
 [jdoe @ server01〜] $

/ var/log/secureの出力は次のとおりです。

 10月25日09：42：42server01 su：pam_unix（su-l：session）：kernelpanic（uid = 0）
 10月25日09：43：53server01suによってユーザーjdoeのセッションが開かれました：pam_unix（su-l：session）：ユーザーjdoe 
のセッションが閉じられました

ユーザーを「su-」から、そもそもボックスへのログインを許可されていないドメインユーザーに制限する方法はありますか？

linuxsuwinbind
1
kernelpanic

/etc/pam.d/suの最初の行は次のようになっていると思います。

auth            sufficient      pam_rootok.so

言い換えれば、suがjdoeになることを許可しようとすると、すべてが正常に見えます。

pam_succeed_if行を/etc/pam.d/suに追加するか、もっと良い方法として/etc/pam.d/system-authにエントリを追加しますが、authがsessionそのように：

session requisite pam_succeed_if.so user ingroup ad_group debug

これは、説明した状況でもトリガーされ、ad_group以外のユーザーがシェルを開くことはできません。これには、rootがシェルを開くのを制限するという不幸な副作用もあります（コメントで指摘されているように）。そのため、正しい範囲のユーザーIDにのみ適用する必要がある場合があります。

session [default=1 success=ignore] pam_succeed_if.so quiet uid >= 1000
session requisite pam_succeed_if.so user ingroup ad_group debug

ちなみに、公開鍵で認証している場合は、sshもPAMをバイパスする可能性があるため、sessionの代わりにauthを使用することをお勧めします。

1
chutz