次の場合、シェルログインを適切にデバッグするにはどうすればよいですか?
認証は、sssd構成とkrb5認証サーバーを介して処理されます。 Ubuntu 16.04 LTSで同じ.conf-fileを使用してログインすると、完全に機能します。 17.04で一度使用すると、root以外のすべてでログインすると、gettyシェルが再起動されます-/ var/log/syslog states
[email protected]: 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-check
を使用すると、16.04 LTSで動作している構成から予想されるエラーは発生しません。
私が言及したすべてのテストは、フォーマットされたドライブに自動的に構成され、手動でチェックされ、新しくインストールされたシステムで実行されました。 ubuntu-standard
メタパッケージを介して追加のパッケージがインストールされました(デスクトップ環境はインストールされていません)。それにもかかわらず、問題は、17.04にアップグレードされた正常な16.04 LTSシステムでも再現されました。
login
の詳細モードも、ログインの失敗した部分をスタンドアロンとして実行するための合理的な方法も見つかりませんでした。それで、あなたは何をしますか?
[編集]回避策
指定された問題の解決策は次のとおりです。
私たちの回避策は、ファイル/etc/sssd/sssd.confの[domain]セクションにad_gpo_access_control = permissiveを設定することでした...
出典: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859445
Sssd.confファイルのすべてのセクションにdebug_level = 10を追加し、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
確かに機能しましたが、根本的な原因は、新しいシステムがActive Directoryに記録されていないサブネット内のIPアドレスを持っていることですサイトとサービス。サブネットが追加されてサイトに割り当てられたら(ADにレプリケートする時間を与える)system error
は報告されなくなりました。
私は今日16.04LTSとまったく同じ問題を抱えていました。
あなたの回避策も私のために働いたことを確認できます。
私のドメインセクションに追加しました:
ad_gpo_access_control = permissive
その後は完璧に機能しました。 16.04LTSとSSSDにバグがあるようです。その回避策を投稿していただき、ありがとうございます。このエラーに関する情報はどこにも見つかりませんでした。