diff --git a/content/en/getting_started/synthetics/private_location.md b/content/en/getting_started/synthetics/private_location.md index 3e2be8dac874f..ccd614a7b4567 100644 --- a/content/en/getting_started/synthetics/private_location.md +++ b/content/en/getting_started/synthetics/private_location.md @@ -4,15 +4,12 @@ further_reading: - link: 'https://www.datadoghq.com/blog/synthetic-private-location-monitoring-datadog/' tag: 'Blog' text: 'Monitor your Synthetic private locations with Datadog' - - link: '/getting_started/synthetics/api_test' - tag: 'Documentation' - text: 'Create your first API test' - - link: '/getting_started/synthetics/browser_test' - tag: 'Documentation' - text: 'Create your first browser test' - link: '/synthetics/private_locations' tag: 'Documentation' text: 'Learn more about private locations' + - link: '/synthetics/guide/kerberos-authentication/' + tag: 'Guide' + text: 'Kerberos Authentication for Synthetic Monitorings' --- ## Overview @@ -26,6 +23,7 @@ You can also use private locations to: - **Create custom locations** in mission-critical areas of your business. - **Verify the application performance in your internal testing environment** before you release new features to production with [Synthetic tests in your CI/CD pipelines][1]. - **Compare the application performance** from inside and outside your internal network. +- **[Authenticate Synthetic Monitoring tests using Kerberos SSO][16]** for internal Windows-based sites and APIs. Private locations are Docker containers or Windows services that you can install anywhere inside your private network. Retrieve the docker image on [Google Container Registry][2] or download the [Windows installer][13].**\*** @@ -117,3 +115,4 @@ Use your new private location just like a managed location in your Synthetic tes [13]: https://ddsynthetics-windows.s3.amazonaws.com/datadog-synthetics-worker-{{< synthetics-worker-version "synthetics-windows-pl" >}}.amd64.msi [14]: https://www.datadoghq.com/legal/eula/ [15]: https://www.datadoghq.com/support/ +[16]: /synthetics/guide/kerberos-authentication/ diff --git a/content/en/synthetics/browser_tests/app-that-requires-login.md b/content/en/synthetics/browser_tests/app-that-requires-login.md index d4885d0f9e663..6469cb9f791e9 100644 --- a/content/en/synthetics/browser_tests/app-that-requires-login.md +++ b/content/en/synthetics/browser_tests/app-that-requires-login.md @@ -17,11 +17,14 @@ further_reading: - link: '/synthetics/browser_tests/actions' tag: 'Documentation' text: 'Learn about browser test steps' + - link: '/synthetics/guide/kerberos-authentication/' + tag: 'Guide' + text: 'Kerberos Authentication for Synthetic Monitoring' --- ## Overview -
If you are interested in testing applications sitting behind MFA, visit the Multi-factor authentication section
+
If you are interested in testing applications sitting behind MFA, see the Multi-factor authentication section.
You may need to monitor user journeys located behind a login. There are two ways to ensure that your Datadog browser tests can go through the login steps of your application to perform validation on post-login pages: @@ -75,17 +78,19 @@ Depending on the type of MFA leveraged by your application, [JavaScript steps][6 ## Leverage browser test configuration options -The second way to ensure that your Datadog Browser tests can login into your applications is to leverage one or several of the available browser test configurations. You can indeed decide to apply: +Alternatively, you can configure your Datadog Browser Tests to authenticate using built-in browser test configuration options. You can apply the following: - Specific headers - Cookies -- Basic Auth, Digest Auth, or NTLM credentials +- Basic Auth, Digest Auth, AWS Signature, NTLM, Kerberos, or Auth 2.0 credentials + +See [authentication methods][10] for more information. These configuration options are set at every test execution and apply to every step of your browser test at execution time, not recording time. -You can manually apply these configured headers, cookies, and credentials on the page you are recording from and then record steps your test performs post-login. By default, the browser test automatically passes through authentication with your specified headers, cookies, and/or credentials at execution time and then goes through all recorded steps. +You can manually apply these headers, cookies, and credentials to the recording page, then record the steps your test performs after login. During test execution, the browser test automatically authenticates using your specified configuration and executes all recorded steps. -{{< img src="synthetics/guide/app_that_requires_login/bt_adv_options.jpg" alt="Login to your app with browser test configuration options">}} +{{< img src="synthetics/guide/app_that_requires_login/browser_test_adv_options_2.png" alt="Login to your app with browser test configuration options">}} ## Account security @@ -93,7 +98,7 @@ You can manually apply these configured headers, cookies, and credentials on the Store your credentials as [global variables][7] (for example, one global variable for username, another one for password) and select **Hide and obfuscate variable value** to hide their values from test results. You can restrict permissions on a browser test for individuals who have access to your instance of Datadog. -Once you create the obfuscated variables, you can then [import these global variables][8] into your browser tests and leverage them for your login steps. +After you create the obfuscated variables, you can then [import these global variables][8] into your browser tests and use them in your login steps. **Note:** Although Datadog global variables are securely stored and encrypted, it is strongly recommended that you use an account dedicated to testing with dummy credentials as a general testing best practice. @@ -112,3 +117,4 @@ For more information about account security, see [Synthetic Monitoring Data Secu [7]: /synthetics/settings/?tab=specifyvalue#global-variables [8]: /synthetics/browser_tests/actions#a-global-variable [9]: /data_security/synthetics +[10]: /synthetics/guide/authentication-protocols/?tab=basicaccess#authentication-methods diff --git a/content/en/synthetics/guide/_index.md b/content/en/synthetics/guide/_index.md index a1983a19816bc..cdeb7d6e277f5 100644 --- a/content/en/synthetics/guide/_index.md +++ b/content/en/synthetics/guide/_index.md @@ -17,6 +17,7 @@ cascade: {{< nextlink href="synthetics/guide/clone-test" >}}Clone your Synthetic tests{{< /nextlink >}} {{< nextlink href="synthetics/guide/otp-email-synthetics-test" >}}Extract a one-time passcode from an email body using Synthetic Browser Tests{{< /nextlink >}} {{< nextlink href="synthetics/guide/version_history" >}}Version History for Synthetic Monitoring{{< /nextlink >}} + {{< nextlink href="synthetics/guide/kerberos-authentication/" >}}Kerberos authentication for Synthetic Monitoring{{< /nextlink >}} {{< /whatsnext >}} {{< whatsnext desc="Alerting:" >}} diff --git a/content/en/synthetics/guide/authentication-protocols.md b/content/en/synthetics/guide/authentication-protocols.md index 98c21bb06ad83..dd58f119dd013 100644 --- a/content/en/synthetics/guide/authentication-protocols.md +++ b/content/en/synthetics/guide/authentication-protocols.md @@ -42,9 +42,9 @@ Click **Digest Auth** and enter a username and password. Digital access authenti [1]: /synthetics/api_tests/http_tests/ [2]: /synthetics/multistep/ {{% /tab %}} -{{% tab "OAuth 2.0" %}} +{{% tab "AWS Signature" %}} -Click **OAuth 2.0**, select a grant type (**Client Credentials** or **Resource Password**), and include an Access Token URL, Client ID, and Client Secret. Select a token API authentication method (**Send as Basic Auth header** or **Send client credentials in body**) and optionally, include an audience, resource, and scope. OAuth 2.0 authentication is supported in [HTTP tests][1] and [multistep API tests][2]. +Click **AWS Signature** and enter an Access Key ID and Secret Access Key. Optionally, enter a region, service name, and session token. AWS Signature authentication is supported in [HTTP tests][1] and [multistep API tests][2]. [1]: /synthetics/api_tests/http_tests/ [2]: /synthetics/multistep/ @@ -56,12 +56,20 @@ Click **NTLM**, enter a username and password, and optionally, a domain and work [1]: /synthetics/api_tests/http_tests/ [2]: /synthetics/multistep/ {{% /tab %}} -{{% tab "AWS Signature" %}} -Click **AWS Signature**, enter an Access Key ID and Secret Access Key, and optionally, a region, service name, and session token. AWS Signature authentication is supported in [HTTP tests][1] and [multistep API tests][2]. +{{% tab "Kerberos" %}} + +Click **Kerberos** and fill in the **Domain** field. See [Kerberos Authentication for Synthetic Monitoring][1] for more information. + +[1]: /synthetics/guide/kerberos-authentication +{{% /tab %}} +{{% tab "OAuth 2.0" %}} + +Click **OAuth 2.0**, select a grant type (**Client Credentials** or **Resource Password**), and enter an Access Token URL, Client ID, and Client Secret. Select a token API authentication method (**Send as Basic Auth header** or **Send client credentials in body**). Optionally, include an audience, resource, and scope. OAuth 2.0 authentication is supported in [HTTP tests][1] and [multistep API tests][2]. [1]: /synthetics/api_tests/http_tests/ [2]: /synthetics/multistep/ + {{% /tab %}} {{% tab "Client Certificate" %}} @@ -73,6 +81,7 @@ Certificate authentication is supported in [HTTP tests][1], [multistep API tests [3]: /synthetics/api_tests/ssl_tests/ [4]: /synthetics/api_tests/grpc_tests/ {{% /tab %}} + {{< /tabs >}} ## Account security diff --git a/content/en/synthetics/guide/kerberos-authentication.md b/content/en/synthetics/guide/kerberos-authentication.md new file mode 100644 index 0000000000000..bcc7aa525df59 --- /dev/null +++ b/content/en/synthetics/guide/kerberos-authentication.md @@ -0,0 +1,53 @@ +--- +title: Kerberos Authentication for Synthetic Monitoring + +further_reading: + - link: 'https://www.datadoghq.com/blog/synthetic-private-location-monitoring-datadog' + tag: 'Blog' + text: 'Monitor your Synthetic private locations with Datadog' + - link: '/synthetics/guide/browser-tests-passkeys' + tag: 'Guide' + text: 'Learn about Passkeys in Browser Tests' +products: +- name: Browser Tests + url: /synthetics/browser_tests/ + icon: browser +- name: API Tests + url: /synthetics/api_tests/ + icon: api +--- + +{{< product-availability names="Browser Tests,API Tests" >}} + +## Overview + +Datadog Synthetic Monitoring enables proactive monitoring of web applications and APIs using Kerberos SSO authentication with Microsoft Active Directory. This allows continuous testing of critical user journeys and HTTP endpoints on your internal Windows sites. + +## Prerequisites + +- A Windows site with Kerberos authentication integrated with Active Directory (usually hosted on IIS). +- A Windows server that is domain-joined to the Active Directory. +- A domain user account with Active Directory authentication access to the Windows site. +- Synthetic Monitoring tests must run on a Windows private location that is configured to authenticate with Active Directory. For more information, see the [Windows private locations][1] prerequisites documentation. + +## Installation + +1. Create your [Windows private location][2] on the Windows server joined to the Active Directory domain. +2. Set up the [Synthetic Monitoring private location worker][3] to run as a Windows service. +3. Configure the private location service to use your Active Directory domain account credentials: + - Open `services.msc`, navigate to **Datadog Synthetics Worker** > **Properties** > **log on** > **this account**, and enter your domain account credentials. +4. Configure your tests to run from the Windows private location (managed locations do not support Kerberos authentication). + +

No further configuration is necessary for Browser Tests.

+ +5. Optionally, for API tests, you must also set the Domain field to your Active Directory domain name under the **Kerberos** tab. Navigate to **Create/Edit API Test** > **Define Request** > **Advanced Options** > **Authentication**. + + {{< img src="synthetics/guide/kerberos-authentication/api_test_kerberos.png" alt="API Test creation with the Advanced options expanded, highlighting the Authentication tab and Kerberos authentication type" style="width:80%;" >}} + +## Further Reading + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /synthetics/platform/private_locations?tab=windows#prerequisites +[2]: /synthetics/platform/private_locations?tab=windows#create-your-private-location +[3]: /synthetics/platform/private_locations/?tab=windowsviagui#install-your-private-location \ No newline at end of file diff --git a/content/en/synthetics/platform/private_locations/_index.md b/content/en/synthetics/platform/private_locations/_index.md index 00a51f59c74b1..0fdd36acfe669 100644 --- a/content/en/synthetics/platform/private_locations/_index.md +++ b/content/en/synthetics/platform/private_locations/_index.md @@ -16,9 +16,6 @@ further_reading: - link: '/synthetics/private_locations/dimensioning' tag: 'Documentation' text: 'Dimension your Private Locations' - - link: '/synthetics/api_tests' - tag: 'Documentation' - text: 'Configure an API Test' - link: "https://www.datadoghq.com/architecture/protect-sensitive-data-with-synthetics-private-location-runners/" tag: "Architecture Center" text: "Protect Sensitive Data with Synthetics Private Location Runners" @@ -34,6 +31,7 @@ Private locations allow you to **monitor internal-facing applications or any pri * **Create custom Synthetic locations** in areas that are mission-critical to your business. * **Verify application performance in your internal CI environment** before you release new features to production with [Continuous Testing and CI/CD][28]. * **Compare application performance** from both inside and outside your internal network. +* **[Authenticate Synthetic Monitoring tests using Kerberos SSO][33]** for internal Windows-based sites and APIs. {{< img src="synthetics/private_locations/private_locations_worker_1.png" alt="Architecture diagram of how a private location works in Synthetic Monitoring" style="width:100%;">}} @@ -1062,4 +1060,5 @@ Use [granular access control][24] to limit who has access to your test based on [30]: https://github.com/DataDog/helm-charts/tree/master/charts/synthetics-private-location [31]: https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LinuxParameters.html [32]: /synthetics/platform/private_locations/configuration +[33]: /synthetics/guide/kerberos-authentication/ diff --git a/static/images/synthetics/guide/app_that_requires_login/browser_test_adv_options_2.png b/static/images/synthetics/guide/app_that_requires_login/browser_test_adv_options_2.png new file mode 100644 index 0000000000000..4ef1edb324adb Binary files /dev/null and b/static/images/synthetics/guide/app_that_requires_login/browser_test_adv_options_2.png differ diff --git a/static/images/synthetics/guide/kerberos-authentication/api_test_kerberos.png b/static/images/synthetics/guide/kerberos-authentication/api_test_kerberos.png new file mode 100644 index 0000000000000..6229e5aa9e1d0 Binary files /dev/null and b/static/images/synthetics/guide/kerberos-authentication/api_test_kerberos.png differ