Udostępnij za pośrednictwem


Rozwiązywanie znanych Microsoft Defender for Identity problemów

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

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=mdiSvc01]

Przyczyna 1

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

Rozwiązanie 1:

Sprawdź, czy kontroler domeny otrzymał uprawnienia dostępu do hasła. W usłudze Active Directory powinna znajdować się grupa zabezpieczeń zawierająca kontrolery domeny, serwery Entra Connect, serwery usług AD FS/AD CS oraz konta komputerów z czujnikami autonomicznymi. Jeśli tak nie jest, zalecamy utworzenie go.

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

Get-ADServiceAccount mdiSvc01 -Properties PrincipalsAllowedToRetrieveManagedPassword

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

Wyniki programu PowerShell.

W tym przykładzie widać, że dodano grupę o nazwie mdiSvc01Group . Jeśli kontroler domeny lub grupa zabezpieczeń nie zostały dodane, możesz użyć następujących poleceń, aby go dodać. Zastąp ciąg mdiSvc01 nazwą gMSA i zastąp wartość 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ły już dodane, ale nadal występuje błąd, możesz spróbować wykonać następujące czynności:

  • Uruchom ponownie serwer, aby zsynchronizować ostatnie zmiany
  • Przeczyść bilet Protokołu Kerberos, zmuszając serwer do żądania nowego biletu protokołu Kerberos. W wierszu polecenia administratora uruchom następujące polecenie klist -li 0x3e7 purge

Przyczyna 2

Ze względu na znany scenariusz związany z inicjowaniem bezpiecznego czasu atrybut gMSA PasswordLastSet można ustawić na datę przyszłą, co powoduje, że czujnik nie może się uruchomić.

Następujące polecenie może służyć do potwierdzenia, czy konto gMSA znajduje się w scenariuszu, gdy wartości PasswordLastSet i LastLogonDate pokazują datę przyszłą:

Get-ADServiceAccount mdiSvc01 -Properties PasswordLastSet, LastLogonDate

Rozwiązanie 2:

Jako rozwiązanie pośrednie można utworzyć nową funkcję gMSA, która będzie miała poprawną datę atrybutu. Zaleca się otwarcie wniosku o pomoc techniczną z usługami katalogowymi w celu zidentyfikowania głównej przyczyny i zapoznania się z opcjami kompleksowego rozwiązania.

Błąd komunikacji z awarią czujnika

Jeśli wystąpi następujący błąd błędu 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 zablokowana dla hosta lokalnego, portu TCP 444. Aby dowiedzieć się więcej na temat Microsoft Defender for Identity wymagań wstępnych, 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 można ją znaleźć pod adresem: C:\Users\Administrator\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 jest wyświetlany 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 wdrażania:

[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 odpowiadać czujnikowi usługi Defender for Identity z błędem 401 lub 403 zamiast błędem 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 pliku *.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 jest wyświetlany jako błąd połączenia

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

Przyczyna:

Problem może być spowodowany brakiem certyfikatów 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 użyj certyfikatu "DigiCert Global Root G2" dla klientów komercyjnych lub użyj certyfikatu "DigiCert Global Root CA" dla klientów us Government GCC High, 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 .

    W dodatku:

  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 spróbujesz użyć programu PowerShell i zostanie wyświetlony następujący błąd:

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

Przyczyna:

Brak uwzględnienia 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 sieciowych czujnika usługi Defender for Identity

Podczas instalowania czujnika usługi Defender for Identity na maszynie skonfigurowanej przy użyciu karty sieciowej i sterownika Winpcap występuje błąd instalacji. Jeśli chcesz zainstalować czujnik usługi Defender for Identity na maszynie skonfigurowanej przy użyciu tworzenia zespołu kart sieciowych, upewnij się, że sterownik Winpcap został zamieniony na Npcap, postępując zgodnie z instrukcjami w tym miejscu.

Tryb grupy wielu procesorów

W systemach operacyjnych Windows 2008R2 i 2012 czujnik usługi Defender for Identity nie jest obsługiwany w trybie grupy z wieloma procesorami.

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 działa na hoście HP, możesz zmienić ustawienie BIOS optymalizacji rozmiaru grupy NUMA z domyślnego klastra na płaski.

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 dotyczący kondycji Część ruchu sieciowego nie jest analizowana. Może się to zdarzyć z powodu niezgodności konfiguracji w programie VMware.

Aby rozwiązać problem:

W systemie operacyjnym gościa ustaw wartość Wyłączone w konfiguracji karty sieciowej maszyny wirtualnej: Odciążanie logowania jednokrotnego IPv4.

Problem z czujnikiem VMware.

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

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

Sprawdź stan LSO.

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

Disable-NetAdapterLso -Name {name of adapter}

Wyłącz stan LSO.

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 o tym, jak wyłączyć funkcję 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 usługi Sensor Updater:

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

Rozdzielczość 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 Logowanie jako usługa są skonfigurowane dla tego kontrolera domeny, personifikacja kończy się niepowodzeniem, chyba że konto gMSA otrzyma uprawnienie Logowanie jako usługa .

Rozdzielczość 2:

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

Przyczyna 3

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

Rozdzielczość 3:

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

  • Uruchom ponownie kontroler domeny.

  • Przeczyść bilet Protokołu Kerberos, zmuszając kontroler domeny do żądania 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 kontroler domeny jest już członkiem, na przykład do grupy Kontrolery domeny.

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:

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

Rozwiązanie:

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

Pliki do pobrania raportów nie mogą zawierać więcej niż 300 000 wpisów

Usługa Defender for Identity nie obsługuje pobierania raportów zawierających więcej niż 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 Access Control uznaniowej ogranicza dostęp do wymaganych dzienników zdarzeń przez konto usługi lokalnej.

Rozwiązanie:

Upewnij się, że lista Access Control uznaniowej (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 powyższy wpis do istniejących zasad. Uruchom C:\Windows\System32\wevtutil.exe gl security polecenie , aby sprawdzić, czy wpis został dodany.

Teraz powinny być wyświetlane lokalne dzienniki usługi Defender for Identity:

Info WindowsEventLogReader EnableEventLogWatchers EventLogWatcher enabled [name=Security]

ApplyInternal nie powiodło się dwukierunkowe połączenie SSL z usługą

Jeśli podczas instalacji czujnika zostanie wyświetlony następujący błąd: ApplyInternal nie powiodło się dwukierunkowe 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 ApplyInternal nie powiodło się dwukierunkowe połączenie SSL z usługą. Problem może być spowodowany przez serwer proxy z włączoną inspekcją protokołu SSL. [_workspaceApplicationSensorApiEndpoint=Unspecified/contoso.atp.azure.com:443 Thumbprint=7C039DA47E81E51F3DA3DF3DA7B5E1899B5B4AD0]"

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 na Windows Server 2019 r. z zainstalowanym KB5009557 lub na serwerze z uprawnieniami do usługi EventLog ze wzmocnionymi zabezpieczeniami

Instalacja 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 przy użyciu narzędzia 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 dyskretnej instalacji czujnika defender for Identity.

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

Jeśli instalacja czujnika nie powiedzie się, 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 tworzenie 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żliwi utworzenie certyfikatu z podpisem własnym. Spowoduje to, że czujnik przestanie komunikować się z zapleczem, co będzie wymagało ponownej instalacji czujnika przy użyciu obejścia wspomnianego powyżej.

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

Jeśli instalacja czujnika nie powiedzie się 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 pliku *.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 i Instalowanie czujnika Microsoft Defender for Identity.

Ważna

Firma Microsoft zaleca użycie najbezpieczniejszego dostępnego przepływu uwierzytelniania. Przepływ uwierzytelniania opisany w tej procedurze wymaga bardzo dużego zaufania do aplikacji i niesie ze sobą ryzyko, które nie występuje w innych przepływach. Tego przepływu należy używać tylko wtedy, gdy inne bezpieczniejsze przepływy, takie jak tożsamości zarządzane, nie są opłacalne.

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

W dzienniku systemowym w przeglądarce zdarzeń zostaną wyświetlone następujące błędy:

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

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:

Usługa NT\Wszystkie usługi 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 Sprawdzanie, czy konto gMSA ma wymagane prawa.

Obszar roboczy nie został utworzony, ponieważ grupa zabezpieczeń o tej samej nazwie już istnieje w Tożsamość Microsoft Entra

Przyczyna:

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

Rozwiązanie:

  1. Przejdź do Azure Portal ->Tożsamość Microsoft Entra ->Grupy
  2. Zmień nazwę następujących trzech grup (gdzie nazwa obszaru roboczego jest nazwą obszaru roboczego), dodając do nich sufiks "- stary":
    • "Azure ATP workspaceName Administrators" —> "Azure ATP workspaceName Administrators - old"
    • "Obszar roboczy usługi Azure ATPNazwa osób przeglądających" —> "Azure ATP workspaceName Viewers - old"
    • "Azure ATP workspaceName Users" —> "Azure ATP workspaceName Users - old"
  3. Następnie możesz wrócić do portalu Microsoft Defender, do sekcji Ustawienia ->Tożsamości, aby utworzyć nowy obszar roboczy usługi Defender for Identity.

Następne kroki