locked
What is the best option to deny user access to Sharepoint if disabling the user in AD is not an option? RRS feed

  • Question

  • Farm: SP2016 with ADFS

    Scenario:

    User1 is a member of "Intranet Readers" -AD group. That AD group is given Read permission to the Intranet landing page/home page. User1 has also direct permissions to several other site collections within the Intranet.

    User1 is removed from that AD group, but the account is not Disabled in AD because the user just changes organization in the same AD to some other organization that does not use the same Intranet. 

    Result:

    • User1 cannot access Intranet landing page/home page anymore, because he is not a member of that AD group anymore
    • User1 can still access those site collections where he has direct permissions

    Eventually user profile deletion would probably help to deny any access even with direct permissions, but that doesn't happen immediately (if not manually deleting user profile from Sharepoint which is not an option in the long term).

    So what is the best option to deny user access to the whole farm when User1 leaves the organization that uses the Intranet, but the user is NOT disabled in AD?

    Here is some options I came up with:

    1. Create a web application user policy to "Deny all" permissions for an AD Group named e.g. "Intranet Deny" and move User1 to that AD group temporarily when he leaves the organization that uses the Intranet. Then SP Admins run a script like this http://www.sharepointdiary.com/2013/01/permission-report-for-specific-user.html#ixzz5s3EF9l5K to scan all the user's permissions and remove them manually. Doable, but very time consuming method so not recommended.
    2. Create a new Custom Claim Rule in ADFS that checks if User1 is a member of "Intranet Readers" -AD group. If User1 is not a member of that AD group then the SAML Token doesn't get that claim and the authentication fails. In other words authentication to the Intranet only succeeds when the SAML Token has this Custom Claim in it, which it has only if the user is a member of the "Intranet Readers" -AD group. Of course there would be also normal identifier claim (which is UPN in our case), but that that custom claim rule would be a specific addition to ADFS for the Intranet relying party to prevent user for even authenticating.

    So Option 1 is denying access by authorization on Sharepoint and Option 2 is denying access by authentication on ADFS.

    And yes, disabling the user in AD would be most obvious solution to prevent any access, but its not an option in our case and I'm not going into details on that.

    Any comments are appreciated!


    Tuesday, June 23, 2020 7:55 AM

Answers

  • User Profiles have nothing to do with permissions to content. Performing this in AD FS is 'cleanest' but both of your options are good approaches -- with the Web App policy on SharePoint the only way to do this in SharePoint.

    Trevor Seward

    Office Apps and Services MVP



    Author, Deploying SharePoint 2019

    Author, Deploying SharePoint 2016

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Tuesday, June 23, 2020 2:38 PM

All replies

  • User Profiles have nothing to do with permissions to content. Performing this in AD FS is 'cleanest' but both of your options are good approaches -- with the Web App policy on SharePoint the only way to do this in SharePoint.

    Trevor Seward

    Office Apps and Services MVP



    Author, Deploying SharePoint 2019

    Author, Deploying SharePoint 2016

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Tuesday, June 23, 2020 2:38 PM
  • Hi Kalervo, 

    If Trevor's reply helps you, please remember to mark it as an answer.

    Thanks for your understanding. 

    Best Regards, 

    Lisa Chen 

    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    SharePoint Server 2019 has been released, you can click here to download it.
    Click here to learn new features. Visit the dedicated forum to share, explore and talk to experts about SharePoint Server 2019.


    Wednesday, June 24, 2020 3:55 AM
  • That is true, but I was wondering that when the profile is deleted wouldn't it be removed also from those site collections' Site-Permissions page where User1 has direct permissions?

    Thanks for your answer!

    Wednesday, June 24, 2020 5:31 AM
  • Hi Kalervo, 

    When you grant permission for a user, the user is added in the User information list of the site collection. 

    So when the profile is deleted it wouldn't be removed from those site collections' Site-Permissions page.

    Best Regards, 

    Lisa Chen 

    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    SharePoint Server 2019 has been released, you can click here to download it.
    Click here to learn new features. Visit the dedicated forum to share, explore and talk to experts about SharePoint Server 2019.

    Wednesday, June 24, 2020 10:52 AM
  • Thanks Lisa!

    I understand the concept of User information list as it is necessary to show those deleted users for example in documents' history (who created, who modified etc), but I don't understand why those deleted users are still showing in SP groups in Site Permissions.

    I just checked my test site collection and there is one user in Visitors group that does not exist anymore. The sharepoint profile is deleted a while ago and the AD account is also deleted. 

    Is there a way to automatically remove those deleted user profiles from those SP groups?

    And what happens if someone creates a new user in AD with the same samaccountname/UPN that matches the deleted user profile still showing in my test site collection Visitors group? Would that new AD user have now permissions to my test site collection?

    Thursday, June 25, 2020 10:45 AM
  • There is no native method to remove them. You can look at 3rd party products which remove orphaned users. Keep in mind, removing these users just marks them as deleted -- they remain, hidden, in the user information list. This is to maintain data referential integrity (i.e. make sure 'Created By' and so on remain consistent).

    SharePoint not only uses sAMAccountName and UPN but it also uses the SID of the object (or other identifier defined by an admin if not using Windows auth). If the sAMAccountName/UPN doesn't match the stored SID, it is a brand new user as far as SharePoint is concerned.


    Trevor Seward

    Office Apps and Services MVP



    Author, Deploying SharePoint 2019

    Author, Deploying SharePoint 2016

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Thursday, June 25, 2020 2:09 PM
  • That's exactly I am looking for. I want to remove those orphaned users, but still keep them in the user information list of the site collection where it had permissions before to maintain data referential integrity.

    I found some powershell scripts to report/remove those orphaned users, but those will remove them also from the user information list. This one for example: https://gallery.technet.microsoft.com/Report-or-Remove-Orphan-dcd45af0

    First line in the description says:

    "This script allow us to report remove the orphan users from SharePoint farm and it removes the orphan user from the site collection user information list hence metadata can't be effect by removing orphan users."

    So it removes orphaned users from the user information list, but doesn't affect the metadata so the data referential integrity stays intact. Is this correct?

    If this is what it does, then I will try this in our TEST farm and maybe schedule it to run daily. This would eliminate the need to scan all permissions of deleted users to clean up those site permissions-pages in our site collections.




    Friday, June 26, 2020 9:41 AM
  • Yes, it hides (marks as deleted) the orphaned user from the user information list preserved the metadata that references the user.

    Trevor Seward

    Office Apps and Services MVP



    Author, Deploying SharePoint 2019

    Author, Deploying SharePoint 2016

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Friday, June 26, 2020 3:24 PM