Rozwiązywanie znanych problemów z usługą Microsoft Defender for Identity

W tym artykule opisano sposób rozwiązywania znanych problemów w usłudze Microsoft Defender for Identity.

Błąd komunikacji z czujnikiem

Jeśli wystąpi następujący błąd czujnika:

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...

Rozwiązanie:

Upewnij się, że komunikacja nie jest blokowana dla hosta lokalnego, portu TCP 444. Aby dowiedzieć się więcej na temat wymagań wstępnych usługi Microsoft Defender for Identity, zobacz porty.

Lokalizacja dziennika wdrożenia

Dzienniki wdrażania usługi Defender for Identity znajdują się w katalogu tymczasowym użytkownika, który zainstalował produkt. W domyślnej lokalizacji instalacji znajduje się: C:\Users\Administracja istrator\AppData\Local\Temp (lub jeden katalog powyżej %temp%). Aby uzyskać więcej informacji, zobacz Rozwiązywanie problemów z usługą Defender for Identity przy użyciu dzienników.

Problem z uwierzytelnianiem serwera proxy występuje jako błąd licencjonowania

Jeśli podczas instalacji czujnika wystąpi następujący błąd: Nie można zarejestrować czujnika z powodu problemów z licencjonowaniem.

Wpisy dziennika wdrożenia:

[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

Przyczyna:

W niektórych przypadkach podczas komunikacji za pośrednictwem serwera proxy podczas uwierzytelniania może on odpowiedzieć na czujnik usługi Defender for Identity z błędem 401 lub 403 zamiast błędu 407. Czujnik usługi Defender for Identity interpretuje błąd 401 lub 403 jako problem z licencjonowaniem, a nie jako problem z uwierzytelnianiem serwera proxy.

Rozwiązanie:

Upewnij się, że czujnik może przejść do adresu *.atp.azure.com za pośrednictwem skonfigurowanego serwera proxy bez uwierzytelniania. Aby uzyskać więcej informacji, zobacz Konfigurowanie serwera proxy w celu włączenia komunikacji.

Problem z uwierzytelnianiem serwera proxy występuje jako błąd połączenia

Jeśli podczas instalacji czujnika wystąpi następujący błąd: Czujnik nie może nawiązać połączenia z usługą.

Przyczyna:

Problem może być spowodowany brakiem zaufanych głównych urzędów certyfikacji wymaganych przez usługę Defender for Identity.

Rozwiązanie:

Uruchom następujące polecenie cmdlet programu PowerShell, aby sprawdzić, czy są zainstalowane wymagane certyfikaty.

W poniższym przykładzie użyj certyfikatu "DigiCert Baltimore Root" dla wszystkich klientów. Ponadto należy użyć certyfikatu "DigiCert Global Root G2" dla klientów komercyjnych lub użyć certyfikatu "DigiCert Global Root CA" dla klientów GCC High dla instytucji rządowych USA, jak wskazano.

# 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

Dane wyjściowe certyfikatu dla wszystkich klientów:

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}

Dane wyjściowe certyfikatu dla certyfikatu klientów komercyjnych:

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}

Dane wyjściowe certyfikatu dla klientów GCC High dla instytucji rządowych USA:

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}

Jeśli nie widzisz oczekiwanych danych wyjściowych, wykonaj następujące kroki:

  1. Pobierz następujące certyfikaty na maszynę Server Core. Dla wszystkich klientów pobierz certyfikat główny Baltimore CyberTrust.

    Dodatkowo:

  2. Uruchom następujące polecenie cmdlet programu PowerShell, aby zainstalować certyfikat.

    # 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
    

Błąd instalacji dyskretnej podczas próby użycia programu PowerShell

Jeśli podczas instalacji czujnika dyskretnego próbujesz użyć programu PowerShell i wystąpi następujący błąd:

"Azure ATP sensor Setup.exe" "/quiet" NetFrameworkCommandLineArguments="/q" Acce ... Unexpected token '"/quiet"' in expression or statement."

Przyczyna:

Nie można uwzględnić prefiksu ./ wymaganego do zainstalowania podczas korzystania z programu PowerShell powoduje ten błąd.

Rozwiązanie:

Użyj kompletnego polecenia, aby pomyślnie zainstalować.

./"Azure ATP sensor Setup.exe" /quiet NetFrameworkCommandLineArguments="/q" AccessKey="<Access Key>"

Problem z tworzeniem zespołu kart interfejsu sieciowego czujnika usługi Defender for Identity

Podczas instalowania czujnika usługi Defender for Identity na maszynie skonfigurowanej za pomocą karty sieciowej i sterownika Winpcap występuje błąd instalacji. Jeśli chcesz zainstalować czujnik usługi Defender for Identity na maszynie skonfigurowanej z tworzeniem zespołu kart interfejsu sieciowego, pamiętaj, aby zastąpić sterownik Winpcap aplikacją Npcap, postępując zgodnie z instrukcjami podanymi tutaj.

Tryb grupy z wieloma procesorami

W przypadku systemów operacyjnych Windows 2008R2 i 2012 czujnik usługi Defender for Identity nie jest obsługiwany w trybie grupy wieloprocesorowej.

Sugerowane możliwe obejścia:

  • Jeśli funkcja hyper threading jest włączona, wyłącz ją. Może to zmniejszyć liczbę rdzeni logicznych na tyle, aby uniknąć konieczności uruchamiania w trybie grupy wielu procesorów.

  • Jeśli maszyna ma mniej niż 64 rdzenie logiczne i jest uruchomiona na hoście HP, może być możliwe zmianę ustawienia BIOS optymalizacji rozmiaru grupy NUMA z domyślnej wartości Clustered na Flat.

Problem z czujnikiem maszyny wirtualnej VMware

Jeśli masz czujnik usługi Defender for Identity na maszynach wirtualnych VMware, może zostać wyświetlony alert kondycji Część ruchu sieciowego nie jest analizowana. Może się to zdarzyć z powodu niezgodności konfiguracji w programie VMware.

W celu rozwiązania tego problemu:

W systemie operacyjnym gościa ustaw następujące ustawienie na Wyłączone w konfiguracji karty sieciowej maszyny wirtualnej: Odciążanie TSO IPv4.

VMware sensor issue.

Użyj następującego polecenia, aby sprawdzić, czy duże odciążanie wysyłania (LSO) jest włączone lub wyłączone:

Get-NetAdapterAdvancedProperty | Where-Object DisplayName -Match "^Large*"

Check LSO status.

Jeśli funkcja LSO jest włączona, użyj następującego polecenia, aby ją wyłączyć:

Disable-NetAdapterLso -Name {name of adapter}

Disable LSO status.

Uwaga

  • W zależności od konfiguracji te akcje mogą spowodować krótką utratę łączności sieciowej.
  • Może być konieczne ponowne uruchomienie maszyny, aby te zmiany zaczęły obowiązywać.
  • Te kroki mogą się różnić w zależności od wersji programu VMWare. Zapoznaj się z dokumentacją programu VMWare, aby uzyskać informacje na temat sposobu wyłączania funkcji LSO/TSO dla wersji programu VMWare.

Czujnik nie może pobrać poświadczeń konta usługi zarządzanej przez grupę (gMSA)

Jeśli zostanie wyświetlony następujący alert dotyczący kondycji: Poświadczenia użytkownika usług katalogowych są nieprawidłowe

Wpisy dziennika czujników:

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]

Wpisy dziennika aktualizatora czujników:

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]

Czujnik nie może pobrać hasła konta gMSA.

Przyczyna 1

Kontroler domeny nie otrzymał uprawnień do pobierania hasła konta usługi gMSA.

Rozwiązanie 1:

Sprawdź, czy komputer z uruchomionym czujnikiem otrzymał uprawnienia do pobierania hasła konta gMSA. Aby uzyskać więcej informacji, zobacz Udzielanie uprawnień do pobierania hasła konta gMSA.

Przyczyna 2

Usługa czujnika działa jako LocalService i wykonuje personifikację konta usługi katalogowej.

Jeśli zasady przypisywania praw użytkownika Log on as a service jest skonfigurowany dla tego kontrolera domeny, personifikacja nie powiedzie się, chyba że konto gMSA zostanie przyznane uprawnienie Logowanie jako usługa .

Rozwiązanie 2:

Skonfiguruj logowanie jako usługę dla kont gMSA, gdy zasady przypisywania praw użytkownika logują się jako usługa na kontrolerze domeny, którego dotyczy problem. Aby uzyskać więcej informacji, zobacz Weryfikowanie, czy konto usługi gMSA ma wymagane prawa.

Przyczyna 3

Jeśli bilet kerberos kontrolera domeny został wystawiony przed dodaniu kontrolera domeny do grupy zabezpieczeń z odpowiednimi uprawnieniami, ta grupa nie będzie częścią biletu Protokołu Kerberos. Nie może więc pobrać hasła konta gMSA.

Rozwiązanie 3:

Wykonaj jedną z następujących czynności, aby rozwiązać ten problem:

  • Uruchom ponownie kontroler domeny.

  • Przeczyść bilet protokołu Kerberos, wymuszając, aby kontroler domeny zażądał nowego biletu protokołu Kerberos. W wierszu polecenia administratora na kontrolerze domeny uruchom następujące polecenie:

    klist -li 0x3e7 purge

  • Przypisz uprawnienie do pobierania hasła gMSA do grupy, do których jest już członkiem kontrolera domeny, na przykład grupy Kontrolery domeny.

Nie można uruchomić usługi czujnika

Wpisy dziennika czujników:

Warn DirectoryServicesClient CreateLdapConnectionAsync failed to retrieve group managed service account password. [DomainControllerDnsName=DC1.CONTOSO.LOCAL Domain=contoso.local UserName=AATP_gMSA]

Przyczyna:

Kontroler domeny nie otrzymał uprawnień dostępu do hasła konta gMSA.

Rozwiązanie:

Sprawdź, czy kontroler domeny otrzymał uprawnienia dostępu do hasła. Należy mieć grupę zabezpieczeń w usłudze Active Directory, która zawiera dołączone konta komputerów z kontrolerami domeny, serwerami usług AD FS/AD CS i autonomicznymi czujnikami. Jeśli to nie istnieje, zalecamy utworzenie go.

Możesz użyć następującego polecenia, aby sprawdzić, czy do parametru dodano konto komputera lub grupę zabezpieczeń. Zastąp wartość mdiSvc01 utworzoną nazwą.

Get-ADServiceAccount mdiSvc01 -Properties PrincipalsAllowedToRetrieveManagedPassword

Wyniki powinny wyglądać następująco:

Powershell results.

W tym przykładzie widać, że dodano grupę o nazwie mdiSvc01Group . Jeśli kontroler domeny lub grupa zabezpieczeń nie została dodana, możesz dodać je za pomocą następujących poleceń. Zastąp wartość mdiSvc01 nazwą gMSA i zastąp ciąg DC1 nazwą kontrolera domeny lub mdiSvc01Group nazwą grupy zabezpieczeń.

# 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

Jeśli kontroler domeny lub grupa zabezpieczeń został już dodany, ale nadal występuje błąd, możesz spróbować wykonać następujące czynności:

  • Opcja 1. Ponowne uruchomienie serwera w celu zsynchronizowania ostatnich zmian
  • Opcja 2:
    1. Ustaw usługi AATPSensor i AATPSensorUpdater na wyłączone
    2. Zatrzymywanie usług AATPSensor i AATPSensorUpdater
    3. Buforowanie konta usługi na serwerze przy użyciu polecenia : Install-ADServiceAccount gMSA_AccountName
    4. Ustaw usługi AATPSensor i AATPSensorUpdater na Wartość Automatyczna
    5. Uruchamianie usługi AATPSensorUpdater

Odmowa dostępu do klucza rejestru "Globalny"

Nie można uruchomić usługi czujnika, a dziennik czujnika zawiera wpis podobny do:

2021-01-19 03:45:00.0000 Error RegistryKey System.UnauthorizedAccessException: Access to the registry key 'Global' is denied.

Przyczyna:

GMSA skonfigurowane dla tego kontrolera domeny lub usług AD FS / AD CS serwera nie ma uprawnień do kluczy rejestru licznika wydajności.

Rozwiązanie:

Dodaj grupę gMSA do grupy użytkownicy monitor wydajności na serwerze.

Pobieranie raportów nie może zawierać więcej niż 300 000 wpisów

Usługa Defender for Identity nie obsługuje pobierania raportów zawierających ponad 300 000 wpisów na raport. Raporty są renderowane jako niekompletne, jeśli uwzględniono więcej niż 300 000 wpisów.

Przyczyna:

Jest to ograniczenie inżynieryjne.

Rozwiązanie:

Brak znanego rozwiązania.

Czujnik nie może wyliczyć dzienników zdarzeń

Jeśli obserwujesz ograniczoną liczbę lub brak alertów zdarzeń zabezpieczeń lub działań logicznych w konsoli usługi Defender for Identity, ale nie są wyzwalane żadne problemy z kondycją.

Wpisy dziennika czujników:

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()

Przyczyna:

Lista kontroli dostępu według uznania ogranicza dostęp do wymaganych dzienników zdarzeń przez konto usługi lokalnej.

Rozwiązanie:

Upewnij się, że lista kontroli dostępu uznaniowego (DACL) zawiera następujący wpis (jest to identyfikator SID usługi AATPSensor).

(A;;0x1;;;S-1-5-80-818380073-2995186456-1411405591-3990468014-3617507088)

Sprawdź, czy lista DACL dziennika zdarzeń zabezpieczeń została skonfigurowana przez obiekt zasad grupy:

Policies > Administrative Templates > Windows Components > Event Log Service > Security > Configure log access

Dołącz wpis powyżej do istniejących zasad. Następnie uruchom polecenie C:\Windows\System32\wevtutil.exe gl security , aby sprawdzić, czy wpis został dodany.

Lokalne dzienniki usługi Defender for Identity powinny teraz być wyświetlane:

Info WindowsEventLogReader EnableEventLogWatchers EventLogWatcher enabled [name=Security]

Niepowodzenie połączenia SSL z usługą ApplyInternal zakończyło się niepowodzeniem

Jeśli podczas instalacji czujnika zostanie wyświetlony następujący błąd: AplikacjaInternal nie powiodła się dwukierunkowo połączenie SSL z usługą , a dziennik czujnika zawiera wpis podobny do:

2021-01-19 03:45:00.0000 Error CommunicationWebClient+\<SendWithRetryAsync\>d__9`1 Połączenie SSL z usługą ApplyInternal nie powiodło się. Problem może być spowodowany przez serwer proxy z włączoną inspekcją protokołu SSL. [_workspaceApplicationSensorApiEndpoint=Unspecified/contoso.atp.azure.com:443 Thumbprint=7C039DA47E81E51F3DA3DF3DA7B5E1899B5B5B4AD0]"

Przyczyna:

Problem może być spowodowany tym, że wartości rejestru SystemDefaultTlsVersions lub SchUseStrongCrypto nie są ustawione na wartość domyślną 1.

Rozwiązanie:

Sprawdź, czy wartości rejestru SystemDefaultTlsVersions i SchUseStrongCrypto są ustawione na 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

Problem z instalacją czujnika w systemie Windows Server 2019 z zainstalowanym KB5009557 lub na serwerze z uprawnieniami dziennika z wzmocnionymi zabezpieczeniami

Zainstalowanie czujnika może zakończyć się niepowodzeniem z komunikatem o błędzie:

System.UnauthorizedAccessException: Attempted to perform an unauthorized operation.

Rozwiązanie:

Istnieją dwa możliwe obejścia tego problemu:

  1. Zainstaluj czujnik za pomocą programu PSExec:

    psexec -s -i "C:\MDI\Azure ATP Sensor Setup.exe"
    
  2. Zainstaluj czujnik z zaplanowanym zadaniem skonfigurowanym do uruchamiania jako LocalSystem. Składnia wiersza polecenia do użycia jest wymieniona w instalacji dyskretnej czujnika usługi Defender for Identity.

Instalacja czujnika kończy się niepowodzeniem z powodu klienta zarządzania certyfikatami

Jeśli instalacja czujnika zakończy się niepowodzeniem, a plik Microsoft.Tri.Sensor.Deployment.Deployer.log zawiera wpis podobny do:

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)

Przyczyna:

Problem może być spowodowany tym, że klient zarządzania certyfikatami, taki jak Entrust Entelligence Security Provider (EESP), uniemożliwia instalacji czujnika utworzenie certyfikatu z podpisem własnym na maszynie.

Rozwiązanie:

Odinstaluj klienta zarządzania certyfikatami, zainstaluj czujnik usługi Defender for Identity, a następnie zainstaluj ponownie klienta zarządzania certyfikatami.

Uwaga

Certyfikat z podpisem własnym jest odnawiany co 2 lata, a proces automatycznego odnawiania może zakończyć się niepowodzeniem, jeśli klient zarządzania certyfikatami uniemożliwia utworzenie certyfikatu z podpisem własnym. Spowoduje to zatrzymanie komunikacji czujnika z zapleczem, co będzie wymagało ponownej instalacji czujnika przy użyciu obejścia wymienionego powyżej.

Instalacja czujnika kończy się niepowodzeniem z powodu problemów z łącznością sieciową

Jeśli instalacja czujnika zakończy się niepowodzeniem z kodem błędu 0x80070643, a plik dziennika instalacji zawiera wpis podobny do:

[22B8:27F0][2016-06-09T17:21:03]e000: Error 0x80070643: Failed to install MSI package.

Przyczyna:

Problem może być spowodowany tym, że proces instalacji nie może uzyskać dostępu do usług w chmurze Defender for Identity na potrzeby rejestracji czujnika.

Rozwiązanie:

Upewnij się, że czujnik może przejść do adresu *.atp.azure.com bezpośrednio lub za pośrednictwem skonfigurowanego serwera proxy. W razie potrzeby ustaw ustawienia serwera proxy dla instalacji przy użyciu wiersza polecenia:

"Azure ATP sensor Setup.exe" [ProxyUrl="http://proxy.internal.com"] [ProxyUserName="domain\proxyuser"] [ProxyUserPassword="ProxyPassword"]

Aby uzyskać więcej informacji, zobacz Uruchamianie instalacji dyskretnej z konfiguracją serwera proxy.

Nie można uruchomić usługi czujnika i pozostaje w stanie początkowym

W podglądzie zdarzeń w dzienniku systemu zostaną wyświetlone następujące błędy:

  • Procedura otwierania dla usługi ". NetFramework" w dll "C:\Windows\system32\mscoree.dll" nie powiodło się z powodu odmowy dostępu do kodu błędu. Dane wydajności dla tej usługi nie będą dostępne.
  • Procedura otwierania usługi "Lsa" w dll "C:\Windows\System32\Secur32.dll" nie powiodła się z kodem błędu Odmowa dostępu. Dane wydajności dla tej usługi nie będą dostępne.
  • Procedura otwierania usługi "WmiApRpl" w dll "C:\Windows\system32\wbem\wmiaprpl.dll" nie powiodła się z kodem błędu "Urządzenie nie jest gotowe". Dane wydajności dla tej usługi nie będą dostępne.

Plik Microsoft.TriSensorError.log będzie zawierać błąd podobny do następującego:

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

Przyczyna:

NT Service\All Services nie mają prawa do logowania się jako usługa.

Rozwiązanie:

Dodaj zasady kontrolera domeny z logowaniem jako usługą. Aby uzyskać więcej informacji, zobacz Weryfikowanie, czy konto usługi gMSA ma wymagane prawa.

Obszar roboczy nie został utworzony, ponieważ grupa zabezpieczeń o tej samej nazwie już istnieje w identyfikatorze Entra firmy Microsoft

Przyczyna:

Problem może pojawić się, gdy licencja obszaru roboczego usługi Defender for Identity wygaśnie i zostanie usunięta po zakończeniu okresu przechowywania, ale grupy firmy Microsoft Entra nie zostały usunięte.

Rozwiązanie:

  1. Przejdź do witryny Azure Portal —>Microsoft Entra ID ->Groups
  2. Zmień nazwę następujących trzech grup (gdzie workspaceName jest nazwą obszaru roboczego), dodając do nich sufiks " - old":
    • "Azure ATP workspaceName Administracja istrators" —> "Azure ATP workspaceName Administracja istrators — old"
    • "Azure ATP workspaceName Viewer" — "Azure ATP workspaceName Viewer -> old"
    • "Azure ATP workspaceName Users" —> "Azure ATP workspaceName Users - old"
  3. Następnie możesz wrócić do portalu Usługi Microsoft Defender do sekcji Ustawienia ->Identities, aby utworzyć nowy obszar roboczy dla usługi Defender for Identity.

Następne kroki