Add account in Channels / MS 365, connects to email account
Actual behavior:
Requests admin permissions when adding account. Admin consent has been granted multiple times.
Steps to reproduce the behavior:
Any ‘add account’ action from MS 365. Have tried multiple times.
Setup detail:
I’ve tried re-using the App existing registration from the Settings / Third Party Applications (this was working in 3.5, and continues to work now). I’ve also tried setting up a new registration just for the email access purposes as per https://admin-docs.zammad.org/en/latest/channels/microsoft365/accounts/register-app.html
Both give the same response - when I log into the user account to connect the email, it asks for consent before it will proceed. Even if consent it given, it just requests it again next time I attempt to link to the mail account.
If I connect to the admin account email then it seems to connect the account, but I can’t actually get to the inbox (or any) folder (though, in it’s defence here I can’t connect to that in outlook either yet, I’ve only just assigned the account a mailbox)
I’ve tried my normal user account and the specific account set up for the zammad emails, and get the same result with either - consent is still required.
There is a difference in the ‘create a secret’ step in the MS portal now compared to the guide in readtheDocs - there’s a value and an ID for the secret. Using this ID and value as client ID and secret in Zammad doesn’t work (we get an error sooner in the process then), only using the ID for the app as shown in the guide, then putting the value for the client secret into Zammad. This is consistent with the only other app registration I have using Client secrets in the same way.
I’m guessing there’s something wrong with the MS setup, but I’ve been through it all so many times and can’t find anything wrong.
I’ve done both at various times today, both give the same result. I can connect the admin account (but not get to a mailbox) but not any user or shared mailbox accounts without getting stuck at the consent screen again.
I’ve removed the consent and re-added it both ways 3 or 4 times across a new app registration and the existing one for two differing zammad instances. Nothing seems to make any difference.
It’s presumably something in our 365 setup, but I’ve no idea what. 365 as a third party sign in works fine.
I’ve not deleted the existing one (it’s working for 3rd party sign-in which we’re actively using, so I’m reluctant to lose it), but I’ve made a completely new one and used that. I get just the same problem.
That could be possible. We are a verified publisher and it works for us. However, if you grant admin consent, it should still work since the restriction only applies to end-users.
I would recommend reaching out to Azure AD support and asking them about this issue. Maybe they’re able to confirm that the missing verification is the cause.
It’s probably something I’ve done in the 365 settings - no-one else has mentioned the same problem here yet so it’s unlikely to be your side. I have opened a support request with MS, I just started here because I suspect your response rate will be better than theirs.
Thanks for the advice, I’ll report back if/when I find out what’s wrong.
The short version is the prompt=consent parameter is killing it, probably because we have user consent turned off on our 365 setup, even though admin consent is granted.
If I adjust the URL call from Zammad to 365 and remove that parameter it all flows through fine.
You may want to look into it and consider removing that parameter from the setup call (it sounds like that’s what MS say should happen, but I’ve only had a quick look). In the mean time, a simple rewrite of the first URL after pressing the Add Account button will fix it for anyone else having this problem.
The next problem now is I can’t select a different outgoing mail server for these accounts, or can’t see how to. Being able to do that would be better as all SMTP mail from that site has to route through a specific internal host to be valid. I can probably work around that in the mean time.
[Then we're just down to the Zammad crashes, but I'll start a new comment if that doesn't go away...]
I’m afraid that you’re trying to run the integration out of its scope at this moment.
I think that’s possibly a feature request on this board.
I don’t know what happens if you don’t have the consent screen prompt activated and do not have a general administrative consent given. I imagine that this could potentially break other systems.
You’re the first one I’ve seen to use administrative consent, so at least in our universe this is a bit “uncommon”. Not saying it’s wrong of course.
