Osquery uses basic SQL commands to leverage a relational data-model to describe a device.

osquery

Hi team - when time permits, could I have someone ping me about a SSO issue I'm running into?

Hi <@U09ERQS4H55>!  So we have two URLs we use on our Fleet server, one for SSO/UI login and one for agent connections.  We did a Fleet update recently and it looks like stricter URL validation has caused our SSO to stop working.  We've tried modifying our Okta SAML app to use multiple URLs but it defaults to trying to use the agent connection URL and times out.  I was wondering if there were any settings on the Fleet side we needed to look at when making these SAML changes.

Error (Admin is UI URL, fleetdm is agent URL):
(destination \"<https://fleetadmin.it.example.com/api/v1/fleet/sso/callback>\", requested \"<https://fleetdm.it.example.com/api/v1/fleet/sso/callback>\", acs \"<https://fleetdm.it.example.com/api/v1/fleet/sso/callback>\")

Let me do some digging and see what I can find. I'll circle back.

<@U04B12DRALB> which version of Fleet are you running?

I think this issue is due to stricter SAML validation introduced in Fleet v4.71.0, which now enforces that the SAML Assertion Consumer Service (ACS) URL and the SSO Destination match exactly. In setups with separate URLs for UI/SSO login and agent/API access, this causes SSO failures like the error you posted.

To resolve this, Fleet added the `sso_server_url` configuration option. This allows you to explicitly set a different URL for SSO (UI login) than the main `server_url` (used by agents and API). When configured, SAML requests and callbacks for SSO will use `sso_server_url`, while agents continue to use `server_url`.

Related issue: <https://github.com/fleetdm/fleet/issues/31480>

So I would set this in my fleet.yml file?

Yes, it would look something like this:

```sso_settings:
  enable_sso: true
  idp_name: Okta
  entity_id: <https://your-okta-entity-id>
  metadata: &lt;your-xml-metadata&gt;
  enable_jit_provisioning: true
  enable_sso_idp_login: true
  sso_server_url: <https://fleetadmin.it.example.com>```

You're welcome! If that doesn't work for you, let me know and we can dig deeper.

But I'm willing to bet this will solve it

Hmm looks like we're running into the same error after applying the yml config and restarting the fleet service.

sso_settings:
  enable_sso: true
  idp_name: Okta
  entity_id: fleet
  metadata_url: &lt;URL&gt;
  enable_sso_idp_login: true
  sso_server_url: <https://fleetadmin.it.example.com>

I left out the jit provisioning since I think that's a premium feature?

Oh weird. If you go to <https://fleetadmin.it.example.com/settings/organization/advanced>, do you see the correct value in _SSO server URL_?

Ah, it's blank there.  Let me populate it there and see how it goes.

That did it!  It was ignoring the yml file for some reason.

Weird. Glad that fixed it for you though!