From 994155c911a0b23f76ab93de71db46d8eb703889 Mon Sep 17 00:00:00 2001 From: Mike Nitsenko Date: Wed, 22 Jul 2026 02:15:39 +0500 Subject: [PATCH] docs: update xmla api connectivity setup (#11318) * upd * upd * upd --- .../visualization-tools/excel.mdx | 11 +- .../visualization-tools/powerbi.mdx | 10 +- .../docs/integrations/power-bi/index.mdx | 10 +- .../docs/integrations/power-bi/kerberos.mdx | 131 +++++++++++++----- .../docs/integrations/power-bi/ntlm.mdx | 32 +++-- .../core-data-apis/dax-api/index.mdx | 8 +- .../reference/core-data-apis/index.mdx | 5 +- .../reference/core-data-apis/mdx-api.mdx | 10 +- 8 files changed, 159 insertions(+), 58 deletions(-) diff --git a/docs-mintlify/admin/connect-to-data/visualization-tools/excel.mdx b/docs-mintlify/admin/connect-to-data/visualization-tools/excel.mdx index de19acdb8d443..0cb50a29089bf 100644 --- a/docs-mintlify/admin/connect-to-data/visualization-tools/excel.mdx +++ b/docs-mintlify/admin/connect-to-data/visualization-tools/excel.mdx @@ -42,7 +42,12 @@ and select **From Database → From Analysis Services**. Then, enter the credentials. To find your MDX API credentials, go to the [Integrations][ref-integrations-apis] page, click -**API credentials**, and choose the **MDX API** tab. +**API credentials**, and choose the **MDX API** tab. Use the full MDX API URL, including +the `/cubejs-api/v2/mdx` path, as the server name. + +The MDX API supports the same [Kerberos][ref-kerberos] and [NTLM][ref-ntlm] +authentication methods as the DAX API, configured on the **Settings → Power BI** page +of your deployment. ### Cube Cloud for Excel @@ -56,4 +61,6 @@ add-in and [authenticate][ref-cube-cloud-for-excel-authentication] to Cube Cloud [ref-cube-cloud-for-excel-installation]: /docs/integrations/microsoft-excel#installation [ref-cube-cloud-for-excel-authentication]: /docs/integrations/microsoft-excel#authentication [ref-integrations-tools]: /admin/connect-to-data/visualization-tools -[ref-integrations-apis]: /admin/connect-to-data/visualization-tools \ No newline at end of file +[ref-integrations-apis]: /admin/connect-to-data/visualization-tools +[ref-kerberos]: /docs/integrations/power-bi/kerberos +[ref-ntlm]: /docs/integrations/power-bi/ntlm \ No newline at end of file diff --git a/docs-mintlify/admin/connect-to-data/visualization-tools/powerbi.mdx b/docs-mintlify/admin/connect-to-data/visualization-tools/powerbi.mdx index 3ab232d78963c..f58bf70087fdc 100644 --- a/docs-mintlify/admin/connect-to-data/visualization-tools/powerbi.mdx +++ b/docs-mintlify/admin/connect-to-data/visualization-tools/powerbi.mdx @@ -32,11 +32,17 @@ method. In Power BI Desktop, choose the **SQL Server Analysis Services database** option when connecting to a data source. Then, enter the DAX API credentials and choose -**Windows** authentication. It accomodates both [Kerberos][ref-kerberos] and +**Windows** authentication. It accommodates both [Kerberos][ref-kerberos] and [NTLM][ref-ntlm] methods. To find your DAX API credentials, go to the [Integrations][ref-integrations-apis] page, -click **API credentials**, and choose the **DAX API** tab. +click **API credentials**, and choose the **DAX API** tab. Use the full DAX API URL, +including the `/cubejs-api/v2/dax` path, as the server name — with a bare hostname, the +client tries to reach an Analysis Services instance on TCP port 2383 and fails to +connect. + +Authentication for the DAX API — the XMLA service account, NTLM credentials, and +Kerberos assets — is configured on the **Settings → Power BI** page of your deployment. ### Authentication methods diff --git a/docs-mintlify/docs/integrations/power-bi/index.mdx b/docs-mintlify/docs/integrations/power-bi/index.mdx index 3be48f5c7540a..6b25c88a192f7 100644 --- a/docs-mintlify/docs/integrations/power-bi/index.mdx +++ b/docs-mintlify/docs/integrations/power-bi/index.mdx @@ -25,11 +25,17 @@ Cube Cloud provides the [DAX API][ref-dax-api] for the native Power BI connectiv In Power BI Desktop, choose the **SQL Server Analysis Services database** option when connecting to a data source. Then, enter the DAX API credentials and choose -**Windows** authentication. It accomodates both [Kerberos][ref-kerberos] and +**Windows** authentication. It accommodates both [Kerberos][ref-kerberos] and [NTLM][ref-ntlm] methods. To find your DAX API credentials, go to the [Integrations][ref-integrations-apis] page, -click **API credentials**, and choose the **DAX API** tab. +click **API credentials**, and choose the **DAX API** tab. Use the full DAX API URL, +including the `/cubejs-api/v2/dax` path, as the server name — with a bare hostname, the +client tries to reach an Analysis Services instance on TCP port 2383 and fails to +connect. + +Authentication for the DAX API — the XMLA service account, NTLM credentials, and +Kerberos assets — is configured on the **Settings → Power BI** page of your deployment. ### Authentication methods diff --git a/docs-mintlify/docs/integrations/power-bi/kerberos.mdx b/docs-mintlify/docs/integrations/power-bi/kerberos.mdx index ab7b952a31240..8327477173bd0 100644 --- a/docs-mintlify/docs/integrations/power-bi/kerberos.mdx +++ b/docs-mintlify/docs/integrations/power-bi/kerberos.mdx @@ -1,10 +1,10 @@ --- title: Kerberos authentication -description: "Kerberos is the most common authentication method for Windows environments. It can be used to authenticate requests to DAX API." +description: "Kerberos is the most common authentication method for Windows environments. It can be used to authenticate requests to the DAX API and MDX API." --- [Kerberos][link-kerberos] is the most common authentication method for Windows environments. -It can be used to authenticate requests to [DAX API][ref-dax-api]. +It can be used to authenticate requests to the [DAX API][ref-dax-api] and [MDX API][ref-mdx-api]. @@ -28,18 +28,25 @@ It works as follows: name](#registering-the-spn) is registered in the domain. * Once verified, the Key Distribution Center issues a Kerberos ticket for the user. * This ticket is transmitted to the DAX API in the request authorization header. -* The DAX API [decrypts and verifies](#configuring-the-deployment) the Kerberos ticket. -* Finally, the user principal name is passed for [further verification](#verifying-the-credentials). +* The DAX API [decrypts and verifies](#generating-and-uploading-the-keytab) the Kerberos ticket. +* Finally, the user principal name is [resolved to a Cube user](#provisioning-users-with-scim). ## Configuration +The **Settings → Power BI** page of your Cube deployment is the main entrypoint for +configuring XMLA authentication. It shows the XMLA endpoint and your deployment's domain, +generates `setspn` and `ktpass` command templates, stores the XMLA service account +credentials, and accepts the keytab upload. The generated commands use the XMLA service +account name — replace it with the [keytab account](#creating-the-service-accounts) +before running them. + Configuring Kerberos authentication includes the following steps: * [Obtain a Windows Server machine](#obtaining-a-windows-machine) to use during the next steps. -* [Register the service principal name](#registering-the-spn). -* [Generate a keytab](#generating-the-keytab). -* [Configure the deployment](#configuring-the-deployment) to verify Kerberos tickets. -* Optionally, [customize the authentication](#verifying-the-credentials). +* [Create the service accounts](#creating-the-service-accounts). +* [Register the SPNs](#registering-the-spn). +* [Generate and upload the keytab](#generating-and-uploading-the-keytab). +* [Set the XMLA service account](#setting-the-xmla-service-account). ### Obtaining a Windows machine @@ -53,8 +60,8 @@ on Azure, this virtual machine can be created in the `aadds-vnet` subnet. You should log in to this Windows Server machine using the account that has [AAD DC Administrators][link-aad-dc-admins] group membership. -It is also recommended to create a custom organizational unit (OU) and a new user -in this OU that will act as the service account. +It is also recommended to create a custom organizational unit (OU) for the +[service accounts](#creating-the-service-accounts). On the screenshot below, the `mdax-api-svc-account` user is created in the `MyCustomOU` OU in the `CUBE` domain: @@ -63,16 +70,26 @@ On the screenshot below, the `mdax-api-svc-account` user is created in the +### Creating the service accounts + +Create two separate accounts in your directory: + +* A **keytab account** (e.g., `mdax-api-svc-account`) that the SPNs are registered on +and the keytab is generated for. Running `ktpass` rewrites this account's user principal +name to the SPN format — this is expected, but it means the account can no longer sign +in as a regular user, so don't use it for anything else. +* An **XMLA service account** (e.g., `cube-pbi-svc-account`) that clients — for example, +the Power BI [on-premises data gateway][link-power-bi-opdg] — use to connect to Cube. + ### Registering the SPN A [service principal name][link-spn] (SPN) is a unique identifier of a service instance. Kerberos authentication uses SPNs to associate a service instance with a service sign-in account. -First, obtain your Cube Cloud deployment’s domain by going to **Settings → General** -and copying the value in the **Custom domain** section. +First, obtain your deployment’s domain from the **Settings → Power BI** page. Then, use the [`setspn` command][link-setspn] to register the Service Principal Name -for the DAX API. +for the DAX API against the keytab account. In the following example, the web service (`HTTP`) SPN on the `redundant-brohman.gcp-us-central1.cubecloudapp.dev` domain is registered for the @@ -82,7 +99,31 @@ In the following example, the web service (`HTTP`) SPN on the setspn -S HTTP/redundant-brohman.gcp-us-central1.cubecloudapp.dev CUBE\mdax-api-svc-account ``` -### Generating the keytab +If clients connect to the deployment through a different hostname (e.g., a custom +domain), register the SPN for the hostname that clients actually connect to. + +#### Load balancer SPN on AWS + +On AWS, the deployment’s domain is a CNAME record pointing to the DNS name of an AWS +load balancer. When connecting directly (without an HTTP proxy), Windows resolves the +CNAME and requests a Kerberos ticket for the load balancer hostname, so a second SPN +must be registered on the same account. Without it, clients silently fall back to +[NTLM][ref-ntlm]. GCP deployments resolve to an A record and don’t need this. + +Find the load balancer hostname and register the second SPN: + +```bash +nslookup redundant-brohman.aws-us-east-1.cubecloudapp.dev +# Name: a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6-1234567890abcdef.elb.us-east-1.amazonaws.com + +setspn -S HTTP/a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6-1234567890abcdef.elb.us-east-1.amazonaws.com CUBE\mdax-api-svc-account +``` + +The keytab doesn’t need to be regenerated — both SPNs share the keytab account’s key. +If the deployment’s load balancer is ever re-provisioned, its hostname changes and the +second SPN must be registered again. + +### Generating and uploading the keytab The [keytab][link-keytab-file] file contains information needed to decrypt the Kerberos token. @@ -94,30 +135,24 @@ prompted to enter the password for the specified user: ktpass /out kerberos.keytab /princ HTTP/redundant-brohman.gcp-us-central1.cubecloudapp.dev@CUBE.DEV /mapuser mdax-api-svc-account /crypto All /ptype KRB5_NT_PRINCIPAL /pass * ``` -Then, convert the keytab to a Base64-encoded string. For example, the following PowerShell -script will do the conversion and put the result in the clipboard: - -```ps -$Path = "C:\kerberos.keytab" -[Convert]::ToBase64String([System.IO.File]::ReadAllBytes($Path)) | Set-Clipboard -``` - -### Configuring the deployment - -Go to **Settings → Environment Variables** of your Cube Cloud deployment and set -the following environment variables to facilitate the verification of Kerberos tickets: +Then, upload the `.keytab` file on the **Settings → Power BI** page. It is stored +Base64-encoded in the `CUBE_XMLA_KRB5_KEYTAB_B64` environment variable. The +`CUBE_XMLA_SPN` and `KRB5_KTNAME` environment variables are managed by Cube +automatically and don’t need to be set. -| Environment variable | Value | -| --- | --- | -| `CUBE_XMLA_KRB5_KEYTAB_B64` | Base64-encoded keytab | -| `CUBE_XMLA_SPN` | `HTTP` | -| `KRB5_KTNAME` | `/cube/conf/kerberos.keytab` | +### Setting the XMLA service account -### Verifying the credentials +On the **Settings → Power BI** page, set the **XMLA service account** name and password. +They are stored in the `CUBE_XMLA_API_USER` and `CUBE_XMLA_API_PASSWORD` environment +variables and default to the deployment’s SQL API credentials. -By default, [`CUBEJS_SQL_USER`](/reference/configuration/environment-variables#cubejs_sql_user) and [`CUBEJS_SQL_PASSWORD`](/reference/configuration/environment-variables#cubejs_sql_password) environment variables are used -to verify the passed credentials. You can also customize the authentication by using the -[`check_sql_auth` configuration option][ref-config-check-sql-auth]. +A connection authenticated as this account is allowed to impersonate other users: when +Power BI Service passes an end user’s UPN via `EffectiveUserName`, Cube switches the +session to that user. For this to work, the value must exactly match the user name the +connection authenticates as — with Kerberos, that is the full principal in `user@REALM` +format, e.g., `cube-pbi-svc-account@CUBE.DEV`. The match is case-sensitive, so keep the +same letter case as the principal — the realm is typically uppercase. A NetBIOS format +like `CUBE\cube-pbi-svc-account` will not match. Once the deployment is ready, you can test the Kerberos authentication by [connecting from Power BI][ref-power-bi] to the DAX API. @@ -184,6 +219,26 @@ only the IdP-side mapping UI differs. In Okta, add a custom attribute on the SCI Profile Editor, then bind your source attribute to it on the Mappings tab. The value Cube receives is just a string — what you map to it is your decision. +## Troubleshooting + +* **Kerberos works through an HTTP proxy (e.g., Fiddler) but falls back to NTLM on a +direct connection.** On AWS, this means the [load balancer SPN](#load-balancer-spn-on-aws) +is missing. +* **`Unable to fetch Cloud context for XMLA user` in logs, `Access Denied` in the client.** +The Kerberos principal doesn’t resolve to a Cube user. Check that the user has a matching +[alternate username](#provisioning-users-with-scim); if the user was provisioned before +the SCIM mapping was added, force a re-sync. +* **`... is not allowed to switch to ''`.** The connection didn’t authenticate as +the [XMLA service account](#setting-the-xmla-service-account) — often because the account +is set in NetBIOS format instead of `user@REALM`, or with a different letter case. +* **Errors when connecting as the keytab account.** `ktpass` rewrites the keytab +account’s UPN, so it can no longer sign in. Connect with a +[separate XMLA service account](#creating-the-service-accounts). + +Cube always offers `Negotiate`, `NTLM`, and `Basic` authentication on the XMLA endpoints; +the NTLM fallback can’t be disabled. Check the deployment logs to see which method a +connection actually used: `method=kerberos` vs. `method=ntlm`. + [link-rsat]: https://learn.microsoft.com/en-us/troubleshoot/windows-server/system-management-components/remote-server-administration-tools [link-kdc]: https://learn.microsoft.com/en-us/windows/win32/secauthn/key-distribution-center @@ -192,8 +247,10 @@ receives is just a string — what you map to it is your decision. [link-setspn]: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc731241(v=ws.11) [link-keytab-file]: https://web.mit.edu/Kerberos/krb5-1.16/doc/basic/keytab_def.html [link-ktpass]: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ktpass -[ref-power-bi]: /admin/connect-to-data/visualization-tools/powerbi#connecting-from-power-bi +[ref-power-bi]: /admin/connect-to-data/visualization-tools/powerbi#connect-to-the-dax-api [link-kerberos]: https://en.wikipedia.org/wiki/Kerberos_(protocol)#Microsoft_Windows [ref-dax-api]: /reference/core-data-apis/dax-api -[ref-config-check-sql-auth]: /reference/configuration/config#check_sql_auth +[ref-mdx-api]: /reference/core-data-apis/mdx-api +[ref-ntlm]: /docs/integrations/power-bi/ntlm +[link-power-bi-opdg]: https://learn.microsoft.com/en-us/power-bi/connect-data/service-gateway-onprem [ref-scim]: /admin/sso/microsoft-entra-id/scim \ No newline at end of file diff --git a/docs-mintlify/docs/integrations/power-bi/ntlm.mdx b/docs-mintlify/docs/integrations/power-bi/ntlm.mdx index 31d85c6118f39..2e86310e72718 100644 --- a/docs-mintlify/docs/integrations/power-bi/ntlm.mdx +++ b/docs-mintlify/docs/integrations/power-bi/ntlm.mdx @@ -1,10 +1,10 @@ --- title: NTLM authentication -description: "NTLM is an authentication method developed by Microsoft that can be used to authenticate requests to DAX API." +description: "NTLM is an authentication method developed by Microsoft that can be used to authenticate requests to the DAX API and MDX API." --- [NTLM][link-ntlm] is an authentication method developed by Microsoft that can be used to -authenticate requests to [DAX API][ref-dax-api]. +authenticate requests to the [DAX API][ref-dax-api] and [MDX API][ref-mdx-api]. @@ -77,7 +77,9 @@ You need to have the [on-premises data gateway][link-power-bi-opdg] installed on a Windows Server machine. It should be configured to authenticate with a _master user_ account. It can be a -local user on the machine or a domain user. +local user on the machine or a domain user. Its credentials must match the [XMLA +service account](#verifying-the-credentials) configured in Cube — the user name must +match exactly, including the format and letter case (e.g., `svc-account@example.com`). The Windows machine running the gateway should be joined to the corporate Active Directory or Entra ID where your business users have their accounts. The service account running @@ -85,19 +87,27 @@ the gateway needs minimal permissions but must exist in that same directory. ### Verifying the credentials -By default, [`CUBEJS_SQL_USER`](/reference/configuration/environment-variables#cubejs_sql_user) and [`CUBEJS_SQL_PASSWORD`](/reference/configuration/environment-variables#cubejs_sql_password) environment variables are used -to verify the passed credentials. You can also customize the authentication by using the -[`check_sql_auth` configuration option][ref-config-check-sql-auth]. +NTLM connections are verified against the **XMLA service account** credentials set on +the **Settings → Power BI** page of your deployment. They are stored in the +`CUBE_XMLA_API_USER` and `CUBE_XMLA_API_PASSWORD` environment variables and default to +the deployment’s SQL API credentials. -Also, the [`CUBEJS_SQL_SUPER_USER`](/reference/configuration/environment-variables#cubejs_sql_super_user) environment variable or the [`can_switch_sql_user` -configuration option][ref-config-can-switch-sql-user] can be used to ensure that the -user name can be changed to the UPN of the interacting user only if proper credentials -of the master user account were passed. +All NTLM connections are validated against this single shared password — per-user +passwords are not supported with NTLM. Users other than the service account must exist +as Cube users. A mismatch fails with +`Authentication failed due to invalid username or password`. + +Cube changes the session user to the UPN of the interacting user only if the connection +authenticated as the XMLA service account. The UPN must resolve to a Cube user — see +[provisioning users with SCIM][ref-kerberos-scim]. The [`can_switch_sql_user` +configuration option][ref-config-can-switch-sql-user] can be used to customize this +check. [link-ntlm]: https://en.wikipedia.org/wiki/NTLM [ref-dax-api]: /reference/core-data-apis/dax-api +[ref-mdx-api]: /reference/core-data-apis/mdx-api [link-power-bi-opdg]: https://learn.microsoft.com/en-us/power-bi/connect-data/service-gateway-onprem [ref-kerberos]: /docs/integrations/power-bi/kerberos -[ref-config-check-sql-auth]: /reference/configuration/config#check_sql_auth +[ref-kerberos-scim]: /docs/integrations/power-bi/kerberos#provisioning-users-with-scim [ref-config-can-switch-sql-user]: /reference/configuration/config#can_switch_sql_user \ No newline at end of file diff --git a/docs-mintlify/reference/core-data-apis/dax-api/index.mdx b/docs-mintlify/reference/core-data-apis/dax-api/index.mdx index 3430840daddce..204ae48128c26 100644 --- a/docs-mintlify/reference/core-data-apis/dax-api/index.mdx +++ b/docs-mintlify/reference/core-data-apis/dax-api/index.mdx @@ -60,11 +60,17 @@ in the same cube or view), that would cause a conflict. ## Authentication The DAX API supports [Kerberos][ref-kerberos] and [NTLM][ref-ntlm] authentication -methods. +methods, as well as user name and password authentication. While NTLM can be used for testing purposes, we strongly recommend configuring Kerberos for production environments. +Authentication is configured on the **Settings → Power BI** page of your deployment. +It shows the XMLA endpoint URL and manages the XMLA service account credentials and +the Kerberos setup, including the keytab upload. For quick connectivity tests, you can +also enable short-lived token authentication in **Settings → Configuration**; it is +not recommended for production. + ## Data modeling diff --git a/docs-mintlify/reference/core-data-apis/index.mdx b/docs-mintlify/reference/core-data-apis/index.mdx index 3c1193ca7f31d..99126112fcc8e 100644 --- a/docs-mintlify/reference/core-data-apis/index.mdx +++ b/docs-mintlify/reference/core-data-apis/index.mdx @@ -62,8 +62,8 @@ tools][ref-viz-tools]: | Method | ✅ Supported in | | --- | --- | -| [User name and password][ref-auth-user-pass] | [DAX API][ref-dax-api]
[Semantic Layer Sync][ref-sls]
[SQL API][ref-sql-api] | -| [Kerberos][ref-auth-kerberos] and [NTLM][ref-auth-ntlm] | [DAX API][ref-dax-api] | +| [User name and password][ref-auth-user-pass] | [DAX API][ref-dax-api]
[MDX API][ref-mdx-api]
[Semantic Layer Sync][ref-sls]
[SQL API][ref-sql-api] | +| [Kerberos][ref-auth-kerberos] and [NTLM][ref-auth-ntlm] | [DAX API][ref-dax-api]
[MDX API][ref-mdx-api] | | [Identity provider][ref-auth-idp] | [Cube Cloud for Excel][ref-cube-cloud-for-excel]
[Cube Cloud for Sheets][ref-cube-cloud-for-sheets] | | [JSON Web Token][ref-auth-jwt] | [REST (JSON) API][ref-rest-api]
[GraphQL API][ref-graphql-api] | @@ -73,6 +73,7 @@ tools][ref-viz-tools]: [ref-queries]: /reference/core-data-apis/queries [ref-sql-api]: /reference/core-data-apis/sql-api [ref-dax-api]: /reference/core-data-apis/dax-api +[ref-mdx-api]: /reference/core-data-apis/mdx-api [ref-rest-api]: /reference/core-data-apis/rest-api [ref-graphql-api]: /reference/core-data-apis/graphql-api [ref-sls]: /docs/integrations/semantic-layer-sync diff --git a/docs-mintlify/reference/core-data-apis/mdx-api.mdx b/docs-mintlify/reference/core-data-apis/mdx-api.mdx index 070c28d030c6f..8df2adac6bf22 100644 --- a/docs-mintlify/reference/core-data-apis/mdx-api.mdx +++ b/docs-mintlify/reference/core-data-apis/mdx-api.mdx @@ -217,9 +217,17 @@ This is going to be harmonized in the future. ## Authentication and authorization -Authentication and authorization work the same as for the [SQL API](/reference/core-data-apis/sql-api/security). +The MDX API shares its authentication layer with the [DAX API][ref-dax-api]: +[Kerberos][ref-kerberos] and [NTLM][ref-ntlm] are supported, as well as user name and +password authentication. Configuration is done on the **Settings → Power BI** page of +your deployment — the same XMLA service account, SPN, and keytab setup applies to both +APIs. [ref-excel]: /admin/connect-to-data/visualization-tools/excel +[ref-time-dimensions]: /docs/data-modeling/dimensions#time-dimensions +[ref-dax-api]: /reference/core-data-apis/dax-api +[ref-kerberos]: /docs/integrations/power-bi/kerberos +[ref-ntlm]: /docs/integrations/power-bi/ntlm [link-mdx]: https://learn.microsoft.com/en-us/analysis-services/multidimensional-models/mdx/multidimensional-model-data-access-analysis-services-multidimensional-data?view=asallproducts-allversions#bkmk_querylang [link-pivottable]: https://support.microsoft.com/en-us/office/create-a-pivottable-to-analyze-worksheet-data-a9a84538-bfe9-40a9-a8e9-f99134456576 [ref-cube-cloud-for-excel]: /docs/integrations/microsoft-excel