User is unable to access SharePoint data through Powerapps, even though he has all the same permissions other users do

[BrendanZ1]

Hi all,

I have an app that is used my over thirty staff, all of which have read, edit (Members) access.

We had a new staff member start a few weeks ago, and despite all things being setup the same, they are unable to access data residing in SharePoint. When they open the app, they receive multiple notifications saying they don't have permission for any of the lists connected to the app......

We still have an exchange on site that syncs with Azure AD (this will be ending soon and we will be completely cloud based).

I have compared this user with others that have access to the same data and the only thing I can see that is different, is the Proxy Address that displays when looking at the user profile in Azure.

Others have: SMTP:user@company.com

Whereas this user has: 

X500:/o=COMPANY/ou=Exchange Administrative Group (*************)/cn=Recipients/cn=*********************-User Name

I have removed information from above as I am not sure how sensitive some of it is.

When I click to view more Proxy addresses, I can see the SMTP:user@company.com, but it sits at the bottom of the list.....

The only other difference between some users, are that some only have Powerapps Plan 2 Trial, Powerautomate Free and Powerapps per app baseline access licences, while others have Microsoft 365 Business Basic. That said, there are many who don't have Business Basic that still have access to data through the app......

When logged in to SharePoint, they are unable to see any sites relating to the data used in the apps.....

So would it be something to do with the Proxy Address or can I rule this out as a potential issue?

I may be looking in the wrong spot, but I can't figure out exactly why a user has all the same permissions etc as everyone else, yet is denied access through Powerapps....

Thanks for any direction on this!

[iAm_ManCat · Accepted solution]

Hi,

SharePoint (& Power Apps) use the User Principal Name (UPN) of the user to authenticate, so proxy addresses will likely not be the issue - it sounds more like the method to create this user differed from other users if they ended up with other proxy addresses.

Things I would look at:

Can they access ANY SharePoint site? Do they have a license for SharePoint? Are they showing as a proper domain member (ie can they see any lists where permissions are granted for 'Everyone in Company_XYZ')? If you add them manually to a specific list, can they reach that list directly? What security groups are they a part of, and compare this against other user's security groups? What SharePoint Groups are they a part of and compare this against other users? Compare this AD account with another known-good AD account in your local domain controller, then do the same in Azure AD. Double-check licenses (I know you mentioned you'd done this before, just adding to list for completeness)

Cheers,

Sancho

[BrendanZ1]

Thanks for the reply @iAm_ManCat , that is good to know about the UPN. I have a feeling the issue may reside in the creation of the user. They were created in Azure AD initially, but this causes issues apparently, as they need to be created on the local exchange first. So we deleted the user (as far as I know) from Azure, then created them on the exchange, and finally re-created them on Azure. This didn't resolve the issue. So then we deleted them from both Azure and local exchange and started from scratch. This it would seem has not fixed the issue either and maybe that is due to the exchange/Azure keeping user records for 30 days after deletion....so maybe we never started from scratch the second time around?

As per all of your suggestions, when the user logs into SharePoint and performs a search, they can see list items and documents belonging to the home site in the tenant. They can't see anything to do with the site in question that they have been given edit/read (member) access to. I have compared the user details with those who match but can actually access the data and site....

I will have to look at creating a new user for them altogether and see if that fixes it, as we have created other users in this time that haven't had this issue - the only difference that I can tell in the process is what I have mentioned above, having them created in the wrong order in the first instance....

I will post back here as soon as I have an answer to testing this theory - unfortunately I am relying on someone else to do the local exchange side of things, otherwise I would test it over the next hour.....will have to wait on them before I can go further.

[BrendanZ1]

I am still waiting on my work colleague to add a new version of the user.
Will post back here soon if this fixes the issue. 

[BrendanZ1]

Forgot to come back to this and reply - by deleting the user completely from our local AD as well as Azure, then re-adding to the local AD, resolved the issue.

[iAm_ManCat]

Awesome, glad to hear that sorted it, thanks for coming back to clarify 🙂