Active Directoryサーバーが提供するKerberosとNISを使用するように設定したいDebian 7.7システムがあります。
kinitADサーバーから資格情報セットを取得できるようにkerberosを設定しました。
su - $USERADユーザーに接続できるようにNISを設定しましたが、すべてがうまく機能します。
ユーザーとしてログインできません。
コンソールからログインすると、auth.log に次のログが表示されます。
Nov 5 10:22:41 debian login[3888]: pam_krb5(login:auth): pam_sm_authenticate: entry
Nov 5 10:22:45 debian login[3888]: pam_krb5(login:auth): (user dmackintosh) attempting authentication as dmackintosh@AD.$ZONE
Nov 5 10:22:45 debian login[3888]: pam_krb5(login:auth): user dmackintosh authenticated as dmackintosh@AD.$ZONE
Nov 5 10:22:45 debian login[3888]: pam_krb5(login:auth): (user dmackintosh) temporarily storing credentials in /tmp/krb5cc_pam_54ruC8
Nov 5 10:22:45 debian login[3888]: pam_krb5(login:auth): pam_sm_authenticate: exit (success)
Nov 5 10:22:45 debian login[3888]: Authentication failure
SSH経由でログインすると、次のようになります。
Nov 5 10:24:00 debian sshd[7641]: pam_krb5(sshd:auth): pam_sm_authenticate: entry (nonull)
Nov 5 10:24:00 debian sshd[7641]: pam_krb5(sshd:auth): (user dmackintosh) attempting authentication as dmackintosh@AD.$ZONE
Nov 5 10:24:00 debian sshd[7641]: pam_krb5(sshd:auth): user dmackintosh authenticated as dmackintosh@AD.$ZONE
Nov 5 10:24:00 debian sshd[7641]: pam_krb5(sshd:auth): (user dmackintosh) temporarily storing credentials in /tmp/krb5cc_pam_NQ9vhz
Nov 5 10:24:00 debian sshd[7641]: pam_krb5(sshd:auth): pam_sm_authenticate: exit (success)
Nov 5 10:24:00 debian sshd[7641]: Failed password for dmackintosh from 10.8.0.21 port 47234 ssh2
Nov 5 10:24:00 debian sshd[7641]: fatal: Access denied for user dmackintosh by PAM account configuration [preauth]
どちらの場合も、ログイン試行はすぐにブロックされます。 A）kinitテストに合格し、B）意図的に間違ったパスワードを入力した場合、再入力するように求める前に、「ユーザーのパスワードが間違っています」というメッセージが表示されるのを待つため、パスワードが正しいことがわかります。
PAM設定は/usr/share/doc/libpam-krb5/README.Debianとほぼ同じです。 PAMデバッグステートメントのみが追加されました。
GSSAPIAuthenticationおよびGSSAPICleanupCredentialsオプションを有効にするようにSSHが変更されましたが、これは違いはありません。
私はCentOS 5と6で作業しているので、これはDebianシステムのどこかで設定の問題であるに違いありません。
私はインターネットがこれを行うためにNISの代わりにLDAPを使用したいと思いますが、「理由」のためにNISを維持する必要があります。
修正する：/etc/shadowにそのユーザーのエントリがある場合は動作することが確認されました。これは、NISを使用する目的を完全に崩壊させることです。これにより、次のような/etc/nsswitch.confファイルに問題があると考えられます。
passwd: files nis
group: files nis
shadow: files nis
hosts: files dns
networks: files
protocols: db files
services: db files
ethers: db files
rpc: db files
netgroup: nis
automount: nis
アップデート2：/etc/shadow に追加情報がないと、 からgetent shadow返されないことがわかりypcat shadowました。また、GentooとUbuntuも同様の影響を受けることがわかりました。 .NETマッピングコンテンツを介したNIS getent。
ベストアンサー1
答えは、broken_shadowpam_unix機能を有効にすることです。
で/etc/pam.d/common-accountpam_unix 行を探し、broken_shadow最後に以下を追加します。
account [success=1 new_authtok_reqd=done default=ignore] pam_unix.so broken_shadow
説明する：
一部のネットワーク設定には、暗号化されたパスワードフィールドに「x」が含まれていますが、シャドウ情報はありません。これが発生すると、pam_unixはこの情報を読み取れないため、アカウントの管理に失敗します。 「brokenshadow」オプションは、情報の読み込み中にエラーが発生した場合、その情報が存在しないことを意味し、ユーザーがログインできるようにします。