How SharePoint 2010 Finds and Updates a User’s Work E-mail Address

In the first part of this series about the SharePoint 2010 IRM implementation, I provided an overview of the technology and why we might use it to enhance SharePoint’s access controls. In this second article, I’ll look closely at the key piece of information that bridges the gap between SharePoint and a Rights Management Server – namely, a user’s e-mail address. RMS relies on a user’s e-mail address in this way outside of the SharePoint world as well; this is an RMS requirement. SharePoint’s implementation attempts to work with this, even though SharePoint doesn’t require a user to have an e-mail address for most things to work.

IRM support has been built in to SharePoint as a WSS (now Foundation) technology. WSS/Foundation don’t have a User Profile Service, so the e-mail address information that RMS requires needs to come from somewhere else. As we’ll see below, it wouldn’t be optimal to query Active Directory for that value whenever RMS-protected content is requested, so SharePoint uses the value it (hopefully) already has in the lowest common denominator (WSS/Foundation) user information container. As we’ll see, reliably populating and updating that information is less straight-forward than it would appear at a glance.

Posts in this Series

SharePoint 2010 On-Premises with AD RMS:

• Part 1 – Protecting SharePoint 2010 with Information Rights Management
• Part 2 – How SharePoint 2010 Finds and Updates a User’s Work E-mail Address
• Part 3 – How SharePoint 2010 Authentication Provider Types Alter the Initial Population of Work E-mail Values
• Part 4 – Inspecting an AD RMS Request from SharePoint 2010
• Part 5 – RMS Publishing Permissions for SharePoint 2010 Application Pool Identities
• Part 6 – RMS AD Caching for SharePoint 2010 Users
• Part 7 – RMS Use Licenses, Offline Access and Rights Revocation with SharePoint 2010
• Part 8 – SharePoint 2010 with AD RMS Process Diagram and Summary

Planned posts, covering newer versions and new twists:

• SharePoint 2010 with Windows Server 2012 AD RMS
• SharePoint 2013 with AD RMS
• SharePoint On-Premises with AADRM
• SharePoint Online with AD RMS
• SharePoint Online with AADRM
• SharePoint with RMS Trusts including ADFS
• Search, Rehydrated Users and RMS

 

Overview: LDAP Queries, E-mail Claims and Timer Jobs

A user’s Work E-mail Address can get populated or updated in a few different ways.

1. When an Active Directory user is granted access to a site as an individual, or when an un-named user (added by Group) logs on to a Site for the first time, SharePoint issues an LDAP Global Catalogue query for the user and writes the LDAP mail attribute to the newly-created User Information List entry’s Work E-mail field, assuming the mail attribute is populated for that user in Active Directory. Along these lines, a user might not be able to access RMS-protected content if the Work E-mail value is inaccurate or mismatched with Active Directory (a bit more on this later).
2. For SAML Claims users, this varies a bit. For now it’s worth noting that the Trusted Identity Provider needs to have a Claims Mapping for E-mail Address. If a user asserts an E-mail Claim (corresponding to this mapping), SharePoint will populate the Work E-mail Address with that value. I’ll pick this apart more in the next post, and also touch on FBA.
3. User Profile to SharePoint Synchronisation Timer Jobs keep this data fresh and plug a few other gaps. Assume a user has an empty Work E-mail attribute in the User Information List, or possibly that the value is incorrect, but also assume that they have accurate information in Active Directory. Say the User’s e-mail address is imported in to SharePoint’s User Profile Service Application from some attribute other than mail or possibly from another source like an HR system. Perhaps the information has changed and SharePoint now has a stale value. For these cases (or rather, in all cases, not just these less common configurations), there are two Timer Jobs associated with the User Profile Service Application that push User Profile data to new users of a Site Collection (Quick) or push all changed profile properties to all existing User Information Lists (Full).

The User Profile to SharePoint Synchronisation Timer Jobs in Central Administration

How the User Profile to SharePoint Synchronisation Timer Jobs can Normalise User Information List Data

For the rest of this post I’ll inspect how these Timer Jobs can and should be used, concerning myself less with how the fields are updated than with how we maintain them over time. In many ways these Timer Jobs become the key tool for gaining control of Work E-mail attributes within a Site Collection. This is important since there’s a reasonable chance that at least some users will never be able to access RMS-protected content in SharePoint by default, or they may lose access over time without them.

Timer Job Scope

By default, these Timer Jobs only target “Active Users”. This is by design. As I understand it, the jobs have been implemented in this way on account of possible performance issues associated with the bulk of these lists (one item per-user per-Site Collection) and the demands of these Timer Jobs at high scale. What’s probably unclear (if you haven’t encountered this before) is that, a user is considered “active” if he or she created or modified any data in the Site Collection. This means that Visitors (Readers) will not be within the scope of the Timer Jobs. They would therefor only have access to RMS-protected content if their User Information List Work E-mail value was initially populated successfully as described in points 1 and 2 above.

A User Information List in a SharePoint content database

The tp_IsActive column in the UserInfo table constrains the scope of the Timer Jobs.

Disclaimer: Of course, this data shouldn’t be queried on an active system! This is a backup/restore of a database for interrogation purposes a dev environment with good snapshots.

The Old Work-Around

Back in the day, people worked around this behaviour by deleting and re-adding a user to the Site Collection. Messy! However, this knowledge base article sheds some more light on how we got where we are:

When a User has Contribute or higher permissions to a Site Collection, that user will be marked as Active on the User Info list (Site Membership), and their profile will be imported. For users that don’t have this flag, their profile will not be imported. While deleting and re-adding the user from the Site Collection will import their Profile, and they will display correctly, they will not be continuously sync’d, meaning that further changes to the Profile will not be automatically imported to that Site Collection.

This Design is to improve SharePoint performance. On certain Site Collections (such as the Root of a Web Application), we will typically see hundreds of thousands of users in the Site Membership, but very few having Contribute or higher permissions. We would see a significant performance impact if SharePoint were to import all those non-Contribute users every hour.

Changing the Scope of the Timer Jobs (and some risks that come with doing so)

There is another option, if you’re cool with the implications. The scope of the Timer Jobs can be modified to ignore the tp_IsActive flag with a little-known parameter of STSADM -o Sync: -IgnoreIsActive 1. If you’re considering running this command, read this article. And run this at your own risk. As noted above, the tp_IsActive constraint on the Timer Jobs is there by design. It’s important to test, plan for and manage the effects of these Jobs if you’re moving away from the default configuration.

Other Factors

Lastly, there are a few other things to think about before settling on an approach to working with the Timer Jobs.

• Keep in mind that these jobs could potentially break an otherwise-working configuration for RMS, for instance if Active Directory has the correct e-mail address for a user and the SharePoint User Profile has some other value (say, if it can be updated by a user). This could be entirely valid for SharePoint, but unless SharePoint publishes the content to an address that RMS can discover for that user, the RMS protection process won’t work.
• By default, the Quick Synchronisation Job runs only once every five minutes, so within this initial window of 0-5 minutes, the Timer Jobs will not solve for RMS access issues. If a user’s Work E-mail value is empty for any of the reasons above, the Timer Jobs still leave a brief initial gap in providing RMS access.
  • An example when this scenario might play out is when a user clicks on a link to an RMS-protected document without having visited the Site Collection first. This user would not be able to access the link until after the Quick Sync Job completes. This may be something you need to live with and support in the long term, or you could do something expensive clever to improve this user experience, but keep in mind this is an edge case.
  • There may be other means of “forcing” SharePoint to push User Profile data to visitors by marking the users as active in the User Information List (like the old school work-around) but for me these approaches would achieve a similar result to the STSADM -o Sync -IgnoreIsActive 1 command, and probably at the expense of introducing something clunkier and less supportable than the Timer Jobs. These approaches are probably only suitable when you want to fix-up access for a small group of “inactive” users or by exception.
  • One last thing to consider is that you probably don’t want to allow users to update their e-mail address in their User Profile, as that could be all kinds of messy. I could see some scenarios where User Profile administrators are relied upon for this, however it’s probably still less than elegant.

Having said all of this, I think the Timer Jobs become essential for many deployments in order to keep the User Information List data up to date. The Jobs will have a greater importance still if e-mail addresses change with any frequency in Active Directory or if Active Directory isn’t the authoritative source of this information. To some extent this is mitigated by RMS, as it also grants access to users with a matching e-mail address in the proxyAddresses LDAP attribute, but in principle you would want to keep SharePoint in sync with the proper Active Directory mail value. Beyond these common scenarios, the Jobs will probably become critical to SAML Claims scenarios if the users won’t present E-mail Claims (either because they don’t have the value or the Claim isn’t mapped). More on this in the next post, when I will focus on how the Work E-mail values get loaded initially for different Authentication Providers.