IRM (Information Rights Management) in SharePoint

This is just a very brief review from my reading of a MS white paper coming with the ECM starter kit.

IRM allows you to have control over a document after it’s downloaded from SharePoint.

This is how is works:

• You need to install/configure IRM at server farm first
• You can configure the Doc Lib to use certain IRM policy (such as No Print, or downloaded copy expires after x days). This policy applies to whole doc lib and you can’t customized at folder level.
• Nothing important happens when you upload a file
• When a support file (you have to install the “protector” for this file type. MOSS 2007 has word, excel, and powerpoint covered) is being downloaded, WSS will encrypt it and send you back the encrypted version.
• You need a IRM-ready viewer to view these files (Office 2003 is fine), or you need to install necessary components for your viewer.
• Your local viewer need to connect to a “Windows Rights management Services” server to decrypt the file.

For Word, Excel, and PowerPoint files, meta data are not encrypted.

Automatically login with domain account

I believe the majority of the SharePoint sites are set up to use Windows Active Directory login. However if the site is set up using a domain name, IE will treat it as a “Internet” zone, and you will be prompted with login window. That’s because the default security setting of Internet zone is not to automatically login with your user name and password.

The best practice to get around this issue is to add your site to the “Trusted Sites” list, and configure it to automatically login (which is the default setting already). Sometimes the Trusted Sites list is locked by a corporate group policy and network admins have to make that change. You have to run

Gpupdate /force

to refresh the group policy on your desktop.

If you want to add multiple sites to the Trusted Sites, this syntax will do it:

*.sharepoint.mydomain.com

Cannot rename file if you don’t have delete permission

In SharePoint, there are different “Permission Levels” you can define (Site Actions->Manage All Site Settings->Advanced Permissions->Settings->Permission Levels). One of the permission is delete.  Recently I just found out that in document library, SharePoint requires “delete” permission to rename a file, which makes sense (but our users will scream on this). I didn’t find the confirmation in the help/documentation but this blog confirms it.

Error event ID 6398 and 6482 – about security rights of OSearch service

I have huge number of following erros in the event log “Application folder”:

Event ID 6398
The Execute method of job definition Microsoft.Office.Server.Search.Administration.IndexingScheduleJobDefinition (ID b94e8106-b5f9-4c2d-ad98-2871bcc4c669) threw an exception. More information is included below.
Retrieving the COM class factory for component with CLSID {3D42CCB1-4665-4620-92A3-478F47389230} failed due to the following error: 80070005.

And this:

Event ID 6482
Application Server Administration job failed for service instance Microsoft.Office.Server.Search.Administration.SearchServiceInstance (7d8b475a-6dda-47e8-8ab7-dbd171926b39).
Reason: Retrieving the COM class factory for component with CLSID {3D42CCB1-4665-4620-92A3-478F47389230} failed due to the following error: 8007000e.

Actually in “System” folder there are 2 events revealing more information about it. It turned out that I need to grant the account that is used by “Office SharePoint Server Search” with Local Activation rights.

Open Component Services->DCOM Config->OSearch->Properties->Security, I added Network Service (may not need) and the account to run “Office SharePoint Server Search” service and gave them “Local Activation” rights (in “Launch and Activation Permissions” group). Those error messages do not appear anymore.

This doesn’t limit to this service and SharePoint only. You can actually search on registry on that CLSID and it might be different DCOM object. For example the other day I got same error with CLSID
{61738644-F196-11D0-9953-00C04FD919C1} and it turned out to IIS WAMREG admin Service.

Target Audiences – doesn’t work with domain groups

I have a webpart that I want to restrict the access (kind of) by specifying Target Audiences. I created a SharePoint security group (i.e. SP-Group1) which has domain users AND a domain group (say AD-group1) in it. The webpart works for those who were directly added to SP-Group1 but not for those only in AD-group1. So nested group doesn’t work in “Target Audiences”? (I’m pretty sure nested domain groups in SharePoint groups work in permission/login configurations).

Then I tried to specify the domain group AD-group1 directly in that Target Audiences field but it didn’t work. It (and the “Select Audiences” dialog) can not find the domain group at all. It looks like it doesn’t make a trip to domain controller at all!

I also tried to create a new audience in SSP. When I was trying to add a rule saying this audience should contain all members of a domain group AD-group1, that interface can’t find AD-group1 either. Someone said you need to import the profiles from the Active Directory first. This isn’t really nice.

I will try it later since our DC has more than 10,000 users and I don’t want to import everyone to my site.  So I will just add everyone to the SharePoint group directly.

User permissions findings

• When adding user by assigning individual rights, if only give user/group “Limited Access”, user will not be able to see the homepage of the site. Need to give user ‘Full access’ to see the home page (WHY?).
• If complete disable user access to Shared Documents, user can’t load home page. (?)
• When directly give use access to a sub folder, that user will be added to the parent folders with ‘Limited Access’ – all the way to “Shared Documents”
• When we remove a user from a folder, it will removed from sub-folders even sub-folders already removed permission inheritance!
• When we add a user to a folder, this user will NOT be added to the sub-folders if the sub-folders have been removed permission inheritance, which makes sense. Also any permission role changes to the parent folder will NOT be populated to sub-folders if permission inheritance is already canceled.
• For user to upload file, user has to have at least ‘View’ access to the document library (root) itself. The actual folder to which user tries to upload file may or may not inherit permission from doc lib.
• For user to start a workflow (the default ones), user need ‘Edit’ access on Doc Lib root.

Webpart security

If the webpart need to access Sharepoint server info, there are 3 options when deploying the webpart in security context:

1. Deploy to GAC, and no other settings need to be changed. Downside: need to recycle application pool when upgrade; webpart will be available to all sites in same server.
2. Deploy to \Bin, and change trust level in web.config to at least WSS_Medium. Downside: this grant the whole ASP.NET application higher access rights. This is very convinient in development stage.
3. Deploy to \Bin, and change trust level in web.config to wss_custom, then change/add the config file in \Program Files\Common Files\Microsoft Shared\web server extensions\12\config. This is safer because it only grant access to specified webparts. Recommended for production environment.

In any case, the webpart need to be signed (obviously) and marked as ‘SafeControl’ in web.config file.

If the webpart doesn’t need to access server resource, only need to mark it as SafeControl in web.config and add this line:

[assembly: AllowPartiallyTrustedCallers]

to the source file.