NetApp-Fehler mit: STATUS_NOLOGON_WORKSTATION_TRUST_ACCOUNT

Seit einem landesweiten Upgrade auf Windows 7 auf dem Desktop habe ich ein Problem mit der Virenprüfung. Insbesondere - wenn Sie eine Umbenennungsoperation für eine (vom Filer gehostete) CIFS-Freigabe ausführen. Die Virenprüfung scheint eine Reihe von Nachrichten auf dem Filer auszulösen:

[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.

Dies scheint sich speziell auf einen auszulösen. renameWir glauben also, dass der Virenprüfer eine 'neue' Datei sieht und versucht, einen On-Access-Scan durchzuführen. Die Virenprüfung, die zuvor als LocalSystem ausgeführt wurde und daher nullals Authentifizierungsanforderung gesendet wurde, ähnelt jetzt eher einem DOS-Angriff und führt dazu, dass der Filer vorübergehend auf die schwarze Liste gesetzt wird. Diese 5s-Sperre für jeden "Zugriffsversuch" ist die meiste Zeit ein kleines Ärgernis und für einige Vorgänge sehr wichtig - z. B. große Dateiübertragungen, bei denen jede Datei 5s dauert

Nach einigen Grabungen scheint dies mit der NLTM-Authentifizierung zu tun zu haben:

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.

Wir haben jetzt einige Problemumgehungen, die nicht besonders hilfreich sind. Eine besteht darin, diese Sicherheitsoption zu ändern. Eine besteht darin, die Virenprüfung zu deaktivieren oder einen Teil der Infrastruktur anderweitig auszunehmen.

Und hier komme ich zu meiner Bitte um Unterstützung von ServerFault - was ist der beste Weg vorwärts? Mir fehlt die Windows-Erfahrung, um sicherzugehen, was ich sehe.

Ich bin mir nicht ganz sicher, warum NTLM überhaupt Teil dieses Bildes ist - ich dachte, wir verwenden die Kerberos-Authentifizierung. Ich bin nicht sicher, wie ich mit der Diagnose oder Fehlerbehebung beginnen soll. (Wir werden domänenübergreifend arbeiten - Workstation-Computerkonten befinden sich in einer separaten AD- und DNS-Domäne zu meinem Filer. Die normale Benutzerauthentifizierung funktioniert jedoch einwandfrei.)

Und wenn dies nicht der Fall ist, kann jemand andere Untersuchungslinien vorschlagen? Ich möchte eine Änderung der Sicherheitsoptionen auf der gesamten Website vermeiden, oder wenn ich diesen Weg gehe, muss ich in der Lage sein, detaillierte Argumente zu liefern. Ebenso funktioniert das Deaktivieren der Virenprüfung als kurzfristige Problemumgehung, und das Anwenden von Ausschlüssen kann hilfreich sein ... aber ich möchte lieber nicht und glaube nicht, dass dies das zugrunde liegende Problem löst.

BEARBEITEN: Filer in AD ldap haben SPNs für:

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

(Sorry, muss diese verschleiern).

Könnte es sein, dass es ohne eine 'cifs / host.fully.qualified.domain' nicht funktioniert? (oder ein anderer SPN?)

Bearbeiten: Im Rahmen meiner Suche habe ich Folgendes gefunden: http://itwanderer.wordpress.com/2011/04/14/tread-lightly-kerberos-encryption-types/

Dies deutet darauf hin, dass in Win7 / 2008R2 standardmäßig mehrere Verschlüsselungstypen deaktiviert waren. Dies könnte relevant sein, da wir definitiv ein ähnliches Problem mit Keberized NFSv4 hatten. Es gibt eine versteckte Option , die möglicherweise einige zukünftige Keberos Benutzer helfen: Optionen nfs.rpcsec.trace auf (Dies hat noch aber nicht gegeben mir nichts, kann so nur NFS spezifisch sein).

Bearbeiten: Beim weiteren Graben kann ich es zur domänenübergreifenden Authentifizierung zurückverfolgen. Es sieht so aus, als würde meine Windows 7-Workstation (in einer Domäne) keine Kerberos-Tickets für die andere Domäne erhalten, in der mein NetApp-Filer CIFS-Mitglied ist. Ich habe dies separat für einen eigenständigen Server (Win2003 und Win2008) durchgeführt und auch für diese keine Kerberos-Tickets erhalten.

Das heißt, ich denke, Kerberos ist möglicherweise defekt, aber ich habe keine Ahnung, wie ich weitere Fehler beheben kann.

Bearbeiten: Ein weiteres Update: Es sieht so aus, als ob Kerberos-Tickets nicht domänenübergreifend ausgestellt wurden. Dies löst dann einen NTLM-Fallback aus, der dann auf dieses Problem stößt (seit Windows 7). Die erste Anlaufstelle wird darin bestehen, die Kerberos-Seite der Dinge zu untersuchen, aber in keinem Fall gibt es Hinweise darauf, dass der Filer die Hauptursache ist. Als solcher - als Speicheringenieur - liegt es nicht in meiner Hand.

Wenn mich jedoch jemand auf die Fehlerbehebung bei Kerberos hinweisen kann, die sich über zwei Windows AD-Domänen (Kerberos Realms) erstreckt, wäre dies wünschenswert.

Optionen, die wir für die Lösung in Betracht ziehen werden:

• Ändern Sie die Richtlinienoption auf allen Arbeitsstationen über das Gruppenrichtlinienobjekt (wie oben).
• Sprechen Sie mit dem AV-Anbieter über die Umbenennung, die das Scannen auslöst.
• Sprechen Sie mit dem AV-Anbieter über die Ausführung von AV als Dienstkonto.
• Untersuchung der Kerberos-Authentifizierung (warum es nicht funktioniert, ob es sein sollte).

Ich würde Ihre Antivirenrichtlinien so ändern, dass keine über das Netzwerk freigegebenen Dateien gescannt werden. Möglicherweise versuchen ein Dutzend Clients, dieselbe Datei gleichzeitig über das Netzwerk zu scannen.

In Windows 2000, 2003, Windows XP, Vista und 2008 lautet das Standardverhalten wie folgt:

• Netzwerksicherheit: Ermöglichen Sie dem lokalen System, die Computeridentität für NTLM zu verwenden
  • Deaktiviert: Dienste, die als lokales System ausgeführt werden und beim Zurücksetzen auf die NTLM-Authentifizierung Negotiate verwenden, werden anonym authentifiziert.

In Windows 7 und 2008 R2 und höher wurde das Standardverhalten jedoch folgendermaßen geändert:

• Netzwerksicherheit: Ermöglichen Sie dem lokalen System, die Computeridentität für NTLM zu verwenden
  • Aktiviert: Dienste, die als lokales System ausgeführt werden und Negotiate verwenden, verwenden die Computeridentität.

Quelle: http://technet.microsoft.com/en-us/library/jj852275.aspx

Sie möchten eine Änderung der Sicherheitsoptionen für die gesamte Website vermeiden, haben diese jedoch bereits vorgenommen, als Sie alle Clients auf Windows 7 aktualisiert haben.

Warum Sie Kerberos überhaupt nicht verwenden, ist eine ganz andere Frage, die Sie uns nicht genügend Daten gegeben haben, um sie beantworten zu können. Damit Kerberos funktioniert, benötigt der CIFS-Dienst eine Vertrauensbeziehung zu den Domänen- und registrierten Dienstprinzipalnamen, und der Client muss den Dienst mit dem Hostnamen oder dem vollqualifizierten Domänennamen und nicht mit der IP-Adresse adressieren.

Ist Ihre Filers-Domain beigetreten? Wenn ja, haben sie CIFS / * SPNs?

Ich bin in diesem Fall am Ende des Laufs angelangt und weiß jetzt, warum es passiert.

Zusammenfassend:

• Seit Windows 7/2008 hat sich das Standardverhalten für 'LocalSystem' auf einem Clientcomputer geändert. Wo zuvor ein Null-Login verwendet wurde, werden Computerkonten für NTLM verwendet.

• Da wir zwischen zwei AD-Gesamtstrukturen wechseln, wird Kerberos nicht verwendet. Dies ist beabsichtigt. http://technet.microsoft.com/en-us/library/cc960648.aspx "Die Kerberos-Authentifizierung verwendet transparentes transitives Vertrauen zwischen Domänen in einer Gesamtstruktur, kann sich jedoch nicht zwischen Domänen in separaten Gesamtstrukturen authentifizieren."

  • Sophos scannt Dateien beim Zugriff, die durch eine Umbenennung ausgelöst werden. Aus sicherheitspolitischen Gründen umfasst dies Netzwerklaufwerke.

  • Da Sophos als LocalSystem ausgeführt wird, wird das Computerkonto über NTLM dem Filer angezeigt. Dieses Konto wird dann mit STATUS_NOLOGON_WORKSTATION_TRUST_ACCOUNT abgelehnt und nach 10 erneuten Versuchen löst der Filer eine Sperre aus.

  • Aufgrund dieser Sperrung werden nachfolgende Virenscanversuche für 5 Sekunden pro Versuch angehalten. Dies ist die Wurzel unseres Problems, da unser Prozess Hunderte von Dateien kopiert und umbenennt und nach dem 10. jede 5 Sekunden dauert.

Dies lässt uns Lösungen von:

• Ändern Sie die Sicherheitsrichtlinienoption wie oben erwähnt: Netzwerksicherheit: Ermöglichen Sie dem lokalen System, die Computeridentität für NTLM zu verwenden: Deaktiviert

  • Wenden Sie im Virenprüfer einen Ausschluss für Netzwerklaufwerke an

  • Führen Sie Ihre separate Domain in derselben Gesamtstruktur zusammen, damit Kerberos funktioniert. (Eine weitere Option wird hier beschrieben: http://xitnotes.wordpress.com/2012/03/29/kerberos-in-an-active-directory-forest-trust- vs-external-trust / beinhaltet das Aktualisieren der Beziehung zwischen den Domänen, sodass Kerberos wieder funktioniert.

  • Verwenden Sie vfilers, und CIFs verbinden sie mit der anderen Domäne.

  • Es gibt auch eine Option im Filer, um die Anzahl der Wiederholungsversuche zu erhöhen, bevor diese Sperre auftritt - dies ist eine versteckte Option, und ich habe keine genaue Syntax zur Hand.