4768(S, F): Es wurde ein Kerberos-Authentifizierungsticket (TGT) angefordert.
Unterkategorie: Kerberos-Authentifizierungsdienst überwachen
Ereignisbeschreibung:
Dieses Ereignis wird jedes Mal generiert, wenn das Key Distribution Center ein Kerberos Ticket Granting Ticket (TGT) ausgibt.
Dieses Ereignis wird nur auf Domänencontrollern generiert.
Wenn das TGT-Problem fehlschlägt, wird das Fehlerereignis mit dem Ergebniscodefeld angezeigt, das nicht gleich "0x0" ist.
Dieses Ereignis wird nicht für Ergebniscodes generiert: 0x10 und 0x18. Ereignis "4771: Kerberos-Vorauthentifizierung fehlgeschlagen". wird stattdessen generiert.
Hinweis
Empfehlungen finden Sie unter Empfehlungen zur Sicherheitsüberwachung für dieses Ereignis.
Ereignis-XML:
- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
<Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" />
<EventID>4768</EventID>
<Version>0</Version>
<Level>0</Level>
<Task>14339</Task>
<Opcode>0</Opcode>
<Keywords>0x8020000000000000</Keywords>
<TimeCreated SystemTime="2015-08-07T18:13:46.074535600Z" />
<EventRecordID>166747</EventRecordID>
<Correlation />
<Execution ProcessID="520" ThreadID="1496" />
<Channel>Security</Channel>
<Computer>DC01.contoso.local</Computer>
<Security />
</System>
- <EventData>
<Data Name="TargetUserName">dadmin</Data>
<Data Name="TargetDomainName">CONTOSO.LOCAL</Data>
<Data Name="TargetSid">S-1-5-21-3457937927-2839227994-823803824-1104</Data>
<Data Name="ServiceName">krbtgt</Data>
<Data Name="ServiceSid">S-1-5-21-3457937927-2839227994-823803824-502</Data>
<Data Name="TicketOptions">0x40810010</Data>
<Data Name="Status">0x0</Data>
<Data Name="TicketEncryptionType">0x12</Data>
<Data Name="PreAuthType">15</Data>
<Data Name="IpAddress">::ffff:10.0.0.12</Data>
<Data Name="IpPort">49273</Data>
<Data Name="CertIssuerName">contoso-DC01-CA-1</Data>
<Data Name="CertSerialNumber">1D0000000D292FBE3C6CDDAFA200020000000D</Data>
<Data Name="CertThumbprint">564DFAEE99C71D62ABC553E695BD8DBC46669413</Data>
</EventData>
</Event>
Erforderliche Serverrollen: Active Directory-Domänencontroller.
Mindestversion des Betriebssystems: Windows Server 2008.
Ereignisversionen: 0.
Beschreibung der Felder:
Kontoinformationen:
Kontoname [Typ = UnicodeString]: Der Name des Kontos, für das ein (TGT)-Ticket angefordert wurde. Der Name des Computerkontos endet mit $ einem Zeichen.
Benutzerkontobeispiel: dadmin
Computerkontobeispiel: WIN81$
Angegebener Bereichsname [Typ = UnicodeString]: der Name des Kerberos-Bereichs, zu dem der Kontoname gehört. Dies kann in einer Vielzahl von Formaten angezeigt werden, einschließlich der folgenden:
NetBIOS-Domänenname, z. B. CONTOSO
Vollständiger Domänenname in Kleinbuchstaben: contoso.local
Vollständiger Domänenname in Großbuchstaben: CONTOSO.LOCAL
Hinweis
Ein Kerberos-Bereich ist eine Gruppe von verwalteten Knoten, die dieselbe Kerberos-Datenbank gemeinsam nutzen. Die Kerberos-Datenbank befindet sich auf dem Kerberos-Mastercomputersystem, das in einem physisch sicheren Raum aufbewahrt werden sollte. Die Active Directory-Domäne ist das Beispiel für den Kerberos-Bereich in der Microsoft Windows Active Directory-Welt.
Benutzer-ID [Typ = SID]: SID des Kontos, für das ein (TGT)-Ticket angefordert wurde. Die Ereignisanzeige versucht automatisch, SIDs aufzulösen und den Kontonamen anzuzeigen. Wenn die SID nicht aufgelöst werden kann, werden die Quelldaten des Ereignisses angezeigt.
Beispiel: CONTOSO\dadmin oder CONTOSO\WIN81$.
- NULL-SID – Dieser Wert wird in 4768-Fehlerereignissen angezeigt.
Hinweis
Eine Sicherheits-ID (SID) ist ein eindeutiger Wert variabler Länge, der zum Identifizieren eines Treuhänders (Sicherheitsprinzipal) verwendet wird. Jedes Konto verfügt über eine eindeutige SID, die von einer Zertifizierungsstelle (z. B. einem Active Directory-Domänencontroller) ausgestellt und in einer Sicherheitsdatenbank gespeichert wird. Jedes Mal, wenn ein Benutzer sich anmeldet, ruft das System die SID für diesen Benutzer aus der Datenbank ab und fügt Sie in sein Zugriffstoken ein. Das System verwendet die SID im Zugriffstoken, um den Benutzer in allen weiteren Interaktionen mithilfe der Windows-Sicherheit zu identifizieren. Sobald eine SID als eindeutiger Bezeichner für einen Benutzer oder eine Gruppe verwendet wurde, kann Sie nicht wieder verwendet werden, um einen anderen Benutzer oder eine andere Gruppe zu identifizieren. Weitere Informationen zu SIDs finden Sie unter Sicherheitskennungen.
Dienstinformationen:
Dienstname [Type = UnicodeString]: Der Name des Diensts im Kerberos-Bereich, an den die TGT-Anforderung gesendet wurde. In der Regel hat der Wert "krbtgt" für TGT-Anforderungen, was bedeutet, dass Ticket Granting Ticket ausstellenden Dienst.
- Für Fehlerereignisse hat der Dienstname in der Regel das folgende Format: krbtgt/REALM_NAME. Beispiel: krbtgt/CONTOSO.
Dienst-ID [Typ = SID]: SID des Dienstkontos im Kerberos-Bereich, an den die TGT-Anforderung gesendet wurde. Die Ereignisanzeige versucht automatisch, SIDs aufzulösen und den Kontonamen anzuzeigen. Wenn die SID nicht aufgelöst werden kann, werden die Quelldaten des Ereignisses angezeigt.
Domänencontroller verfügen über ein bestimmtes Dienstkonto (krbtgt), das vom Key Distribution Center (KDC)-Dienst zum Ausstellen von Kerberos-Tickets verwendet wird. Es verfügt über eine integrierte, vordefinierte SID: S-1-5-21-DOMAIN[](/previous-versions/windows/it-pro/windows-2000-server/cc962011(v=technet.10))_IDENTIFIER-502.
- NULL-SID – Dieser Wert wird in 4768-Fehlerereignissen angezeigt.
Netzwerkinformationen:
Clientadresse [Type = UnicodeString]: IP-Adresse des Computers, von dem die TGT-Anforderung empfangen wurde. Die Formate sind unterschiedlich und umfassen:
IPv6- oder IPv4-Adresse .
::ffff:IPv4_address.
::1 - localhost.
Clientport [Type = UnicodeString]: Quellportnummer der Clientnetzwerkverbindung (TGT-Anforderungsverbindung).
- 0 für lokale (localhost)-Anforderungen.
Weitere Informationen:
Ticketoptionen [Typ = HexInt32]: Dies ist eine Reihe unterschiedlicher Ticketkennzeichnungen im Hexadezimalformat.
Beispiel:
Ticketoptionen: 0x40810010
Binäransicht: 01000000100000010000000000010000
Mit msb 0 bit nummerierung haben wir bit 1, 8, 15 und 27 set = Forwardable, Renewable, Canonicalize, Renewable-ok.
Hinweis
In der folgenden Tabelle wird die Bitnummerierung "MSB 0" verwendet, da RFC-Dokumente diese Formatvorlage verwenden. In der Formatvorlage "MSB 0" beginnt die Bitnummerierung von links.
Die häufigsten Werte:
0x40810010 - Forwardable, Renewable, Canonicalize, Renewable-ok
0x40810000 - Forwardable, Renewable, Canonicalize
0x60810010 - Forwardable, Forwarded, Renewable, Canonicalize, Renewable-ok
| Bit | Kennzeichenname | Beschreibung |
|---|---|---|
| 0 | Reserviert | - |
| 1 | Forwardable | (nur TGT). Teilt dem Ticketerteilungsdienst mit, dass er einen neuen TGT (basierend auf dem präsentierten TGT) mit einer anderen Netzwerkadresse basierend auf dem vorgestellten TGT ausstellen kann. |
| 2 | Weitergeleitet | Gibt an, dass ein TGT weitergeleitet wurde oder dass ein Ticket von einem weitergeleiteten TGT ausgestellt wurde. |
| 3 | Proxiable | (nur TGT). Teilt dem Ticketerteilungsdienst mit, dass er Tickets mit einer Netzwerkadresse ausstellen kann, die sich von der im TGT unterscheidet. |
| 4 | Proxy | Gibt an, dass sich die Netzwerkadresse im Ticket von der im TGT zum Abrufen des Tickets verwendeten unterscheidet. |
| 5 | Allow-postdate | Postdated tickets SHOULD NOT be supported in KILE (Microsoft Kerberos Protocol Extension). |
| 6 | Postdated | Postdated tickets SHOULD NOT be supported in KILE (Microsoft Kerberos Protocol Extension). |
| 7 | Ungültig | Dieses Kennzeichen gibt an, dass ein Ticket ungültig ist, und muss vor der Verwendung vom KDC überprüft werden. Anwendungsserver müssen Tickets ablehnen, für die dieses Kennzeichen festgelegt ist. |
| 8 | Erneuerbare | Wird in Kombination mit den Feldern "Endzeit" und "Kasse verlängern" verwendet, um zu bewirken, dass Tickets mit langer Lebensdauer regelmäßig am KDC erneuert werden. |
| 9 | Ersten | Gibt an, dass ein Ticket mithilfe des Authentifizierungsdiensts (AS) ausgestellt und nicht basierend auf einem TGT ausgestellt wurde. |
| 10 | Vorauthentisierung | Gibt an, dass der Client vom KDC authentifiziert wurde, bevor ein Ticket ausgestellt wurde. Diese Kennzeichnung gibt in der Regel das Vorhandensein eines Authentifikators im Ticket an. Es kann auch das Vorhandensein von Anmeldeinformationen kennzeichnen, die aus einer Smartcardanmeldung stammen. |
| 11 | Opt-hardware-auth | Dieses Kennzeichen sollte ursprünglich angeben, dass die hardwaregestützte Authentifizierung während der Vorauthentifizierung verwendet wurde. Dieses Kennzeichen wird im Kerberos V5-Protokoll nicht mehr empfohlen. KDCs DÜRFEN KEIN Ticket ausgeben, für das diese Kennzeichnung festgelegt ist. KDCs SOLLTEN dieses Kennzeichen NICHT beibehalten, wenn es von einem anderen KDC festgelegt wird. |
| 12 | Transited-policy-checked | KILE DARF NICHT nach transitierten Domänen auf Servern oder einem KDC suchen. Anwendungsserver MÜSSEN das TRANSITED-POLICY-CHECKED-Flag ignorieren. |
| 13 | Ok-as-delegate | Der KDC MUSS das OK-AS-DELEGATE-Flag festlegen, wenn das Dienstkonto für die Delegierung vertrauenswürdig ist. |
| 14 | Anforderungs-anonym | KILE verwendet dieses Kennzeichen nicht. |
| 15 | Name-kanonicalize | Um Verweise anzufordern, muss der Kerberos-Client explizit die KDC-Option "kanonisieren" für den AS-REQ oder TGS-REQ anfordern. |
| 16-25 | Unbenutzte | - |
| 26 | Disable-transited-check | Standardmäßig überprüft der KDC das transitierte Feld eines TGT anhand der Richtlinie des lokalen Bereichs, bevor es abgeleitete Tickets basierend auf dem TGT ausgibt. Wenn dieses Kennzeichen in der Anforderung festgelegt ist, ist die Überprüfung des transitierten Felds deaktiviert. Tickets, die ohne die Durchführung dieser Überprüfung ausgestellt wurden, werden durch den Zurücksetzungswert (0) des TRANSITED-POLICY-CHECKED-Flags notiert, der dem Anwendungsserver angibt, dass das transitierte Feld lokal überprüft werden muss. KDCs werden ermutigt, aber nicht zur Ehre verpflichtet die Option DISABLE-TRANSITED-CHECK. Sollte nicht verwendet werden, da das flag "Transited-policy-checked" von KILE nicht unterstützt wird. |
| 27 | Verneuerbar-ok | Die Option RENEWABLE-OK weist darauf hin, dass ein verneuerbares Ticket akzeptabel ist, wenn ein Ticket mit der angeforderten Lebensdauer nicht anderweitig bereitgestellt werden kann, in diesem Fall kann ein verneuerbares Ticket mit einer Verlängerungskarte ausgestellt werden, die der angeforderten Endzeit entspricht. Der Wert des Felds "Renew-Till" kann weiterhin durch lokale Grenzwerte oder vom einzelnen Prinzipal oder Server ausgewählte Grenzwerte begrenzt sein. |
| 28 | Enc-tkt-in-skey | Keine Informationen. |
| 29 | Unbenutzte | - |
| 30 | Verlängern | Die Option VERLÄNGERN gibt an, dass die vorliegende Anforderung eine Verlängerung ist. Das bereitgestellte Ticket wird im geheimen Schlüssel für den Server verschlüsselt, auf dem es gültig ist. Diese Option wird nur berücksichtigt, wenn für das zu erneuernde Ticket die RENEWABLE-Kennzeichnung festgelegt ist und die Zeit in ihrem Verlängerungs-Kasse-Feld nicht abgelaufen ist. Das zu erneuernde Ticket wird im Padata-Feld als Teil des Authentifizierungsheaders übergeben. |
| 31 | Überprüfen | Diese Option wird nur vom Ticketerteilungsdienst verwendet. Die Option VALIDATE gibt an, dass die Anforderung darin besteht, ein postdiertes Ticket zu überprüfen. Sollte nicht verwendet werden, da postdierte Tickets nicht von KILE unterstützt werden. |
Tabelle 2 Kerberos-Ticketflags
Hinweis
KILE (Microsoft Kerberos-Protokollerweiterung) – Kerberos-Protokollerweiterungen, die in Microsoft-Betriebssystemen verwendet werden. Diese Erweiterungen bieten zusätzliche Funktionen für Autorisierungsinformationen, einschließlich Gruppenmitgliedschaften, interaktive Anmeldeinformationen und Integritätsstufen.
- Ergebniscode [Typ = HexInt32]: Hexadezimaler Ergebniscode des TGT-Problemvorgangs. Die "Tabelle 3. TGT/TGS gibt Fehlercodes aus." enthält die Liste der häufigsten Fehlercodes für dieses Ereignis.
| Code | Codename | Beschreibung | Mögliche Ursachen |
|---|---|---|---|
| 0x0 | KDC_ERR_NONE | Kein Fehler | Es wurden keine Fehler gefunden. |
| 0 x 1 | KDC_ERR_NAME_EXP | Der Eintrag des Clients in der KDC-Datenbank ist abgelaufen. | Keine Informationen. |
| 0 x 2 | KDC_ERR_SERVICE_EXP | Der Servereintrag in der KDC-Datenbank ist abgelaufen. | Keine Informationen. |
| 0x3 | KDC_ERR_BAD_PVNO | Angeforderte Kerberos-Versionsnummer wird nicht unterstützt | Keine Informationen. |
| 0 x 4 | KDC_ERR_C_OLD_MAST_KVNO | Clientschlüssel, der im alten Masterschlüssel verschlüsselt ist | Keine Informationen. |
| 0x5 | KDC_ERR_S_OLD_MAST_KVNO | Serverschlüssel, der im alten Masterschlüssel verschlüsselt ist | Keine Informationen. |
| 0x6 | KDC_ERR_C_PRINCIPAL_UNKNOWN | Client in Kerberos-Datenbank nicht gefunden | Der Benutzername ist nicht vorhanden. |
| 0x7 | KDC_ERR_S_PRINCIPAL_UNKNOWN | Der Server wurde in der Kerberos-Datenbank nicht gefunden | Dieser Fehler kann auftreten, wenn der Domänencontroller den Namen des Servers in Active Directory nicht finden kann. Dieser Fehler ähnelt KDC_ERR_C_PRINCIPAL_UNKNOWN mit dem Unterschied, dass er auftritt, wenn der Servername nicht gefunden werden kann. |
| 0 x 8 | KDC_ERR_PRINCIPAL_NOT_UNIQUE | Mehrere Prinzipaleinträge in der KDC-Datenbank | Dieser Fehler tritt auf, wenn doppelte Prinzipalnamen vorhanden sind. Eindeutige Prinzipalnamen sind entscheidend, um die gegenseitige Authentifizierung sicherzustellen. Daher sind doppelte Prinzipalnamen auch in mehreren Bereichen strengstens verboten. Ohne eindeutige Prinzipalnamen kann der Client nicht sicherstellen, dass der Server, mit dem er kommuniziert, der richtige ist. |
| 0x9 | KDC_ERR_NULL_KEY | Der Client oder Server verfügt über einen NULL-Schlüssel (Masterschlüssel) | Es wurde kein Masterschlüssel für Client oder Server gefunden. Normalerweise bedeutet dies, dass der Administrator das Kennwort für das Konto zurücksetzen sollte. |
| 0xA | KDC_ERR_CANNOT_POSTDATE | Ticket (TGT) ist nicht für postdating berechtigt | Dieser Fehler kann auftreten, wenn ein Client das Postdating eines Kerberos-Tickets anfordert. Postdating ist der Akt der Anforderung, dass die Startzeit eines Tickets in die Zukunft festgelegt wird. Sie kann auch auftreten, wenn ein Zeitunterschied zwischen dem Client und dem KDC besteht. |
| 0xB | KDC_ERR_NEVER_VALID | Die angeforderte Startzeit ist später als die Endzeit. | Es gibt einen Zeitunterschied zwischen dem KDC und dem Client. |
| 0xC | KDC_ERR_POLICY | Die angeforderte Startzeit ist später als die Endzeit. | Dieser Fehler ist in der Regel das Ergebnis von Anmeldeeinschränkungen für das Konto eines Benutzers. Beispielsweise Einschränkung der Arbeitsstation, Smartcard-Authentifizierungsanforderung oder Anmeldezeiteinschränkung. |
| 0xD | KDC_ERR_BADOPTION | KDC kann die angeforderte Option nicht aufnehmen | Bevorstehender Ablauf eines TGT. Der SPN, an den der Client Anmeldeinformationen delegieren möchte, ist nicht in der Liste "Zulässig zu delegieren" enthalten. |
| 0xE | KDC_ERR_ETYPE_NOTSUPP | KDC unterstützt keinen Verschlüsselungstyp | Im Allgemeinen tritt dieser Fehler auf, wenn der KDC oder ein Client ein Paket empfängt, das nicht entschlüsselt werden kann. |
| 0xF | KDC_ERR_SUMTYPE_NOSUPP | KDC unterstützt keinen Prüfsummentyp | Der KDC, Server oder Client empfängt ein Paket, für das er keinen Schlüssel des entsprechenden Verschlüsselungstyps besitzt. Das Ergebnis ist, dass der Computer das Ticket nicht entschlüsseln kann. |
| 0x10 | KDC_ERR_PADATA_TYPE_NOSUPP | KDC unterstützt keinen PADATA-Typ (Vorauthentifizierungsdaten) | Die Smartcardanmeldung wird versucht, und das richtige Zertifikat kann nicht gefunden werden. Dies kann passieren, weil die falsche Zertifizierungsstelle abgefragt wird oder die richtige Zertifizierungsstelle nicht kontaktiert werden kann. Dies kann auch vorkommen, wenn auf einem Domänencontroller kein Zertifikat für Smartcards (Vorlagen für domänencontroller- oder Domänencontrollerauthentifizierung) installiert ist. Dieser Fehlercode kann im Ereignis "4768. Ein Kerberos-Authentifizierungsticket (TGT) wurde angefordert". Es tritt in "4771. Kerberos-Vorauthentifizierung fehlgeschlagen" -Ereignis. |
| 0x11 | KDC_ERR_TRTYPE_NO_SUPP | KDC unterstützt keinen transitierten Typ | Keine Informationen. |
| 0x12 | KDC_ERR_CLIENT_REVOKED | Die Anmeldeinformationen des Clients wurden widerrufen. | Dies kann auf eine explizite Deaktivierung oder auf andere Einschränkungen für das Konto zurückzuführen sein. Beispiel: Konto deaktiviert, abgelaufen oder gesperrt. |
| 0x13 | KDC_ERR_SERVICE_REVOKED | Die Anmeldeinformationen für den Server wurden widerrufen. | Keine Informationen. |
| 0x14 | KDC_ERR_TGT_REVOKED | TGT wurde widerrufen | Da der Remote-KDC seine PKCROSS-Taste ändern kann, während PKCROSS-Tickets noch aktiv sind, SOLLTE er die alten PKCROSS-Schlüssel zwischenspeichern, bis das letzte ausgestellte PKCROSS-Ticket abläuft. Andernfalls antwortet der Remote-KDC auf einen Client mit einer KRB-ERROR-Meldung vom Typ KDC_ERR_TGT_REVOKED. Weitere Informationen finden Sie unter RFC1510 . |
| 0x15 | KDC_ERR_CLIENT_NOTYET | Client noch nicht gültig – versuchen Sie es später erneut. | Keine Informationen. |
| 0x16 | KDC_ERR_SERVICE_NOTYET | Server noch nicht gültig – versuchen Sie es später erneut. | Keine Informationen. |
| 0x17 | KDC_ERR_KEY_EXPIRED | Kennwort ist abgelaufen – Kennwort ändern, um es zurückzusetzen | Das Kennwort des Benutzers ist abgelaufen. Dieser Fehlercode kann im Ereignis "4768. Ein Kerberos-Authentifizierungsticket (TGT) wurde angefordert". Es tritt in "4771. Kerberos-Vorauthentifizierung fehlgeschlagen" -Ereignis. |
| 0x18 | KDC_ERR_PREAUTH_FAILED | Die Vorauthentifizierungsinformationen waren ungültig. | Das falsche Kennwort wurde angegeben. Dieser Fehlercode kann im Ereignis "4768. Ein Kerberos-Authentifizierungsticket (TGT) wurde angefordert". Es tritt in "4771. Kerberos-Vorauthentifizierung fehlgeschlagen" -Ereignis. |
| 0x19 | KDC_ERR_PREAUTH_REQUIRED | Zusätzliche Vorauthentifizierung erforderlich | Dieser Fehler tritt häufig in UNIX-Interoperabilitätsszenarien auf. MIT-Kerberos Clients fordern keine Vorauthentifizierung an, wenn sie eine KRB_AS_REQ-Nachricht senden. Wenn eine Vorauthentifizierung erforderlich ist (Standardeinstellung), wird dieser Fehler von Windows-Systemen gesendet. Die meisten MIT-Kerberos Clients reagieren auf diesen Fehler, indem sie die Vorauthentifizierung angeben. In diesem Fall kann der Fehler ignoriert werden, aber einige Clients reagieren möglicherweise nicht auf diese Weise. |
| 0x1A | KDC_ERR_SERVER_NOMATCH | KDC kennt den angeforderten Server nicht | Keine Informationen. |
| 0x1D | KDC_ERR_SVC_UNAVAILABLE | KDC ist nicht verfügbar | Keine Informationen. |
| 0x1F | KRB_AP_ERR_BAD_INTEGRITY | Integritätsprüfung für entschlüsseltes Feld fehlgeschlagen | Der Authentifikator wurde mit etwas anderem als dem Sitzungsschlüssel verschlüsselt. Das Ergebnis ist, dass der Client die resultierende Nachricht nicht entschlüsseln kann. Die Änderung der Nachricht kann das Ergebnis eines Angriffs oder aufgrund von Netzwerkgeräuschen sein. |
| 0x20 | KRB_AP_ERR_TKT_EXPIRED | Das Ticket ist abgelaufen. | Je kleiner der Wert für die Kerberos-Richtlinieneinstellung "Maximale Lebensdauer für Benutzerticket" ist, desto wahrscheinlicher tritt dieser Fehler auf. Da die Ticketverlängerung automatisch erfolgt, sollten Sie nichts tun müssen, wenn Sie diese Meldung erhalten. |
| 0x21 | KRB_AP_ERR_TKT_NYV | Das Ticket ist noch nicht gültig. | Das dem Server vorgelegte Ticket ist noch nicht gültig (in Beziehung zur Serverzeit). Die wahrscheinlichste Ursache ist, dass die Uhren auf dem KDC und dem Client nicht synchronisiert werden. Wenn die bereichsübergreifende Kerberos-Authentifizierung versucht wird, sollten Sie auch die Zeitsynchronisierung zwischen dem KDC im Zielbereich und dem KDC im Clientbereich überprüfen. |
| 0x22 | KRB_AP_ERR_REPEAT | Die Anforderung ist eine Wiedergabe | Dieser Fehler weist darauf hin, dass ein bestimmter Authentifikator zweimal angezeigt wurde – der KDC hat festgestellt, dass dieses Sitzungsticket eins dupliziert, das es bereits erhalten hat. |
| 0x23 | KRB_AP_ERR_NOT_US | Das Ticket ist nicht für uns. | Der Server hat ein Ticket erhalten, das für einen anderen Bereich gedacht war. |
| 0x24 | KRB_AP_ERR_BADMATCH | Ticket und Authentifikator stimmen nicht überein | Der KRB_TGS_REQ wird an den falschen KDC gesendet. Während des Protokollübergangs besteht ein Kontokonflikt. |
| 0x25 | KRB_AP_ERR_SKEW | Die Uhr schief ist zu groß | Dieser Fehler wird protokolliert, wenn ein Clientcomputer einen Zeitstempel sendet, dessen Wert sich vom Zeitstempel des Servers um mehr als die Anzahl von Minuten unterscheidet, die in der Kerberos-Richtlinie unter "Maximale Toleranz für die Computeruhrsynchronisierung" gefunden wurde. |
| 0x26 | KRB_AP_ERR_BADADDR | Die Netzwerkadresse im Netzwerkschichtheader stimmt nicht mit der Adresse innerhalb des Tickets überein. | Sitzungstickets KÖNNEN die Adressen enthalten, von denen aus sie gültig sind. Dieser Fehler kann auftreten, wenn sich die Adresse des Computers, der das Ticket sendet, von der gültigen Adresse im Ticket unterscheidet. Eine mögliche Ursache hierfür könnte eine Ip-Adressänderung (Internet Protocol) sein. Eine weitere mögliche Ursache ist, wenn ein Ticket über einen Proxyserver oder NAT übergeben wird. Der Client kennt das vom Proxyserver verwendete Adressschema nicht. Es sei denn, das Programm hat den Client veranlasst, ein Proxyserverticket mit der Quelladresse des Proxyservers anzufordern, es sei denn, das Ticket ist ungültig. |
| 0x27 | KRB_AP_ERR_BADVERSION | Protokollversionsnummern stimmen nicht überein (PVNO) | Wenn eine Anwendung eine KRB_SAFE-Nachricht empfängt, wird sie überprüft. Wenn ein Fehler auftritt, wird ein Fehlercode für die Verwendung durch die Anwendung gemeldet. Die Nachricht wird zunächst überprüft, indem überprüft wird, ob die Protokollversions- und Typfelder der aktuellen Version bzw. KRB_SAFE entsprechen. Ein Konflikt erzeugt eine KRB_AP_ERR_BADVERSION. Weitere Informationen finden Sie unter RFC4120 . |
| 0x28 | KRB_AP_ERR_MSG_TYPE | Der Nachrichtentyp wird nicht unterstützt. | Diese Nachricht wird generiert, wenn der Zielserver feststellt, dass das Nachrichtenformat falsch ist. Dies gilt für KRB_AP_REQ-, KRB_SAFE-, KRB_PRIV- und KRB_CRED-Nachrichten. Dieser Fehler wird auch generiert, wenn versucht wird, das UDP-Protokoll mit der Benutzer-zu-Benutzer-Authentifizierung zu verwenden. |
| 0x29 | KRB_AP_ERR_MODIFIED | Nachrichtendatenstrom geändert und Prüfsumme nicht übereinstimmen | Die Authentifizierungsdaten wurden mit dem falschen Schlüssel für den vorgesehenen Server verschlüsselt. Die Authentifizierungsdaten wurden während der Übertragung durch einen Hardware- oder Softwarefehler oder durch einen Angreifer geändert. Der Client hat die Authentifizierungsdaten an den falschen Server gesendet, da falsche DNS-Daten dazu geführt haben, dass der Client die Anforderung an den falschen Server sendet. Der Client hat die Authentifizierungsdaten an den falschen Server gesendet, da DNS-Daten auf dem Client veraltet waren. |
| 0x2A | KRB_AP_ERR_BADORDER | Nachricht nicht in ordnung (mögliche Manipulation) | Dieses Ereignis wird für KRB_SAFE- und KRB_PRIV-Meldungen generiert, wenn eine falsche Sequenznummer enthalten ist oder eine Sequenznummer erwartet, aber nicht vorhanden ist. Weitere Informationen finden Sie unter RFC4120 . |
| 0x2C | KRB_AP_ERR_BADKEYVER | Die angegebene Version des Schlüssels ist nicht verfügbar. | Dieser Fehler kann serverseitig beim Empfang einer ungültigen KRB_AP_REQ-Nachricht generiert werden. Wenn es sich bei der vom Ticket im KRB_AP_REQ angegebenen Schlüsselversion nicht um eine handelt, die der Server verwenden kann (z. B. ein alter Schlüssel, und der Server verfügt nicht mehr über eine Kopie des alten Schlüssels), wird der Fehler KRB_AP_ERR_BADKEYVER zurückgegeben. |
| 0x2D | KRB_AP_ERR_NOKEY | Dienstschlüssel nicht verfügbar | Dieser Fehler kann serverseitig beim Empfang einer ungültigen KRB_AP_REQ-Nachricht generiert werden. Da der Server in mehreren Bereichen mit jeweils unterschiedlichen Schlüsseln registriert werden kann, wird das Bereichsfeld im unverschlüsselten Teil des Tickets in der Datei "KRB_AP_REQ" verwendet, um anzugeben, welchen geheimen Schlüssel der Server zum Entschlüsseln dieses Tickets verwenden soll. Der Fehlercode KRB_AP_ERR_NOKEY wird zurückgegeben, wenn der Server nicht über den richtigen Schlüssel zum Entschlüsseln des Tickets verfügt. |
| 0x2E | KRB_AP_ERR_MUT_FAIL | Fehler bei der gegenseitigen Authentifizierung. | Keine Informationen. |
| 0x2F | KRB_AP_ERR_BADDIRECTION | Falsche Nachrichtenrichtung | Keine Informationen. |
| 0x30 | KRB_AP_ERR_METHOD | Alternative Authentifizierungsmethode erforderlich | Gemäß RFC4120 ist diese Fehlermeldung veraltet. |
| 0x31 | KRB_AP_ERR_BADSEQ | Falsche Sequenznummer in Nachricht | Keine Informationen. |
| 0x32 | KRB_AP_ERR_INAPP_CKSUM | Unzulässiger Typ von Prüfsumme in Nachricht (Prüfsumme wird möglicherweise nicht unterstützt) | Wenn KDC KRB_TGS_REQ Nachricht empfängt, wird sie entschlüsselt, und danach MUSS die vom Benutzer bereitgestellte Prüfsumme im Authenticator anhand des Inhalts der Anforderung überprüft werden. Die Meldung MUSS entweder abgelehnt werden, wenn die Prüfsummen nicht übereinstimmen (mit einem Fehlercode von KRB_AP_ERR_MODIFIED) oder wenn die Prüfsumme nicht kollisionssicher ist (mit einem Fehlercode von KRB_AP_ERR_INAPP_CKSUM). |
| 0x33 | KRB_AP_PATH_NOT_ACCEPTED | Der gewünschte Pfad ist nicht erreichbar. | Keine Informationen. |
| 0x34 | KRB_ERR_RESPONSE_TOO_BIG | Zu viele Daten | Die Größe eines Tickets ist zu groß, um zuverlässig über UDP übertragen zu werden. In einer Windows-Umgebung ist diese Meldung rein informal. Ein Computer, auf dem ein Windows-Betriebssystem ausgeführt wird, versucht automatisch TCP, wenn UDP fehlschlägt. |
| 0x3C | KRB_ERR_GENERIC | Allgemeiner Fehler | Die Gruppenmitgliedschaft hat das PAC überladen. Mehrere kürzlich vorgenommene Kennwortänderungen wurden nicht weitergegeben. Crypto-Subsystem-Fehler, der durch das Auslaufen des Arbeitsspeichers verursacht wird. SPN zu lang. SPN hat zu viele Teile. |
| 0x3D | KRB_ERR_FIELD_TOOLONG | Field ist zu lang für diese Implementierung | Jeder Anforderung (KRB_KDC_REQ) und Antwort (KRB_KDC_REP oder KRB_ERROR), die über den TCP-Datenstrom gesendet werden, geht die Länge der Anforderung als 4 Oktette in Netzwerkbytereihenfolge voraus. Das hohe Bit der Länge ist für zukünftige Erweiterungen reserviert und MUSS derzeit auf Null festgelegt werden. Wenn ein KDC, der nicht versteht, wie ein festgelegtes High Bit der Längencodierung interpretiert wird, eine Anforderung mit dem Bit mit hoher Reihenfolge der festgelegten Länge empfängt, MUSS er eine KRB-ERROR-Meldung mit dem Fehler KRB_ERR_FIELD_TOOLONG zurückgeben und MUSS den TCP-Datenstrom schließen. |
| 0x3E | KDC_ERR_CLIENT_NOT_TRUSTED | Fehler bei der Clientvertrauensstellung oder nicht implementiert | Dies geschieht in der Regel, wenn das Smartcardzertifikat des Benutzers widerrufen wird oder die Stammzertifizierungsstelle, die das Smartcardzertifikat (in einer Kette) ausgestellt hat, vom Domänencontroller nicht als vertrauenswürdig eingestuft wird. |
| 0x3F | KDC_ERR_KDC_NOT_TRUSTED | Die KDC-Serververtrauensstellung ist fehlgeschlagen oder konnte nicht überprüft werden. | Das Feld "trustedCertifiers" enthält eine Liste der Zertifizierungsstellen, denen der Client vertraut, falls der Client nicht über das Zertifikat für den öffentlichen Schlüssel des KDC verfügt. Wenn der KDC kein Zertifikat von einem der trustedCertifiers signiert hat, wird ein Fehler vom Typ KDC_ERR_KDC_NOT_TRUSTED zurückgegeben. Weitere Informationen finden Sie unter RFC1510 . |
| 0x40 | KDC_ERR_INVALID_SIG | Die Signatur ist ungültig. | Dieser Fehler bezieht sich auf PKINIT. Wenn eine PKI-Vertrauensstellung vorhanden ist, überprüft der KDC die Signatur des Clients auf AuthPack (TGT-Anforderungssignatur). Wenn dies fehlschlägt, gibt der KDC eine Fehlermeldung vom Typ KDC_ERR_INVALID_SIG zurück. |
| 0x41 | KDC_ERR_KEY_TOO_WEAK | Eine höhere Verschlüsselungsstufe ist erforderlich. | Wenn das Feld "clientPublicValue" ausgefüllt ist, das angibt, dass der Client Diffie-Hellman Schlüsselvereinbarung verwenden möchte, überprüft der KDC, ob die Parameter seiner Richtlinie entsprechen. Wenn sie dies nicht tun (z. B. ist die Primzahlgröße für den erwarteten Verschlüsselungstyp nicht ausreichend), sendet der KDC eine Fehlermeldung vom Typ KDC_ERR_KEY_TOO_WEAK zurück. |
| 0x42 | KRB_AP_ERR_USER_TO_USER_REQUIRED | Eine Benutzer-zu-Benutzer-Autorisierung ist erforderlich. | Falls die Clientanwendung nicht weiß, dass ein Dienst eine Benutzer-zu-Benutzer-Authentifizierung erfordert, und eine herkömmliche KRB_AP_REP anfordert und empfängt, sendet der Client die ANFORDERUNG KRB_AP_REP, und der Server antwortet mit einem KRB_ERROR-Token, wie in RFC1964 beschrieben, mit einem msg-Typ von KRB_AP_ERR_USER_TO_USER_REQUIRED. |
| 0x43 | KRB_AP_ERR_NO_TGT | Es wurde kein TGT präsentiert oder ist verfügbar. | Wenn der Dienst in der Benutzer-zu-Benutzer-Authentifizierung nicht über ein Ticket verfügt, das ein Ticket gewährt, sollte der Fehler KRB_AP_ERR_NO_TGT zurückgegeben werden. |
| 0x44 | KDC_ERR_WRONG_REALM | Falsche Domäne oder falscher Prinzipal | Dieser Fehler tritt zwar selten auf, tritt jedoch auf, wenn ein Client einen bereichsübergreifenden TGT für einen anderen als den im TGT angegebenen Bereich darstellt. In der Regel ergibt sich dies aus falsch konfigurierten DNS.Typically, this results from incorrectly configured DNS. |
Tabelle 3. TGT/TGS-Fehlercodes
- Ticketverschlüsselungstyp [Typ = HexInt32]: die kryptografische Suite, die für ausgegebene TGT verwendet wurde.
Tabelle4. Kerberos-Verschlüsselungstypen
| Typ | Typname | Beschreibung |
|---|---|---|
| 0 x 1 | DES-CBC-CRC | Standardmäßig ab Windows 7 und Windows Server 2008 R2 deaktiviert. |
| 0x3 | DES-CBC-MD5 | Standardmäßig ab Windows 7 und Windows Server 2008 R2 deaktiviert. |
| 0x11 | AES128-CTS-HMAC-SHA1-96 | Unterstützt ab Windows Server 2008 und Windows Vista. |
| 0x12 | AES256-CTS-HMAC-SHA1-96 | Unterstützt ab Windows Server 2008 und Windows Vista. |
| 0x17 | RC4-HMAC | Standardsuite für Betriebssysteme vor Windows Server 2008 und Windows Vista. |
| 0x18 | RC4-HMAC-EXP | Standardsuite für Betriebssysteme vor Windows Server 2008 und Windows Vista. |
| 0xFFFFFFFF oder 0xffffffff | - | Dieser Typ wird in Überwachungsfehlerereignissen angezeigt. |
- Vorauthentifizierungstyp [Typ = UnicodeString]: Die Codenummer des Vorauthentifizierungstyps , der in der TGT-Anforderung verwendet wurde.
Tabelle5. Kerberos-Vorauthentifizierungstypen
| Typ | Typname | Beschreibung |
|---|---|---|
| 0 | - | Anmeldung ohne Vorauthentifizierung. |
| 2 | PA-ENC-TIMESTAMP | Dies ist ein normaler Typ für die Standardkennwortauthentifizierung. |
| 11 | PA-ETYPE-INFO | Der ETYPE-INFO-Vorauthentifizierungstyp wird vom KDC in einem KRB-FEHLER gesendet, der eine Anforderung für zusätzliche Vorauthentifizierung angibt. Es wird in der Regel verwendet, um einen Client darüber zu informieren, welcher Schlüssel für die Verschlüsselung eines verschlüsselten Zeitstempels zum Senden eines PA-ENC-TIMESTAMP-Vorauthentifizierungswerts verwendet werden soll. Dieser Vorauthentifizierungstyp wurde in der Microsoft Active Directory-Umgebung nie gesehen. |
| 15 | PA-PK-AS-REP_OLD | Wird für die Smartcard-Anmeldeauthentifizierung verwendet. |
| 16 | PA-PK-AS-REQ | Anforderung, die in Smartcard-Authentifizierungsszenarien an KDC gesendet wird. |
| 17 | PA-PK-AS-REP | Dieser Typ sollte auch für die Smartcardauthentifizierung verwendet werden, aber in bestimmten Active Directory-Umgebungen wird er nie gesehen. |
| 19 | PA-ETYPE-INFO2 | Der ETYPE-INFO2-Vorauthentifizierungstyp wird vom KDC in einem KRB-FEHLER gesendet, der eine Anforderung für zusätzliche Vorauthentifizierung angibt. Es wird in der Regel verwendet, um einen Client darüber zu informieren, welcher Schlüssel für die Verschlüsselung eines verschlüsselten Zeitstempels zum Senden eines PA-ENC-TIMESTAMP-Vorauthentifizierungswerts verwendet werden soll. Dieser Vorauthentifizierungstyp wurde in der Microsoft Active Directory-Umgebung nie gesehen. |
| 20 | PA-SVR-REFERRAL-INFO | Wird in KDC Referrals-Tickets verwendet. |
| 138 | PA-VERSCHLÜSSELTE HERAUSFORDERUNG | Melden Sie sich mit Kerberos Armoring (FAST) an. Wird ab Windows Server 2012 Domänencontrollern und Windows 8 Clients unterstützt. |
| - | Dieser Typ wird in Überwachungsfehlerereignissen angezeigt. |
Zertifikatinformationen:
Name des Zertifikatausstellers [Type = UnicodeString]: Der Name der Zertifizierungsstelle, die das Smartcardzertifikat ausgestellt hat. Aufgefüllt in "Ausgestellt von " im Feld "Zertifikat".
Seriennummer des Zertifikats [Typ = UnicodeString]: Seriennummer des Smartcardzertifikats. Kann im Feld "Seriennummer " im Zertifikat gefunden werden.
Zertifikatfingerabdruck [Typ = UnicodeString]: Fingerabdruck des Smartcardzertifikats. Kann im Thumbprint-Feld im Zertifikat gefunden werden.
Empfehlungen für die Sicherheitsüberwachung
Für 4768(S, F): Ein Kerberos-Authentifizierungsticket (TGT) wurde angefordert.
| Typ der erforderlichen Überwachung | Empfehlung |
|---|---|
| Konten mit hohem Wert: Sie verfügen möglicherweise über Domänen oder lokale Konten mit hohem Wert, für die Sie jede einzelne Aktionen überwachen müssen. Beispiele für hochwertige Konten sind Datenbankadministratoren, ein integriertes lokales Administratorkonto, Domänenadministratoren, Dienstkonten, Domänencontrollerkonten usw. |
Überwachen Sie dieses Ereignis mit der "Benutzer-ID" , die dem oder den Konten mit hohem Wert entspricht. |
| Anomalien oder schädliche Aktionen: Sie haben möglicherweise spezielle Anforderungen für das Erkennen von Anomalien oder das Überwachen potenziell schädlicher Aktionen. Möglicherweise müssen Sie beispielsweise die Verwendung eines Kontos außerhalb der Arbeitszeit überwachen. | Wenn Sie auf Anomalien oder böswillige Aktionen überwachen, verwenden Sie die "Benutzer-ID" (mit anderen Informationen), um zu überwachen, wie oder wann ein bestimmtes Konto verwendet wird. |
| Nicht aktive Konten: Sie haben möglicherweise nicht aktive, deaktivierte oder Gastkonten oder andere Konten, die nie verwendet werden sollten. | Überwachen Sie dieses Ereignis mit der "Benutzer-ID" , die den Konten entspricht, die niemals verwendet werden sollten. |
| Kontozulassungsliste: Sie verfügen möglicherweise über eine spezielle Liste zugelassener Konten, die als einzige die Berechtigung haben, Aktionen auszuführen, die bestimmten Ereignissen entsprechen. | Wenn dieses Ereignis einer "allowlist-only"-Aktion entspricht, überprüfen Sie die "Benutzer-ID" für Konten, die sich außerhalb der Zulassungsliste befinden. |
| Externe Konten: Sie überwachen möglicherweise Konten aus einer anderen Domäne oder "externe" Konten, die bestimmte Aktionen (repräsentiert durch bestimmte Ereignisse) nicht ausführen dürfen. | Überwachen Sie dieses Ereignis auf den "angegebenen Bereichsnamen" , der einer anderen Domäne oder einem "externen" Speicherort entspricht. |
| Namenskonventionen für Konten: Ihre Organisation hat möglicherweise spezifische Konventionen für Kontonamen. | Überwachen Sie "Benutzer-ID" auf Namen, die nicht den Benennungskonventionen entsprechen. |
Sie können alle 4768 Ereignisse nachverfolgen, bei denen die Clientadresse nicht aus Ihrem internen IP-Adressbereich oder nicht aus privaten IP-Adressbereichen stammt.
Wenn Sie wissen, dass der Kontoname nur aus einer bekannten Liste von IP-Adressen verwendet werden soll, verfolgen Sie alle Clientadressenwerte für diesen Kontonamen in 4768-Ereignissen nach. Wenn die Clientadresse nicht aus der Zulassungsliste stammt, generieren Sie die Warnung.
"Alle Clientadressen =
::1" bedeutet lokale Authentifizierung. Wenn Sie die Liste der Konten kennen, die sich bei den Domänencontrollern anmelden sollten, müssen Sie alle möglichen Verstöße überwachen, bei denen sich Clientadresse =::1und Kontoname nicht bei einem Domänencontroller anmelden dürfen.Alle 4768-Ereignisse mit dem Clientportfeldwert > 0 und < 1024 sollten untersucht werden, da ein bekannter Port für die ausgehende Verbindung verwendet wurde.
Erwägen Sie auch, die in der folgenden Tabelle angezeigten Felder zu überwachen, um die aufgeführten Probleme zu ermitteln:
| Feld | Problem, das erkannt werden soll |
|---|---|
| Name des Zertifikatausstellers | Der Name der Zertifizierungsstelle stammt nicht von Ihrer PKI. |
| Name des Zertifikatausstellers | Der Name der Zertifizierungsstelle ist nicht berechtigt, Smartcard-Authentifizierungszertifikate auszustellen. |
| Vorauthentifizierungstyp | Der Wert ist 0, was bedeutet, dass die Vorauthentifizierung nicht verwendet wurde. Alle Konten sollten die Vorauthentifizierung verwenden, mit Ausnahme von Konten, die mit "Kerberos-Vorauthentifizierung nicht erforderlich" konfiguriert sind, was ein Sicherheitsrisiko darstellt. Weitere Informationen finden Sie in Tabelle 5. Kerberos-Vorauthentifizierungstypen. |
| Vorauthentifizierungstyp | Der Wert ist nicht 15 , wenn das Konto eine Smartcard für die Authentifizierung verwenden muss. Weitere Informationen finden Sie in Tabelle 5. Kerberos-Vorauthentifizierungstypen. |
| Vorauthentifizierungstyp | Der Wert ist nicht 2 , wenn in der Organisation nur die Standardkennwortauthentifizierung verwendet wird. Weitere Informationen finden Sie in Tabelle 5. Kerberos-Vorauthentifizierungstypen. |
| Vorauthentifizierungstyp | Der Wert ist nicht 138 , wenn Kerberos Armoring für alle Kerberos-Kommunikationen in der Organisation aktiviert ist. Weitere Informationen finden Sie in Tabelle 5. Kerberos-Vorauthentifizierungstypen. |
| Ticketverschlüsselungstyp | Der Wert ist 0x1 oder 0x3, was bedeutet, dass der DES-Algorithmus verwendet wurde. DES sollte aufgrund geringer Sicherheit und bekannter Sicherheitsrisiken nicht verwendet werden. Sie ist standardmäßig ab Windows 7 und Windows Server 2008 R2 deaktiviert. Weitere Informationen finden Sie in Tabelle 4. Kerberos-Verschlüsselungstypen. |
| Ticketverschlüsselungstyp | Überwachen Sie ab Windows Vista und Windows Server 2008 andere Werte als 0x11 und 0x12. Dies sind die erwarteten Werte, beginnend mit diesen Betriebssystemen, und stellen AES-Familienalgorithmen dar. Weitere Informationen finden Sie in Tabelle 4. Kerberos-Verschlüsselungstypen. |
| Ergebniscode | 0x6 (Der Benutzername ist nicht vorhanden), wenn sie angezeigt werden, z. B. N-Ereignisse in den letzten N Minuten. Dies kann ein Indikator für Einen Kontoaufzählungsangriff sein, insbesondere für hochkritische Konten. |
| Ergebniscode | 0x7 (Der Server wurde in der Kerberos-Datenbank nicht gefunden). Dieser Fehler kann auftreten, wenn der Domänencontroller den Namen des Servers in Active Directory nicht finden kann. |
| Ergebniscode | 0x8 (Mehrere Prinzipaleinträge in der KDC-Datenbank). Dies hilft Ihnen, doppelte SPNs schneller zu finden. |
| Ergebniscode | 0x9 (Der Client oder Server verfügt über einen NULL-Schlüssel (Masterschlüssel)). Dieser Fehler kann Ihnen helfen, Probleme mit der Kerberos-Authentifizierung schneller zu erkennen. |
| Ergebniscode | 0xA (Ticket (TGT) ist nicht für postdating berechtigt). Microsoft-Systeme sollten keine postierten Tickets anfordern. Diese Ereignisse könnten dazu beitragen, Anomalieaktivitäten zu identifizieren. |
| Ergebniscode | 0xC (Die angeforderte Startzeit ist später als die Endzeit), wenn sie angezeigt wird, z. B. N-Ereignisse in den letzten N Minuten. Dies kann ein Indikator für einen Kompromissversuch des Kontos sein, insbesondere bei sehr kritischen Konten. |
| Ergebniscode | 0xE (KDC unterstützt keinen Verschlüsselungstyp). Im Allgemeinen tritt dieser Fehler auf, wenn der KDC oder ein Client ein Paket empfängt, das nicht entschlüsselt werden kann. Überwachen Sie diese Ereignisse, da dies in einer standardmäßigen Active Directory-Umgebung nicht geschehen sollte. |
| Ergebniscode | 0xF (KDC unterstützt keinen Prüfsummentyp). Überwachen Sie diese Ereignisse, da dies in einer standardmäßigen Active Directory-Umgebung nicht geschehen sollte. |
| Ergebniscode | 0x12 (Die Anmeldeinformationen des Clients wurden widerrufen), wenn sie angezeigt werden, z. B. N-Ereignisse in den letzten N Minuten. Dies kann ein Indikator für Anomalieaktivität oder Brute-Force-Angriff sein, insbesondere für hochkritische Konten. |
| Ergebniscode | 0x1F (Integritätsprüfung für entschlüsseltes Feld fehlgeschlagen). Der Authentifikator wurde mit etwas anderem als dem Sitzungsschlüssel verschlüsselt. Das Ergebnis ist, dass der KDC das TGT nicht entschlüsseln kann. Die Änderung der Nachricht kann das Ergebnis eines Angriffs oder aufgrund von Netzwerkgeräuschen sein. |
| Ergebniscode | 0x22 (Die Anforderung ist eine Wiedergabe). Dieser Fehler weist darauf hin, dass ein bestimmter Authentifikator zweimal angezeigt wurde – der KDC hat festgestellt, dass dieses Sitzungsticket eins dupliziert, das es bereits erhalten hat. Dies könnte ein Anzeichen für einen Angriffsversuch sein. |
| Ergebniscode | 0x29 (Nachrichtendatenstrom geändert und Prüfsumme nicht übereinstimmen). Die Authentifizierungsdaten wurden mit dem falschen Schlüssel für den vorgesehenen Server verschlüsselt. Die Authentifizierungsdaten wurden während der Übertragung durch einen Hardware- oder Softwarefehler oder durch einen Angreifer geändert. Überwachen Sie diese Ereignisse, da dies in einer standardmäßigen Active Directory-Umgebung nicht geschehen sollte. |
| Ergebniscode | 0x3C (allgemeiner Fehler). Dieser Fehler kann Ihnen helfen, Probleme mit der Kerberos-Authentifizierung schneller zu erkennen. |
| Ergebniscode | 0x3E (Die Clientvertrauensstellung ist fehlgeschlagen oder nicht implementiert). Dieser Fehler hilft Ihnen beim Identifizieren von Anmeldeversuchen mit widerrufenen Zertifikaten und den Situationen, in denen die Stammzertifizierungsstelle, die das Smartcardzertifikat (über eine Kette) ausgestellt hat, von einem Domänencontroller nicht als vertrauenswürdig eingestuft wird. |
| Ergebniscode | 0x3F, 0x40**, 0x41** Fehler. Diese Fehler können Ihnen helfen, Smartcardprobleme bei der Kerberos-Authentifizierung schneller zu erkennen. |
Feedback
Feedback senden und anzeigen für