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 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 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.
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
# 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>
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.
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…
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.
