Uncategorized

Windows Rights Management Services, Microsoft SharePoint Products and Technologies, and Forest Boundaries

I recently was asked about the possibility of implementing Windows Rights Management Services with Microsoft Office SharePoint Server 2007 in a resource forest, or otherwise, the Microsoft Office SharePoint Server 2007 deployment was in a forest other than that where the users reside (login forest).  In this particular scenario, a one-way non-transitive trust was implemented, which provided an isolation boundary between the resource and login forest.

Microsoft Office SharePoint Server 2007 is generally supportive of the resource forest concept (see posts tagged Cross-Forest Hosting) however, with the Windows Rights Management Services (RMS) cluster in a forest other than that of the resource forest, problems will surface in that SharePoint will need to obtain a RMS user certificate / RAC (from the /_wmcs/certification pipeline) that is trusted by the RMS Licensing pipeline(s) configured in SharePoint 3.0 Central Administration – as a result there are two (2) requirements during the certification process that Microsoft Office SharePoint Server 2007 is unable to support when the RMS cluster resides outside of the resource forest:

  1. Authentication
  2. Boundaries

Authentication

Since Microsoft Office SharePoint Server 2007 is deployed in the resource forest, the identities associated with the individual IIS application pools are also most likely identities derived from the resource forest.  Those identities are not valid in the login forest because the one way trust is the wrong way in this particular scenario.

Boundaries

The RMS certification service can only issues certificates to identities from the same forest as the RMS cluster.

Possible Solutions

Deploy an RMS certification cluster in the resource forest and configure the RMS server in the login forest to trust the user certificates issues from this server or optionally (haven’t tested this theory ;-)), implement identities for the IIS application pools from the login forest.

The result of an implementation that does not meet the requirements of RMS will be presented in the Event Log on the front-end Web servers as:

Event Type:        Error

Event Source:    Windows SharePoint Services 3

Event Category:                IRM

Event ID:              5058

Date:                     6/10/2009

Time:                     8:47:07 PM

User:                     N/A

Computer:          <WFE_SERVER>

Description:

Information Rights Management (IRM): There was a problem while trying to activate a rights account certificate.

Unspecified connection error. Try activating again later.

Additional Data

Error value: 8004cf3b

Server URL: /_wmcs/certification">/_wmcs/certification">/_wmcs/certification">https://<RMS_CLUSTER>/_wmcs/certification

Event Type:        Error

Event Source:    Windows SharePoint Services 3

Event Category:                IRM

Event ID:              5133

Date:                     6/10/2009

Time:                     8:47:07 PM

User:                     N/A

Computer:          <SERVER>

Description:

Information Rights Management (IRM): There was a problem while obtaining a Rights Management Services (RMS) group identity certificate (GIC).

A GIC is an essential credential that allows a user to read/view rights protected documents.

Additional Data

Error value: 8004cf3b

Standard
Uncategorized

Moving site collections between domains…

Moving site collections between domains is not a common operation, but occurs frequently enough to provide some prescriptive guidance. 


User Accounts


SharePoint maintains the security identifiers of user accounts as opposed to just usernames, as a result, when restoring a site collection to a farm in a domain other than that where the original source site collection was located, those usernames are no longer recognized regardless as to whether or not those usernames were recreated in the target domain.  STSADM provides an operation suited to address this potential issue in the migrateuser operation which will effectively resolve the security identifiers of the users.


Migrating User Accounts


STSADM -o migrateuser migrates a user account in Microsoft Windows SharePoint Services 3.0 to a new user name and binary identifier (security identifier).


Syntax


stsadm -o migrateuser


   -oldlogin <domainname>


   -newlogin <domainname>


   [-ignoresidhistory]


-oldlogin specifies the credentials of the source account (account to be migrated) and -newlogin the target account or destination credentials of the new account replacing the source account.  When specifying the -ignoresidhistory argument the security identifier history of the destination user is checked to determine and match the name of the old user or otherwise the meta data is ignored.

Standard
Uncategorized

Excel Calculation Services for Cross-Forest Deployments

While on vacation, yes working ;-), I was asked to look into an issue where Excel Calculation Services was deployed in a cross-forest environment; specifically where Excel Services is deployed on server A residing in Forest 1 and the clients requesting workbooks reside in Forest 2. Forest 2 does not trust Forest 1; however, Forest 1 trusts Forest 2. The Excel Calculation Services topology in this scenario was fairly basic where Excel Web Access, Web Services, and the Calculation Services are distributed across two network load-balanced web front-end servers and Excel Calculation Services and any UDF assemblies are hosted on a separate application server also servicing the Office SharePoint Server Search indexing service.


The Excel Calculation Services topology is supportive of a cross-forest deployment and only needed one minor adjustment. In a scenario such as that described above to allow workbooks in trusted file locations to be access across domains [in this scenario, the Windows SharePoint Services Web application is defined as a Trusted File Location and includes all children in the trust] Excel Calculation Services must be configured to allow cross domain access using the SharePoint administration tool (STSADM). To allow access across domains you will need to run the following STSADM operation on the application server hosting the Excel Calculation Services component:


stsadm.exe -o Set-EcsSecurity -Ssp <SSP name> -AllowCrossDomainAccess true


About the Components

The Excel Calculation Services component is the “engine” of Excel Calculation Services and handles loading, calculation, session management, and external data refresh for workbooks.

The Excel Web Access component is a Web part used to display and enable interaction with Microsoft Office Excel workbooks in a browser.

The Excel Web Services component is a Web service hosted in Microsoft Office SharePoint Server 2007 that provides methods that a developer can use as an API to build custom applications based on Microsoft Office Excel workbooks.

Basic Component Distribution

Standard
Uncategorized

Configuring SharePoint Products and Technologies for Cross-Forest Deployments

 



People Picker works both cross-domain and cross-forest in one and two way trust environments.

People Picker will issue queries to all two-way trusted domains and two-way trusted forests to search People & Groups out-of-the-box. *People Picker uses the Windows SharePoint Services Web Application logon identity to access the target domain/forest.  If the Web Application pool does not have access to the target domain/forest, People Picker will need to be configured to use an account with access to the target domain/forest using the following STSADM operations:

STSADM –o setapppassword –password <password>
which establishes the Credential Key used to encrypt/decrypt the service logon identity in the configuration database. This must be configured identically on all servers that have the Windows SharePoint Services Web Application service configured.

NOTE This operation not required in scenarios where the target domain/forest is trusted. Each server farm should use a unique credential key.

STSADM.exe –o setproperty –pn peoplepicker-searchadforests –pv <domain(s)/forests(s)> -url http://<webapp&gt;

The format of

<domain(s)/forests(s)>
is a list of
forest:DnsName,LoginName,Password
or
domain:DnsName,LoginName,Password
separated by a semicolon where necessary in scenarios where the target forest/domain is trusted, People Picker can be configured using
forest:DnsName
or
domain:DnsName

Standard
Uncategorized

Renaming a Resource Forest on SharePoint Servers

* I haven’t revisted this post in awhile and thought I would include some additional information on the topic; in response to dkbobe‘s questions surrounding updating the user information; you can use the SPUserUtility to update the tp_Login column to reflect the new domain – more information on this tool can be found at Keith Richie’s blog @ http://blogs.msdn.com/krichie.

I was pleased to see my mention in Joel Oleson’s SharePoint Blog on the Impacts of Renaming a Resource Forest on SharePoint Servers; I’m hoping to elaborate more here as there is little documentation on this topic; at least from the perspective of impacts to SharePoint services.  The good news is that SharePoint services can be recovered after renaming the resource forest without a great deal of configuration management and member server preperation.  One item to note, do NOT run rendom /clean on the SharePoint servers; otherwise, as opposed to only having to reboot the members twice to learn the domain name changes you will be required to disjoin the server from its current forest and rejoin the new forest.  Rebooting twice ensures that each member computer learns of the domain name changes (LSA policy changes) and propagates them to all applications and services running on the member computer. Note that each computer must be restarted by logging into the computer and using the Shutdown/Restart administrative option. Computers must not be restarted by turning off the machine power and then turning it back on, as a result of this you may experience the same behavior as have you run the rendom /clean tool.  As far as the recovery aspect is concerned; recover the servers in the order of (assuming a typical topology), active Microsoft SQL Server node, passive SQL Server node, primary SharePoint Portal Server Web/Search server, SharePoint Portal Server Index server, secondary SharePoint Portal Server Web/Search server.  This will ensure the most rapid restoration of services.  As a prerequisite it is recommended that you collect each member servers IP address and local Administrator credentials in the event the machine is renamed or their are issues impacting name resolution that may prevent access by name.  Assuming the machines have successfully learned of the domain name changes; you will need to reestablish the password used for the service, appication pool, and access accounts for the following service, appication pool, and access accounts  in this order:


  1. Active SQL Server Node:  Cluster Service, SQL Server Agent and MSSQLServer
  2. Passive SQL Server Node:  SQL Server Agent and MSSQLServer
  3. Primary Front-End Web Server:  MSSharePointPortalAppPool and CentralAdminAppPool (NOTE IISRESET when complete)
  4. Primary Front-End Web Server:  SharePoint Timer, SharePoint Portal Administration, Microsoft SharePointPS Search, and SharePoint Portal Alert services
  5. Primary Front-End Web Server:  Configuration Database Administration Account, Default Content Access Account, and SharePoint Central Administration Account (NOTE IISRESET when complete)
  6. Repeat steps 3-5 on the Index/Job Server
  7. Repeat steps 3-5 on the Secondary Front-End Web Server

Standard