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*)
Suspected identity theft (pass-the-ticket) when switching LAN/WiFI
Hi, I see this alert "Suspected identity theft (pass-the-ticket)" when a user switches from LAN to WiFi or back. The laptop's DNS record has both IP addresses. I'm guessing Defender still thinks a different device is using the same Kerberos ticket. How do you deal with that? Can you tune the alert somehow so that doesn't keep alerting? Jan 16, 2025 4:15 PM This Kerberos ticket was first observed on 1/16/25 4:15 PM on [Device Name] (Laptop IP1). Jan 16, 2025 4:57 PM - Jan 16, 2025 4:57 PM [Username] accessed [Server Name] (CIFS) from [Server IP] (Laptop IP2). Thanks for your support
Azure ATP Sensor Setup - service not starting - missing dependency
When installing Azure ATP Sensor Setup it just stalls midway and the rolls back the installation. I've looked into the logs and can see its unable to startup the service AATPSensorUpdater. I did a dependecy check and the WMI Performance Adapter (wmiApSrv) service is missing, which is a dependecy. We got 3 domain controllers, the setup only completed on one (it also got the WMI Performance Adapter (wmiApSrv) service). My question is now, how do I get the WMI Performance Adapter (wmiApSrv) service on the other 2 domain controllers so I can complete the installation? We are running virtual servers with VMware (WS2019)What's new and What's learning period in Microsoft Defender for Identity.
In this blog post, I will explain an advanced settings capability available in the Microsoft Defender for Identity, which will help the security admins in evaluating the product and tweaking the sensitivity level of the alerts. What's Learning Period in MDI? What are the latest enhancements added to that feature? https://www.linkedin.com/pulse/whats-new-learning-period-microsoft-defender-identity-elie-karkafy
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, Ingo
MDI 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)
