AAD > User Profile Service sync (aka: Why is the Check permissions tool inaccurate?)

%3CLINGO-SUB%20id%3D%22lingo-sub-2528409%22%20slang%3D%22en-US%22%3EAAD%20%26gt%3B%20User%20Profile%20Service%20sync%20(aka%3A%20Why%20is%20the%20Check%20permissions%20tool%20inaccurate%3F)%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2528409%22%20slang%3D%22en-US%22%3E%3CP%3EWe%20have%20a%20number%20of%20departments%20that%20use%20Azure%20AD%20groups%20to%20manage%20access%20to%20their%20SharePoint%20Online%20sites.%20For%20example%3A%20the%20College%20of%20Nursing%20has%20a%20site%20(%2Fsites%2FCoN%2F)%20and%20a%20local%2Fon-prem%20AD%20group%20(that%20is%20synced%20to%20AAD)%20called%20%22CoN_Visitors%22.%20That%20group%20has%20read%20permission%20to%20the%20site.%20People%20who%20are%2Fwere%20members%20of%20the%20group%20when%20it%20was%20added%20have%20the%20appropriate%20permission%2C%20and%20you%20can%20verify%20that%20via%20the%20%22Check%20permissions%22%20tool%20in%20the%20Advanced%20permissions%20page%20on%20the%20site.%20Weeks%20go%20by%20and%20other%20users%20are%20added%20to%20the%20on-prem%20AD%20group.%20At%20the%20allotted%20interval%2C%20the%20memberships%20sync%20to%20AAD%20(we%20can%20verify%20that%20the%20users%20are%20members%20both%20in%20local%20AD%20and%20Azure%20AD).%20However%2C%20if%20we%20use%20the%20Check%20permissions%20tool%20in%20the%20site%20for%20one%20of%20those%20new%20members%2C%20it%20will%20report%20that%20they%20have%20%22No%20access%22.%20In%20most%20cases%20(but%20not%20all)%2C%20the%20user%20actually%20IS%20able%20to%20access%20the%20site.%20Re-running%20the%20Check%20permissions%20tool%26nbsp%3B%3CEM%3Eafter%3C%2FEM%3E%20they've%20done%20that%20will%20show%20that%20they%20have%20the%20appropriate%20permissions.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20believe%20this%20is%20because%20there%20are%20two%20other%20syncs%20that%20occur%20between%20AAD%20and%20the%20User%20Profile%20Service%20in%20SPO%2C%20and%20then%20the%20UPA%20to%20the%20site%20(described%20here%3A%26nbsp%3B%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fsharepoint%2Fuser-profile-sync%23sync-process%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%22%3Ehttps%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fsharepoint%2Fuser-profile-sync%23sync-process%3C%2FA%3E).%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThe%20timing%20of%20those%20last%20two%20sync%20operations%20is%20not%20clearly%20defined%20in%20that%20document.%20The%20fact%20that%20there%20does%20not%20seem%20to%20be%20a%20way%20(as%20a%20SharePoint%20service%20admin)%20to%20monitor%20them%20or%20check%20their%20status%20complicates%20the%20situation%20significantly.%20Our%20two%20workarounds%20(neither%20of%20which%20is%20100%25%20effective%20in%20all%20cases)%20have%20been%3C%2FP%3E%3COL%3E%3CLI%3Emanually%20add%20the%20%22new%22%20users%20to%20the%20appropriate%20site%20group%20temporarily%3B%20once%20they've%20accessed%20the%20site%20successfully%2C%20we%20remove%20the%20direct%20membership%20and%20their%20permissions%20(via%20the%20group)%20will%20remain%20and%20be%20reported%20correctly.%3C%2FLI%3E%3CLI%3Eremove%20the%20AD%20group%20from%20the%20site%20group%20and%20re-add%20it%3B%20this%20seems%20to%20be%20more%20consistently%20effective%20than%20the%20first%20option%2C%20assuming%20we've%20allowed%20sufficient%20time%20(about%2024%20hours)%20for%20the%20sync%20processes%20to%20%22complete%22%20(although%2C%20again%2C%20we're%20only%26nbsp%3B%3CEM%3Eassuming%3C%2FEM%3E%20they've%20completed%2C%20since%20we%20don't%20have%20a%20reliable%20means%20to%20check%20the%20status)%3C%2FLI%3E%3C%2FOL%3E%3CP%3ESo%2C%20are%20others%20having%2Fseeing%20the%20same%20sort%20of%20behavior%3F%20Is%20this%20just%20par%20for%20the%20course%20using%20AD%2FAAD%20groups%20to%20manage%20SharePoint%20permissions%3F%20I%20know%20MS%20is%20basically%20(or%20largely)%20%22all-in%22%20on%20unified%20groups%20(aka%3A%20O365%2FM365%20groups)%20for%20permissions%20management%2C%20but%20even%20there%20we%20see%20a%20fair%20number%20of%20inconsistencies%20(e.g.%3A%20members%20are%20added%20to%20a%20Team%20that's%20in%20the%20visitors%20group%20for%20a%20site%20but%20get%20%22access%20denied%22%20when%20trying%20to%20visit%20the%20site).%20I%20mean%2C%20permissions%20management%20in%20SharePoint%20has%26nbsp%3B%3CSTRONG%3E%3CEM%3Enever%3C%2FEM%3E%26nbsp%3B%3C%2FSTRONG%3Ebeen%20a%20walk%20in%20the%20park%2C%20but%20I%20was%20%3CSTRONG%3E%3CEM%3Ehoping%3C%2FEM%3E%3C%2FSTRONG%3E%20for%20a%20bit%20more%20reliability%20and%20consistency%20in%20moving%20to%20the%20cloud.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-2528409%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EAdmin%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EPermissions%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3ESecurity%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3ESharePoint%20Online%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3ESites%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E
Regular Contributor

We have a number of departments that use Azure AD groups to manage access to their SharePoint Online sites. For example: the College of Nursing has a site (/sites/CoN/) and a local/on-prem AD group (that is synced to AAD) called "CoN_Visitors". That group has read permission to the site. People who are/were members of the group when it was added have the appropriate permission, and you can verify that via the "Check permissions" tool in the Advanced permissions page on the site. Weeks go by and other users are added to the on-prem AD group. At the allotted interval, the memberships sync to AAD (we can verify that the users are members both in local AD and Azure AD). However, if we use the Check permissions tool in the site for one of those new members, it will report that they have "No access". In most cases (but not all), the user actually IS able to access the site. Re-running the Check permissions tool after they've done that will show that they have the appropriate permissions.

 

I believe this is because there are two other syncs that occur between AAD and the User Profile Service in SPO, and then the UPA to the site (described here: https://docs.microsoft.com/en-us/sharepoint/user-profile-sync#sync-process). 

 

The timing of those last two sync operations is not clearly defined in that document. The fact that there does not seem to be a way (as a SharePoint service admin) to monitor them or check their status complicates the situation significantly. Our two workarounds (neither of which is 100% effective in all cases) have been

  1. manually add the "new" users to the appropriate site group temporarily; once they've accessed the site successfully, we remove the direct membership and their permissions (via the group) will remain and be reported correctly.
  2. remove the AD group from the site group and re-add it; this seems to be more consistently effective than the first option, assuming we've allowed sufficient time (about 24 hours) for the sync processes to "complete" (although, again, we're only assuming they've completed, since we don't have a reliable means to check the status)

So, are others having/seeing the same sort of behavior? Is this just par for the course using AD/AAD groups to manage SharePoint permissions? I know MS is basically (or largely) "all-in" on unified groups (aka: O365/M365 groups) for permissions management, but even there we see a fair number of inconsistencies (e.g.: members are added to a Team that's in the visitors group for a site but get "access denied" when trying to visit the site). I mean, permissions management in SharePoint has never been a walk in the park, but I was hoping for a bit more reliability and consistency in moving to the cloud.

0 Replies