Can't connect on-prem to Microsoft ADFS for SSO

On-Premise
1

I’ve setup Sentry on-prem on a VM using the standard install.sh script. My main goal ATM is to use our internal Microsoft ADFS to authenticate users.

The first issue was that I had to set “SENTRY_SINGLE_ORGANIZATION = False” in sentry.conf.py in order to have the SSO pane show up on the UI. NBD, easy change.

The second issue I ran into was that Microsoft AD requires the metadata endpoint to be a secure endpoint before it will successfully register a new organization. I struggled to get Sentry’s Nginx configured to do this and upon further research read that Sentry recommends that we setup another Nginx in front of Sentry’s to perform TLS termination/proxying. Did that, but then the SAML metadata for my organization located at https://my-sentry.domain/saml/metadata/my-org/ had a whole bunch of insecure references to the localhost (i.e. http://localhost:9000/saml/sls/my-org/ ) vs secure references with my domain name (i.e. https://my-sentry.domain/saml/sls/my-org/).

I “fixed” that by using the Nginx substitution module on the Nginx I setup in front of Sentry’s Nginx, to replace the http://localhost:9000/saml entries in the XML being returned to ADFS with https://my-sentry.domain/saml.

This made AD happy, but now when I try to Configure Active Directory from the UI for my-org it spits out an error showing the insecure http://localhost:9000/saml address:

Error details: MSIS7007: The requested relying party trust 'http://localhost:9000/saml/metadata/my-org/' is unspecified or unsupported. If a relying party trust was specified, it is possible that you do not have permission to access the trust relying party. Contact your administrator for details.

How do I configure things to where the request above to my ADFS doesn’t include http://localhost:9000?

2

It looks like the URL is pulled from a variable called system.url-prefix here - sentry/provider.py at 133f1fa37b1c83d9f53d1188d32bc1b44b22c44b · getsentry/sentry · GitHub

How should I set this?

3

I set system.url-prefix in the config.yml file and it worked. I have no idea if I broke other things doing that as this is my first install.

It sucks that wiring up on-prem to ADFS felt like an adventure/wild ride with little documentation and that I kept seeing repeated messaging in the docs and in the forums that basically said “if it’s too hard move to our cloud solution”… :frowning:

1 Like
4

Sorry that you had a bad experience. That said the root cause of most of your issues seem to be an incorrectly set configuration which is both asked at the initial setup (on the welcome screen) and is clearly documented/advertised in config files and our config documentation.

It is not possible for us to document all possible integrations and cover all the edge cases. That said your post here would probably help others in the future so we are better than where we are started :slight_smile:

If you’d like to improve the docs on ADFS integration, we’d be more than happy to assist you in the process.

5

Thanks for replying. I was just frustrated, no worries. I’d be game to put something together for the self-hosted docs. It looks like I need to fork the repo here - https://github.com/getsentry/develop/edit/master/src/docs/self-hosted/sso.mdx

Any other important things to note?

1 Like
6

Not really. It is a fairly standard Gatsby repo. Please let us know if you run into any issues getting it up and running to test locally. Feel free (please do) to checkout existing self-hosted pages/docs to mimic things there.

And finally, thanks a lot for volunteering for this. It is one thing to set things for yourself but it takes extra effort to go that extra mile to fix it for future folks :heart:

7

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.