Del via


Feilsøking Microsoft Defender for identitet kjente problemer

Denne artikkelen beskriver hvordan du feilsøker kjente problemer i Microsoft Defender for identitet.

Sensortjenesten starter ikke

Sensorloggoppføringer:

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

Årsak 1

Domenekontrolleren har ikke fått rettigheter til å få tilgang til passordet for gMSA-kontoen.

Løsning 1:

Kontroller at domenekontrolleren har fått rettigheter til å få tilgang til passordet. Du bør ha en sikkerhetsgruppe i Active Directory som inneholder domenekontrolleren(e), Entra Connect, AD FS / AD CS-server(er) og frittstående sensorer, inkludert datamaskinkontoer. Hvis dette ikke finnes, anbefaler vi at du oppretter en.

Du kan bruke følgende kommando til å kontrollere om en datamaskinkonto eller sikkerhetsgruppe er lagt til i parameteren. Erstatt mdiSvc01 med navnet du opprettet.

Get-ADServiceAccount mdiSvc01 -Properties PrincipalsAllowedToRetrieveManagedPassword

Resultatene skal se slik ut:

Powershell-resultater.

I dette eksemplet kan vi se at en gruppe kalt mdiSvc01Group er lagt til. Hvis domenekontrolleren eller sikkerhetsgruppen ikke er lagt til, kan du bruke følgende kommandoer til å legge den til. Erstatt mdiSvc01 med navnet på gMSA, og erstatt DC1 med navnet på domenekontrolleren, eller mdiSvc01Group med navnet på sikkerhetsgruppen.

# 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

Hvis domenekontrolleren eller sikkerhetsgruppen allerede er lagt til, men du fremdeles ser feilen, kan du prøve følgende fremgangsmåte:

  • Start serveren på nytt for å synkronisere de siste endringene
  • Tøm Kerberos-billetten, noe som tvinger serveren til å be om en ny Kerberos-billett. Kjør følgende kommando fra en ledetekst for administrator klist -li 0x3e7 purge

Årsak 2

På grunn av et kjent scenario relatert til seeding av sikker tid, kan gMSA-attributtet PasswordLastSet settes til en fremtidig dato, noe som fører til at sensoren ikke kan starte.

Følgende kommando kan brukes til å bekrefte om gMSA-kontoen faller i scenarioet, når verdiene PasswordLastSet og LastLogonDate viser en fremtidig dato:

Get-ADServiceAccount mdiSvc01 -Properties PasswordLastSet, LastLogonDate

Løsning 2:

Som en midlertidig løsning kan det opprettes en ny gMSA som har riktig dato for attributtet. Det anbefales å åpne en støtteforespørsel med katalogtjenester for å identifisere hovedårsaken og utforske alternativer for en omfattende løsning.

Kommunikasjonsfeil for sensorfeil

Hvis du får følgende feil ved sensorfeil:

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øsning:

Kontroller at kommunikasjon ikke er blokkert for localhost, TCP-port 444. Hvis du vil vite mer om Microsoft Defender for identitet forutsetninger, kan du se porter.

Plassering av distribusjonslogg

Distribusjonsloggene for Defender for Identity er plassert i temp-katalogen til brukeren som installerte produktet. Du finner den på standard installasjonsplassering på: C:\Users\Administrator\AppData\Local\Temp (eller én mappe over %temp%). Hvis du vil ha mer informasjon, kan du se Feilsøke Defender for identitet ved hjelp av logger.

Proxy-godkjenningsproblem presenterer som en lisensieringsfeil

Hvis du får følgende feilmelding under sensorinstallasjonen: Sensoren kan ikke registreres på grunn av lisensieringsproblemer.

Oppføringer i distribusjonsloggen:

[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

Årsak:

I noen tilfeller, når du kommuniserer via en proxy, kan det under godkjenning svare på Defender for Identity-sensoren med feil 401 eller 403 i stedet for feil 407. Defender for Identity-sensoren tolker feil 401 eller 403 som et lisensieringsproblem og ikke som et proxy-godkjenningsproblem.

Løsning:

Kontroller at sensoren kan bla til *.atp.azure.com gjennom konfigurert proxy uten godkjenning. Hvis du vil ha mer informasjon, kan du se Konfigurere proxy for å aktivere kommunikasjon.

Proxy-godkjenningsproblem vises som en tilkoblingsfeil

Hvis du får følgende feilmelding under sensorinstallasjonen: Sensoren kan ikke koble til tjenesten.

Årsak:

Problemet kan oppstå når sertifikater for klarerte rotsertifiseringsinstanser som kreves av Defender for Identity, mangler.

Løsning:

Kjør følgende PowerShell-cmdlet for å bekrefte at de nødvendige sertifikatene er installert.

I eksemplet nedenfor bruker du «DigiCert Baltimore Root»-sertifikatet for alle kunder. I tillegg kan du bruke sertifikatet «DigiCert Global Root G2» for kommersielle kunder eller bruke sertifikatet «DigiCert Global Root CA» for US Government GCC High-kunder, som angitt.

# 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

Utdata for sertifikat for alle kunder:

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}

Utdata for sertifikat for kommersielle kunder-sertifikat:

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}

Utdata for sertifikat for US Government GCC High-kunder:

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}

Hvis du ikke ser forventet utdata, bruker du følgende fremgangsmåte:

  1. Last ned følgende sertifikater til Server Core-maskinen. Last ned Baltimore CyberTrust-rotsertifikatet for alle kunder.

    I tillegg:

  2. Kjør følgende PowerShell-cmdlet for å installere sertifikatet.

    # 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
    

Stille installasjonsfeil når du prøver å bruke PowerShell

Hvis du prøver å bruke PowerShell under installasjonen av stille sensor og får følgende feilmelding:

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

Årsak:

Hvis du ikke inkluderer ./-prefikset som kreves for å installere når du bruker PowerShell, forårsakes denne feilen.

Løsning:

Bruk den fullstendige kommandoen til å installere.

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

Teamingproblem for Defender for Identity Sensor NIC

Når du installerer Defender for Identity-sensoren på en maskin som er konfigurert med en NIC-teamingadapter og Winpcap-driveren, får du en installasjonsfeil. Hvis du vil installere Defender for Identity-sensoren på en maskin som er konfigurert med NIC-teaming, må du passe på at du erstatter Winpcap-driveren med Npcap ved å følge instruksjonene her.

Gruppemodus for flere prosessorer

For Windows-operativsystemer 2008R2 og 2012 støttes ikke Defender for Identity-sensoren i gruppemodus for flere prosessorer.

Foreslåtte mulige løsninger:

  • Hvis hypertråder er aktivert, deaktiverer du den. Dette kan redusere antall logiske kjerner nok til å unngå å måtte kjøre i gruppemodus for flere prosessorer .

  • Hvis maskinen har mindre enn 64 logiske kjerner og kjører på en HP-vert, kan det hende du kan endre BIOS-innstillingen for OPTIMALisering av NUMA-gruppestørrelse fra standardinnstillingen gruppert til flat.

VMware-sensorproblem for virtuell maskin

Hvis du har en Defender for Identity-sensor på virtuelle maskiner for VMware, kan det hende du får tilstandsvarselet Noe nettverkstrafikk analyseres ikke. Dette kan skje på grunn av manglende konfigurasjonskonflikt i VMware.

Slik løser du problemet:

På gjesteoperativsystemet angir du følgende til Deaktivert i den virtuelle maskinens NIC-konfigurasjon: IPv4 TSO-avlastning.

Problem med VMware-sensor.

Bruk følgende kommando for å kontrollere om stor avlastning (LSO) er aktivert eller deaktivert:

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

Kontroller LSO-status.

Hvis LSO er aktivert, kan du bruke følgende kommando til å deaktivere den:

Disable-NetAdapterLso -Name {name of adapter}

Deaktiver LSO-status.

Obs!

  • Avhengig av konfigurasjonen kan disse handlingene føre til et kort tap av nettverkstilkobling.
  • Du må kanskje starte maskinen på nytt for at disse endringene skal tre i kraft.
  • Disse trinnene kan variere avhengig av DIN VMWare-versjon. Se dokumentasjonen for VMWare for informasjon om hvordan du deaktiverer LSO/TSO for DIN VMWare-versjon.

Sensoren kan ikke hente legitimasjon for gruppeadministrert tjenestekonto (gMSA)

Hvis du får følgende tilstandsvarsel: Brukerlegitimasjon for katalogtjenester er feil

Sensorloggoppføringer:

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]

Loggoppføringer for sensoroppdatering:

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]

Sensoren kan ikke hente passordet for gMSA-kontoen.

Årsak 1

Domenekontrolleren har ikke fått tillatelse til å hente passordet for gMSA-kontoen.

Oppløsning 1:

Valider at datamaskinen som kjører sensoren, har fått tillatelse til å hente passordet for gMSA-kontoen. Hvis du vil ha mer informasjon, kan du se Gi tillatelser til å hente gMSA-kontoens passord.

Årsak 2

Sensortjenesten kjører som LocalService og utfører etterligning av katalogtjenestekontoen.

Hvis policyen Logg på som en tjeneste for brukerrettigheter er konfigurert for denne domenekontrolleren, mislykkes representasjonen med mindre gMSA-kontoen får påloggingstillatelsen som en tjeneste .

Oppløsning 2:

Konfigurer Logg på som en tjeneste for gMSA-kontoene når policyen for tilordning av brukerrettigheter logger på som en tjeneste , konfigureres på den berørte domenekontrolleren. Hvis du vil ha mer informasjon, kan du se Kontrollere at gMSA-kontoen har de nødvendige rettighetene.

Årsak 3

Hvis kerberos-billetten for domenekontrolleren ble utstedt før domenekontrolleren ble lagt til i sikkerhetsgruppen med de riktige tillatelsene, vil ikke denne gruppen være en del av Kerberos-billetten. Så den kan ikke hente passordet for gMSA-kontoen.

Oppløsning 3:

Gjør ett av følgende for å løse dette problemet:

  • Start domenekontrolleren på nytt.

  • Tøm Kerberos-billetten, noe som tvinger domenekontrolleren til å be om en ny Kerberos-billett. Kjør følgende kommando fra en administratorkommando på domenekontrolleren:

    klist -li 0x3e7 purge

  • Tilordne tillatelsen til å hente gMSAs passord til en gruppe som domenekontrolleren allerede er medlem av, for eksempel gruppen Domenekontrollere.

Ingen tilgang til registernøkkelen Global

Sensortjenesten starter ikke, og sensorloggen inneholder en oppføring som ligner på:

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

Årsak:

GMSA-en som er konfigurert for denne domenekontrolleren eller AD FS/AD CS-serveren, har ikke tillatelser til ytelsestellerens registernøkler.

Løsning:

Legg til gMSA i gruppen Brukere av ytelsesmåler på serveren.

Rapportnedlastinger kan ikke inneholde mer enn 300 000 oppføringer

Defender for Identity støtter ikke rapportnedlastinger som inneholder mer enn 300 000 oppføringer per rapport. Rapporter gjengis som ufullstendige hvis mer enn 300 000 oppføringer er inkludert.

Årsak:

Dette er en teknisk begrensning.

Løsning:

Ingen kjent oppløsning.

Sensoren lister ikke opp hendelseslogger

Hvis du observerer et begrenset antall, eller mangel på, varsler om sikkerhetshendelser eller logiske aktiviteter i Defender for Identity-konsollen, men ingen helseproblemer utløses.

Sensorloggoppføringer:

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

Årsak:

En vilkårlig Access Control liste begrenser tilgangen til de nødvendige hendelsesloggene av den lokale tjenestekontoen.

Løsning:

Sørg for at den skjønnsmessige Access Control list (DACL) inkluderer følgende oppføring (dette er SID-en til AATPSensor-tjenesten).

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

Kontroller om DACL for sikkerhetshendelsesloggen ble konfigurert av et gruppepolicyobjekt:

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

Tilføy oppføringen ovenfor til den eksisterende policyen. Kjør C:\Windows\System32\wevtutil.exe gl security etterpå for å bekrefte at oppføringen ble lagt til.

Den lokale Defender for Identitet-loggen skal nå vises:

Info WindowsEventLogReader EnableEventLogWatchers EventLogWatcher enabled [name=Security]

ApplyInternal mislyktes toveis SSL-tilkobling til tjenestefeil

Hvis du får følgende feilmelding under sensorinstallasjonen: ApplyInternal mislyktes toveis SSL-tilkobling til tjenesten , og sensorloggen inneholder en oppføring som ligner på:

2021-01-19 03:45:00.0000 Error CommunicationWebClient+\<SendWithRetryAsync\>d__9`1 ApplyInternal mislyktes toveis SSL-tilkobling til tjenesten. Problemet kan skyldes en proxy med SSL-inspeksjon aktivert. [_workspaceApplicationSensorApiEndpoint=Uspesifisert/contoso.atp.azure.com:443 Thumbprint=7C039DA47E81E51F3DA3DF3DA7B5E1899B5B4AD0]'

Årsak:

Problemet kan oppstå når registerverdiene SystemDefaultTlsVersions eller SchUseStrongCrypto ikke er satt til standardverdien 1.

Løsning:

Kontroller at registerverdiene SystemDefaultTlsVersions og SchUseStrongCrypto er satt til 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 med å installere sensoren på Windows Server 2019 med KB5009557 installert, eller på en server med herdede EventLog-tillatelser

Installasjon av sensoren kan mislykkes med feilmeldingen:

System.UnauthorizedAccessException: Attempted to perform an unauthorized operation.

Løsning:

Det finnes to mulige løsninger for dette problemet:

  1. Installer sensoren med PSExec:

    psexec -s -i "C:\MDI\Azure ATP Sensor Setup.exe"
    
  2. Installer sensoren med en planlagt oppgave konfigurert til å kjøre som LocalSystem. Kommandolinjesyntaksen som skal brukes, nevnes i Defender for identity sensor stille installasjon.

Sensorinstallasjonen mislykkes på grunn av sertifikatbehandlingsklienten

Hvis sensorinstallasjonen mislykkes, og den Microsoft.Tri.Sensor.Deployment.Deployer.log filen inneholder en oppføring som ligner på:

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)

Årsak:

Problemet kan oppstå når en sertifikatbehandlingsklient, for eksempel Entrust Entelligence Security Provider (EESP), hindrer sensorinstallasjonen i å opprette et selvsignert sertifikat på maskinen.

Løsning:

Avinstaller sertifikatbehandlingsklienten, installer Defender for Identity-sensoren, og installer deretter sertifikatbehandlingsklienten på nytt.

Obs!

Det selvsignerte sertifikatet fornyes hvert 2. år, og prosessen for automatisk fornyelse kan mislykkes hvis sertifikatbehandlingsklienten hindrer selvsignert sertifikatoppretting. Dette vil føre til at sensoren slutter å kommunisere med serverdel, noe som krever en sensorinstallasjon ved hjelp av den midlertidige løsningen nevnt ovenfor.

Sensorinstallasjonen mislykkes på grunn av problemer med nettverkstilkoblingen

Hvis sensorinstallasjonen mislykkes med en feilkode for 0x80070643, og installasjonsloggfilen inneholder en oppføring som ligner på:

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

Årsak:

Problemet kan oppstå når installasjonsprosessen ikke får tilgang til Cloud Services i Defender for Identity for sensorregistreringen.

Løsning:

Kontroller at sensoren kan bla til *.atp.azure.com direkte eller gjennom konfigurert proxy. Angi om nødvendig innstillingene for proxy-serveren for installasjonen ved hjelp av kommandolinjen:

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

Hvis du vil ha mer informasjon, kan du se Kjøre en stille installasjon med en proxy-konfigurasjon og installere Microsoft Defender for identitet-sensoren.

Viktig

Microsoft anbefaler at du bruker den sikreste godkjenningsflyten som er tilgjengelig. Godkjenningsflyten som er beskrevet i denne prosedyren, krever en svært høy grad av tillit til programmet, og medfører risikoer som ikke finnes i andre flyter. Du bør bare bruke denne flyten når andre sikrere flyter, for eksempel administrerte identiteter, ikke er levedyktige.

Sensortjenesten kan ikke kjøres og forblir i starttilstand

Følgende feil vises i systemloggen i hendelsesvisningsprogrammet:

  • Åpne-prosedyren for tjenesten . NETFramework i DLL-filen C:\Windows\system32\mscoree.dll mislyktes med feilkodetilgang. Ytelsesdata for denne tjenesten vil ikke være tilgjengelige.
  • Åpne-prosedyren for tjenesten Lsa i DLL-filen C:\Windows\System32\Secur32.dll mislyktes med feilkodetilgang. Ytelsesdata for denne tjenesten vil ikke være tilgjengelige.
  • Open-prosedyren for tjenesten WmiApRpl i DLL-filen C:\Windows\system32\wbem\wmiaprpl.dll mislyktes med feilkoden «Enheten er ikke klar». Ytelsesdata for denne tjenesten vil ikke være tilgjengelige.

Den Microsoft.TriSensorError.log inneholder en feil som ligner på dette:

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

Årsak:

NT Service\Alle tjenester har ikke rett til å logge på som en tjeneste.

Løsning:

Legg til policy for domenekontroller med påloggingen som en tjeneste. Hvis du vil ha mer informasjon, kan du se Kontrollere at gMSA-kontoen har de nødvendige rettighetene.

Arbeidsområdet ble ikke opprettet fordi det allerede finnes en sikkerhetsgruppe med samme navn i Microsoft Entra ID

Årsak:

Problemet kan oppstå når en defender for identitetsområdelisens utløper og slettes når oppbevaringsperioden er avsluttet, men Microsoft Entra grupper ikke ble slettet.

Løsning:

  1. Gå til Azure Portal ->Microsoft Entra ID ->Grupper
  2. Gi nytt navn til følgende tre grupper (der workspaceName er navnet på arbeidsområdet), ved å legge til et suffiks av typen " - old":
    • "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»
  3. Deretter kan du gå tilbake i Microsoft Defender-portalen, til Innstillinger -Identiteter-delen> for å opprette det nye arbeidsområdet for Defender for Identity.

Neste trinn