Fehler bei Win SBS 2003 - Sicherheitslogs

[fanman66 10]

Hallo,

 

ich habe einen Windows SBS 2003 Server bei einem Kunden und in den Sicherheitsmeldungen kommt sehr oft dieses vor:

 

EVENT # : 1056414

EVENT LOG : Security

EVENT TYPE : Audit Failure

SOURCE : Security

CATEGORY : An-/Abmeldung

EVENT ID : 537

USERNAME : NT-AUTORITÄT\SYSTEM

COMPUTER : XXXXXX-Server

TIME : 14.09.2005 15:01:54

MESSAGE : Fehlgeschlagene Anmeldung:

Grund: Während der Anmeldung ist ein Fehler aufgetreten.

Benutzername:

Domäne:

Anmeldetyp: 3

Anmeldevorgang: Kerberos

Authentifizierungspaket: Kerberos

Name der Arbeitsstation: -

Statuscode: 0xC000006D

Substatuscode: 0xC0000133

Aufruferbenutzername: -

Aufruferdomäne: -

Aufruferanmeldekennung: -

Aufruferprozesskennung: -

Übertragene Dienste: -

Quellnetzwerkadresse: 192.168.1.32

Quellport: 0

 

Nun weiß ich nichts damit anzufangen, vorallem, weil auch manchmal IP-Adressen vorkommen, die ich gar nicht vergeben habe.

Das Netzwerk steht hinter einem DSL-Router mit Firewall.

 

Hat da jemand eine Idee. Es kann doch nicht sein, dass sich die Mitarbeiter innerhalb kürzester Zeit 43 mal falsch anmelden (hab ich aus dem Serverleistungsbericht).

 

Bin über jede Hilfe dankbar. Rechte habe ich schon öfters überprüft und da scheint alles in Ordnung zu sein.

 

Fanman

[fanman66 10]

Hi,

 

kann mir niemand darüber etwas sagen?

 

habe bei Google diese Seite gefunden mit dem folgenden Text - auf Englisch. Leider ist mein Englisch etwas schlecht hierbei.

 

Kann jemand übersetzen?

 

http://www.eventid.net/

 

From a newsgroup post: "The 537 event is common when Kerberos fails. The operation will not necessarily fail, as the Kerberos failure might be followed immediately by a successful NTLM logon (look up "SNEGO" on MSDN to see how we try Kerberos first, then NTLM, for many authentication operations).

 

There are two likely reasons why this occurred:

1) No explicit Kerberos trust between the domain containing the machine doing the accessing and the domain containing the machine being accessed; in other words only an external trust or no trust between the domains.

 

2) The SPN for the target machine was unavailable to the requesting machine, at the time of the request. This could be due to a lack of routing hints on the trust, or due to the absence of the SPN in the directory. The SETSPN utility in the Windows 2000 Resource Kit can be used to see if the SPN is in place, and to re-register it if not (SETSPN.EXE -L COMPUTERNAME)".

 

From a newsgroup post: "If you are using protocol transition, this means you have to satisfy the following requirements:

1) The Domain must be in Windows 2003 native mode.

2) Act as part of operating system (TCB) privilege has to be granted to the process that calls “WindowsIdentity” on the front-end machine (where the code runs) and not on the domain controller. Please the Kerberos protocol transition whitepaper for more details on these requirements".

 

- Error code: 0xC000006D - From a newsgroup post: "Generally speaking, status code 0xC000006D means "STATUS_LOGON_FAILURE, the attempted logon is invalid. This is either due to bad username or authentication information. Status code 0xC0000133 means STATUS_TIME_DIFFERENCE_AT_DC. The problem could be caused because there is a time difference (greater than 5 minutes) between the two computers. Can you logon the domain from this workstation or can you access the network sharing from this workstation? Please go to the workstations and check the time settings. If you can successfully logon to the domain from the workstations and access the network resources, you can ignore this event message.

I would like to suggest you go to the SBS 2003 server and check the time service status. Open “Services” console in “Administrative Tools”. Double-click “Windows Time” service. If the time service is disabled, please follow the steps below to start the services:

1. Open Services console in “Administrative Tools”.

2. Double-click Windows Time service. Change the startup type from Disabled to Automatic.

3. Open Registry editor (regedit); navigate to the following registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\. Double-click “Type” value in the right panel. Change the value data from NoSync to NT5DS.

4. Go to the service console, double-click the Windows Time service, and click “Start” button to start the service.

5. Check the settings on the firewall (router or ISA firewall). Make sure that outgoing UDP 123 port request is allowed. The SBS server will use this port to synchronize the time with an external time source (on the Internet).

6. This problem can also occur if the Time service is not started on the client computers or the clients are pointing to the wrong timeserver for sync. By default, it should be the SBS 2K3 server.

For a Windows XP computer, you should run the following at a command prompt:

“w32tm /monitor /computers:localhost”.

[fanman66 10]

hier der Rest

 

 

Command output:

localhost [127.0.0.1]:

ICMP: 0ms delay.

NTP: +0.0000000s offset from local clock

RefID: ntdev-dc-10.ntdev.microsoft.com [x.x.x.x]

 

The computer returned on the RefID line is the timeserver with whom the client is synchronizing its time.

For a Windows 2000 computer you should run the following at a command prompt:

w32tm -v –once.

 

In the output, search for the following lines:

BEGIN: GetSocketForSynch

NTP: ntpptrs [0] - <IP address>

PORT pinging to -123

Connecting to "\\<fqdn>" (IP address).

 

The "Connecting to" line gives you fully qualified domain name and IP address of the SBS server that is providing time synchronization. It also provides the port (123) that the Windows Time Service is utilizing. You can find more information by reading M314054".

 

This problem might also be caused by a “loopback check” security feature that is designed to help prevent reflection attacks on your computer. This feature was introduced in Windows XP SP2 and Windows Server 2003 SP1. Read M896861 for information on resolving this problem.

 

See MSW2KDB for additional information on this event.

 

Paul (Last update 3/14/2005):

I had this problem on one of the Win2k Domain Controllers in a remote office. It turns out that although the time on the DC was correct, the date was wrong. This caused Kerberos authentication to fail. Correcting the date solved the problem.

 

Robert Sieber (Last update 3/10/2004):

In my case the Netlogon Service and LSA were disabled by a hardware profile. Getting a default HW profile solved the issue.

 

Eran Guri (Last update 12/27/2003):

I had this problem because the time on the other DCs was not sync with the PDC.

 

Fanman