
1 人のユーザーだけに影響する奇妙な Samba の問題が発生しています。Samba の設定は次のとおりです。
Red Hat Enterprise Linux Server リリース 5.4 (Tikanga) - Samba サーバー
Samba バージョン 3.0.33-3.14.el5 - Samba バージョン
ドメイン コントローラ WIN2008R2 標準 - Windows DC
Windows 7 64 ビット - クライアント PC
数週間前にPCを強制シャットダウンした後、この問題に直面したとユーザーは述べています。本来であれば、\\sambaservername
Windowsでアクセスすると、すべてのユーザーがSambaサーバーのすべての共有が表示されますが、このユーザーはPCを起動するとアクセスできなくなり\\sambaservername
、エラーメッセージが表示されます。
Windowsはアクセスできません
\\sambaservername
問題を解決するための現在の回避策:
\\sambaservername
たとえば、の共有にアクセスしようとします\\sambaservername\sharedfolder1
。しかし、そうする場合でも、最初はエラーが表示されます。エラーメッセージは次のとおりです。
ログオン失敗: ユーザー名が不明であるか、パスワードが間違っています。
\\sambaservername
ユーザーは資格情報を再度入力して共有にアクセスする必要があります。その後は問題なくアクセスできるようになります。しかし、コンピューターを再起動すると、問題は解決されません。
これまでに行われたトラブルシューティング:
次の設定を確認してください。
コントロールパネル → 管理ツール → ローカルセキュリティポリシー に移動して、ローカルポリシー → セキュリティオプションを選択します。
「ネットワーク セキュリティ: LAN Manager 認証レベル」→ LM および NTLM 応答を送信する「NTLM SSP の最小セッション セキュリティ」→ チェックを外す: 128 ビット暗号化が必要
ユーザーにパスワードをリセットして再試行するようアドバイスしたが、問題は解決しない
ユーザーの PC で自分のアカウントを試してみましたが、問題はありませんでした。自分のものを含め、他のいくつかの Windows 7 PC でユーザー アカウントを試してみましたが、問題は解決しませんでした。Windows XP ではこの問題は発生しません。
Windows 7 PCに保存されている資格情報がないことを確認してください。コントロールパネルの資格情報マネージャーをチェックし、次のコマンドを入力します。
rundll32.exe keymgr.dll, KRShowKeyMgr
Samba サーバーで winbindd デーモンを再起動しましたが、効果はありませんでした。
これはキャッシュの問題によるものだと思いますが、どこに問題があるのかはわかりません。ユーザーがアクセス時にエラーが発生すると\\sambaservername
、次のエラーが Samba サーバーに記録されます。
[2012/10/10 17:10:26, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
[2012/10/10 17:10:27, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
[2012/10/10 17:10:27, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
[2012/10/10 17:10:27, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
[2012/10/10 17:10:27, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
[2012/10/10 17:10:27, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
[2012/10/10 17:10:27, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
[2012/10/10 17:10:27, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
[2012/10/10 17:10:27, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
[2012/10/10 17:10:27, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
しかし、回避策を講じると、エラーは発生しなくなります。以下の記事を読んだ後、ディレクトリにいくつかの修正を加える必要があると思われます\var\samba\cache
。
- http://www.linuxquestions.org/questions/linux-server-73/getent-passwd-dont-show-ad-groups-and-users-745829/
- http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/tdb.html
- http://lists.samba.org/archive/samba/2010-May/155521.html
- http://lists.samba.org/archive/samba/2011-March/161912.html
- http://lzeit.blogspot.sg/2009/10/samba-shares-inaccessible-after-power.html
Samba サーバーを使用しているユーザーは複数いるため、影響を与えることなくこの問題を解決したいと考えています。
私は以下の記事を見ました:
「winbind オフライン ログオン (G) このパラメータは、Winbind がキャッシュされた資格情報を使用して pam_winbind モジュールでログインすることを許可するかどうかを制御するように設計されています。有効にすると、winbindd は成功したログインからのユーザー資格情報を暗号化してローカル キャッシュに保存します。
デフォルト: winbind オフライン ログオン = false
例: winbind オフライン ログオン = true "
ローカル キャッシュ内の 1 人のユーザーのエントリを削除する方法について何かアイデアはありますか?
答え1
よく分かりませんが、nbtstat -R
コマンド(「リモート キャッシュ名テーブルを消去して再読み込みします。」)またはnbtstat -RR
(「名前解放パケットを WIN に送信し、更新を開始します。」) は、あなたが求めている種類のリフレッシュを強制するために何でもできます...
マニュアルをご覧になりたい場合は、ここを見て..
答え2
ntpd がドメイン コントローラと同期されていることを確認してください。私も同じ問題を抱えていましたが、今日、問題のあるサーバーとドメイン コントローラの間に 45 分の時間差があることに気付きました。ntpdate を実行すると、問題なく動作しました。
答え3
私の経験では、これは通常、ドメイン コントローラ、または接続中のクライアント マシン (1 つのクライアントのみに問題がある場合) の時刻のずれの結果です。Kerberos では、認証サーバー要求と認証サーバー応答 (AS_Req と AS_rep) の両方に時間関連のパラメータが含まれているため、大きな差異があるとセッション トークンが拒否されます。
AS_Req には、要求されたトークンの有効期間が含まれます: AS_REQ = ( PrincipalClient 、 PrincipalService 、 IP_list 、 Lifetime )
AS_Rep には、DC タイムスタンプと適用された有効期間が含まれます: AS_REP = { PrincipalService 、 Timestamp 、 Lifetime 、 SKTGS }
したがって、時間の変動が Lifetime の範囲外の場合、接続は拒否されます。
推測: ドキュメントで寿命が分単位で指定されているかどうかは確認できませんでしたが、断続的に動作するマシンがあったため、寿命の境界にちょうど達していたことが唯一の理由だと考えています。つまり、約 30 秒間は動作しますが、その後分が反転し、接続が拒否されます。