ID Event ID 36886 Warnung Schannel

[mcdaniels 22]

Hello again,

seit dem Vorfall hier 

Auf dem System ist keine Standard-Serverreferenz vorhanden. Serveranwendungen, die Standard-Systemreferenzen verwenden, werden keine SSL-Verbindungen akzeptieren. Als Beispiel einer solchen Anwendung dient der Verzeichnisserver. Dies hat keine Auswirkung auf Anwendungen wie der Internet Information Server, die die eigenen Referenzen verwalten, .

 

Wir haben keine eigne CA.

 

Ist diese Warnung dann problematisch? Eine Recherche im Internet ergab zumindest (zum Teil), dass man den Fehler ignorien kann wenn man keine eigene CA einsetzt.

 

Was mich wiederum stutzig mach ist, dass die Warnung bislang nicht aufgetreten ist.

 

Danke!

bearbeitet 15. Februar von mcdaniels

[Nobbyaushb 1.359]

Habt ihr von NTLM auf Kerberos umgebaut?

Habe sowas mal gesehen glaube ich...

[mcdaniels 22]

Hi, nein alles beim Alten. Wir haben nix umgebaut.

[mcdaniels 22]

Hallo nochmals,

 

was ich jetzt noch gesehen habe:

 

SRV-DC4 meldet im Systemlog um 10:30h

QUELLE LSA(Lsasrv)

ID 6038

Von MS Windows Server wurde festgestellt, dass momentan zwischen Clients und diesem Server NTLM Authentifizierung verwendet wird.

Dieses Ereignis tritt einmal pro Serverstart auf, wen NTLM von einem Client erstmalig für den Server verwendet wird.

 

40 Sekunden später starten dann auf dem SRV-DC3 die Meldungen mit:

Quelle Schannel

ID: 36886

Warnung

Auf dem System ist keine Standard-Serverreferenz vorhanden. Serveranwendungen, die Standard-Systemreferenzen verwenden, werden keine SSL-Verbindungen akzeptieren. Als Beispiel einer solchen Anwendung dient der Verzeichnisserver. Dies hat keine Auswirkung auf Anwendungen wie der Internet Information Server, die die eigenen Referenzen verwalten, .

 

Verstehe ich das richtig, dass irgend ein Client NTLM Auth nutzt und das dieses Verhalten auslöst?

 

Seit 14:12h übrigens bislang keine Einträge mir ID 36886 auf dem SRV-DC3. Vermutlich weil der Client nicht mehr via NTLM authentifiziert (abgeschaltet ist / heruntergefahren). Sofern diese Meldungen zusammen hängen.

 

Interessant auch das hier: https://learn.microsoft.com/en-us/answers/questions/327711/windows-2019-server-id-36886

 

Hier ist wieder die Rede davon, dass man die 36886 ignorieren kann, wenn man keine eigene CA betreibt (also so wie bei uns). Komisch nur, dass das Ganze noch nie aufgetreten ist und jetzt plötzlich geloggt wird.

bearbeitet 15. Februar von mcdaniels

[daabm 1.185]

Bitte nicht zu viel durcheinander werfen NTLM bekommst Du in den Griff, wenn Du auf den DCs das NLTM Auditing einschaltest. Dann kannst Du im Eventlog NTLM/Operational nachschauen, von wo das kommt. Und damit kannst Du dann analysieren, warum Kerberos nicht funktioniert. Dazu wiederum ist es hilfreich, auf den DCs das Advanced Auditing für Kerberos-Events zu aktivieren und die dann auf Audit Failure Events zu prüfen.

 

Das Event mit der Server-Referenz habe ich noch nie gesehen... Da bin ich also erst mal raus und stille.

[mcdaniels 22]

vor 4 Minuten schrieb daabm:

Bitte nicht zu viel durcheinander werfen NTLM bekommst Du in den Griff, wenn Du auf den DCs das NLTM Auditing einschaltest.

ich werfe nicht, ich schleudere

 

Das mit dem NTLM Auditing hab ich noch "irgendwo" im Hinterkopf. Könnte ein Linuxserver sein. Muss ich checken.

 

Du meinst also, das hängt ev. nicht zusammen.

bearbeitet 15. Februar von mcdaniels

[daabm 1.185]

Das hängt ganz sicher (hust...) nicht zusammen.

[mcdaniels 22]

Ich möchte die Lösung des Problems mal anhand eines Videos posten: