At my current job, I’m more of an administrator than I am a dev. It’s quite enlightening to be honest. As a developer, you don’t tend to think that much about site structure, governance and all those things. Not that I had no experience in that, but I surely have learned some things extra since my admin job. One of those is permission management and I’d like to share a little story about that.
At my customer, we made up the following requirements for our environment:
- Sites have to be restrained from growing excessively big by using quota’s.
- We will use site retention to automatically clean-up old, unused sites.
- We do not want to give users the “manage permissions” and “create groups” permissions. I won’t go in to too much detail there, just accept the requirements 🙂
- Of course, there is a select group of admins who are allowed to manage permissions. So those people need to be granted that permission level.
Ok. So to start with the bad news: I didn’t solve this puzzle (yet). And that might surprise you cause all of these things sound doable, right? Well, it’s the combination that’s the problem and I’ll explain why.
Both the quota system and retention are e-mail based. That means the user will start getting e-mails when there’s something wrong. This is cool, but the e-mail is sent out to the account listed as primary site collection administrator. So, we need to ensure the end-user is listed as primary site collection administrator. Hmmm. That gives that user a lot of permissions, some of which we might not want to give out.
At that point you should be looking at permission management on web application level. Basically there’s two options there:
- You can disable certain permissions completely, making them unavailable on all site collection in this web application. That’s nice, but disabling “manage permissions” will have serious impact. For instance: your approval workflows will get stuck because they cannot change the approver any more. Not really a good option.
- Secondly, there’s the option to use permission levels and Grant / Deny those to users. This works like in SQL: a deny always overrides all other grants. The problem with this is that you cannot say “I want to deny by default, except for my admin users”. Believe me: I tried all possible combinations you might think of, it just doesn’t work that way.
Hmmm, getting more and more stuck. You might tell me: “you can create a custom permission level on your site collection via script, and give that permission level to your users”. Well yes, you can. But on site collection level, there’s no denying permissions; there’s just granting them. And your end-user the site collection administrator will have, well… site collection administrator permissions. Which boils down to: Full Control. So although this will do the trick for owners, it will not for site collection administrators.
I made this a case with MS support, but didn’t get to a good solution with the support engineer. It just seems to be impossible. Which doesn’t mean I’m done with it, cause I still have the belief this should be possible some how. So… if you have a brilliant idea or solution, do me a favour and leave it in the comments please!
Update: you might be tempted (as I was) to think that the permission levels (or changes to…) on web application level will be propagated to the site collections. That’s not the case. The Full Control permission level on a site collection contains all permissions (well duh…) and cannot be changed. Changes you make to “Full Control” on web application level are not propagated down to the site collections (I expected this). These are two seperate levels which both affect the permissions a user has, but are not connected as such.