search

Azure / Azure-Sentinel

Cloud-native SIEM for intelligent security analytics for your entire enterprise.
https://azure.microsoft.com/en-us/services/azure-sentinel/
MIT License
4.5k stars 2.96k forks source link

Cannot enable Microsoft XDR connector either by ARM/CLI - License is invalid #9986

Closed Kaloszer closed 6 months ago

Kaloszer commented 6 months ago

Describe the bug Unable to enable Microsoft 365 XDR Connector using either the ARM template or CLI - getting License is invalid

Even though all the requirements are met: E5 License is on the target tenant User Assigned Managed Identity with Security Admin permissions / Contrib on workspace - within the target tenant is used to enable said connector Initial Microsoft XDR connector is installed (but not enabled)

This can be enabled by pressing the button in GUI, but not with code/az CLI (not there)/ Az.SecurityInsights module (there, but not working)

To Reproduce Steps to reproduce the behavior:

  1. Create a new sentinel subscription/instance/rg
  2. Enable E5 license on a user account
  3. Execute 
    
New-AzSentinelDataConnector -SubscriptionId subid -ResourceGroupName rgname -WorkspaceName wkname -Kind MicrosoftThreatProtection -Incident 'enabled'


**Expected behavior**
Microsoft Threat Protection (XDR Defender) connector is enabled with Incidents/Alerts : enabled

**Screenshots**
<img width="516" alt="image" src="https://github.com/Azure/Azure-Sentinel/assets/62133917/3b2e5e43-06e0-4015-af59-e850e624422c">

**Additional context**
This does not seem to be an isolated issue - because the same happens when I try to enable it using an ARM template. **Manually enabling it IS NOT A FIX.** This is preventing IaC to be 100% automatic.

To note, when it had been enabled at least once manually in the workspace - this will work! So it seems that there's some other api calls being made when you press that GUI button that is missing in the first place.
v-sudkharat commented 6 months ago

Hi @Kaloszer, Thanks for flagging this issue, we will investigate this issue and get back to you with some updates by 28-02-2024 . Thanks!

Kaloszer commented 6 months ago

@v-sudkharat Any update?

AnthonyTayar commented 6 months ago

I don't have the license error @Kaloszer has but I do agree that:

To note, when it had been enabled at least once manually in the workspace - this will work! So it seems that there's some other api calls being made when you press that GUI button that is missing in the first place.

Using ARM template it will not behave as it should but that could be I'm doing it wrong (If I'm not connecting MDE, MDI or other, for some reason XDR does not want to connect using the template) and using the following command: New-AzSentinelDataConnector -SubscriptionId subid -ResourceGroupName rgname -WorkspaceName wkname -Kind MicrosoftThreatProtection -Incident 'enabled'

Will only connect XDR connector, not MDE or MDI and other related connectors

Kaloszer commented 6 months ago

@v-sudkharat Any update?

v-sudkharat commented 6 months ago

Hi @Kaloszer, Could you please check with below command and make sure you should be compliance with below highlighted pre-requisite permissions- New-AzSentinelDataConnector -ResourceGroupName rgname -WorkspaceName wkname -kind MicrosoftThreatProtection -TenantId YourTenantId -Incident Enabled

image

Thanks!

Kaloszer commented 6 months ago

@v-sudkharat

This is all already mentioned in the bug. Every prereq is met.

**Even though all the requirements are met:

Initial Microsoft XDR connector is installed (but not enabled) -> User Assigned Managed Identity with Security Administrator permissions / Contrib on workspace - within the target tenant is used to enable said connector ( Connector Access Control + Workspace read and write permissions + Tenant Permissions) -> E5 License is on the target tenant ( License requirement )**

Read the additional context:

This does not seem to be an isolated issue - because the same happens when I try to enable it using an ARM template. Manually enabling it IS NOT A FIX. This is preventing IaC to be 100% automatic.

To note, when it had been enabled at least once manually in the workspace - this will work! So it seems that there's some other api calls being made when you press that GUI button that is missing in the first place.

As we're actively onboarding customers we can't reliably wait for response when the issue presents itself, and we have to go the manual route but I assure you, it exists.

v-sudkharat commented 6 months ago

@Kaloszer, have you checked with this below cmd? - New-AzSentinelDataConnector -ResourceGroupName rgname -WorkspaceName wkname -kind MicrosoftThreatProtection -TenantId YourTenantId -Incident Enabled

Thanks!

Kaloszer commented 6 months ago

@Kaloszer, have you checked with this below cmd? - New-AzSentinelDataConnector -ResourceGroupName rgname -WorkspaceName wkname -kind MicrosoftThreatProtection -TenantId YourTenantId -Incident Enabled

Thanks!

Ah I see! So there's the difference that there is no SubId but the TenantId. No but I'll change it in my code so when I have a new customer I can check if it works :). It might take a while to test though :/.

v-sudkharat commented 6 months ago

@Kaloszer, Please let us know if your issue get resolve. Thanks!

v-sudkharat commented 6 months ago

Hi @Kaloszer, Any update on this? Thanks!

Kaloszer commented 6 months ago

Hey @v-sudkharat I don't think we'll have a new customer that I can validate this on in the near future so we might want to close this/ and I'll re-open if this is an issue then.

v-sudkharat commented 6 months ago

@Kaloszer, Noted. Closing this issue. If you still need support for this issue, feel free to re-open it any time. Thank you for your co-operation.

Kaloszer commented 5 months ago

@v-sudkharat

Unfortunately this did not fix the issue, still seeing the same issue :( - can you re-open this case?

image



              $defenderXDR = Get-AzSentinelDataConnector -SubscriptionId <<subId>> -ResourceGroupName <<rgname>> -WorkspaceName <<workspaceName>> | Where-object {$_.Kind -eq 'MicrosoftThreatProtection'}
              if ($defenderXDR -eq $null) {
                Write-Verbose -Verbose "Defender XDR not found! Trying to create one!"
                try {
                    New-AzSentinelDataConnector -TenantId <<tenantId>> -ResourceGroupName <<rgname>> -WorkspaceName <<workspaceName>> -Kind MicrosoftThreatProtection -Incident 'enabled'
                } catch {
                  Write-Error -ErrorAction Stop "Failed to create Defender XDR!"
                  exit 1
                }
                exit 0
              } else {
                Write-Verbose -Verbose "Defender XDR found! Updating!"
              }
              $defenderXDRId = $defenderXDR.id.split("/")[-1]
              Write-Verbose -Verbose "Enabling Defender XDR!"
              Update-AzSentinelDataConnector -Id $defenderXDRId -ResourceGroupName <<rgname>> -WorkspaceName <<workspaceName>> -TenantId <<tenantId>> -MicrosoftThreatProtection -Incident 'enabled'
v-sudkharat commented 5 months ago

Hey @Kaloszer, Could you please raise a support ticket for this issue, so our support team can look into it and if required they can forward this issue to respective team. Thanks!

Kaloszer commented 5 months ago

@v-sudkharat Sure, I opened 2404180050001474 - it's in a different tenant (MSSP primary) than the issue is in but as mentioned we won't be able to keep it 'in the error' state as we need to continue with service and theres a manual workaround.

liam-stevenson commented 5 months ago

In case its useful to anyone troubleshooting/reading this; we've been getting this error when we come across customers upgrading from Business Premium to a license that entitles them to Defender for Endpoint (like E5). The manual installation is a work around but defeats the point of infrastructure as code entirely.

Kaloszer commented 5 months ago

@liam-stevenson - in our experience it does not matter what state the environment is in, as long as a particular 'button' to enable XDR was never pressed ( not even in the same workspace ) this happens.

So it goes back to my idea of some API being called in the back which we can't see.

Kaloszer commented 4 months ago

@liam-stevenson @AnthonyTayar

According to support, 'this is not supported'

We have discussed this with Senior technical leads and TA's
There is no method as of now to enable the XDR connector. So it will work only for a few connectors and XDR is not one of them.
For now we wont be able to help you out with the issue,

It can only be done for the connectors given in this request api list
https://learn.microsoft.com/en-us/rest/api/securityinsights/data-connectors/create-or-update?view=rest-securityinsights-2024-03-01&tabs=HTTP#request-body

This feels like a joke, why would it not be supported? It's in the docs so it should be supported:

https://learn.microsoft.com/en-us/azure/templates/microsoft.securityinsights/dataconnectors?pivots=deployment-language-bicep#:~:text=For%20MicrosoftThreatProtection%2C%20use,%27string%27%0A%20%20%7D

Do you guys have any channels to actually get this addressed?

AnthonyTayar commented 4 months ago

hey @Kaloszer

I strongly disagree with this statement as I managed to do it but you have to "simulate" what's being done when pressing the enable button by adding the enabled state properties for all connectors that should being enable. and by combining with the poweshell script available here https://github.com/Azure/Azure-Sentinel/blob/master/Tools/Sentinel-All-In-One/v2/Scripts/Create-NewSolutionAndRulesFromList.ps1 for remaining data connectors not available within Microsoft.SecurityInsights/dataConnectors@2023-02-01-preview'

resource xdr 'Microsoft.SecurityInsights/dataConnectors@2023-02-01-preview' = if (contains(dataConnectorsKind, 'Microsoft Defender XDR')) {
  name: xdrName
  scope: workspace
  kind: 'MicrosoftThreatProtection'
  properties: {
    dataTypes: {
      alerts: {
        state: 'enabled'
      }
      incidents: {
        state: 'enabled'
      }
    }
    tenantId: tenantId
  }
}

resource mdi 'Microsoft.SecurityInsights/dataConnectors@2023-02-01-preview' = if (contains(dataConnectorsKind, 'Microsoft Defender XDR')) {
  name: mdiName
  scope: workspace
  kind: 'AzureAdvancedThreatProtection'
  properties: {
    dataTypes: {
      alerts: {
        state: 'enabled'
      }
    }
    tenantId: tenantId
  }
}

resource mde 'Microsoft.SecurityInsights/dataConnectors@2023-02-01-preview' = if (contains(dataConnectorsKind, 'Microsoft Defender XDR')) {
  name: mdeName
  scope: workspace
  kind: 'MicrosoftDefenderAdvancedThreatProtection'
  properties: {
    dataTypes: {
      alerts: {
        state: 'enabled'
      }
    }
    tenantId: tenantId
  }

There are also discord you can use: Community Server invite link: https://discord.gg/r22F4A5g2c Official Microsoft Discord server: https://aka.ms/community-discord

cheers!

Kaloszer commented 4 months ago

hey @Kaloszer

I strongly disagree with this statement as I managed to do it but you have to "simulate" what's being done when pressing the enable button by adding the enabled state properties for all connectors that should being enable. and by combining with the poweshell script available here https://github.com/Azure/Azure-Sentinel/blob/master/Tools/Sentinel-All-In-One/v2/Scripts/Create-NewSolutionAndRulesFromList.ps1 for remaining data connectors not available within Microsoft.SecurityInsights/dataConnectors@2023-02-01-preview'

resource xdr 'Microsoft.SecurityInsights/dataConnectors@2023-02-01-preview' = if (contains(dataConnectorsKind, 'Microsoft Defender XDR')) {
  name: xdrName
  scope: workspace
  kind: 'MicrosoftThreatProtection'
  properties: {
    dataTypes: {
      alerts: {
        state: 'enabled'
      }
      incidents: {
        state: 'enabled'
      }
    }
    tenantId: tenantId
  }
}

resource mdi 'Microsoft.SecurityInsights/dataConnectors@2023-02-01-preview' = if (contains(dataConnectorsKind, 'Microsoft Defender XDR')) {
  name: mdiName
  scope: workspace
  kind: 'AzureAdvancedThreatProtection'
  properties: {
    dataTypes: {
      alerts: {
        state: 'enabled'
      }
    }
    tenantId: tenantId
  }
}

resource mde 'Microsoft.SecurityInsights/dataConnectors@2023-02-01-preview' = if (contains(dataConnectorsKind, 'Microsoft Defender XDR')) {
  name: mdeName
  scope: workspace
  kind: 'MicrosoftDefenderAdvancedThreatProtection'
  properties: {
    dataTypes: {
      alerts: {
        state: 'enabled'
      }
    }
    tenantId: tenantId
  }

There are also discord you can use: Community Server invite link: https://discord.gg/r22F4A5g2c Official Microsoft Discord server: https://aka.ms/community-discord

cheers!

That was my argument as well. Which fell on deaf ears 😭

Kaloszer commented 4 months ago

@AnthonyTayar - well tried it just now on a new workspace - no difference 😫 image

fujiant commented 4 months ago

We have the same issue, just dropping this comment in here to keep this discussion alive.

AnthonyTayar commented 3 months ago

Hey @Kaloszer, sorry I was OoO :)

I never faced that issue internally nor at customers (yet)

Maybe a dumb question but did you double check the subscription you are working with? Alongside permissions of the user

I am always working with global admin permissions personally, because the solution I created required so many different kind of access that's it is easier and endup the same

You can also contact me on discord also (Akiranai)

Kaloszer commented 3 months ago

@AnthonyTayar Yeah - it doesn't matter if you're GA or whatever. Got some feedback from someone internal at MSFT:

When deploying Microsoft Sentinel for the first time in a tenant, it won’t work without clicking the “Connect” button due to necessary consent. If the connection has already occurred once in the tenant, it should function properly.

But we're trying to get this addressed so we'll see if I can get some feedback on if they plan to fix it and when ;).

Sannadiana commented 2 months ago

Hi,

I have received the input below from @f-bader testing, where we are both struggling with the same issue: The Defender XDR Data Connector seems to have a requirement of clicking the User Interface to trigger an API call to the security graph, which cannot be done as using application-based permissions and get aztoken based bearer tokens will not be accepted because there is no trust between the two apps ( cloud shell and security API).

Best regards

Kaloszer commented 2 months ago

Hi,

I have received the input below from @f-bader testing, where we are both struggling with the same issue: The Defender XDR Data Connector seems to have a requirement of clicking the User Interface to trigger an API call to the security graph, which cannot be done as using application-based permissions and get aztoken based bearer tokens will not be accepted because there is no trust between the two apps ( cloud shell and security API).

Best regards

clickOps - not acceptable