I'm trying to fullfill a requirement which forces the use of Active Directory groups. I'm having issues getting to where I want to be.

Upon creation of a new site, I'm going to use AD groups to assign rights to groups of users. This implies that I need to disable two permission levels: manage rights and create groups, otherwise site owners could still bypass the default assignment. But there is the situation in which a site owner might request a second group to have access to content. To solve that, I would like to grant a group of admins the rights to do this. They and only they should be able to manage rights.

I thought I could get there using web application policies, but it seems to be impossible. Here's what I tried:

  • Disable the "manage rights" and "create groups" user permissions. This disables the permissions in the entire webapp. I tried then overriding this with a custom permission level assigned to the admins group using a user policy. Doesn't work.
  • I also tried creating a "deny rights" policy for the "all authenticated users" group, and then creating a second policy explicitely granting those permissions again for the admins group, doesn't work either. Even tried the sequence in which the policies are created, no go.
  • Tried altering the "Full Control" permission level in CA, which doesn't seem to reflect on the Full Control permission level of the site collections. So altering it doesn't change the rights already assigned to site owners.

The only option I found is altering the OOTB "Full Control" permission level on site collection level. That works, but a site collection administrator can always change it back again. If you want to prevent that, you need to disable the manage rights permission from CA, which again blocks the rights for the admin users as well.

I already found the following two topics, which don't provide a good answer to the question:

3 Answers 3


Your site collection admins will be able to do anything and everything that SharePoint allows, including the creation of SP groups. You can turn this off at the web application level, but it doesn't sound like that's something you want to do to all of your other site collections. I think the basic issue you're running into here is that anything you set at the web app level supersedes anything set at lower levels. One way of resolving this issue:

  1. At the CA Application Management screen, select your web app, create a new permission level that has everything Full Control has except the two permissions you don't want it to have, and call it "Almost Full Control" or whatever. Check the box that says that site collection admins have this level of rights, and then make sure that the corresponding check box in Full Control is unchecked.
  2. Optionally, you could remove the permissions from the Full Control level, make a new level called Super Full Control or something, and give that level all of the access rights. If you did that, you could leave site collection admins and auditors where they are.
  3. This now means that all site collection admins on all of your site collections on your web application no longer have the ability to create groups. If you only wanted to restrict this for one site collection, what you would need to do is add all site admins to the site collection's Owners group (which has Full Control rights by default).
  4. Grant your small group of people Super Full Control or Full Control access, depending on what of the above you decided to do. At least one person needs to have that access at the web application level because otherwise, well, nobody has access to manage access rights, period. You could leave it with a select group of people assigned that right at the web app level, or you could have the one web app level user grant rights to each person at the site collection level.

Please note, too, that denying rights isn't the same as not granting them. SharePoint operates like SQL in this respect: if you have 5 different access levels tied to your account, one of which doesn't expressly grant you the rights to read a list but another of which does, you can access that list. If a 3rd access level explicitly denies you read access to that list, it doesn't matter what you've been granted otherwise. Deny > Grant > nothing.

  • Sounds workable, thanks a lot! You're getting the bonus for your well described answer.
    – Jasper
    Commented May 24, 2013 at 10:14
  • Hmmm... whether it sounds workable, it doesn't seem to work. Or, most likely, I made a mistake somewhere? I created a new permission "Super User" which I granted to a special service account on web application level. I changed the default "Full Control" level and changed the "manage permissions" and "create groups" permissions to deny instead of grant. But my SCA account still has these permissions. Is this also being propagated to existing site collections?
    – Jasper
    Commented May 24, 2013 at 11:35
  • For newly created sites; the SCA's are automatically added into the Owners group of that site. The Owners group has full control, including the Manage Permissions and Create groups levels. I assumed changes made to the Full Control level of the WebApp would propagate to the Full Control permission level of the site collections, but that does not seem to be the case. To be clear: I denied the permissions on my Full Control level, but their still in effect on existing as well as new site collections.
    – Jasper
    Commented May 24, 2013 at 13:05
  • You can implement custom provisioning code on top of the solution provided here so that you can change the permission levels or modify the permissions associated with the OOTB groups as you want.
    – Manju
    Commented May 29, 2013 at 5:37
  • I know, but I want to know / understand why it doesn't work as I expected. I can always write custom provisioning code which adapts all the permission levels; but the above seems like a great solution, when it would work...
    – Jasper
    Commented May 29, 2013 at 8:44
  1. Disable the manage rights and create groups user permissions on the webapp
  2. Create a simple webpart that runs elevated and can be used only by the admin group - this webpart can add additional groups to the site.

TBH I have not tried it, but it should be easy to test and fulfills all your requirements.

  • Yes, I guess that should work, but we have rather strict rules about custom code on the farm. And no developers to actually code it. So it's a bit easier said then done, but thanks for the suggestion.
    – Jasper
    Commented Apr 4, 2013 at 6:39
  • 1
    To add: disabling permissions on web application level kills a lot of scenario's. For instance; approval workflows create tasks on behalf of the user, this does not work properly once you've disabled the permission level. And yes; I learned that the hard way ;)
    – Jasper
    Commented May 23, 2013 at 11:04

Leave full control for your "super admins", and then create an "Almost Full Control" permission level for your regular site owners. Your group of "super admins" would have to include the site collection administrators though - I don't see a way around that.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.