RE: [OzMOSS] SharePoint Groups and Permission Levels [SEC=UNCLASSIFIED]
Background: We now have a large corporate wide roll out aiming to reach 6000 people, currently at about 2000. We have been through a few iterations of permission structures, from completely do-as-you-please to completely managed in AD and a few part way in-between I don't think any approach so far has been perfect but I have to say from a management perspective I am now over the moon that I can answer the following questions in about 2 seconds: - who has access to this site - who has access to this library - what does this person have access to To achieve this, and on advice from various experts (you know who you are), I have put all the permissions in AD - I don't use SP groups at all. On the actual SP page, I keep it as standard as possible e.g. one read group, one readwrite group and one approver group (depending on the situation). This allows me to be able to determine the members of a site (or list) in one fell swoop, through AD. My AD naming convention allows me to work out, without having to visit the site, the details of the site I am looking at (e.g. [sitepath-read]). Where they don't exist elsewhere, I create team AD groups for special purposes e.g. [sitepath-nswonly] or [sitepath-coordinators]. There are certain nesting rules e.g. don't put permission groups inside permission groups e.g. don't put [sitepath-site1-read] inside [sitepath-site2-readwrite]. I have even managed to create a partially automated process for people to request access and have the uneducated IT Support add people to the correct group. And I have a long document detailing all the specifics of conventions and rules around nesting AD groups (to avoid loops) etc. The people in my team usually take a few weeks to really understand everything about it but if they generally stick with the conventions it stays together. It is not a perfect approach and I suspect we are going to end up with 1000's of AD groups (and put a load on AD) but it is the best so far to manage. Oh yeah - and I never allow people to have unique permissions on anything smaller than a library or a list. It would be a nightmare to track (if this matters to you as it does to us). cheers, Wilhelmina. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Noone Sent: Thursday, 3 July 2008 8:59 AM To: listserver@ozMOSS.com Subject: RE: [OzMOSS] SharePoint Groups and Permission Levels Thanks guys, this has all been terribly reassuring. Has anyone else got something to add which might further depress me? ;) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Grist Sent: Wednesday, 2 July 2008 6:15 PM To: listserver@ozMOSS.com Subject: RE: [OzMOSS] SharePoint Groups and Permission Levels What I have done is have Owners - full control, which inside it has a sharepoint admins group, and a sharepoint owners group(i.e. reps across company who are sharepoint leaders). Then a group for each unit, i.e. finance, hr, business dev etc. These more specific groups have full control to their units set of sites by breaking inheritance where they need. I had lots of planning to set it up just right and what im annoyed about is that say I have the following structure: Home - Site1 o Site2 Say I give groups Owners, Members permission over the whole thing. Then at site2 for shared documents an individual group/user is given full control over that. When viewing the permissions for Home they will appear as limited access. I could be doing something wrong but all im saying is that it does seem to end up in quite a bit of a mess J Chris Grist Network Support Officer education.au Limited Level 1, 182 Fullarton Road DULWICH SA 5065 p +61 8 83343291 f +61 8 83343211 e [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] w www.educationau.edu.au http://www.educationau.edu.au/ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Witherdin, Nigel Sent: Wednesday, 2 July 2008 5:06 PM To: listserver@ozMOSS.com Subject: RE: [OzMOSS] SharePoint Groups and Permission Levels We have followed the supposed best practice of creating AD groups for each site (Owner, Approver, Contributor and Visitor) and adding these to the equivalent MOSS groups. I agree that if you have a large site collection it means that you are going to end up with hundreds of AD groups, but for us it makes sense because: - Our site owners are still coming to grips with the added responsibility of managing their site (design, content approval, etc.), having them worry about security would not be acceptable - use of AD groups means the centralized Starter and Leaver processes take care assigning/removing peoples access to the portal cheers. Nigel Witherdin Senior Support Analyst Eversheds Direct Dial: +44 (0) 84 549 754 17 Mobile: +44 (0) 7738 553256 www.eversheds.com http://www.eversheds.com
RE: [OzMOSS] SharePoint Groups and Permission Levels
I used scriptlogic's other security-explorer products for a large AD redesign a couple of years ago and had a bug they could not repro which rendered the product unusable in my case. While the product would have been ideal if it had worked for me, as a potential client their end-user support I found disappointing in my case. But that may be a once-off incident. Anyway, the first thing in large AD deployments is that 'best practice' isn't always best at large scales. The theory will tell you to create AD groups and add them to SharePoint groups, but if you are putting in SharePoint to decentralise the administration and delegation of content admin, then this is not going to help you. So as a former AD specialist, I actually have no fundamental objections to adding user accounts directly into SharePoint groups - particularly team portals where there is a designated 'site administrator' that has enough rights to manage access. This is purely a philosophical decision (as is many SharePoint decisions) However, if you are of the philosophy that the IT thought police should stay in control of access, then it makes sense to manage it via Active Directory. Additionally, one AD redesign I did also had adopted the 'best practice' of local groups, with global groups as members of the local groups. However because of a complex filesystem, there were 350 AD groups for each project file structure (read, write, delete for subfolders with global and local groups.) Result? over 35000 groups in AD across all projects - scary. So many groups had issues with Kerberos authentication among other things. So I guess the first thing is to determine the type of site you are delivering and the philosophy around management of sites and delegation or centralisation of that management. Is this any help? Paul www.cleverworkarounds.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Noone Sent: Wednesday, 2 July 2008 10:51 AM To: listserver@ozMOSS.com Subject: [OzMOSS] SharePoint Groups and Permission Levels Hi guys, I've recently been tasked with providing a list of groups and permissions for a new MOSS site collection with a significant Active Directory. Does anyone have a no-nonsense approach to this? I've been looking for a table of SharePoint Groups and their applied Permission Levels but can't seem to find any detailed or practical information on this obviously important first step. I did come across what seems like a fantastic management tool once things are up and running though. Would be interested to know if anyone has experience with this. http://www.scriptlogic.com/products/security-explorer/sharepoint/ Kind regards, Paul _ This e-mail is intended for the use of the addressed recipient(s) only and may contain confidential and privileged information. If you have received this message in error, please delete the message and any attachments and copies immediately; and notify the sender by return e-mail. Any views expressed in this message or any attachments are those of the individual sender and do not necessarily represent the corporate opinion of the Catholic Education Office (CEO), Sydney. The CEO Privacy Policy is located at http://www.ceo.syd.catholic.edu.au --- OzMOSS.com - to unsubscribe from this list, send a message back to the list with 'unsubscribe' as the subject. Powered by mailenable.com --- OzMOSS.com - to unsubscribe from this list, send a message back to the list with 'unsubscribe' as the subject. Powered by mailenable.com
RE: [OzMOSS] SharePoint Groups and Permission Levels
We have followed the supposed best practice of creating AD groups for each site (Owner, Approver, Contributor and Visitor) and adding these to the equivalent MOSS groups. I agree that if you have a large site collection it means that you are going to end up with hundreds of AD groups, but for us it makes sense because: - Our site owners are still coming to grips with the added responsibility of managing their site (design, content approval, etc.), having them worry about security would not be acceptable - use of AD groups means the centralized Starter and Leaver processes take care assigning/removing peoples access to the portal cheers. Nigel Witherdin Senior Support Analyst Eversheds Direct Dial: +44 (0) 84 549 754 17 Mobile: +44 (0) 7738 553256 www.eversheds.com http://www.eversheds.com/ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Culmsee Sent: 02 July 2008 07:11 To: listserver@ozMOSS.com Subject: RE: [OzMOSS] SharePoint Groups and Permission Levels I used scriptlogic's other security-explorer products for a large AD redesign a couple of years ago and had a bug they could not repro which rendered the product unusable in my case. While the product would have been ideal if it had worked for me, as a potential client their end-user support I found disappointing in my case. But that may be a once-off incident. Anyway, the first thing in large AD deployments is that 'best practice' isn't always best at large scales. The theory will tell you to create AD groups and add them to SharePoint groups, but if you are putting in SharePoint to decentralise the administration and delegation of content admin, then this is not going to help you. So as a former AD specialist, I actually have no fundamental objections to adding user accounts directly into SharePoint groups - particularly team portals where there is a designated 'site administrator' that has enough rights to manage access. This is purely a philosophical decision (as is many SharePoint decisions) However, if you are of the philosophy that the IT thought police should stay in control of access, then it makes sense to manage it via Active Directory. Additionally, one AD redesign I did also had adopted the 'best practice' of local groups, with global groups as members of the local groups. However because of a complex filesystem, there were 350 AD groups for each project file structure (read, write, delete for subfolders with global and local groups.) Result? over 35000 groups in AD across all projects - scary. So many groups had issues with Kerberos authentication among other things. So I guess the first thing is to determine the type of site you are delivering and the philosophy around management of sites and delegation or centralisation of that management. Is this any help? Paul www.cleverworkarounds.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Noone Sent: Wednesday, 2 July 2008 10:51 AM To: listserver@ozMOSS.com Subject: [OzMOSS] SharePoint Groups and Permission Levels Hi guys, I've recently been tasked with providing a list of groups and permissions for a new MOSS site collection with a significant Active Directory. Does anyone have a no-nonsense approach to this? I've been looking for a table of SharePoint Groups and their applied Permission Levels but can't seem to find any detailed or practical information on this obviously important first step. I did come across what seems like a fantastic management tool once things are up and running though. Would be interested to know if anyone has experience with this. http://www.scriptlogic.com/products/security-explorer/sharepoint/ Kind regards, Paul This e-mail is intended for the use of the addressed recipient(s) only and may contain confidential and privileged information. If you have received this message in error, please delete the message and any attachments and copies immediately; and notify the sender by return e-mail. Any views expressed in this message or any attachments are those of the individual sender and do not necessarily represent the corporate opinion of the Catholic Education Office (CEO), Sydney. The CEO Privacy Policy is located at http://www.ceo.syd.catholic.edu.au --- OzMOSS.com - to unsubscribe from this list, send a message back to the list with 'unsubscribe' as the subject. Powered by mailenable.com --- OzMOSS.com - to unsubscribe from this list, send a message back to the list with 'unsubscribe' as the subject. Powered by mailenable.com ** This email is sent for and on behalf of Eversheds LLP ** This email is sent for and on behalf
RE: [OzMOSS] SharePoint Groups and Permission Levels
What I have done is have Owners - full control, which inside it has a sharepoint admins group, and a sharepoint owners group(i.e. reps across company who are sharepoint leaders). Then a group for each unit, i.e. finance, hr, business dev etc. These more specific groups have full control to their units set of sites by breaking inheritance where they need. I had lots of planning to set it up just right and what im annoyed about is that say I have the following structure: Home - Site1 o Site2 Say I give groups Owners, Members permission over the whole thing. Then at site2 for shared documents an individual group/user is given full control over that. When viewing the permissions for Home they will appear as limited access. I could be doing something wrong but all im saying is that it does seem to end up in quite a bit of a mess :) Chris Grist Network Support Officer education.au Limited Level 1, 182 Fullarton Road DULWICH SA 5065 p +61 8 83343291 f +61 8 83343211 e [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] w www.educationau.edu.auhttp://www.educationau.edu.au/ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Witherdin, Nigel Sent: Wednesday, 2 July 2008 5:06 PM To: listserver@ozMOSS.com Subject: RE: [OzMOSS] SharePoint Groups and Permission Levels We have followed the supposed best practice of creating AD groups for each site (Owner, Approver, Contributor and Visitor) and adding these to the equivalent MOSS groups. I agree that if you have a large site collection it means that you are going to end up with hundreds of AD groups, but for us it makes sense because: - Our site owners are still coming to grips with the added responsibility of managing their site (design, content approval, etc.), having them worry about security would not be acceptable - use of AD groups means the centralized Starter and Leaver processes take care assigning/removing peoples access to the portal cheers. Nigel Witherdin Senior Support Analyst Eversheds Direct Dial: +44 (0) 84 549 754 17 Mobile: +44 (0) 7738 553256 www.eversheds.comhttp://www.eversheds.com/ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Culmsee Sent: 02 July 2008 07:11 To: listserver@ozMOSS.com Subject: RE: [OzMOSS] SharePoint Groups and Permission Levels I used scriptlogic's other security-explorer products for a large AD redesign a couple of years ago and had a bug they could not repro which rendered the product unusable in my case. While the product would have been ideal if it had worked for me, as a potential client their end-user support I found disappointing in my case. But that may be a once-off incident. Anyway, the first thing in large AD deployments is that 'best practice' isn't always best at large scales. The theory will tell you to create AD groups and add them to SharePoint groups, but if you are putting in SharePoint to decentralise the administration and delegation of content admin, then this is not going to help you. So as a former AD specialist, I actually have no fundamental objections to adding user accounts directly into SharePoint groups - particularly team portals where there is a designated 'site administrator' that has enough rights to manage access. This is purely a philosophical decision (as is many SharePoint decisions) However, if you are of the philosophy that the IT thought police should stay in control of access, then it makes sense to manage it via Active Directory. Additionally, one AD redesign I did also had adopted the 'best practice' of local groups, with global groups as members of the local groups. However because of a complex filesystem, there were 350 AD groups for each project file structure (read, write, delete for subfolders with global and local groups.) Result? over 35000 groups in AD across all projects - scary. So many groups had issues with Kerberos authentication among other things. So I guess the first thing is to determine the type of site you are delivering and the philosophy around management of sites and delegation or centralisation of that management. Is this any help? Paul www.cleverworkarounds.comhttp://www.cleverworkarounds.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Noone Sent: Wednesday, 2 July 2008 10:51 AM To: listserver@ozMOSS.com Subject: [OzMOSS] SharePoint Groups and Permission Levels Hi guys, I've recently been tasked with providing a list of groups and permissions for a new MOSS site collection with a significant Active Directory. Does anyone have a no-nonsense approach to this? I've been looking for a table of SharePoint Groups and their applied Permission Levels but can't seem to find any detailed or practical information on this obviously important first step. I did come across what seems like a fantastic management tool once things are up and running though. Would be interested to know if anyone has experience with this. http
RE: [OzMOSS] SharePoint Groups and Permission Levels
One other thought. File server permissions are often designed just as much to protect against accidental misuse, as opposed to no you can't access it because you are not cool enough. I'm sure we have all fielded the oh the folder just *disappeared* it wasn't me sort of excuse when someone has a bad right-click day and doesn't want to fess up. Document library permissions need not be quite as anal as that, due to the recycle bin, versioning and audit policies. But people aren't conditioned to work this way and I find that clients often still want to restrict access, but not because people aren't supposed to have access. Instead its motivated by that mother-hen reflex that IT can have of protecting users from themselves. (Certainly I used to do that - I confess) Regards Paul From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Noone Sent: Thursday, 3 July 2008 6:59 AM To: listserver@ozMOSS.com Subject: RE: [OzMOSS] SharePoint Groups and Permission Levels Thanks guys, this has all been terribly reassuring. Has anyone else got something to add which might further depress me? ;) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Grist Sent: Wednesday, 2 July 2008 6:15 PM To: listserver@ozMOSS.com Subject: RE: [OzMOSS] SharePoint Groups and Permission Levels What I have done is have Owners - full control, which inside it has a sharepoint admins group, and a sharepoint owners group(i.e. reps across company who are sharepoint leaders). Then a group for each unit, i.e. finance, hr, business dev etc. These more specific groups have full control to their units set of sites by breaking inheritance where they need. I had lots of planning to set it up just right and what im annoyed about is that say I have the following structure: Home - Site1 o Site2 Say I give groups Owners, Members permission over the whole thing. Then at site2 for shared documents an individual group/user is given full control over that. When viewing the permissions for Home they will appear as limited access. I could be doing something wrong but all im saying is that it does seem to end up in quite a bit of a mess J Chris Grist Network Support Officer education.au Limited Level 1, 182 Fullarton Road DULWICH SA 5065 p +61 8 83343291 f +61 8 83343211 e [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] w www.educationau.edu.au http://www.educationau.edu.au/ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Witherdin, Nigel Sent: Wednesday, 2 July 2008 5:06 PM To: listserver@ozMOSS.com Subject: RE: [OzMOSS] SharePoint Groups and Permission Levels We have followed the supposed best practice of creating AD groups for each site (Owner, Approver, Contributor and Visitor) and adding these to the equivalent MOSS groups. I agree that if you have a large site collection it means that you are going to end up with hundreds of AD groups, but for us it makes sense because: - Our site owners are still coming to grips with the added responsibility of managing their site (design, content approval, etc.), having them worry about security would not be acceptable - use of AD groups means the centralized Starter and Leaver processes take care assigning/removing peoples access to the portal cheers. Nigel Witherdin Senior Support Analyst Eversheds Direct Dial: +44 (0) 84 549 754 17 Mobile: +44 (0) 7738 553256 www.eversheds.com http://www.eversheds.com/ _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Culmsee Sent: 02 July 2008 07:11 To: listserver@ozMOSS.com Subject: RE: [OzMOSS] SharePoint Groups and Permission Levels I used scriptlogic's other security-explorer products for a large AD redesign a couple of years ago and had a bug they could not repro which rendered the product unusable in my case. While the product would have been ideal if it had worked for me, as a potential client their end-user support I found disappointing in my case. But that may be a once-off incident. Anyway, the first thing in large AD deployments is that 'best practice' isn't always best at large scales. The theory will tell you to create AD groups and add them to SharePoint groups, but if you are putting in SharePoint to decentralise the administration and delegation of content admin, then this is not going to help you. So as a former AD specialist, I actually have no fundamental objections to adding user accounts directly into SharePoint groups - particularly team portals where there is a designated 'site administrator' that has enough rights to manage access. This is purely a philosophical decision (as is many SharePoint decisions) However, if you are of the philosophy that the IT thought police should stay in control of access, then it makes sense to manage it via Active Directory. Additionally, one AD redesign I did also had adopted the 'best practice' of local groups, with global
