我正在嘗試根據 Sander Van Vugt 的 RHEL7 的 RHCSA/RHCE 書中的說明設定 LDAP 身份驗證。在第 6 章中，他解釋了當使用authconfig-tui該FORCELEGACY選項時，將其設為yesin /etc/sysconfig/authconfig。這應該配置nslcd而不是sssd.
我不認為這種情況會發生。也許在 7.0 甚至 7.1 中就是這樣，但在 7.3 中該選項設定為noafter using authconfig-tui.
如果我拋開nslcdvs混亂並嘗試完成導致運行透過 LDAP 對所述使用者進行身份驗證的sssd練習，我只會得到：su - lara
su: user lara does not exist
我已經驗證 FreeIPA 伺服器正在使用 回答查詢，ldapsearch並在這樣做時確認使用者位於 LDAP 中。但在我看來，這su並不是針對 LDAP 進行身份驗證，而是針對/etc/passwd.
我的PAM system-auth配置包括sssd似乎必要的條目：
auth sufficient pam_sss.so forward_pass
account [default=bad success=ok user_unknown=ignore] pam.sss.so
password sufficient pam_sss.so use_authtok
session optional pam_sss.so
我的/etc/nsswitch.conf文件包含：
passwd: files sss
shadow: files sss
group: files sss
該sssd服務處於活動狀態。
/var/log/*或中沒有任何日誌條目/var/log/sssd/*。事實上，所有sssd日誌都不包含任何內容。
編輯
經過一番閱讀後，我仍然沒有找到解決方案，但是，我確實有更多資訊。
ssh如果我進入 LDAP 伺服器，我就能夠以使用者 lara 身份進行身份驗證。所以我知道 LDAP 確實在工作。
我還查看了PAM的配置su。這是拉入system-auth文件：
auth substack system-auth
account include system-auth
password include system-auth
session include system-auth
所以它應該隱式地使用該pam_sss.so模組。
但仍然無法解決。
編輯2
由於能夠在本機或透過 SSH 使用使用者 lara 登入 IPA 伺服器，我決定將其上的 pam 檔案與用戶端上的 pam 檔案進行比較。我能夠確定的唯一區別是客戶端包含broken_shadow在pam_unix.so帳戶條目中。我刪除了它，甚至重新啟動，但它沒有解決任何問題。
我該如何禁用broken_shadow？我找不到任何相關資訊。
答案1
這可能是不相關的，但我正在遵循相同的過程（使用我創建的客戶端伺服器）並設法透過執行以下操作來修復它：
- 檢查所有內容是否與我在 /etc/sssd/sssd.conf 中的 authconfig-tui 中設定的內容相符
- 將 /etc/sssd/sssd.conf 上的權限設為 0600（此後立即生效） - 我不確定為什麼這會產生影響，因為它只授予用戶 R/W，但我在 Oracle 指南下找到了它對RHEL7 SSSD 用戶端設定：https://docs.oracle.com/cd/E52668_01/E54669/html/ol7-sssd-ldap.html