Problembehandlung bei bekannten Problemen mit Microsoft Defender for Identity
In diesem Artikel wird beschrieben, wie bekannte Probleme in Microsoft Defender for Identity behoben werden.
Fehler beim Starten des Sensordiensts
Sensorprotokolleinträge:
Warn DirectoryServicesClient CreateLdapConnectionAsync failed to retrieve group managed service account password. [DomainControllerDnsName=DC1.CONTOSO.LOCAL Domain=contoso.local UserName=mdiSvc01]
Ursache 1
Der Domänencontroller hat keine Rechte für den Zugriff auf das Kennwort des gMSA-Kontos erhalten.
Lösung 1:
Vergewissern Sie sich Standard dem Controller Die Berechtigung zum Zugriff auf das Kennwort erteilt wurde. Sie sollten über eine Sicherheitsgruppe in Active Directory verfügen, die die Domänencontroller, Entra Connect, AD FS/AD CS-Server und eigenständige Sensorcomputerkonten enthält. Wenn dies nicht vorhanden ist, empfehlen wir, ein Objekt zu erstellen.
Mit dem folgenden Befehl können Sie überprüfen, ob dem Parameter ein Computerkonto oder eine Sicherheitsgruppe hinzugefügt wurde. Ersetzen Sie mdiSvc01 durch den von Ihnen erstellten Namen.
Get-ADServiceAccount mdiSvc01 -Properties PrincipalsAllowedToRetrieveManagedPassword
Das Ergebnis sollte in etwa wie folgt aussehen:
In diesem Beispiel können wir sehen, dass eine Gruppe mit dem Namen "mdiSvc01Group " hinzugefügt wurde. Wenn der Do Standard Controller oder die Sicherheitsgruppe nicht hinzugefügt wurde, können Sie die folgenden Befehle verwenden, um ihn hinzuzufügen. Ersetzen Sie mdiSvc01 durch den Namen von gMSA, und ersetzen Sie DC1 durch den Namen des Do Standard Controllers oder mdiSvc01Group durch den Namen der Sicherheitsgruppe.
# To set the specific domain controller only:
$specificDC = Get-ADComputer -Identity DC1
Set-ADServiceAccount mdiSvc01 -PrincipalsAllowedToRetrieveManagedPassword $specificDC
# To set a security group that contains the relevant computer accounts:
$group = Get-ADGroup -Identity mdiSvc01Group
Set-ADServiceAccount mdiSvc01 -PrincipalsAllowedToRetrieveManagedPassword $group
Wenn der Do Standard Controller oder die Sicherheitsgruppe bereits hinzugefügt wurde, der Fehler jedoch weiterhin angezeigt wird, können Sie die folgenden Schritte ausprobieren:
- Neustarten des Servers, um die letzten Änderungen zu synchronisieren
- Löschen Sie das Kerberos-Ticket, und erzwingen Sie, dass der Server ein neues Kerberos-Ticket anfordert. Führen Sie an einer Administrator-Eingabeaufforderung den folgenden Befehl aus:
klist -li 0x3e7 purge
Ursache 2
Aufgrund eines bekannten Szenarios im Zusammenhang mit Secure Time Seeding kann das gMSA-Attribut „PasswordLastSet“ auf ein zukünftiges Datum festgelegt werden, wodurch der Sensor nicht gestartet werden kann.
Der folgende Befehl kann verwendet werden, um zu bestätigen, ob das gMSA-Konto in das Szenario fällt, wenn die Werte PasswordLastSet und LastLogonDate ein zukünftiges Datum anzeigen:
Get-ADServiceAccount mdiSvc01 -Properties PasswordLastSet, LastLogonDate
Lösung 2:
Als Zwischenlösung kann eine neue gMSA erstellt werden, die das richtige Datum für das Attribut hat. Es ist ratsam, eine Supportanfrage mit Verzeichnisdiensten zu öffnen, um die Ursache zu identifizieren und Optionen für eine umfassende Lösung zu erkunden.
Fehler bei Sensorfehlerfehlern
Wenn Sie den folgenden Sensorfehler erhalten:
System.Net.Http.HttpRequestException:
An error occurred while sending the request. ---> System.Net.WebException:
Unable to connect to the remote server --->
System.Net.Sockets.SocketException: A connection attempt failed because the
connected party did not properly respond after a period of time, or established
connection failed because connected host has failed to respond...
Lösung:
Stellen Sie sicher, dass die Kommunikation für localhost, TCP-Port 444 nicht blockiert ist. Weitere Informationen zu den Voraussetzungen für Microsoft Defender for Identity finden Sie unter Ports.
Bereitstellungsspeicherort
Die Bereitstellungsprotokolle von Defender for Identity befinden sich im temporären Verzeichnis des Benutzers, der das Produkt installiert hat. Am Standardinstallationsspeicherort finden Sie folgendes: C:\Users\Administrator\AppData\Local\Temp (oder ein Verzeichnis über %temp%). Weitere Informationen finden Sie unter Problembehandlung von Defender for Identity mithilfe von Protokollen.
Proxyauthentifizierungsproblem tritt als Lizenzierungsfehler auf
Wenn während der Sensorinstallation die folgende Fehlermeldung angezeigt wird: Der Sensor konnte aufgrund von Lizenzierungsproblemen nicht registriert werden.
Bereitstellungsprotokolleinträge:
[1C60:1AA8][2018-03-24T23:59:13]i000: 2018-03-25 02:59:13.1237 Info InteractiveDeploymentManager ValidateCreateSensorAsync returned [validateCreateSensorResult=LicenseInvalid]]
[1C60:1AA8][2018-03-24T23:59:56]i000: 2018-03-25 02:59:56.4856 Info InteractiveDeploymentManager ValidateCreateSensorAsync returned [validateCreateSensorResult=LicenseInvalid]]
[1C60:1AA8][2018-03-25T00:27:56]i000: 2018-03-25 03:27:56.7399 Debug SensorBootstrapperApplication Engine.Quit [deploymentResultStatus=1602 isRestartRequired=False]]
[1C60:15B8][2018-03-25T00:27:56]i500: Shutting down, exit code: 0x642
Ursache:
In einigen Fällen kann sie bei der Kommunikation über einen Proxy während der Authentifizierung auf den Defender for Identity-Sensor mit Fehler 401 oder 403 anstelle von Fehler 407 reagieren. Der Defender for Identity-Sensor interpretiert Fehler 401 oder 403 als Lizenzierungsproblem und nicht als Proxyauthentifizierungsproblem.
Lösung:
Stellen Sie sicher, dass der Sensor über den konfigurierten Proxy ohne Authentifizierung zu *.atp.azure.com navigieren kann. Weitere Informationen finden Sie unter Konfigurieren des Proxys, um die Kommunikation zu ermöglichen.
Problem bei der Proxyauthentifizierung als Verbindungsfehler
Wenn während der Sensorinstallation die folgende Fehlermeldung angezeigt wird: Der Sensor konnte nicht mit dem Dienst verbunden werden.
Ursache:
Das Problem kann verursacht werden, wenn die von Defender for Identity erforderlichen Zertifikate der vertrauenswürdigen Stammzertifizierungsstellen fehlen.
Lösung:
Führen Sie das folgende PowerShell-Cmdlet aus, um zu überprüfen, ob die erforderlichen Zertifikate installiert sind.
Verwenden Sie im folgenden Beispiel das Zertifikat "DigiCert Baltimore Root" für alle Kunden. Verwenden Sie außerdem das Zertifikat "DigiCert Global Root G2" für kommerzielle Kunden oder verwenden Sie das Zertifikat "DigiCert Global Root CA" für US Government GCC High-Kunden, wie angegeben.
# Certificate for all customers
Get-ChildItem -Path "Cert:\LocalMachine\Root" | where { $_.Thumbprint -eq "D4DE20D05E66FC53FE1A50882C78DB2852CAE474"} | fl
# Certificate for commercial customers
Get-ChildItem -Path "Cert:\LocalMachine\Root" | where { $_.Thumbprint -eq "df3c24f9bfd666761b268073fe06d1cc8d4f82a4"} | fl
# Certificate for US Government GCC High customers
Get-ChildItem -Path "Cert:\LocalMachine\Root" | where { $_.Thumbprint -eq "a8985d3a65e5e5c4b2d7d66d40c6dd2fb19c5436"} | fl
Ausgabe für Zertifikat für alle Kunden:
Subject : CN=Baltimore CyberTrust Root, OU=CyberTrust, O=Baltimore, C=IE
Issuer : CN=Baltimore CyberTrust Root, OU=CyberTrust, O=Baltimore, C=IE
Thumbprint : D4DE20D05E66FC53FE1A50882C78DB2852CAE474
FriendlyName : DigiCert Baltimore Root
NotBefore : 5/12/2000 11:46:00 AM
NotAfter : 5/12/2025 4:59:00 PM
Extensions : {System.Security.Cryptography.Oid, System.Security.Cryptography.Oid, System.Security.Cryptography.Oid}
Ausgabe für Zertifikat für kommerzielle Kundenzertifikat:
Subject : CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US
Issuer : CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US
Thumbprint : DF3C24F9BFD666761B268073FE06D1CC8D4F82A4
FriendlyName : DigiCert Global Root G2
NotBefore : 01/08/2013 15:00:00
NotAfter : 15/01/2038 14:00:00
Extensions : {System.Security.Cryptography.Oid, System.Security.Cryptography.Oid, System.Security.Cryptography.Oid}
Ausgabe für Zertifikat für US Government GCC High-Kunden:
Subject : CN=DigiCert Global Root CA, OU=www.digicert.com, O=DigiCert Inc, C=US
Issuer : CN=DigiCert Global Root CA, OU=www.digicert.com, O=DigiCert Inc, C=US
Thumbprint : A8985D3A65E5E5C4B2D7D66D40C6DD2FB19C5436
FriendlyName : DigiCert
NotBefore : 11/9/2006 4:00:00 PM
NotAfter : 11/9/2031 4:00:00 PM
Extensions : {System.Security.Cryptography.Oid, System.Security.Cryptography.Oid, System.Security.Cryptography.Oid, System.Security.Cryptography.Oid}
Wenn die erwartete Ausgabe nicht angezeigt wird, führen Sie die folgenden Schritte aus:
Laden Sie die folgenden Zertifikate auf den Server Core-Computer herunter. Laden Sie für alle Kunden das Baltimore CyberTrust-Stammzertifikat herunter.
Außerdem:
- Für kommerzielle Kunden laden Sie das DigiCert Global Root G2-Zertifikat herunter.
- Für US Government GCC High-Kunden laden Sie das DigiCert Global Root CA-Zertifikat herunter.
Verwenden Sie das folgende PowerShell-Cmdlet, um das neue Zertifikat zu generieren.
# For all customers, install certificate Import-Certificate -FilePath "<PATH_TO_CERTIFICATE_FILE>\bc2025.crt" -CertStoreLocation Cert:\LocalMachine\Root # For commercial customers, install certificate Import-Certificate -FilePath "<PATH_TO_CERTIFICATE_FILE>\DigiCertGlobalRootG2.crt" -CertStoreLocation Cert:\LocalMachine\Root # For US Government GCC High customers, install certificate Import-Certificate -FilePath "<PATH_TO_CERTIFICATE_FILE>\DigiCertGlobalRootCA.crt" -CertStoreLocation Cert:\LocalMachine\Root
Fehler bei der automatischen Installation beim Versuch, PowerShell zu verwenden
Wenn Sie während der automatischen Sensorinstallation versuchen, PowerShell zu verwenden, und erhalten Sie die folgende Fehlermeldung:
"Azure ATP sensor Setup.exe" "/quiet" NetFrameworkCommandLineArguments="/q" Acce ... Unexpected token '"/quiet"' in expression or statement."
Ursache:
Fehler beim Einschließen des Präfixes ./, das bei Verwendung von PowerShell installiert werden muss.
Lösung:
Verwenden Sie den vollständigen Befehl, um die Installation erfolgreich auszuführen.
./"Azure ATP sensor Setup.exe" /quiet NetFrameworkCommandLineArguments="/q" AccessKey="<Access Key>"
Teamproblem des Defender for Identity-Sensor-NIC
Wenn Sie versuchen, den Defender for Identity-Sensor auf einem Computer zu installieren, der mit einem NIC-Teaming-Adapter konfiguriert ist, wird ein Installationsfehler gemeldet. Wenn Sie den Defender for Identity-Sensor auf einem Computer installieren möchten, der mit der NIC-Teamerstellung konfiguriert ist, stellen Sie sicher, dass Sie den Winpcap-Treiber durch Npcap ersetzen, indem Sie die anweisungen hier befolgen.
Multiprozessorgruppenmodus
Unter den Windows-Betriebssystemen 2008R2 und 2012 werden Defender for Identity-Sensoren im Modus Mehrere Prozessorgruppen nicht unterstützt.
Mögliche Problemumgehungen vorgeschlagen:
Wenn Hyperthreading aktiviert ist, deaktivieren Sie sie. Dies kann die Anzahl der logischen Kerne verringern, um zu vermeiden, dass sie im Multiprozessorgruppenmodus ausgeführt werden müssen.
Wenn Ihr Computer weniger als 64 logische Kerne aufweist und auf einem HP-Host ausgeführt wird, können Sie möglicherweise die BIOS-Einstellung für die NUMA-Gruppengrößenoptimierung von der Standardeinstellung " Gruppiert" in "Flach" ändern.
VMware Virtual Machine Sensor-Problem
Wenn Sie über einen Defender for Identity-Sensor auf virtuellen VMware-Computern verfügen, erhalten Sie möglicherweise die Integritätswarnung Einige Netzwerkdatenverkehr werden nicht analysiert. Dies kann aufgrund eines Konfigurationskonflikts in VMware auftreten.
So lösen Sie das Problem:
Legen Sie im Gastbetriebssystem Folgendes in der NIC-Konfiguration des virtuellen Computers auf "Deaktiviert " fest: "IPv4 TSO Offload".
Verwenden Sie den folgenden Befehl, um zu überprüfen, ob "Großes Ausladen" (Large Send Offload, LSO) aktiviert oder deaktiviert ist:
Get-NetAdapterAdvancedProperty | Where-Object DisplayName -Match "^Large*"
Verwenden Sie den folgenden Befehl, um die Einstellung zu aktivieren:
Disable-NetAdapterLso -Name {name of adapter}
Hinweis
- Je nach Konfiguration können diese Aktionen zu einem kurzen Verlust der Netzwerkkonnektivität führen.
- Sie müssen möglicherweise Ihren Computer neu starten, damit die neuen Einstellungen wirksam werden.
- Diese Schritte können je nach VMWare-Version variieren. Informationen zum Deaktivieren von LSO/TSO für Ihre VMWare-Version finden Sie in der VMWare-Dokumentation.
Sensor konnte keine Gruppenverwalteten Dienstkonto-Anmeldeinformationen (gMSA) abrufen.
Wenn Sie die folgende Integritätswarnung erhalten: Anmeldeinformationen für Verzeichnisdienste sind falsch.
Sensorprotokolleinträge:
2020-02-17 14:01:36.5315 Info ImpersonationManager CreateImpersonatorAsync started [UserName=account_name Domain=domain1.test.local IsGroupManagedServiceAccount=True]
2020-02-17 14:01:36.5750 Info ImpersonationManager CreateImpersonatorAsync finished [UserName=account_name Domain=domain1.test.local IsSuccess=False]
Protokolleinträge für Sensoraktualisierungen:
2020-02-17 14:02:19.6258 Warn GroupManagedServiceAccountImpersonationHelper GetGroupManagedServiceAccountAccessTokenAsync failed GMSA password could not be retrieved [errorCode=AccessDenied AccountName=account_name DomainDnsName=domain1.test.local]
Der Sensor konnte das Kennwort des gMSA-Kontos nicht abrufen.
Ursache 1
Dem Domänencontroller wurde keine Berechtigung zum Abrufen des Kennworts des gMSA-Kontos erteilt.
Lösung 1:
Überprüfen Sie, ob dem Computer, auf dem der Sensor ausgeführt wird, Berechtigungen zum Abrufen des Kennworts des gMSA-Kontos erteilt wurden. Weitere Informationen finden Sie unter Erteilen von Berechtigungen zum Abrufen des Kennworts des gMSA-Kontos.
Ursache 2
Der Sensordienst wird als LocalService ausgeführt und führt einen Identitätswechsel des Verzeichnisdienstkontos aus.
Wenn die Benutzerrechtezuweisungsrichtlinie als Dienst für diese Aufgabe konfiguriert ist Standard Controller, schlägt der Identitätswechsel fehl, es sei denn, dem gMSA-Konto wird die Berechtigung "Anmelden als Dienst" erteilt.
Lösung 2:
Konfigurieren Sie die Anmeldung als Dienst für die gMSA-Konten, wenn die Richtlinie für die Benutzerrechtezuweisung als Dienst auf dem betroffenen Do Standard Controller konfiguriert ist. Weitere Informationen finden Sie unter Überprüfen, ob das gMSA-Konto über die erforderlichen Rechte verfügt.
Ursache 3
Wenn das Domänencontroller-Kerberos-Ticket vor dem Ausführen ausgestellt wurde Standard Controller der Sicherheitsgruppe mit den entsprechenden Berechtigungen hinzugefügt wurde, ist diese Gruppe nicht Teil des Kerberos-Tickets. Daher kann es das Kennwort des gMSA-Kontos nicht abrufen.
Lösung 3:
Führen Sie einen der folgenden Schritte aus, um dieses Problem zu beheben:
Domänencontroller neu starten.
Löschen Sie das Kerberos-Ticket, und erzwingen Sie den Domänencontroller, um ein neues Kerberos-Ticket anzufordern. Führen Sie an einer Administrator-Eingabeaufforderung den folgenden Befehl aus:
klist -li 0x3e7 purgeWeisen Sie die Berechtigung zum Abrufen des gMSA-Kennworts einer Gruppe zu Standard Controller ist bereits Mitglied der Gruppe "Do Standard Controller".
Der Zugriff auf den Registrierungsschlüssel "Global" wurde verweigert.
Der Sensordienst kann nicht gestartet werden, und das Sensorprotokoll enthält einen Eintrag ähnlich wie:
2021-01-19 03:45:00.0000 Error RegistryKey System.UnauthorizedAccessException: Access to the registry key 'Global' is denied.
Ursache:
Die für diese Vorgehensweise konfigurierte gMSA Standard Controller oder AD FS/AD CS-Server verfügt nicht über Berechtigungen für die Registrierungsschlüssel des Leistungsindikators.
Lösung:
Fügen Sie die gMSA zur Gruppe "Leistungsmonitor Benutzer" auf dem Server hinzu.
Berichtsdownloads dürfen nicht mehr als 300.000 Einträge enthalten.
Defender for Identity unterstützt keine Berichtsdownloads, die mehr als 300.000 Einträge pro Bericht enthalten. Berichte werden als unvollständig gerendert, wenn mehr als 300.000 Einträge enthalten sind.
Ursache:
Dies ist eine technische Einschränkung.
Lösung:
Keine bekannte Auflösung.
Sensor kann Ereignisprotokolle nicht aufzählen
Wenn Sie eine begrenzte Anzahl oder einen Mangel an Sicherheitsereigniswarnungen oder logischen Aktivitäten innerhalb der Defender for Identity-Konsole beobachten, aber keine Integritätsprobleme ausgelöst werden.
Sensorprotokolleinträge:
Error EventLogException System.Diagnostics.Eventing.Reader.EventLogException: The handle is invalid at void System.Diagnostics.Eventing.Reader.EventLogException.Throw(int errorCode) at object System.Diagnostics.Eventing.Reader.NativeWrapper.EvtGetEventInfo(EventLogHandle handle, EvtEventPropertyId enumType) at string System.Diagnostics.Eventing.Reader.EventLogRecord.get_ContainerLog()
Ursache:
Eine Diskretionäre Zugriffssteuerungsliste beschränkt den Zugriff auf die erforderlichen Ereignisprotokolle durch das Lokale Dienstkonto.
Lösung:
Stellen Sie sicher, dass die DaCL (Discretionary Access Control List) den folgenden Eintrag enthält (dies ist die SID des AATPSensor-Diensts).
(A;;0x1;;;S-1-5-80-818380073-2995186456-1411405591-3990468014-3617507088)
Überprüfen Sie, ob die DACL für das Sicherheitsereignisprotokoll von einem Gruppenrichtlinienobjekt konfiguriert wurde:
Policies > Administrative Templates > Windows Components > Event Log Service > Security > Configure log access
Fügen Sie den obigen Eintrag an die vorhandene Richtlinie an. Führen Sie C:\Windows\System32\wevtutil.exe gl security anschließend die Ausführung aus, um zu überprüfen, ob der Eintrag hinzugefügt wurde.
Die lokalen Defender for Identity-Protokolle sollten jetzt angezeigt werden:
Info WindowsEventLogReader EnableEventLogWatchers EventLogWatcher enabled [name=Security]
ApplyInternal failed two way SSL connection to service error
Wenn während der Sensorinstallation die folgende Fehlermeldung angezeigt wird: ApplyInternal failed two way SSL connection to service and the sensor log contains an entry similar to:
2021-01-19 03:45:00.0000 Error CommunicationWebClient+\<SendWithRetryAsync\>d__9`1 ApplyInternal konnte auf zwei Weisen eine SSL-Verbindung mit dem Dienst herstellen.
Das Problem kann durch einen Proxy mit aktivierter SSL-Inspektion verursacht werden.
[_workspaceApplicationSensorApiEndpoint=Unspecified/contoso.atp.azure.com:443 Thumbprint=7C039DA47E81E51F3DA3DF3DA7B5E1899B5B4AD0]'
Ursache:
Das Problem kann verursacht werden, wenn die Registrierungswerte "SystemDefaultTlsVersions" oder "SchUseStrongCrypto " nicht auf den Standardwert 1 festgelegt sind.
Lösung:
Setzen Sie die Registrierungsschlüssel SchUseStrongCrypto und SystemDefaultTlsVersions auf 1.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001
In diesem Release wurden Probleme bei der Installation des Sensors unter Windows Server 2019 mit KB5009557 und auf Servern mit gehärteten EventLog-Berechtigungen behoben.
Fehler beim Installieren des Sensors mit der Fehlermeldung:
System.UnauthorizedAccessException: Attempted to perform an unauthorized operation.
Lösung:
Es gibt zwei Lösungen für dieses Problem:
Installieren Sie den Sensor mit PSExec:
psexec -s -i "C:\MDI\Azure ATP Sensor Setup.exe"Installieren Sie den Sensor mit einer geplanten Aufgabe, die für die Ausführung als "LocalSystem" konfiguriert ist. Die zu verwendende Befehlszeilensyntax wird in der automatischen Installation des Defender for Identity-Sensors Erwähnung.
Fehler bei der Sensorinstallation aufgrund des Zertifikatverwaltungsclients
Wenn die Sensorinstallation fehlschlägt, und die Datei "Microsoft.Tri.Sensor.Deployment.Deployer.log" enthält einen Eintrag ähnlich wie:
2022-07-15 03:45:00.0000 Error IX509CertificateRequestCertificate2 Deployer failed [arguments=128Ve980dtms0035h6u3Bg==] System.Runtime.InteropServices.COMException (0x80090008): CertEnroll::CX509CertificateRequestCertificate::Encode: Invalid algorithm specified. 0x80090008 (-2146893816 NTE_BAD_ALGID)
Ursache:
Das Problem kann verursacht werden, wenn ein Zertifikatverwaltungsclient wie Entrust Entelligence Security Provider (EESP) verhindert, dass die Sensorinstallation ein selbstsigniertes Zertifikat auf dem Computer erstellt.
Lösung:
Deinstallieren Sie den Zertifikatverwaltungsclient, installieren Sie den Defender for Identity-Sensor, und installieren Sie dann den Zertifikatverwaltungsclient erneut.
Hinweis
Das selbstsignierte Zertifikat wird alle 2 Jahre verlängert, und der Prozess der automatischen Verlängerung schlägt möglicherweise fehl, wenn der Zertifikatverwaltungsclient die selbstsignierte Zertifikaterstellung verhindert. Dies führt dazu, dass der Sensor die Kommunikation mit dem Back-End beendet, was eine Sensor-Neuinstallation erfordert, indem die oben Erwähnung beschriebene Problemumgehung verwendet wird.
Fehler bei der Sensorinstallation aufgrund von Netzwerkverbindungsproblemen
Wenn die Sensorinstallation mit einem Fehlercode von 0x80070643 fehlschlägt, und die Installationsprotokolldatei enthält einen Eintrag ähnlich wie:
[22B8:27F0][2016-06-09T17:21:03]e000: Error 0x80070643: Failed to install MSI package.
Ursache:
Das Problem kann verursacht werden, wenn der Installationsprozess nicht auf die Defender for Identity-Clouddienste für die Sensorregistrierung zugreifen kann.
Lösung:
Stellen Sie sicher, dass der Sensor direkt oder über den konfigurierten Proxy zu *.atp.azure.com navigieren kann. Legen Sie bei Bedarf die Proxyservereinstellungen für die Installation mithilfe der Befehlszeile fest:
"Azure ATP sensor Setup.exe" [ProxyUrl="http://proxy.internal.com"] [ProxyUserName="domain\proxyuser"] [ProxyUserPassword="ProxyPassword"]
Weitere Informationen finden Sie unter Ausführen einer automatischen Installation mit einer Proxykonfiguration und Installieren des Microsoft Defender for Identity-Sensors.
Wichtig
Microsoft empfiehlt, immer den sichersten Authentifizierungsflow zu verwenden. Der in diesem Verfahren beschriebene Authentifizierungsflow erfordert ein sehr hohes Maß an Vertrauen in die Anwendung und birgt Risiken, die bei anderen Flows nicht vorhanden sind. Sie sollten diesen Flow nur verwenden, wenn andere sicherere Flows (z. B. verwaltete Identitäten) nicht anwendbar sind.
Der Sensordienst konnte nicht ausgeführt und wieder ausgeführt werden Standard s im Startzustand
Die folgenden Fehler werden im Systemprotokoll in der Ereignisanzeige angezeigt:
- Das Open-Verfahren für den Dienst ". NETFramework" in DER DLL "C:\Windows\system32\mscoree.dll" fehlgeschlagen, fehler beim Fehlercode Access wird verweigert. Leistungsdaten für diesen Dienst sind nicht verfügbar.
- Fehler bei der Open-Prozedur für den Dienst "Lsa" in der DLL "C:\Windows\System32\Secur32.dll". Fehler beim Fehlercode Access. Es sind keine Leistungsindikatoren für diesen Dienst verfügbar.
- Fehler beim Öffnen des Diensts "WmiApRpl" in der DLL "C:\Windows\system32\wbem\wmiaprpl.dll" mit dem Fehlercode "Das Gerät ist nicht bereit". Leistungsdaten für diesen Dienst sind nicht verfügbar.
Der Microsoft.TriSensorError.log enthält einen Fehler ähnlich dem folgenden:
Microsoft.Tri.Sensor.DirectoryServicesClient.TryCreateLdapConnectionAsync(DomainControllerConnectionData domainControllerConnectionData, bool isGlobalCatalog, bool isTraversing) 2021-07-13 14:56:20.2976 Error DirectoryServicesClient Microsoft.Tri.Infrastructure.ExtendedException: Failed to communicate with configured domain controllers at new Microsoft.Tri.Sensor.DirectoryServicesClient(IConfigurationManager
Ursache:
NT-Dienst\Alle Dienste haben nicht das Recht, sich als Dienst anzumelden.
Lösung:
Fügen Sie die Do Standard Controllerrichtlinie mit der Anmeldung als Dienst hinzu. Weitere Informationen finden Sie unter Überprüfen, ob das gMSA-Konto über die erforderlichen Rechte verfügt.
Ihr Arbeitsbereich wurde nicht erstellt, da bereits eine Sicherheitsgruppe mit demselben Namen in der Microsoft Entra-ID vorhanden ist.
Ursache:
Das Problem kann auftreten, wenn eine Defender for Identity-Arbeitsbereichslizenz abläuft und gelöscht wird, wenn der Aufbewahrungszeitraum beendet wurde, aber die Microsoft Entra-Gruppen wurden nicht gelöscht.
Lösung:
- Navigieren Sie zu den Azure-Portal ->Microsoft Entra ID ->Gruppen
- y≈x¥Benennen Sie die folgenden drei Gruppen um (wobei workspaceName der Name Ihres Arbeitsbereichs ist), indem Sie ihnen ein „ - old“-Suffix hinzufügen:
- "Azure ATP workspaceName Administrators" –> "Azure ATP workspaceName Administrators - old"
- "Azure ATP workspaceName Viewers" –> "Azure ATP workspaceName Viewers - old"
- "Azure ATP workspaceName Users" –> "Azure ATP workspaceName Users - old"
- Anschließend können Sie im Microsoft Defender-Portal zum Abschnitt Einstellungen ->Identitäten zurückkehren, um den neuen Arbeitsbereich für Defender for Identity zu erstellen.