web-dev-qa-db-ja.com

PAMを使用して一部のユーザーのLDAPパスワードを確認しながら、常にローカルファイルのUID / GIDを使用する方法

_/etc/passwd_のユーザーのサブセットについて、LDAPサーバーに対してログオンのパスワードチェック部分を実行するようにPAM（Linux）を構成します。これらのユーザーが実際に_/etc/passwd_。特に、uidnumberやgidnumberなどのプロパティをディレクトリに追加する必要がないように、_/etc/passwd_および_/etc/group_をUIDおよびGIDのすべてのケースで使用する必要があります。 （ここでは、Active Directory） LDAP Implementation HOWTO などのドキュメントに通常表示されるものとは異なります。

これは可能ですか（カスタムPAMモジュール開発なしで）？ LDAPディレクトリにプロパティを追加することはできません。私はActive Directoryドメイン管理者ではありません。そのレベルに関与をエスカレートすることは、このプロジェクトの範囲外です。これは、システムが主にWindowsサーバーである環境で稼働している場合です。指定されたWindowsユーザーが問題のシステムでADパスワードを使用できれば、それは素晴らしいことです。

ユーザーに応じて、ユーザーはUNIX認証またはLDAP認証でチェックされる必要がありますが、両方ではチェックされません。 Active Directoryのユーザーに属性を追加することはできませんが、セキュリティグループに追加することができます（実際には、LDAPユーザーが特定のLDAPセキュリティグループに属していることをさらに要求します）。

linuxldappam
6
Jason Kresowaty

あなたの質問を更新してくれてありがとう、そのアドバイスはしばしば間違った方法で行われます。

私が理解しているあなたの要件：

  • すべてのユーザーのUID/GIDルックアップは、ローカルファイルに対して実行する必要があります。
  • specificの認証ユーザーは、最初にLDAP（Active Directory）を試す必要があります。

簡単に言えば、可能ですが、オンラインHOWTOに依存せずに、これらのサブシステムがどのように機能するかを実際に理解する必要があります。私の既存の回答を入門書として紹介します。 https://serverfault.com/a/538503/15207

NSSは、UIDおよびGIDルックアップを実行するシステムです。 /etc/nsswitch.confを変更せずに、ldapまたはsssdを使用するように指示すると、システムコールはローカルファイルに依存します。 LDAPのほとんどのPAMプラグインは、LDAPのNSSプラグインと構成ファイルを共有しますが、NSSがNSSプラグインを使用していない場合でも、これは問題になりません。

これを特定のユーザーに対してのみ行うという要件は、より複雑です。 pam_ldap.soの直前にpam_krb5.soとしてpam_winbind.so（またはauth sufficient、またはauth required pam_unix.so...は使用するシステムによって異なります）を試すようにPAMを構成します。 sufficientは、「これで十分です」を意味します。 requiredは、「ここまで到達してこのテストが失敗した場合、認証が失敗する」ことを意味します。

これは最も簡単な方法ですが、問題があります。

  1. 誰かが自分のADパスワードと一致しないローカルパスワードで頻繁に認証している場合（つまり、他のシステムでは頻繁にADに対して正常に認証されない場合）、ADパスワードロックアウトが発生します。
  2. 特定のユーザーに対して有効なADパスワードを考慮したくない場合も、これは要件に適合しません。

本当に、本当に、本当に特定のユーザーリストのLDAPに対してのみ認証する必要があるかどうかをお知らせください。それは間違いなく可能ですが、PAM構成の複雑さが増し、すでにかなりの量の情報が提供されています。

必要に応じて答えを拡張します：

ADに対して認証するユーザーを厳密に制御するための推奨事項は、pam_access.soを使用することです。これが機能するためには、ADおよびUnix PAMモジュールmustが隣接しており、この順序で隣接しています。それらの前に次の行を配置します。

auth    [success=ignore default=1] pam_access.so accessfile=/etc/security/somefile.conf noaudit

success=ignoreは、「このテストが成功した場合、この行を無視して通常どおり続行する」ことを意味します。 default=1は、「その他の場合はすべて次の行をスキップする」ことを意味します。 somefile.confを作成し、AD authの使用を許可するユーザーのリストを定義する必要があります。詳細については、access.confのマンページを確認してください。このファイルですべてのユーザーのリストを定義するか、ローカルグループを作成してメンバーシップをテストします。すべての場合において、3番目のフィールドはALLである必要があります。 （つまり、+ : whatever : ALL）

オプションの要件（ADセキュリティグループでこれを制御する）は、次の2つの方法のいずれかで実装できます。

  1. PAMモジュールで、グループメンバーシップに基づいてauthチェックをスキップするLDAPクエリを指定できる場合は、それを使用します。これは、パスワードが成功した場合にaccountを介してユーザーを拒否することとは異なります。
  2. Active Directoryに到達するGIDルックアップで妥協。つまり、/etc/nsswitch.confのpasswdをldapルックアップポイントに持つことになりますが、-wouldldap行をgroupに追加します。セキュリティグループオブジェクトは、適切なobjectClass（つまりposixGroup）を適用するか、NSSプラグインを1つとして認識するように構成することにより、Unixグループとして認識できるように構成する必要があります。 LDAPに強いバックグラウンドがない限り、これを伝えたいだけかもしれません。

getent groupがADグループを表示するまでの設定が完了したら、そのグループのメンバーシップに基づいて成功するようにアクセスファイルを変更できます。

9
Andrew B