Forum Discussion
Microsoft Sentinel UEBA – AWS CloudTrail data source fails to connect with HTTP 500
Hi everyone,
I am currently testing the newer UEBA capabilities in Microsoft Sentinel through the Microsoft Defender Unified SecOps portal and I am facing an issue while trying to enable AWS CloudTrail as a UEBA data source. I wanted to share the troubleshooting steps I have already completed in case anyone has seen something similar.
1. Verified AWS CloudTrail ingestion
AWS CloudTrail is already connected to Microsoft Sentinel and the AWSCloudTrail table is receiving data normally. There is no issue with the AWS connector or the existing log ingestion.
2. Verified the CloudTrail data
I checked the CloudTrail data specifically for the events used by UEBA.
The required ConsoleLogin events are present, with:
- EventSource = signin.amazonaws.com
- UserIdentityPrincipalId populated for the majority of events
- Other relevant identity and source information available
So the source data appears to meet the documented AWS CloudTrail UEBA requirements.
3. Verified permissions
The required Microsoft Entra and Azure RBAC permissions were checked. The user also has permission to perform the Sentinel UEBA settings update.
Other UEBA data sources have already been enabled successfully from the same environment.
4. Checked resource locks and other settings
The Sentinel workspace was checked for Azure resource locks and none were found.
The UEBA anomaly detection setting is also enabled.
5. Checked the backend operation
When AWS CloudTrail is selected from the UEBA settings and I try to connect it, the operation fails with:
InternalServerError – HTTP 500
The Azure Activity Log shows the operation as:
Microsoft.SecurityInsights/settings/write
with the final status:
Failed – InternalServerError (HTTP Status Code: 500)
There is no AuthorizationFailed or RequestDisallowedByPolicy error.
6. Tested the API directly
I also checked the current UEBA configuration through the Microsoft SecurityInsights API. The GET request works and returns the existing UEBA configuration.
As an additional test, I attempted to update the same existing UEBA configuration without adding AWS CloudTrail. That update also returned HTTP 500.
This makes me think the issue may not be related specifically to AWS CloudTrail or the AWS data itself, but potentially to the UEBA settings update or backend service.
My questions
- Has anyone recently experienced UEBA settings returning HTTP 500 when updating data sources, particularly in the new Microsoft Defender/Unified SecOps portal?
- If anyone from the Microsoft Sentinel team can confirm whether there is a known issue or additional prerequisite for enabling AWS CloudTrail UEBA, that would be very helpful.
Thanks.
1 Reply
hi abeniwal73 Based on the troubleshooting you've already done, I agree that this looks less like an AWS CloudTrail ingestion or permissions issue and more like something happening when the Sentinel UEBA configuration is being updated.
The strongest clue for me is that you can read the existing UEBA configuration successfully, but even an update that doesn't involve AWS CloudTrail returns the same HTTP 500 on Microsoft.SecurityInsights/settings/write.
Since the Activity Log also shows InternalServerError rather than AuthorizationFailed or RequestDisallowedByPolicy, I'd be inclined to investigate the Sentinel/UEBA backend rather than spending more time on the AWS connector.
If you haven't already, I would capture the correlation ID, timestamp, workspace/resource ID, and the exact API request/response from one of the failed updates and provide those to Microsoft Support. Those details should give the Sentinel engineering team something concrete to trace on the backend.
It may also be worth testing the same configuration update through the API using the documented API version, just to rule out a portal-specific issue. Since you've already seen the same 500 through the API, though, that would further strengthen the case that this is service-side.
I'd be interested to hear from anyone else using the new Unified SecOps/Defender experience whether UEBA configuration updates are currently working for them. If multiple workspaces are seeing the same settings/write 500, it would certainly point toward a backend issue rather than the AWS configuration.
