Access Requests impacting permissions granted to Azure AD group?

[Chad_V_Kealey]

We have a site where we're managing permissions via Azure AD groups (well, local AD groups that sync to Azure). This has been working fine, but recently a couple of users who were going to be added to the AAD group jumped the gun and submitted "access requests" for the site. One was declined, the other is still sitting there. When I go to the Site Permissions and run Check Permissions for their usernames, both come up as "None", despite the fact that they are now in that AAD group; others who were added to that group at the same time DO have access to the site. 

So, it seems like the "access request" process has some kind of impact on the users' access to the site when it is granted via an AAD group. In other words if a user requests access and it's declined, does that put some kind of block in place that interferes with permissions being "inherited" from the AAD group? If this is the case, how can I fix this (since it seems access requests can't be deleted, which I kind of understand from an audit trail standpoint)? Can I delete them from the Site Collection Users? Well, I know I can, but will that fix this problem?

[#2]

Them being in there as None isn't a Deny, so it shouldn't have an affect on their permissions if you add them to a group later manually it'll use the group permission level.

[#3]

---

@Chris Webb wrote:
Them being in there as None isn't a Deny, so it shouldn't have an affect on their permissions if you add them to a group later manually it'll use the group permission level.

---

When you say "group", you're talking Azure AD group, or SharePoint group? If I add them to the SP group, then, yes, they have access, but I'm using Azure AD groups because we're also using them to manage access to PowerApps used in the site. To keep things coordinated, we want to ONLY populate the AAD groups and put those groups into the appropriate SP groups.

[#4]

Either one, it's not a deny so it's going to use whatever they do have access too over that. So if they are in or added to an AAD group they will be added.

However, the problem is, if you're noticing that not working, when you add someone to a AD group after they have tried to access the site there used to be a group caching mechinism on-prem that you would have to recycle the app pool to force it to recheck the group for new members. Not 100% sure if it still does this in Cloud, I think it does, so if you're having issues it's related to that and not so much the request access issue.

[#5]

---

@Chris Webb wrote:
However, the problem is, if you're noticing that not working, when you add someone to a AD group after they have tried to access the site there used to be a group caching mechinism on-prem that you would have to recycle the app pool to force it to recheck the group for new members. Not 100% sure if it still does this in Cloud, I think it does, so if you're having issues it's related to that and not so much the request access issue.

---

This sounds like the case (the group caching mechanism part). The question is how do I recycle the app pool in SPO? Or, if that's not possible/practical, how do I get the same effect (e.g.: remove them from the site collection users to "flush" them from the site)? I have tried removing the AAD group from the site and re-adding it. Also, if I add it to another site collection, those two users show up with the appropriate access, so it's something specific to that site collection (leading me to suspect removing from the site collection users may do the trick, but I've always used that as a solution of last resort).

[#6]

Yeah them not being in the site collection probably forces the group memebership check on it. Since you can't do an app pool recycle to force that cache bit to happen might be your only work around when using Security Groups is to remove them to force that. I didn't have that option back on-prem cause we had a way old school setup with one site collection and everything sub site under it, so we would lose all sub site permissions with the site collection removal method :).

[#7]

I'm officially confused now. With no intervention on my part (I did not delete them from the site collection users, nor did I add them to any of the groups in the site), they actually do have access as appropriate to the Azure AD group in which they are a member. However, the confusing part is that the "Check Permissions" function still shows their permission level as "None". Now, it seems, we cannot trust that function to accurately report a user's permissions to a SharePoint object (site, list, item, etc.), which kind of sucks. Telling users "hey, try it now...it should work" doesn't inspire a lot of confidence.