M365 Oauth -> 403: Forbidden

  • Used Zammad version: 5.4.1
  • Used Zammad installation type: (source, package, docker-compose, …) package
  • Operating system: Ubuntu 22.04 LTS
  • Browser + version: chrome/firefox

Expected behavior:

I already create the app registration in azure AD, but all the time, when I press “allow” after login with global admin account (in name of organization) or just with the prepared email user, I get 403 Forbidden.

so the callback is working, but it says forbidden - Authentication required. Which step am I missing?

Hope you got any ideas, I Tried with clean browser, cookie allowed, I created the app registration again.
There is one thing I dont understand, there are 2 Steps where you can enter app configuration for M365 in Zammad.
One is a standalone M365 Options with a button “add account”/“request administrator approval”
One is under “Security” - Third party Applications - M365

pictures below, I hope anybody have an idea for me, thanks in advance!

I’d double check the permissions granted in the app registration.

For reference, here is the Zammad documentation with instructions on configuring AzureAD SSO:

https://admin-docs.zammad.org/en/latest/settings/security/third-party/microsoft.html

I’m not sure if this is relevant to your problem, but in our Zammad we have “Automatic account link on initial logon” enabled, as well:

https://admin-docs.zammad.org/en/latest/settings/security/third-party.html#automatic-account-link-on-initial-logon

Checking the AzureAD sign in log might also provide some hints to why it’s not working:

Hi spats,

thanks for your help, but still the same.

I did it like in documentation written.

I tried automatic account link in past too and its still on.

so the procedure is: Add Account in zammad O365, login works then redirect → 403: forbidden.

But I checked then cause of your advice the sign-in logs and yes there is a error which is telling callback url wouldnt match.

The {redirectTerm} ‘{replyAddress}’ specified in the request does not match the {redirectTerm}s configured for the application ‘{identifier}’. Make sure the {redirectTerm} sent in the request matches one added to your application in the Azure portal. Navigate to {akamsLink} to learn more about how to fix this. {detail}

but I tried the callback url mentioned in documentation
and the callback url which is under settings → M365 → App config
https://fqdn/api/v1/external_credentials/microsoft365/callback

and the other one I tried:
https://fqdn/auth/microsoft_office365/callback

hope you got an idea here too

But I checked then cause of your advice the sign-in logs and yes there is a error which is telling callback url wouldnt match.

Thank you for the new information, this is very helpful.

I also had this error yesterday, when setting up M365 Channel and AzureAD SSO on a new Zammad deployment.

Please check these two settings:

Setting 1: Make sure that the fully qualified domain name and HTTP type are configured in your Zammad

The problem was that my Zammad FQDN setting was still using a local IP “192.168.100.50” as the fully qualified domain, because I was using a reverse proxy I never had to change it.

But this means that Zammad was sending requests to M365 that used the FQDN “192.168.100.50” instead of “zammad.example.com” which is what I used with the Azure app registration.

After changing the FQDN and HTTP type, the M365 permission prompts started working.

https://zammad.example.com/#settings/system

Setting 2: Add redirect URL https://zammad.example.com/api/v1/external_credentials/microsoft365/callback

The AzureAD application registration requires a different callback URL for the M365 email channel than for AzureAD SSO.

I’m not sure if I’m doing it correctly. But I used the same application registration for both the M365 email channel, and for AzureAD SSO.

SSO worked with https://zammad.example.com/auth/microsoft_office365/callback

But to get M365 email channel working, I needed to also add https://zammad.example.com/api/v1/external_credentials/microsoft365/callback

Hi spats,

thanks again.

I got this settings already everything, the only difference was I got only one Secret token, makes sense to have 2 here because this are 2 different callbacks. But I tried first time using SSO with M365
then it comes 422 reject. csrf_detected

I found out, that it can be a problem in my zammad conf, Im using apache

maybe you got a working zammad.conf as example ? or here is my (xxxx is usually fqdn of course):

security - prevent information disclosure about server version

ServerTokens Prod

<VirtualHost *:80>
ServerName xxxx
Redirect permanent / https://xxxx

<VirtualHost *:443>
SSLEngine on
SSLCertificateFile /etc/apache2/sites-available/certificate.pem
SSLCertificateKeyFile /etc/apache2/sites-available/key.pem
SSLOpenSSLConfCmd DHParameters /etc/apache2/sites-available/dhparam.pem

# replace 'localhost' with your fqdn if you want to use zammad from remote
ServerName xxxx

## don't loose time with IP address lookups
HostnameLookups Off

## needed for named virtual hosts
UseCanonicalName Off

## configures the footer on server-generated documents
ServerSignature Off

ProxyRequests Off
ProxyPreserveHost On

<Proxy 127.0.0.1:3000>
  Require local
</Proxy>

RequestHeader set X_FORWARDED_PROTO ‘https’
RequestHeader set X-Forwarded-Ssl on
ProxyPass /assets !
ProxyPass /favicon.ico !
ProxyPass /apple-touch-icon.png !
ProxyPass /robots.txt !
# legacy web socket server
ProxyPass /ws ws://127.0.0.1:6042/
# action cable
ProxyPass /cable ws://127.0.0.1:3000/cable
ProxyPass / http://127.0.0.1:3000/

# change this line in an SSO setup
   RequestHeader unset X-Forwarded-User

# Use settings below if proxying does not work and you receive HTTP-Errror 404
# if you use the settings below, make sure to comment out the above two options
# This may not apply to all systems, applies to openSuse
#ProxyPass /ws ws://127.0.0.1:6042/ "retry=1 acque=3000 timeout=600 keepalive=On"
#ProxyPass /cable ws://127.0.0.1:3000/cable "retry=1 acque=3000 timeout=600 keepalive=On"
#ProxyPass / http://127.0.0.1:3000/ "retry=1 acque=3000 timeout=600 keepalive=On"

DocumentRoot "/opt/zammad/public"

<Directory />
    Options FollowSymLinks
    AllowOverride None
</Directory>

<Directory "/opt/zammad/public">
    Options FollowSymLinks
          Require all granted
</Directory>

sorry for double post.
now I got Login Success with app Zammad in Azure, but still 403:forbidden is coming up after callback to zammad.

dont get it…

Microsoft 365 login and Microsoft 365 channel are two different things and do use two different callback URLs. You have to provide both callback URLs to your app if you want to use both.

The forbidden error should then disappear.
If not, have a look in your production log which should contain more input.

Hello

and thanks to you both,

got not a lot time in the last weeks, but now I figured it out.
It was a lot easier than this.

It was own administration laziness,
the zammad application is only internal IP/DNS, so the callback works only within your browser.
I configured everywhere the fqdn (zammad.conf etc.), but I was too lazy to put it in browser. I entered only the short dns name (because dns entry works) but then it was of course a different callback url…

1 Like

Just as a sidemark. While Zammads desktop app currently allows your fqdn to mismatch as long as your webserver proxies it correctly, it’s strongly discouraged to do so.

You should use one dedicated FQDN for this. If you want to help lazy users, redirect to the correct FQDN. This should reduce confusion and will ensure that you’ll have no other roadblocks in the future. :pray:

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