web-dev-qa-db-ja.com

Kerberosが有効になっている場合にユーザーのアカウントをローカルでロックする

次の特性を持つマシンのグループに対して、Chefが管理するアカウントを設定しようとしています。

  • ローカルアカウントがない場合、ログインはブロックされます。
  • SSHキーを持つローカルアカウントがある場合は、それらを認証に使用できます。
  • ローカルパスワードを持つローカルアカウントがある場合、そのパスワードが認証に使用されます。
  • ローカルパスワードのないローカルアカウントがある場合は、Kerberosが使用されます。

私はそれだけの仕事をしています。

しかし、私ができるようにしたい最後のことは、パスワードをローカルでロックすることによってアカウントのログインを無効にすることです（たとえば、usermod -L）。問題は、ローカルパスワードがロックされると、PAMがKerberosにフォールバックして...アクセスを許可することです。

ローカルパスワードが存在するが、Kerberosを試行しないようにロックされている場合に、PAMを構成する方法はありますか？

これまで私が考えることができる最善の方法は、ローカルパスワードを推測できないもので破壊してアカウントをロックすることです。しかし、それは少し粗雑であり、誰かが「手順に従わない」場合はうまく機能しません...

linuxkerberospam
5
Stephen C

MichaelHamptonのコメントに同意します。これを行うにはKerberosを使用できます。ただし、ローカルマシンで変更を加えて実行したい場合は、次のソリューションが機能するはずです。

あなたのsshd_config、行を追加します

DenyGroups blocked

「blocked」という名前のグループを作成します。ユーザーのローカルパスワードをロックするときは、それらを「ブロックされた」グループにも追加します。

警告！これは、正気の世界に存在してはならない恐ろしく醜い応急修理です。しかし、それは私たちが住んでいるものでは役立つかもしれません。

5
Jenny D

この問題は主に、pam_unix.soauthではなくaccountスタックでアカウントのロックアウトをチェックします。これは、PAM初心者にとっては少し直感に反します。アカウンティングの決定shouldaccountではなくauthで行われますが、シャドウベースのアカウントロックはパスワードフィールドに基づいて実行されます。これはそれを必要な妥協にします。

そこから続行して修正の実装方法を決定する前に、PAMによって定義された管理グループを確認しましょう。

  • auth-認証に関する懸念。特に、プログラムが独自の認証スキームを実装している場合、プログラムがこのモジュールを完全にバイパスすることを選択する可能性があるため、ユーザーが認証のために送信する資格情報に基づく決定に微調整を制限します。 （誰もが忘れている例：SSHキー認証が有効になって成功した場合、sshdはauthをスキップします）
  • account- PAMを初めて使用するほとんどの人が見落としているもの。認証succeededであるが、とにかくユーザーがアクセスを拒否されるべきである場合、その決定はここで行われるべきです。 （sshd will notauthとは異なり、SSHキー認証が成功した場合はこのモジュールをスキップします）
  • passwd-authで定義したサービスに関連するパスワードを変更します。
  • session-認証が成功するかどうかとは通常ほとんど関係のないその他のタスク。ロギング、マウントなど。

問題の説明に基づく：

  1. Krb5資格情報よりもローカル資格情報を優先するauthスタックが必要ですが、2つのうちの1つが成功する必要があります。あなたはそれをカバーしているように聞こえます。
  2. ローカルユーザーが定義されていない場合にアクセスを拒否するaccountスタックが必要です。前に述べたように、pam_unix.soこの点で私たちを失敗させます。
  3. passwdのデフォルトは、ローカルパスワードの変更にはおそらく問題ありません。
  4. sessionに触れる直接の理由はありません。

あなたの提案した自己回答に基づいて、あなたはここからそれをどこに持っていくべきかについての考えを持っているように見えます。

1
Andrew B

仕事でこれをチェックする必要がありますが、私はthink「pam_krb5」エントリの後に「pam_exec」エントリをスタックに追加できます。これにより、「passwd -S」を使用するスクリプトを実行して、ユーザーのパスワードエントリがロックされていないことを確認できます。

または、ユーザーを「ブロックされた」グループに配置し、次のようにpam_succeed_ifを使用することでそれを行うことができます。

auth required pam_succeed_if.so quiet_success user notingroup blocked
0
Stephen C

一般的な使用では、ローカルアカウントとKerberosアカウントを混在させることはお勧めしません。ただし、このauthpamスタックは私たちの目的には機能するはずです。 （あなたは他の部分を持っているかもしれません、例えばpam_env.so含める予定です。）

auth     requisite     pam_unix.so nullok
auth     sufficient    pam_krb5 ignore_root use_first_pass
auth     required      pam_deny.so

ユーザーのローカルパスワードが正しくないか、ロックされている場合、認証は失敗します。ユーザーがローカルパスワードを持っていない場合、認証は（GSSAPIではなく）Kerberosを使用します。それが失敗すると、認証は失敗します。

0
84104