Use Kerberos SSO Authentication in Synthetic Monitoring

[CMEL]

Hi community (my first post !) !

I tried to register a Synthetic monitoring on a WebAp using Kerberos Auth only.

Some considerations :

> From a Windows opened user session, I'm available to access this WebAp with my Kerberos token.

> There is no prompt for login/password (no other possibility that Kerberos, no Auth alternatives)

It looks like Synthetic Monitor can"t run that kind of Authentication.

Manually, I succeeded to log in, setting manually in cookie a "gssapi_session / MagBearerToken=xxxx" in the advanced setup of the Monitor Settings. (Token retrieved from browser debug to accessing WebAp)

But this token is only valid for some hours, so that can't be the solution to run for monitoring.

Vault doesn't seem to be the only solution, as (I think) it doesn't/can't play the Kerberos Auth.

So the idea may be to run something like "kinit" via the Vault to run the Kerveros Auth and then be able to use it in the Synthetic Monitoring.

If you have any experience, confirmaton/invalidation, suggestion ...

Thanks for your help !

CMEL

(Depending on the replies, it may be a post to recreate in "Product Ideas" ?)

(1st post ! Hope that's a good one ^_^)

[Julius_Loman]

I assume you are doing the synthetic tests from a private location, right? In the case of Synthetic ActiveGate for Windows this is achievable by running the synthetic engine as the user who has access to the Web Application.

[CMEL]

Oh, yes I'm running in private location, but I have tried for now only under Linux AG ! (running Dynatrace  Managed on-prem, forgot to say it)
I'm gonna try on Windows AG and set a service account user to try this.

> I'll let you know the result (next year now) 🙂

(But it could be also a great thing to be able to run this kind of test under Linux !)

Thx !

[Julius_Loman]

Well - I'm not sure about getting that working on Linux - but I would guess the same applies - and you have to "log in" the user which is running those synthetic tests.

@HannahM is there any recommended solution?

[HannahM]

EDIT: The information in this comment is outdated. Please see the latest solution here

Kerberos definitely prefers windows, so I would go with Julius's suggestion of trying that and logging the Dynatrace Synthetic service on as a domain user - you will need to disable auto-updates if you do that though, as the Service defaults back to the Local Service user on update. So you will need to add the extra step of resetting it to your upgrade run book. 
For Linux machines, we will likely need to add the following line/ lines (depending on what the setup) to the user.properties file in the \dynatrace\synthetic\config directory.

com.ruxit.vuc.poolConfig.playerConfig.additionalStartupParams=--auth-server-whitelist="_"

or 

com.ruxit.vuc.poolConfig.playerConfig.additionalStartupParams=--auth-server-whitelist="customerdomain"
com.ruxit.vuc.poolConfig.playerConfig.additionalStartupParams=--auth-negotiate-delegate-whitelist="customerdomain"

[CMEL]

Hello,

Thanks for the reply.

The problem is that we have hundreds of applications to check. And we can't have common user credentials to test them. So that means that we must run a dedicated ActiveGate for each credential we have to access via Kerberos ...

So, I think that we can't run our checks like this.

Do you think I can post as an "idea" to have Kerberos credentials managed for Synthetic ? I must not be alone having those security constraints.

Having in the monitoring script something like a checkbox to use a credential Vault with a Kerberos init (providing domain informations) would be perfect !

Thanks,
CMEL.

[HannahM]

For many instances just adding the credentials using HTTP Authentication is sufficient but it really depends on the set up. If you create a support ticket we can try to see if we can get it working and then you can decide if a Product Idea is required. 

[HannahM · Accepted solution]

Update to the previous changes that were used for setting this up on Linux. 
 To add the settings to your Linux ActiveGate you need to add either

com.ruxit.vuc.poolConfig.playerConfig.additionalStartupParams=--auth-server-allowlist="_"

or 

com.ruxit.vuc.poolConfig.playerConfig.additionalStartupParams=--auth-server-allowlist="customerdomain"
com.ruxit.vuc.poolConfig.playerConfig.additionalStartupParams=--auth-negotiate-delegate-allowlist="customerdomain"

to the /var/lib/dynatrace/synthetic/config/user.properties file directory, replacing customerdomain with the domain required. Then restart the vuc.service.

You may then need to  write the credentials as "USERNAME@DOMAIN" (<== All uppercase, DOMAIN in FQDN).

[patmis]

Hi,

We have a similar issue here at Swiss Post. We try to monitor Webapplications which use SSO with Kerberos (Negotiate). Our ActiveGates are also running on Linux. We have now setup a Windows server for an additianal ActiveGate. However, we would prefer Linux. 

The interesting thing is, when executing a `kinit`and then starting the Chromium browser (via X11 forwarding) on the Linux host on which the AG is installed, it works. So we are not really sure, how the ActiveGate performs the Kerberos authentication. As we configure the credentials as HTTP extension, i assume that a login window from the browser is expected. Without the `kinit` the Chromium browser does not display such a login window. In our case we are redirected to a 2FA login page. 

We have now opened a support ticket to analyse this in detail.

Kind regards,
Patrick

[HannahM · Accepted solution]

From Cluster 312 & ActiveGate 311, our Kerberos offering has been updated. 

Synthetic Browser Monitors now support Kerberos authentication for private Synthetic locations

Private Synthetic locations on Linux, Windows, and Kubernetes can now be set up to execute Browser Monitors using Kerberos as an authentication protocol.

You can learn more about configuring a Synthetic-enabled ActiveGate in the Kerberos client setup for Linux/Windows and in the Kerberos authentication configuration for containerized locations.

And how to add this in HTTP Authentication here

[patmis]

Hi everyone,

We're also facing persistent challenges in getting Kerberos SSO authentication to work reliably with our Dynatrace Synthetic Monitors, specifically with browser monitors running on private locations. We've diligently followed the official documentation, but consistently encounter the "Login procedure for Non-Kerberos-Users" screen instead of a seamless SSO experience.

This indicates that the Kerberos negotiation isn't happening as expected, or the browser environment within the Synthetic ActiveGate isn't correctly configured to participate in the Kerberos authentication process.

We're running our Private Synthetic Locations on Linux / Windows.

Here's what we've checked and what we're observing:

• Credential Vault: We have created and stored the Kerberos credentials in the Dynatrace Credential Vault, and verified their accuracy.
• Monitor Configuration:
  • For browser monitors, we've enabled "Enable global login authentication" and selected "Kerberos authentication" under Additional options.
  • We've provided the correct Domain and carefully configured the Auth server allow list, including wildcards where necessary, referencing Chrome Enterprise documentation as advised.
• ActiveGate Setup: We've followed the Kerberos client setup instructions for our Private Synthetic Locations.
  • For Linux ActiveGates: We've ensured krb5.conf is correctly configured and the necessary packages are installed. We've also added com.ruxit.vuc.poolConfig.playerConfig.additionalStartupParams=--auth-server-allowlist="_" (or specific domains) to user.properties. We've even tried kinit manually on the AG host to confirm ticket acquisition, which works.
  • For Windows ActiveGates: We've verified that the Dynatrace Synthetic service is running under a domain user account that has permissions to access the Kerberos-protected application. We're aware this requires disabling auto-updates or including a step in our upgrade runbook to reset the service user.
• Network Connectivity: Confirmed that the Private Synthetic Location has direct network connectivity to the Kerberos Key Distribution Center (KDC) and the application's authentication server.
• Firewall Rules: Verified no firewall rules are blocking Kerberos ports (UDP/TCP 88, 464) or access to the authentication server.
• Time Synchronization: Checked that the clock on the Synthetic ActiveGate is synchronized with the KDC.

Our specific challenge: The consistent presentation of the non-Kerberos login screen suggests that the Chromium browser running within the Synthetic ActiveGate environment isn't receiving or presenting the Kerberos ticket, or the target application isn't correctly initiating the Kerberos negotiation.

Has anyone successfully implemented Kerberos SSO for Synthetic Monitoring, especially in similar environments?

We're looking for insights into:

1. Common misconfigurations: Are there any subtle settings or environment variables we might be missing that are critical for Kerberos to function within the Synthetic environment?
2. Troubleshooting deeper: Beyond the basic steps, what advanced logging or diagnostics can we enable on the Synthetic ActiveGate or in Dynatrace to pinpoint where the Kerberos negotiation is failing?
3. Specific considerations for Linux/Windows ActiveGates: Are there nuances related to the OS that might impede Kerberos functionality?
4. Application-side requirements: Are there any specific configurations required on the web application's side (e.g., SPN registration, IIS/Apache settings) that might be overlooked, even if they work for interactive user logins?

Any guidance or shared experiences would be greatly appreciated. We're keen to leverage Kerberos for our synthetic monitoring for improved security and efficiency.

Thanks in advance for your help!

[Zureq]

Hello,

Thank you for the detailed checklist of the things that you have already done. As you mentioned previously, I see you checked that the kinit command seems to be working, and running Chromium via X11 forwarding also works. The Synthetic engine works pretty much the same: it runs the kinit command and runs Chromium with "--auth-server-allowlist" property. In ActiveGate 311, the parameter is passed from the monitor, so there is no need to fill it in the user.properties file, and sets the property in the "Local State" file due to a bug in Chromium (which was the main purpose of the Kerberos authentication failures).

You can verify the vuc-browser.log file

• There should be a log entry for KerberosAuthProcessRunner, eg.

  2025-01-07T12:05:30,568Z INFO [v=456284910680241739] [BM-BrowserInternalExecutorPool-2] KerberosAuthProcessRunner: kerberosAuthorization: `username: user1, password: *****, domain: E2EKERBEROS.LOCAL, authServerAllowlist: *tomcat.e2ekerberos.local*`, visitHomeDir: `/var/tmp/dynatrace/synthetic/user-home/456284910680241739`, kerberosAuthCommand: `echo {0} | kinit {1}@{2}`

• Check if the --auth-server-allowlist parameter is present when the Browser is launched, eg.

  2025-01-07T12:05:30,789Z INFO [v=456284910680241739] [BM-BrowserInternalExecutorPool-2] BrowserLauncher: /opt/dynatrace/synthetic/browser --user-data-dir=/var/tmp/dynatrace/synthetic/cache/vuc_work_4562849106802

So, if it's still not working after ensuring that everything should work and you are willing to spend some more time on it, I would advise using Wireshark to troubleshoot the Kerberos authentication because netlogs could not be sufficient.

For Windows ActiveGates

You can verify if the browser (running from %PROGRAMFILES%\dynatrace\synthetic) is properly handling the Kerberos authentication for the given page. If the username/password window pops up, please provide the username with the domain in the format username@DOMAIN or DOMAIN\username.