SharePoint: Reviewing the New Features in Version 2 - Page 2

By Jacqueline Emigh | Posted Jan 2, 2003
Page 2 of 2   |  Back to Page 1
Print ArticleEmail Article
  • Share on Facebook
  • Share on Twitter
  • Share on LinkedIn

Security: IIS Integration, Permissions
Integration between SPS and IIS is still problematic, according to English. "Do not install the latest IIS security hot fixes with SharePoint," he recommended. Otherwise, SPS is likely to crash. "The anti-virus hot fixes between service pack releases is what we're talking about."

Also, SPS permissions are less fine-grained than those in STS. "How can I configure file and folder level security on documents? I want to be able to add a document and have myself and a select group of people view the document. I then want to take another document in the same folder and assign permissions. Is this possible yet?" asked one reader, in Microsoft's SharePoint forum.

A Microsoft consultant responded: "You cannot do file level security and even if you could, why would you want that? You can do folder-level security and all coordinators will have to see the file. The only thing you can do is put a password in the document."

Another administrator raised a similar kind of problem. "I am able to manage my workspace from any PC that I log in (to) with local 'Administrator' ID. What modification should I make on my SPS server so the local Admin ID of any PC cannot manage my workspace. Security settings on the SPS server are 'Coordinator': myself and server's Local Administrator group; 'Reader': Everyone.'"

The administrator said he'd come up with two possible workarounds: "(1) Create a new ID for the coordinator and remove the local admin from coordinator rights; (2) Use a different password for the SharePoint administrator than for the workstation local admin."

"As to (1), this cannot be done," came the reply. "The Local Admin account automatically (has) access to SharePoint security and can add itself to the coordinator role no matter what. This is for data recovery."

Due to the user roles in STS, though, "There is no need for you to go in and mess with the NTFS permissions any more. Roles can be configured through the Web page. You could give a certain user a certain role to be able to add something, but not the other; to be able to do certain tasks on the Web site, but not other tasks," according to Khalaf.

STS's customizable roles include administrator, advanced author, author, contributor, and browser. In contrast, roles in SPS are currently limited to administrator, coordinator, author, and reader.

Version 2 Waiting in the Wings
In version 2 of SPS/STS, greater integration with Commerce Server/BizTalk Server is also in the cards, according to a recent report by the Meta Group. Microsoft has already posted four demos of integration between STS and Commerce Server/BizTalk Server on its Web site. The scenariors include purchase orders and catalog management, for instance.

Microsoft's existing SPS Integration Pack already offers some integration between SPS2001 and CMS2001, mainly in terms of integration between repositories and "publish to Web" features. "[But] central to Microsoft's SPS2 plans are promises to resolve SPS1's weaknesses -- notably integrated personalization, single sign-on, stronger ties to Content Management Server [CMS] and BizTalk Server, and provision of user and application management servers," according to Meta's report.

"With SPS2 and CMS2002, Microsoft plans to provide stronger content publishing delegration, providing users with managed capability to publish documents directly to the Web (roles, approvals, etc.)."

Meta anticipates that Microsoft will enable single sign-on and personalization -- name, group, basic roles, subscriptions -- through integration with Active Directory.

"However, such personalization will be neither deep not dynamic -- richer capabilities [e.g. integration to usage analysis] will likely come in later SPS versions. We also expect deeper personalization to emerge as coexisting infrastructure alongside the directory [e.g. a personalization database] to avoid bloating AD. IT planners should avoid putting all user attributes into a directory and isolate generic attributes that should live in the directory versus personalization-specific attributes living in the database," according to the report.

Organizations planning integration between SPS2 and AD should focus on defining schema elements that support sign-on and simple role-based access access, while also involving "their security/privacy, server, and directory teams to identify likely changes and dependencies as part of AD and .Net deployment (e.g. operations, administration, and topology changes."

The Meta Group analysts added that they don't expect Microsoft to offer "generic" single sign-on capabilities beyond LDAP services. Instead, Microsoft will "cede cross-portal provisioning, policy management, and cross-portal unified access to companies such as IBM, Novell, CA, Netegrity, and possibly, Microsoft companion vendors with SSO expertise [e.g. Corechange.]"


» See All Articles by Columnist Jacqueline Emigh


Comment and Contribute
(Maximum characters: 1200). You have
characters left.
Get the Latest Scoop with Enterprise Networking Planet Newsletter