Rbac for application : getSchedule gets access to subject and locations of other calendar without having Calendars.Read to them ?

Question

Rbac for application : getSchedule gets access to subject and locations of other calendar without having Calendars.Read to them ?

Jean-Baptiste Zeller 5

We would like to make an application that can :

Check the busy status of people in an exchange tenant, without seeing the details of their meeting (no subject or location).
Read and write into one (or multiple) shared calendar in order to invite said people to meetings.

This design deliberately try to keep rights to a bare minimum in order for our client to be able to trust us with our application : we don't get to read people's personal information in their calendar. We get only to invite said people, and check whether they are busy.

The problem is, while I personally, with my own mailbox in exchange online, get to see only 'busy' 'tentative' etc inside people's calendar when I look at them. The application which is supposed to only get Calendars.ReadWrite (configured in rbac for application, not inside entra) for specifically one email address (that'll be used as organizer), get to see the subject and location of event for everyone in our own tenant, which is too far for what we want to offer our clients : 'we only access your busy state, like a regular user, we can't know anything else'.

The entra app only got the default User.Read delegated authorization (which shouldn't come into play in this). I don't know why I'm still able to see everyone detail.

What am I doing wrong and what can I do to diagnose this issue ? What I do today : I call https://graph.microsoft.com/v1.0/users/<theOneEmailIHaveCalendars.ReadWriteTo>/calendar/getSchedule

I have no access to each individual calendars, only my own calendar. But I get to see everyone's full calendar info from getSchedule, which is something I don't want. And my tenant is supposed to be configured for availability only view (which I can verify from my own personal user calendar).

Sven 25 Reputation points

2026-11-04T08:29:40.3433333+00:00

Root cause was EX1537187.
We had the same issue and it's working as expected again now.
Jean-Baptiste Zeller 5 Reputation points

2026-11-04T09:56:49.0333333+00:00

I think you might be right, after tearing our hair off the last few days checking scope etc... everything now works properly today and my exchange administrator stated that he hasn't touched anything about it. We now get responses that are completely details free, as we hoped for.

1 answer

Your answer

Sven 25 Reputation points

2026-11-04T08:29:40.3433333+00:00

Root cause was EX1537187.
We had the same issue and it's working as expected again now.
Jean-Baptiste Zeller 5 Reputation points

2026-11-04T09:56:49.0333333+00:00

I think you might be right, after tearing our hair off the last few days checking scope etc... everything now works properly today and my exchange administrator stated that he hasn't touched anything about it. We now get responses that are completely details free, as we hoped for.

Answer 1

Hin Vo 1,745 Independent Advisor

Hi @Jean-Baptiste Zeller

From what I understand, RBAC for Applications primarily controls which mailbox scopes an application can access, rather than the level of calendar details returned by getSchedule.

If the subject and location properties are being returned, it could indicate that the effective free/busy visibility for those calendars is greater than AvailabilityOnly.

To further investigate, could you please verify the following:

The output of Get-MailboxFolderPermission -Identity user@domain:\Calendar for one of the affected users.

Whether the organizer mailbox has any additional delegated permissions, Full Access permissions, administrative roles, or other elevated access that could influence the results.

Whether the application has any Microsoft Graph application permissions, such as Calendars.Read or Calendars.ReadWrite, that have been consented in Entra ID.

Please check these items and let me know the results. Any update would be appreciated.

Jean-Baptiste Zeller 5 Reputation points

2026-11-02T11:01:23.4466667+00:00

The graph permission are already cleaned up. How can I check the part which I find most promising.

Whether the organizer mailbox has any additional delegated permissions, Full Access permissions, administrative roles, or other elevated access that could influence the results.

I'll report the other results once I get them. The main thing that puzzle me (and there might be a simple explanation) is why my getSchedule though my app, can see information I with my personal identity cannot.
Hin Vo 1,745 Reputation points Independent Advisor

2026-11-03T06:34:42.7433333+00:00

Hi @Jean-Baptiste Zeller

Since the Graph permissions have already been ruled out, I'm wondering whether there may be a difference between the effective permissions of the organizer mailbox and your personal account.

Could you check whether the organizer mailbox has any additional role assignments or delegated mailbox permissions that your personal account does not have?

Since getSchedule appears to return more information when accessed through the organizer mailbox than when accessed through your personal account, it's possible that the behavior is related to the organizer mailbox's effective permissions.

Please take your time to review this and let me know what you find. The results may help determine whether the difference is related to the organizer mailbox itself or another configuration within the environment.
Jean-Baptiste Zeller 5 Reputation points

2026-11-04T09:57:54.3133333+00:00

I think this was solved by https://www.365fanatic.com/m365-status/EX1537187/ my exchange admin said he changed nothing since yesterday, and this morning all api response now truly only forward availability and not full details. Which is exactly what we were hoping to see.
Hin Vo 1,745 Reputation points Independent Advisor

2026-11-04T12:41:31.2633333+00:00

Hi @Jean-Baptiste Zeller

Thank you for your update. I'm really happy to hear that the issue has resolved itself.

Best regards,