Behandeln von Microsoft Defender for Identity bekannten Problemen
In diesem Artikel wird beschrieben, wie Sie bekannte Probleme in Microsoft Defender for Identity beheben.
Sensordienst kann nicht gestartet werden
Sensorprotokolleinträge:
Warn DirectoryServicesClient CreateLdapConnectionAsync failed to retrieve group managed service account password. [DomainControllerDnsName=DC1.CONTOSO.LOCAL Domain=contoso.local UserName=mdiSvc01]
Ursache 1
Dem Domänencontroller wurden keine Rechte für den Zugriff auf das Kennwort des gMSA-Kontos erteilt.
Lösung 1
Vergewissern Sie sich, dass dem Domänencontroller Rechte für den Zugriff auf das Kennwort erteilt wurden. Sie sollten über eine Sicherheitsgruppe in Active Directory verfügen, die die Computerkonten Domänencontroller, Entra Connect, AD FS-/AD CS-Server und eigenständige Sensoren enthält. Wenn dies nicht vorhanden ist, empfiehlt es sich, eine zu erstellen.
Sie können den folgenden Befehl verwenden, um zu überprüfen, ob dem Parameter ein Computerkonto oder eine Sicherheitsgruppe hinzugefügt wurde. Ersetzen Sie mdiSvc01 durch den Namen, den Sie erstellt haben.
Get-ADServiceAccount mdiSvc01 -Properties PrincipalsAllowedToRetrieveManagedPassword
Die Ergebnisse sollten wie folgt aussehen:
In diesem Beispiel sehen Wir, dass eine Gruppe mit dem Namen mdiSvc01Group hinzugefügt wurde. Wenn der Domänencontroller oder die Sicherheitsgruppe nicht hinzugefügt wurde, können Sie ihn mit den folgenden Befehlen hinzufügen. Ersetzen Sie mdiSvc01 durch den Namen von gMSA und DC1 durch den Namen des Domänencontrollers 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 Domänencontroller oder die Sicherheitsgruppe bereits hinzugefügt wurde, der Fehler aber weiterhin angezeigt wird, können Sie die folgenden Schritte ausführen:
- Starten Sie den Server neu, um die letzten Änderungen zu synchronisieren.
- Bereinigen Sie das Kerberos-Ticket, und erzwingen Sie, dass der Server ein neues Kerberos-Ticket anzufordern. Führen Sie an einer Administratoreingabeaufforderung 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, sodass 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 ein neuer gMSA erstellt werden, der das richtige Datum für das Attribut hat. Es ist ratsam, eine Supportanfrage mit Verzeichnisdiensten zu öffnen, um die Grundursache zu identifizieren und Optionen für eine umfassende Lösung zu erkunden.
Fehler bei der Kommunikation mit Sensorfehlern
Wenn der folgende Sensorfehlerfehler angezeigt wird:
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 Microsoft Defender for Identity Voraussetzungen finden Sie unter Ports.
Speicherort des Bereitstellungsprotokolls
Die Defender for Identity-Bereitstellungsprotokolle befinden sich im temporären Verzeichnis des Benutzers, der das Produkt installiert hat. Der Standardinstallationsspeicherort befindet sich unter : C:\Users\Administrator\AppData\Local\Temp (oder in einem Verzeichnis oberhalb von %temp%). Weitere Informationen finden Sie unter Problembehandlung bei Defender for Identity mithilfe von Protokollen.
Proxyauthentifizierungsproblem wird als Lizenzierungsfehler angezeigt
Wenn während der Sensorinstallation der folgende Fehler 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 bei der Kommunikation über einen Proxy während der Authentifizierung auf den Defender for Identity-Sensor der Fehler 401 oder 403 anstelle von Fehler 407 reagiert werden. 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 zum Aktivieren der Kommunikation.
Proxyauthentifizierungsproblem wird als Verbindungsfehler angezeigt
Wenn während der Sensorinstallation der folgende Fehler angezeigt wird: Der Sensor konnte keine Verbindung mit dem Dienst herstellen.
Ursache:
Das Problem kann verursacht werden, wenn die für 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 das Zertifikat "DigiCert Global Root CA" für GCC High-Kunden der US-Regierung, 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 das 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 das Zertifikat für kommerzielle Kunden:
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 das Zertifikat für GCC High-Kunden der US-Regierung:
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.
Weitere Schritte:
- Laden Sie für gewerbliche Kunden das DigiCert Global Root G2-Zertifikat herunter.
- Laden Sie für GCC High-Kunden der US-Regierung das DigiCert Global Root Ca-Zertifikat herunter.
Führen Sie das folgende PowerShell-Cmdlet aus, um das Zertifikat zu installieren.
# 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 bei der Verwendung von PowerShell
Wenn Sie während der automatischen Sensorinstallation versuchen, PowerShell zu verwenden, und erhalten Sie den folgenden Fehler:
"Azure ATP sensor Setup.exe" "/quiet" NetFrameworkCommandLineArguments="/q" Acce ... Unexpected token '"/quiet"' in expression or statement."
Ursache:
Wenn bei Verwendung von PowerShell das präfix ./ nicht eingeschlossen werden muss, wird dieser Fehler verursacht.
Lösung:
Verwenden Sie den vollständigen Befehl, um die Installation erfolgreich durchzuführen.
./"Azure ATP sensor Setup.exe" /quiet NetFrameworkCommandLineArguments="/q" AccessKey="<Access Key>"
NIC-Teamingproblem des Defender for Identity-Sensors
Wenn Sie den Defender for Identity-Sensor auf einem Computer installieren, der mit einem NIC-Teamadapter und dem Winpcap-Treiber konfiguriert ist, erhalten Sie einen Installationsfehler. Wenn Sie den Defender for Identity-Sensor auf einem Computer installieren möchten, der mit NIC-Teaming konfiguriert ist, stellen Sie sicher, dass Sie den Winpcap-Treiber durch Npcap ersetzen, indem Sie die anweisungen hier befolgen.
Multiprozessorgruppenmodus
Für die Windows-Betriebssysteme 2008R2 und 2012 wird der Defender for Identity-Sensor im Modus "Multiprozessorgruppen" nicht unterstützt.
Mögliche Problemumgehungen vorgeschlagen:
Wenn Hyperthreading aktiviert ist, deaktivieren Sie es. Dadurch kann die Anzahl der logischen Kerne so reduziert werden, dass sie nicht im Multiprozessorgruppenmodus ausgeführt werden müssen.
Wenn Ihr Computer über weniger als 64 logische Kerne verfügt 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 Clustered in Flat ändern.
Problem mit dem VMware-VM-Sensor
Wenn Sie über einen Defender for Identity-Sensor auf virtuellen VMware-Computern verfügen, erhalten Sie möglicherweise die Integritätswarnung Einige Netzwerkdatenverkehre werden nicht analysiert. Dies kann aufgrund eines Konfigurationskonflikts in VMware auftreten.
So lösen Sie das Problem:
Legen Sie auf dem Gastbetriebssystem in der NIC-Konfiguration des virtuellen Computers Auf Deaktiviert fest: IPv4-TSO-Auslagerung.
Verwenden Sie den folgenden Befehl, um zu überprüfen, ob große Sendeauslagerung (Large Send Offload, LSO) aktiviert oder deaktiviert ist:
Get-NetAdapterAdvancedProperty | Where-Object DisplayName -Match "^Large*"
Wenn LSO aktiviert ist, verwenden Sie den folgenden Befehl, um es zu deaktivieren:
Disable-NetAdapterLso -Name {name of adapter}
Hinweis
- Abhängig von Ihrer Konfiguration können diese Aktionen zu einem kurzen Verlust der Netzwerkkonnektivität führen.
- Möglicherweise müssen Sie Ihren Computer neu starten, damit diese Änderungen 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.
Fehler beim Abrufen von Anmeldeinformationen für ein gruppenverwaltetes Dienstkonto (Group Managed Service Account, gMSA) durch den Sensor
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]
Sensor Updater-Protokolleinträge:
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 Richtlinie zum Zuweisen von Benutzerrechten als Dienst für diesen Domänencontroller konfiguriert ist, schlägt der Identitätswechsel fehl, es sei denn, dem gMSA-Konto wird die Berechtigung Anmelden als Dienst erteilt.
Lösung 2:
Konfigurieren Sie Log on as a Service (Anmelden als Dienst ) für die gMSA-Konten, wenn die Richtlinie zum Zuweisen von Benutzerrechten als Dienst auf dem betroffenen Domänencontroller konfiguriert ist. Weitere Informationen finden Sie unter Überprüfen, ob das gMSA-Konto über die erforderlichen Rechte verfügt.
Ursache 3
Wenn das Kerberos-Ticket für den Domänencontroller ausgestellt wurde, bevor der Domänencontroller der Sicherheitsgruppe mit den richtigen Berechtigungen hinzugefügt wurde, ist diese Gruppe nicht Teil des Kerberos-Tickets. Daher kann das Kennwort des gMSA-Kontos nicht abgerufen werden.
Lösung 3:
Führen Sie einen der folgenden Schritte aus, um dieses Problem zu beheben:
Starten Sie den Domänencontroller neu.
Bereinigen Sie das Kerberos-Ticket, und erzwingen Sie, dass der Domänencontroller ein neues Kerberos-Ticket anzufordern. Führen Sie an einer Administratoreingabeaufforderung auf dem Domänencontroller den folgenden Befehl aus:
klist -li 0x3e7 purgeWeisen Sie die Berechtigung zum Abrufen des Kennworts des gMSA einer Gruppe zu, in der der Domänencontroller bereits Mitglied ist, z. B. der Gruppe Domänencontroller.
Der Zugriff auf den Registrierungsschlüssel "Global" wird verweigert.
Der Sensordienst kann nicht gestartet werden, und das Sensorprotokoll enthält einen Eintrag ähnlich dem folgenden:
2021-01-19 03:45:00.0000 Error RegistryKey System.UnauthorizedAccessException: Access to the registry key 'Global' is denied.
Ursache:
Der für diesen Domänencontroller oder AD FS/AD CS-Server konfigurierte gMSA verfügt nicht über Berechtigungen für die Registrierungsschlüssel des Leistungsindikators.
Lösung:
Fügen Sie die gMSA der 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 fehlende Sicherheitsereigniswarnungen oder logische Aktivitäten in der Defender for Identity-Konsole feststellen, 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 ermessensbasierte Access Control Liste 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 GPO 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 anschließend aus C:\Windows\System32\wevtutil.exe gl security , um zu überprüfen, ob der Eintrag hinzugefügt wurde.
In den lokalen Defender for Identity-Protokollen sollte nun Folgendes angezeigt werden:
Info WindowsEventLogReader EnableEventLogWatchers EventLogWatcher enabled [name=Security]
Fehler bei "ApplyInternal" bei der zweiseitigen SSL-Verbindung mit dem Dienst
Wenn sie während der Sensorinstallation den folgenden Fehler erhalten: 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 Fehler bei ApplyInternal bei der bidirektionalen SSL-Verbindung mit dem Dienst.
Das Problem kann durch einen Proxy mit aktivierter SSL-Überprüfung 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 ihren Standardwert 1 festgelegt sind.
Lösung:
Überprüfen Sie, ob die Registrierungswerte SystemDefaultTlsVersions und SchUseStrongCrypto auf 1 festgelegt sind:
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
Problem bei der Installation des Sensors auf Windows Server 2019 mit installiertem KB5009557 oder auf einem Server mit gehärteten EventLog-Berechtigungen
Die Installation des Sensors schlägt möglicherweise mit der folgenden Fehlermeldung fehl:
System.UnauthorizedAccessException: Attempted to perform an unauthorized operation.
Lösung:
Es gibt zwei mögliche Problemumgehungen 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 einem geplanten Task, der für die Ausführung als LocalSystem konfiguriert ist. Die zu verwendende Befehlszeilensyntax wird unter Automatische Installation des Defender for Identity-Sensors erwähnt.
Fehler bei der Sensorinstallation aufgrund des Zertifikatverwaltungsclients
Wenn bei der Sensorinstallation ein Fehler auftritt und die Microsoft.Tri.Sensor.Deployment.Deployer.log-Datei einen Eintrag wie folgt enthält:
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 neu.
Hinweis
Das selbstsignierte Zertifikat wird alle zwei Jahre erneuert, und der automatische Verlängerungsprozess kann fehlschlagen, wenn der Zertifikatverwaltungsclient die Erstellung des selbstsignierten Zertifikats verhindert. Dies führt dazu, dass der Sensor nicht mehr mit dem Back-End kommuniziert, was eine Neuinstallation des Sensors mithilfe der oben genannten Problemumgehung erfordert.
Fehler bei der Sensorinstallation aufgrund von Netzwerkkonnektivitätsproblemen
Wenn die Sensorinstallation mit dem Fehlercode 0x80070643 fehlschlägt und die Installationsprotokolldatei einen Eintrag wie folgt enthält:
[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 über die 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, den sichersten Authentifizierungsablauf zu verwenden, der verfügbar ist. Der in diesem Verfahren beschriebene Authentifizierungsablauf erfordert ein sehr hohes Maß an Vertrauen in die Anwendung und birgt Risiken, die in anderen Flows nicht vorhanden sind. Sie sollten diesen Flow nur verwenden, wenn andere sicherere Flows, z. B. verwaltete Identitäten, nicht praktikabel sind.
Der Sensordienst konnte nicht ausgeführt werden und verbleibt 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" ist mit dem Fehlercode "Zugriff verweigert" fehlgeschlagen. Leistungsdaten für diesen Dienst sind nicht verfügbar.
- Die Open-Prozedur für den Dienst "Lsa" in der DLL "C:\Windows\System32\Secur32.dll" ist mit dem Fehlercode "Zugriff verweigert" fehlgeschlagen. Leistungsdaten für diesen Dienst sind nicht verfügbar.
- Die Open-Prozedur für den Dienst "WmiApRpl" in der DLL "C:\Windows\system32\wbem\wmiaprpl.dll" ist mit dem Fehlercode "Das Gerät ist nicht bereit" fehlgeschlagen. Leistungsdaten für diesen Dienst sind nicht verfügbar.
Die Microsoft.TriSensorError.log enthält einen Fehler wie den 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 eine Domänencontrollerrichtlinie 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 Microsoft Entra ID
Ursache:
Das Problem kann auftreten, wenn eine Defender for Identity-Arbeitsbereichslizenz abläuft und nach Ablauf des Aufbewahrungszeitraums gelöscht wird, aber die Microsoft Entra Gruppen nicht gelöscht wurden.
Lösung:
- Wechseln Sie zum Azure-Portal ->Microsoft Entra ID ->Gruppen
- Benennen Sie die folgenden drei Gruppen um (wobei workspaceName der Name Ihres Arbeitsbereichs ist), indem Sie ihnen ein -altes 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 EinstellungenIdentitäten> zurückkehren, um den neuen Arbeitsbereich für Defender for Identity zu erstellen.