Azure Advanced Threat Protection Sensor service terminated
Since applying June patches and Azure automatically updating the Azure Advanced Threat Protection Sensor, the service continues to bomb. Anyone else seeing this behavior? The Azure Advanced Threat Protection Sensor service terminated unexpectedly. It has done this 31 time(s). The following corrective action will be taken in 5000 milliseconds: Restart the service. App event Application: Microsoft.Tri.Sensor.exe Framework Version: v4.0.30319 Description: The process was terminated due to an unhandled exception. Exception Info: System.Net.Sockets.SocketException at System.Net.Sockets.Socket.EndReceive(System.IAsyncResult) at System.Net.Sockets.NetworkStream.EndRead(System.IAsyncResult) Exception Info: System.IO.IOException at System.Net.Sockets.NetworkStream.EndRead(System.IAsyncResult) at Microsoft.Tri.Infrastructure.TaskExtension.UnsafeAsyncCallback[[System.Int32, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]](System.IAsyncResult, System.Func`2<System.IAsyncResult,Int32>, Microsoft.Tri.Infrastructure.TaskCompletionSourceWithCancellation`1<Int32>) at System.Net.LazyAsyncResult.Complete(IntPtr) at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object) at System.Net.ContextAwareResult.Complete(IntPtr) at System.Net.LazyAsyncResult.ProtectedInvokeCallback(System.Object, IntPtr) at System.Net.Sockets.BaseOverlappedAsyncResult.CompletionPortCallback(UInt32, UInt32, System.Threading.NativeOverlapped*) at System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32, UInt32, System.Threading.NativeOverlapped*)Using gMSA with ATP results in many 2947 events
We have an ATP deployment with several domains and different Trusts. We have 3 different credentials in use, 2 x 'ordinary' service accounts and 1 x gMSA. On the DCs in the domain where the gMSA is hosted the "Directory Service" event logs are full of 2947 events ("An attempt to fetch the password of a group managed service account failed.") for the gMSA. The source computers for these events are computers in other domains with the ATP sensor installed. Is there any way of filtering which credentials are used by the sensors in a given domain? The deluge of 2947 events is making it difficult to find useful information in the logs of the affected DCs.Unable to access Update 3 for Microsoft Advanced Threat Analytics 1.9
Hi, Microsoft Tech Community and Ricky Simpson from Microsoft, I cannot download Update 3 for Microsoft Advanced Threat Analytics 1.9. Whenever I tried to access the download update from this article, it seemed the ID number 56725 was missing, and an error code of 404 was returned. Tried URL: https://www.microsoft.com/download/details.aspx?id=56725 Hope you can fix this problem as soon as possible, because Microsoft ATA still plays an important role in most of the enterprise network, including my company's network. Best regards for all people in the community
ATP sensor fails to start since yesterday
Hi there, we run the ATP sensor with a gMSA account on all domain controllers. Yesterday we restarted all machines because of January patch day and now the ATP sensor will get stuck while starting. Funny: there are more than 40 DC's. The service is still starting on exactly one (!) DC. It can be restarted on this DC without any issues. All others show this error. Rebooting the machines will not help. 2024-01-24 16:24:50.9788 Info RemoteImpersonationManager CreateImpersonatorInternalAsync started [UserName=mdiuser$ Domain=domain.local IsGroupManagedServiceAccount=True] 2024-01-24 16:24:51.4632 Info RemoteImpersonationManager GetGroupManagedServiceAccountTokenAsync finished [UserName=mdiuser$ Domain=domain.local IsSuccess=False] 2024-01-24 16:24:51.4632 Info RemoteImpersonationManager CreateImpersonatorInternalAsync finished [UserName=mdiuser$ Domain=domain.local] 2024-01-24 16:24:51.4632 Warn DirectoryServicesClient CreateLdapConnectionAsync failed to retrieve group managed service account password. [DomainControllerDnsName=dc03.domain.local Domain=domain.local UserName=mdiuser$ ] We have not changed anything regarding sensors or the gMSA account for months, so this configuration was running without issues until yesterday. Running Test-ADServiceAccount -Identity "mdiuser" on the affected machines gives "True", so the machine can successfully retrieve the gMSA password. I have checked that the mdiuser account is part of the GPO that allows logon as service on all machines. Now I am running out of ideas. The system tells me, it can access the gMSA password, the agent tells me it can't. Whats wrong? Best regards, IngoSensor Status - Not configured
Hi all, I've installed the sensors on each DC following the setup process. Even if there are no Health issues, the sensors status reports "Not Configured" and the healty status is marked as "Not Healthy" However, I'm receiving data and alerts about accounts in the Identities section of the Microsoft Defender portal. So everything seems to be working properly. Sensor version is: 2.239.18075.31594 Is that a glitch or do I have just to wait for it to be updated? Will the sensor and health status be updated somewhen? thanks for your supportMDI Sensor Updates options?
Hi, So far we have noticed that MDI Sensor updates can be "automatic" or "delayed". However, for our Production environment, we'd like these updates to be controlled by our team, once they have done their testing in a TEST Environment (i.e. we do not want them to be "automatic" or "delayed"). How do we therefore change the MDI Sensor update to be "manual", or via SCCM or similar? Thank you, SKMDI & gMSA config
Hi, We have followed the MDI Deployment guide from Microsoft: https://learn.microsoft.com/en-us/defender-for-identity/deploy/deploy-defender-identity We have also cross referenced this guide: https://jeffreyappel.nl/how-to-implement-defender-for-identity-and-configure-all-prerequisites/ The MDI Portal shows the gMSA account. The MDI agents are running fine and reporting to the MDI Portal. However, when we look at Services.msc on the Domain Controllers, the MDI agent runs under the security context of "Local Service" and not the gMSA account. Can anyone advise us on whether this is correct? or should we see the gMSA account in Service.msc console? And what other config may be required to make it run under the gMSA account? Thank you SK (screenshot below)
Detecting service account provisioning
Hi all I'm doing some research around the creation and enabling of old fashioned service accounts using MS Defender. I'm trying to achieve of coupe of things actually. I can detect LogonType of Service Service on MDE onboarded machines using the DeviceLogonEvents Table. But there are a few other things I would like to achieve 1.) Raise an alert when a domain account is granted the "Logon as a Service" right on any machine. 2.) When an account that has never logged on as service suddenly does so. 3.) Perhaps detect when a user account's ServicePrincipalName attribute is populayed or updated. So the service account logon query looks like this: DeviceLogonEvents | where Timestamp >= ago(30d) | where LogonType == "Service" or LogonType == "Batch" | where AccountDomain =~ "saica" | summarize count() by AccountName, DeviceName, LogonType | sort by count_ desc The other ones seem to be a bit trickier. Anyone got any ideas? I would rather not install the MMA agent every and ingest security event logs.
