web-dev-qa-db-ja.com

NetAppエラー：STATUS_NOLOGON_WORKSTATION_TRUST_ACCOUNT

デスクトップ上のWindows 7へのサイト全体のアップグレード以降、ウイルスチェックに問題が生じ始めました。具体的には ファイラーがホストする）CIFS共有で名前変更操作を実行するとき。ウイルスチェッカーがファイラーで一連のメッセージをトリガーしているようです：

[filerB: auth.trace.authenticateUser.loginTraceIP:info]: AUTH: Login attempt by user server-wk8-r2$ of domain MYDOMAIN from client machine 10.1.1.20 (server-wk8-r2).
[filerB: auth.dc.trace.DCConnection.statusMsg:info]: AUTH: TraceDC- attempting authentication with domain controller \\MYDC.
[filerB: auth.trace.authenticateUser.loginRejected:info]: AUTH: Login attempt by user rejected by the domain controller with error 0xc0000199: STATUS_NOLOGON_WORKSTATION_TRUST_ACCOUNT.
[filerB: auth.trace.authenticateUser.loginTraceMsg:info]: AUTH: Delaying the response by 5 seconds due to continuous failed login attempts by user server-wk8-r2$ of domain MYDOMAIN from client machine 10.1.1.20.

これは特にrenameでトリガーされるようです。そのため、ウイルスチェッカーが「新しい」ファイルを見つけ、オンアクセススキャンを実行しようとしていると考えられます。ウイルスチェッカー-以前はLocalSystemとして実行されていたため、認証リクエストとしてnullを送信しているため、DOS攻撃のように見え、ファイラーが一時的にブラックリストに登録されます。この5秒ごとの「アクセス試行」のロックアウトは、ほとんどの場合マイナーな迷惑であり、一部の操作では非常に重要です。すべてのファイルに5秒かかる大きなファイル転送

いくつかの掘り下げを行った後、これはNLTM認証に関連しているようです：

Symptoms

Error message:

System error 1808 has occurred.
The account used is a computer account. Use your global user account or local user     account to access this server.

A packet trace of the failure will show the error as:

STATUS_NOLOGON_WORKSTATION_TRUST_ACCOUNT (0xC0000199)

Cause

Microsoft has changed the functionality of how a Local System account identifies itself
during NTLM authentication.  This only impacts NTLM authentication.  It does not impact
Kerberos Authentication.

Solution

On the Host, please set the following group policy entry and reboot the Host.
Network Security: Allow Local System to use computer identity for NTLM: Disabled
Defining this group policy makes Windows Server 2008 R2 and Windows 7 function like Windows Server 2008 SP1.

これで、特にナイスではないいくつかの回避策ができました。1つは、このセキュリティオプションを変更することです。 1つは、ウイルスチェックを無効にするか、インフラストラクチャの一部を免除することです。

そして、ここでServerFaultからの支援を求められます-最善の方法は何ですか？表示されている内容を確認するためのWindowsの経験がありません。

そもそもなぜNTLMがこの図の一部になっているのか、完全にはわかりません。Kerberos認証を使用していると思いました。これを診断またはトラブルシューティングする方法がわかりません。 （私たちはクロスドメインに行きます-ワークステーションマシンアカウントは私のファイラーとは別のADとDNSドメインにあります。しかし、通常のユーザー認証はうまくいきます。）

それに失敗した場合、他の質問を提案できますか？サイト全体のセキュリティオプションの変更を回避したい場合、またはそのようにした場合、詳細な理由を提供できるようにする必要があります。同様に-ウイルスチェックを無効にすることは短期的な回避策として機能し、除外を適用します may help ...しかし、私はむしろそうしません、そしてそれが根本的な問題を解決するとは思いません。

編集：AD ldapのファイラーには、以下のSPNがあります。

nfs/Host.fully.qualified.domain
nfs/Host
HOST/Host.fully.qualified.domain
Host/host

（申し訳ありませんが、それらを難読化する必要があります）。

'cifs/Host.fully.qualified.domain'がないと機能しないのでしょうか？ （または他のSPN？）

編集：私が行ってきた検索の一部として、次のことがわかりました：---（http://itwanderer.wordpress.com/2011/04/14/tread-lightly-kerberos-encryption-types/

これは、Win7/2008R2ではいくつかの暗号化タイプがデフォルトで無効にされていたことを示唆しています。 Keberized NFSv4でも同様の問題が確実に発生しているため、この might が適切である可能性があります。 かもしれませんいくつかの将来のKeberosユーザーを助ける隠されたオプションがあります：オプションnfs.rpcsec.trace on（これは私にまだ何も与えていないので、NFS固有かもしれません）。

編集：さらに掘り下げると、クロスドメイン認証に追跡できます。私のWindows 7ワークステーション（1つのドメイン内）が他のドメインのKerberosチケットを取得していないように見えます。NetAppファイラーがCIFSに参加している他のドメインのKerberosチケットを取得していません。これをスタンドアロンサーバー（Win2003およびWin2008）に対して個別に実行しましたが、それらのKerberosチケットも取得しませんでした。

つまり、 think Kerberosが壊れている可能性がありますが、さらにトラブルシューティングする方法がわかりません。

編集：更なる更新：クロスドメインで発行されていないKerberosチケットがダウンしている可能性があります。これによりNTLMフォールバックがトリガーされ、この問題が発生します（Windows 7以降）。呼び出しの最初のポートは、Kerberos側の問題を調査することですが、どちらの場合も、根本的な原因であるファイラーを指摘するものは何もありません。そのように-ストレージエンジニアとして-それは私の手にはありません。

ただし、2つのWindows ADドメイン（Kerberosレルム）にまたがるKerberosのトラブルシューティングの方向に誰かが私を向けることができれば、それはありがたいです。

解決のために検討する予定のオプション：

  • GPO（上記のとおり）を介してすべてのワークステーションのポリシーオプションを修正します。
  • 名前変更トリガースキャンについてAVベンダーと話します。
  • AVをサービスアカウントとして実行することに関してAVベンダーと話します。
  • kerberos認証を調査する（機能しない理由、機能する必要があるかどうか）。
windowskerberosntlmnetapp
7
Sobrique

私はこれの実行の終わりに来ました、そして今、それが起こっている理由を知っています。

要約すれば：

  • Windows 7/2008以降、クライアントマシンの「LocalSystem」のデフォルトの動作が変更されました。 「null」ログインを使用する前に、NTLMのマシンアカウントを使用します。

  • 2つのADフォレスト間を移動しているため、Kerberosは使用されていません。これは仕様によるものです。 http://technet.Microsoft.com/en-us/library/cc960648.aspx "Kerberos認証では、フォレスト内のドメイン間で透過的な推移的信頼が使用されますが、別のフォレスト内のドメイン間では認証できません"

    • ソフォスは、ファイル名を変更することで「オンアクセス」でファイルをスキャンしています。セキュリティポリシー上の理由から、これにはネットワークドライブが含まれます。

    • ソフォスはLocalSystemとして実行されているため、NTLMを介してファイラーにマシンアカウントを提示しています。その後、このアカウントはSTATUS_NOLOGON_WORKSTATION_TRUST_ACCOUNTで拒否され、10回再試行した後、ファイラーがロックアウトをトリガーします。

    • このロックアウトのため、その後のウイルススキャンの試行は、試行ごとに5秒間停止します。私たちのプロセスは数百のファイルをコピーして名前を変更するので、これが私たちの問題の根源であり、10日以降はそれぞれに5秒かかります。

これにより、次の解決策が残されます。

  • 上記のセキュリティポリシーオプションを修正します。ネットワークセキュリティ：ローカルシステムがNTLMのコンピューターIDを使用できるようにする：無効

    • ネットワークドライブのウイルスチェッカーに除外を適用する

    • 別のドメインを同じフォレストにマージして、Kerberosが機能するようにします（別のオプションの概要を以下に示します： http://xitnotes.wordpress.com/2012/03/29/kerberos-in-an-active-directory- forest-trust-vs-external-trust / ドメイン間の関係をアップグレードして、Kerberosが再び機能するようにします。

    • Vfilerを使用すると、CIFがそれを他のドメインに参加させます。

    • ファイラーには、このロックアウトが発生する前に再試行の回数を増やすオプションもあります。これは非表示のオプションであり、正確な構文はありません。

3
Sobrique

ネットワーク経由で共有されているファイルをスキャンしないようにウイルス対策ポリシーを変更します。潜在的に、ネットワーク全体で同じファイルを同時にAVスキャンしようとするダースのクライアントがいる可能性があります。

したがって、Windows 2000、2003、Windows XP、Vista、および2008では、デフォルトの動作は次のようになります。

  • ネットワークセキュリティ：ローカルシステムがNTLMのコンピューターIDを使用できるようにします
    • 無効：NTLM認証に戻すときにネゴシエートを使用するローカルシステムとして実行されているサービスは匿名で認証されます。

しかし、Windows 7および2008 R2以降では、デフォルトの動作が次のように変更されました。

  • ネットワークセキュリティ：ローカルシステムがNTLMのコンピューターIDを使用できるようにします
    • 有効：ローカルシステムとして実行されている、ネゴシエートを使用するサービスは、コンピューターのIDを使用します。

ソース： http://technet.Microsoft.com/en-us/library/jj852275.aspx

サイト全体のセキュリティオプションの変更を回避したいとおっしゃっていますが、すべてのクライアントをWindows 7にアップグレードしたときに、すでに変更を加えています。

そもそもなぜKerberosを使用していないのかについては、これはまったく異なる質問であり、答えられるだけの十分なデータを私たちに提供していません。 Kerberosが機能するためには、CIFSサービスはドメインと登録されたサービスプリンシパル名との信頼関係を必要とし、クライアントはIPアドレスではなくホスト名またはFQDNでサービスをアドレス指定する必要があります。

ファイラードメインに参加していますか？その場合、CIFS/* SPNはありますか？

4
Ryan Ries