-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Function App for getting Office 365 Management API data into Azure Sentinel is broken #9439
Comments
Thank you for submitting an Issue to the Azure Sentinel GitHub repo! You should expect an initial response to your Issue from the team within 5 business days. Note that this response may be delayed during holiday periods. For urgent, production-affecting issues please raise a support ticket via the Azure Portal. |
Hi @PeterShiMSFT , Thanks for flagging this issue, we will investigate this issue and get back to you with some updates by 24Nov23. Thanks! . |
Sorry corrected the above comment by typo* |
Hi @PeterShiMSFT , Could you please share exact function app details,so unable to get the data connector from the above screen shot ,is it https://github.com/Azure/Azure-Sentinel/blob/master/DataConnectors/MCASActivityFunction/AzureFunctionMCASActivity/MCASActivityTimerTrigger/run.ps1? |
Yes, it's the run.ps1 |
Hi @PeterShiMSFT, thanks for your response, we will investigate this issue and get back to you by - 1 Dec 2023. |
Hi @v-muuppugund, we are still investigating this issue and also working on reproduce it. we will share update with you by - 7-12-2023. Thanks! |
Hello @v-sudkharat we also a customer facing the similar error |
Hello @v-sudkharat may I ask if there is any update? |
We are also experiencing this issue. In fact, I had encountered this a couple of months back and raised a support ticket with Microsoft at the time, however, despite my request that MS try to reproduce the issue internally to determine if the issue is with the solution rather than customer implementation and despite pointing to, what I believe "could" be the issue, the dealing engineers ignored all this and instead suggested troubleshooting steps which suggested that they didn't understand the issue. For anyone in a position to test this i.e., for anyone that can get this function app to run from their own blob container rather than the read only MS GitHub repo where this solution lives, having reviewed the run.ps1 script, I believe that the cause of the "MCASActivity-SecurityEvents: Invalid Login Endpoint Uri." error is due to the below $resource variable which in itself references a variable $managementApi, which up to that point has not actually been declared meaning that $managementApi is empty. Given that this forms part of the authentication block later on in the script, I suspect that this empty variable is causing the authentication with the Microsoft service endpoint to fail at the first hurdle. Just in case the below picture doesn't show here, this is on line 165 of the run.ps1 script. I'm think that simply adding a line before this to declare the $managementApi variable with a value of "manage.office.com" should resolve this (assuming no other issues with the function app) or this could be referenced by using a parameter in the function app called managementApi and then referencing this in run.ps1 as $env:managementApi. The below shows what the current $resource variable would return. |
Hi @PeterShiMSFT, the team is checking on this issue, which required more investigation on this. we will share update on this with you. |
[like] Sourabh Dangi (MINDTREE LIMITED) reacted to your message:
…________________________________
From: v-sudkharat ***@***.***>
Sent: Wednesday, December 13, 2023 12:56:16 PM
To: Azure/Azure-Sentinel ***@***.***>
Cc: Sourabh Dangi (MINDTREE LIMITED) ***@***.***>; Comment ***@***.***>
Subject: Re: [Azure/Azure-Sentinel] Function App for getting Office 365 Management API data into Azure Sentinel is broken (Issue #9439)
Hi @PeterShiMSFT<https://github.com/PeterShiMSFT>, the team is checking on this issue, which required more investigation on this. we will share update on this with you.
Thanks!
—
Reply to this email directly, view it on GitHub<#9439 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BD4CA2PT6IBNRZIENV272NLYJGQXBAVCNFSM6AAAAAA7U55MO2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNJTHA3DQOBYGY>.
You are receiving this because you commented.Message ID: ***@***.***>
|
Hello, We have been investigating this issue at Phoenix Software and have found a fix for this issue. We intially created a new version of the function app deploying it using a zip package through VS Code direct to the function app. Instead of using a package deployment that runs in a storage account. We reconfigured app settings on the function app to use the zip deployment instead of the package deployment. The function was failing due to lack of variables so we copied across the rest of the app settings from the original app deployment into our test. We wrote into the code some Write-Host statements for debugging. These checked the values or variables and imprinted a log entry at the time they were called. (LAURI, loginURL and managementApi) We found the script would exit as coded when calling the loginURL variable After checking that logic in the code we found that the loginEndpoint environment variable (set in the app settings) had a trailing slash. This would cause the "if" statement to fail as it didn't fit the criteria in the logic. This is poor coding practice and should be accounted for in the code for proper variable formatting and handling. We removed the trailing slash from the variable and the function started to run with no errors. The Microsoft documentation for this script includes a trailing slash in the instructions. We're not sure how this was ever meant to work. Since getting his working we have encountered timeout issues with this function due to the amount of data it is trying to gather. It is set to run every 5 minutes by default but the job takes longer than 10minutes to complete. This means you would need a premium app service plan for this function app to run on so the timeout can be increased greater than a Y1 consumption plan. Microsoft need to update the package deployment and also configure variable handling for this to work. I suggest also moving to a messaged based architecture to make it more efficient so it doesn't take so long to run. |
Hi @samcopsey-phoenix ,We are looking in to the above issues and get back to you with an updates by 21Dec23 |
Hi @samcopsey-phoenix , Its a multi tenant,while generating point authority to https://login.microsoftonline.com/common or https://login.windows.net/common or https://login.microsoftonline.com/tenantid tenant id = tanant id of the organization while generating the token |
Have you even read what I've put? It's the trailing slash nothing to do with the words exactly. I understand it's multi-tenant. |
Yes I have read gone through the thread and the original issue shared by author has https://github.com/Azure/Azure-Sentinel/blob/master/DataConnectors/MCASActivityFunction/AzureFunctionMCASActivity/MCASActivityTimerTrigger/run.ps1 the script we are using this parameters and it doesn't have any authority url. |
Hi @PeterShiMSFT ,Could you please share couple of time slots for further troubleshooting of this issue to this email id i.e. (v-muuppugund@microsoft.com),so we can have a teams meeting. |
Hi @PeterShiMSFT, Could you please check on above comment and confirm once you shared the time slots with our team. Thanks ! |
Mail sent, thank you. |
Hi @PeterShiMSFT ,As discussed over call,this issue has been fixed,we are closing your issue (#9439) as per our standard operating procedures. If you still need support for this issue, feel free to re-open at any time. Thank you for your co-operation!,please open another issue for the data. |
Describe the bug
After deploying the function app with ARM templates, there was an error "MCASActivity-SecurityEvents: Invalid Login Endpoint Uri." Such error has been reproduced in several Azure tenants, it seems to be irrelevant to the environment. Based on the run.ps1 script, it should be caused by some error in the process of determining the login endpoint of AAD.
The text was updated successfully, but these errors were encountered: