Methods for Managing Site Templates
• Share templates across Site Collections as an .stp file (custom template).
• Import the .stp file into other site collection by adding the .stp file to the site template gallery.
• You can get additional templates from the Microsoft web site or other third parties.
• SharePoint Designer imports and exports packages (.cab files) that contain site templates.
• Exporting copies web parts, lists, and documents.
The Process of Installing Web Parts
• Custom Web part packages exported to other sites as cabinet, or .cab, files.
• Use the command line tool stsadm.exe to install Web parts from a Web part package on one or more virtual servers.
• stsadm.exe keeps a copy of the Web part package in the configuration database.
• Install web parts in \BIN. The assembly is available only to the web app. When you install Web parts on the BIN directory, an assembly is available only to the Web application.
• To use stsadm.exe to install a Web part, use the following command line:
stsadm.exe -o addwppack -filename <path to Web Part Package> [-url <URL>] [-globalinstall]
Where:
-filename = the path to the cab file that stores the web part
-url = URL of the Web application on which you install the Web part. To install on all the Web applications, leave out this tag
-globalinstall = optional parameter used to install on the GAC rather than \BIN
1. After installing web parts, add them to the site web part gallery.
2. Install the web part assembly.
3. Use the SharePoint Configureation Analyzer to check the installation.
4. Run the Configuration Analyzer again with the Save State Information option selected. This creates a reference XML file for recreating the mappings between GUIDs and typenames. This allows the analyzer to report the more readable types names of web part parts in its reports.
• The ASP.NET code access security feature assigns a level of trust based on SharePoint. You can configure this setting.
• By default, applications receive a level of trust appropriate for the evidence they present. For example, local applications must run in the My Computer zone with the Full trust permission set; applications located on a UNC share must run in the intranet zone with the LocalIntranet restricted permission set.
• You can change the levels of trust assigned to an application. To allow this, WSS 3.0 includes the ASP.NET default security policy files and policy files of its own. Code Access Security can be easily handled for an individual assembly if the administrator names it strongly and adds a policy for that assembly. The administrator can assign the appropriate level of trust to the application within the web.config file of that application.
• You can change the permissions associated with the installed assemblies, depending on the requirement and trust associated with the assemblies. The easiest way is to change the policy applied to the Web application; this raises or lowers the permissions given to all the associated assemblies.
• You can change the policy by editing the web.config file that contains the trust level attribute of the specific Web app.
• The levels of trust available are:
o Full
o WSS_Medium
o WSS_Minimal
To modify the policy level for a Web application:
1. Open the web.config file of the Web application.
2. Search for: <trust level=”WSS_Minimal” originUrl=”" />.
3. Change it to: <trust level=”WSS_Medium” originUrl=”" />.
4. Save the file.
5. Reset Internet Information Services (IIS) by using iisreset in the command prompt.
Managing Users and Site Permissions
Guidelines for Managing User Accounts
When installing WSS 3.0, you must select the account modes for users.
Two types of account modes, based on the methods used for creating the account:
• Domain mode – import users into existing WSS environment. To create new domain accounts, use Active Directory Users and Computers option.
• Active Directory mode – used by ISPs who provide WSS 3.0 services to users on Internet. ISPs create unique accounts in Active Directory in the org unit that you specify.
Important The Domain mode is permanent when you install. The account mode affects the database configuration on your server or farm. You can’t change the user account modes after creating the configuration database.
• Administration for user accounts is the same for both account modes.
• The administration of the user accounts is consistent for all account modes. You can use the same method to assign permissions to users for both the account modes.
• If you select Active Directory mode, you can’t access all the administrative tasks in the Central Administration site, such as creating a top-level site or enabling self-service web sites creation. You must use stsadm.exe or the object model to do these things with Active Directory mode.
• The Minimum Password Age group policy on the domain controller is set to 0 days. In case this group policy is not set, users an’t modify their passwords, unless they are administrators on the server.
• You can’t use Active Directory account mode for WSS 3.0 installations on Active Directory Domain Controllers.
Best Practices for Managing User Groups
You should manage users with SharePoint groups, custom groups based on your organizational requirements.
Best practices for SharePoint groups:
1. Assigns permissions to groups, rather than to users. It’s difficult to maintain user accounts.
2. Three default permission groups:
o Owners: Full control.
o Members: View pages and edit documents.
o Visitors: Read-only.
3. Owners of information must be able to assign permissions to other users who need to share that information.
4. Might need to create custom group when default groups do not meet the security needs of a site.
How to Customize Site Permissions
Site permissions: Full Control, Design, Contribute, and Read.
Customizing Security Configurations
What Are the Content Security Levels Available for a WSS Site?
Default site groups:
• Guest,
• Reader,
• Member,
• Contributor,
• Content Manager,
• Web Designer,
• Administrator
Considerations for Configuring Security for Lists and Items
• If you have relatively few items that require restrictive permissions, you should set permissions from the site level downward to the item level.
• If a site contains multiple lists with complex permission requirements, you just set permissions for the list and then for the items.
• Minimize giving individual permissions to items; preferable to create new libraries in which the same group of users can be given access to the content.
• Complicated permissions strain the server when processing pages.
The Role of IRM in WSS 3.0
• IRM (Information rights management) integrates with Microsoft Windows Rights Management Services (RMS) to provide a centralized way to control document access. RMS provides information protection through persistent usage policies.
• WSS 3.0 supports IRM for documents in document libraries.
• To implement IRM for a file type, you must install a protector for the file type. This controls the encryption and decryption of rights-managed documents for a file type. IRM helps you control:
o Actions that users can perform on documents they open from WSS 3.0 document libraries.
o Sensitive information on the server.
For example, if you make a document library available to users within your organization for previewing upcoming products, you can use IRM to prevent them from publishing sensitive content for external audiences. When users upload a document from a document library, the IRM permissions of the document determine the users’ permissions to access the content in WSS 3.0 security settings.
• To use IRM in WSS 3.0, you must install RMS Client with Service Pack 1 (SP1) on every WFE on your farm.
To use IRM, do the following:
1. To open IRM, click Central Admin and click Operations.
2. On the Operations page, click Security Configuration.
3. Click Information Rights Management.
What Are the Various User Rights in WSS 3.0?
• You can grant access permissions to WSS 3.0 sites to users through membership in site groups. When permissions are disabled, they become unavailable for site groups and the users in those groups.
• Each Web app has 33 rights available to the server. You can enable or disable these rights but cannot assign them directly to users.
• You must assign the rights to site groups.
• To enable or disable permissions on a Web application:
1. Go to Start and click All Programs.
2. Click Administrative Tools, and then click SharePoint 3.0 Central Administration.
3. Click the Application Management link on the page, and then click the User rights for Web application link.
4. Select or clear the specific permissions and click OK.
• Categories of user rights: list, site, and personal rights.
Considerations for Managing Access to Web Applications
• Manage access to Web applications with Web application policies.
• Use these policies to grant or deny permissions for user or service accounts across an entire Web application.
• You can permit a service account that is used by another process to access part of or an entire Web application.
• Using the policies, you can restrict access of users, such as preventing users from modifying Web parts. The Search service provides a special policy that gives access to the entire Web app.
• Use the SharePoint Central Administration site to set up web application policies. Site or Site Collection owners cannot view the users or permissions assigned to them. You
• A Web application policy is available for controlling anonymous access.
Adding a Policy Permission Level
The steps for adding a policy permission level are:
1. Click Central Admin, click Application Management > Application Security > Policy for Web Application.
2. Click Manage Policy Permission Levels.
3. On the top bar, click Add Permission Policy Level.
4. Enter a name and a description for the policy level and select the appropriate permissions.
When adding a policy permission level, you might consider denial of permission. Denial of permission prevents users from having that permission, even if permission is granted in a site collection or site.
Adding Users to a Policy
The steps for adding a user to a policy are:
1. Click Manage Permission Policy in the Quick Launch section in the left navigation bar.
2. Click Add Users.
3. Specify the user or users to whom this policy applies, select a permission level, and click OK.
The considerations for adding users to a policy are:
• Account operates as System option - The name of the account does not appear in the form of a system in logs and reports.
• You can use policies to deny or allow access across a Web application.
• If an action is denied at the Web application policy level, no user can perform that action in any site.
• Site-level permission cannot restrict the users who have the permission granted in the policy.
• Share templates across Site Collections as an .stp file (custom template).
• Import the .stp file into other site collection by adding the .stp file to the site template gallery.
• You can get additional templates from the Microsoft web site or other third parties.
• SharePoint Designer imports and exports packages (.cab files) that contain site templates.
• Exporting copies web parts, lists, and documents.
The Process of Installing Web Parts
• Custom Web part packages exported to other sites as cabinet, or .cab, files.
• Use the command line tool stsadm.exe to install Web parts from a Web part package on one or more virtual servers.
• stsadm.exe keeps a copy of the Web part package in the configuration database.
• Install web parts in \BIN. The assembly is available only to the web app. When you install Web parts on the BIN directory, an assembly is available only to the Web application.
• To use stsadm.exe to install a Web part, use the following command line:
stsadm.exe -o addwppack -filename <path to Web Part Package> [-url <URL>] [-globalinstall]
Where:
-filename = the path to the cab file that stores the web part
-url = URL of the Web application on which you install the Web part. To install on all the Web applications, leave out this tag
-globalinstall = optional parameter used to install on the GAC rather than \BIN
1. After installing web parts, add them to the site web part gallery.
2. Install the web part assembly.
3. Use the SharePoint Configureation Analyzer to check the installation.
4. Run the Configuration Analyzer again with the Save State Information option selected. This creates a reference XML file for recreating the mappings between GUIDs and typenames. This allows the analyzer to report the more readable types names of web part parts in its reports.
• The ASP.NET code access security feature assigns a level of trust based on SharePoint. You can configure this setting.
• By default, applications receive a level of trust appropriate for the evidence they present. For example, local applications must run in the My Computer zone with the Full trust permission set; applications located on a UNC share must run in the intranet zone with the LocalIntranet restricted permission set.
• You can change the levels of trust assigned to an application. To allow this, WSS 3.0 includes the ASP.NET default security policy files and policy files of its own. Code Access Security can be easily handled for an individual assembly if the administrator names it strongly and adds a policy for that assembly. The administrator can assign the appropriate level of trust to the application within the web.config file of that application.
• You can change the permissions associated with the installed assemblies, depending on the requirement and trust associated with the assemblies. The easiest way is to change the policy applied to the Web application; this raises or lowers the permissions given to all the associated assemblies.
• You can change the policy by editing the web.config file that contains the trust level attribute of the specific Web app.
• The levels of trust available are:
o Full
o WSS_Medium
o WSS_Minimal
To modify the policy level for a Web application:
1. Open the web.config file of the Web application.
2. Search for: <trust level=”WSS_Minimal” originUrl=”" />.
3. Change it to: <trust level=”WSS_Medium” originUrl=”" />.
4. Save the file.
5. Reset Internet Information Services (IIS) by using iisreset in the command prompt.
Managing Users and Site Permissions
Guidelines for Managing User Accounts
When installing WSS 3.0, you must select the account modes for users.
Two types of account modes, based on the methods used for creating the account:
• Domain mode – import users into existing WSS environment. To create new domain accounts, use Active Directory Users and Computers option.
• Active Directory mode – used by ISPs who provide WSS 3.0 services to users on Internet. ISPs create unique accounts in Active Directory in the org unit that you specify.
Important The Domain mode is permanent when you install. The account mode affects the database configuration on your server or farm. You can’t change the user account modes after creating the configuration database.
• Administration for user accounts is the same for both account modes.
• The administration of the user accounts is consistent for all account modes. You can use the same method to assign permissions to users for both the account modes.
• If you select Active Directory mode, you can’t access all the administrative tasks in the Central Administration site, such as creating a top-level site or enabling self-service web sites creation. You must use stsadm.exe or the object model to do these things with Active Directory mode.
• The Minimum Password Age group policy on the domain controller is set to 0 days. In case this group policy is not set, users an’t modify their passwords, unless they are administrators on the server.
• You can’t use Active Directory account mode for WSS 3.0 installations on Active Directory Domain Controllers.
Best Practices for Managing User Groups
You should manage users with SharePoint groups, custom groups based on your organizational requirements.
Best practices for SharePoint groups:
1. Assigns permissions to groups, rather than to users. It’s difficult to maintain user accounts.
2. Three default permission groups:
o Owners: Full control.
o Members: View pages and edit documents.
o Visitors: Read-only.
3. Owners of information must be able to assign permissions to other users who need to share that information.
4. Might need to create custom group when default groups do not meet the security needs of a site.
How to Customize Site Permissions
Site permissions: Full Control, Design, Contribute, and Read.
Customizing Security Configurations
What Are the Content Security Levels Available for a WSS Site?
Default site groups:
• Guest,
• Reader,
• Member,
• Contributor,
• Content Manager,
• Web Designer,
• Administrator
Considerations for Configuring Security for Lists and Items
• If you have relatively few items that require restrictive permissions, you should set permissions from the site level downward to the item level.
• If a site contains multiple lists with complex permission requirements, you just set permissions for the list and then for the items.
• Minimize giving individual permissions to items; preferable to create new libraries in which the same group of users can be given access to the content.
• Complicated permissions strain the server when processing pages.
The Role of IRM in WSS 3.0
• IRM (Information rights management) integrates with Microsoft Windows Rights Management Services (RMS) to provide a centralized way to control document access. RMS provides information protection through persistent usage policies.
• WSS 3.0 supports IRM for documents in document libraries.
• To implement IRM for a file type, you must install a protector for the file type. This controls the encryption and decryption of rights-managed documents for a file type. IRM helps you control:
o Actions that users can perform on documents they open from WSS 3.0 document libraries.
o Sensitive information on the server.
For example, if you make a document library available to users within your organization for previewing upcoming products, you can use IRM to prevent them from publishing sensitive content for external audiences. When users upload a document from a document library, the IRM permissions of the document determine the users’ permissions to access the content in WSS 3.0 security settings.
• To use IRM in WSS 3.0, you must install RMS Client with Service Pack 1 (SP1) on every WFE on your farm.
To use IRM, do the following:
1. To open IRM, click Central Admin and click Operations.
2. On the Operations page, click Security Configuration.
3. Click Information Rights Management.
What Are the Various User Rights in WSS 3.0?
• You can grant access permissions to WSS 3.0 sites to users through membership in site groups. When permissions are disabled, they become unavailable for site groups and the users in those groups.
• Each Web app has 33 rights available to the server. You can enable or disable these rights but cannot assign them directly to users.
• You must assign the rights to site groups.
• To enable or disable permissions on a Web application:
1. Go to Start and click All Programs.
2. Click Administrative Tools, and then click SharePoint 3.0 Central Administration.
3. Click the Application Management link on the page, and then click the User rights for Web application link.
4. Select or clear the specific permissions and click OK.
• Categories of user rights: list, site, and personal rights.
Considerations for Managing Access to Web Applications
• Manage access to Web applications with Web application policies.
• Use these policies to grant or deny permissions for user or service accounts across an entire Web application.
• You can permit a service account that is used by another process to access part of or an entire Web application.
• Using the policies, you can restrict access of users, such as preventing users from modifying Web parts. The Search service provides a special policy that gives access to the entire Web app.
• Use the SharePoint Central Administration site to set up web application policies. Site or Site Collection owners cannot view the users or permissions assigned to them. You
• A Web application policy is available for controlling anonymous access.
Adding a Policy Permission Level
The steps for adding a policy permission level are:
1. Click Central Admin, click Application Management > Application Security > Policy for Web Application.
2. Click Manage Policy Permission Levels.
3. On the top bar, click Add Permission Policy Level.
4. Enter a name and a description for the policy level and select the appropriate permissions.
When adding a policy permission level, you might consider denial of permission. Denial of permission prevents users from having that permission, even if permission is granted in a site collection or site.
Adding Users to a Policy
The steps for adding a user to a policy are:
1. Click Manage Permission Policy in the Quick Launch section in the left navigation bar.
2. Click Add Users.
3. Specify the user or users to whom this policy applies, select a permission level, and click OK.
The considerations for adding users to a policy are:
• Account operates as System option - The name of the account does not appear in the form of a system in logs and reports.
• You can use policies to deny or allow access across a Web application.
• If an action is denied at the Web application policy level, no user can perform that action in any site.
• Site-level permission cannot restrict the users who have the permission granted in the policy.
Comments
Post a Comment