Microsoft Office Tutorials and References
In Depth Information
additional site collections. The URL for that path would be, on the same server, http://spf2/
sites/. What this means is if you create that additional site collection, it can be something on
that path, such as http://spf2/sites/something.
You can, of course, create your own managed paths, depending on your required topology.
This is useful if you are planning to have one web application, say, per region, and then site
collections for each office. Then you might consider creating a managed path for the London office,
Beijing office, Helsinki, and so on.
A site collection makes a good user account or permissions boundary because you can add
users once to the top-level site, apply permissions to them either individually or in groups, and
if the subsites inherit permissions (which they do by default), those users will be able to access
subsite resources with those permissions as well—but for that site collection only. The other site
collections are unaffected by the comings and goings of users in any other site collection.
Another thing to consider with managed paths is that if you have additional non-SharePoint
websites or web software you want to run in the same IIS Web Site virtual directory, SharePoint
automatically ignores anything that is on a path not specified as a managed path.
User Accounts and Permissions
For anyone to use SharePoint, there must be users. SharePoint leans toward organizing users
and permissions based on the users’ roles. So, a site owner would need to have full control of the
site, but a member would only need to be able to contribute.
SharePoint controls the user permissions that can be applied at the web application level. So if
necessary, you could block certain permissions entirely from ever being applied to users in the site
collections that the web application contained. At the site and site collection levels, individual
permissions can be combined to create permission levels, which are then applied to users or groups.
Individual Active Directory (AD) users can be added to SharePoint, but you can also simply
add domain security groups as well. Doing so lets you add numerous users to SharePoint that
might require the same permission levels at one time. It is also easier for SharePoint to handle
because it has limitations on how many separate security principals it can manage at one time.
It’s actually considered a SharePoint best practice to use AD security groups to add users rather
than individual domain users for that reason (the same applies if SharePoint is on a non-domain
server, only they’ll be local server users and security groups).
SharePoint uses SharePoint groups to organize users. There are three SharePoint groups
built in, Members, Visitors, and Owners, but you can also make your own. When you create a
SharePoint group, you assign permission levels to the group (permission levels are
combinations of individual permissions). Then, when you add a user, you choose the SharePoint group
they should belong to, and that group’s permission levels automatically apply to that user.
Default permission levels include Full Control (all permissions), Read (permissions that only
allow a user to view the site and its contents, but not add, edit, or delete), and Contribute (per-
missions that allow users to read, add, edit, or delete site content). So when planning your user
management strategy, keep permissions, permission levels, and SharePoint groups in mind.
Another thing to consider is that you can apply user policies to a web application that affect
all the site collections contained in them. A user policy is when you add a user to the web
application and explicitly allow or deny them permissions to access the web application (and
therefore all site collections contained therein). A user policy at the web application level overrides
permissions at the site collection level. This means a user account, given the correct permissions
in a user policy, can log into any site collection in the web application, even if that account is not
Search JabSto ::




Custom Search