調試 sssd 登錄：pam_sss………系統錯誤
在以下情況下如何正確調試 shell 登錄？
身份驗證通過 sssd 配置和 krb5 身份驗證伺服器處理。在 Ubuntu 16.04 LTS 上使用相同的 .conf 文件登錄可以完美執行。一旦將它與 17.04 一起使用，使用除 root 以外的所有內容登錄會導致重新啟動 getty shell - /var/log/syslog 狀態
getty@tty2.service: Service has no hold-off time, sheduling restert. Stopped Getty on tty2. Started Getty on tty2.並在 auth.log 中註明以下內容：
pam_sss(login:account): Access denied for user <user>: 4 (System error) System error執行
login <user>結果root@pctest# login <user> password: System error root@pctest#使用
sssctl config-check16.04 LTS 上的工作配置不會產生預期的錯誤。我提到的每個測試都是在格式化驅動器上自動配置和手動檢查、新安裝的系統上執行的。通過元包安裝了其他
ubuntu-standard包（未安裝桌面環境）。儘管如此，該問題也在升級到 17.04 的工作 16.04 LTS 系統上重現。我既沒有找到詳細的模式，
login也沒有找到一種合理的方法來獨立執行登錄的失敗部分。那你會怎麼做？$$ Edit $$解決方法
給定問題的解決方案是：
我們的解決方法是在
$$ domain $$文件 /etc/sssd/sssd.conf 的部分 …
來源：https ://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859445
您需要將 debug_level=10 添加到 sssd.conf 文件中的所有部分，重新啟動 sssd 並重新執行登錄。然後查看 /var/log/sssd。另請閱讀 https://docs.pagure.org/sssd.sssd/users/troubleshooting.html
只是想知道為什麼一些新的連接 Active Directory 的 Linux (Debian 9) 系統報告
system error了，su而一些較舊的系統沒有顯示這種行為。設置ad_gpo_access_control = permissive確實使它起作用，但根本原因是新系統的 IP 地址位於未記錄在 Active Directory站點和服務中的子網中。一旦子網被添加並分配給一個站點（給 AD 一些時間來複製），system error就不再報告了。