Windows Archives - Page 2 of 7 - Tristan Watkins on IT Infrastructure

RMS AD Caching for SharePoint 2010 Users

As this series of posts about SharePoint 2010 with Rights Management moves on, it moves further from SharePoint. In this post I’m describing the final steps in the RMS protection process, where RMS authenticates the requesting user and authorises actions with RMS-protected content.

In most configurations, RMS will rely on its internal AD Cache to reduce the number of LDAP queries for user attributes or Active Directory group membership. RMS typically queries this cache when users request a license. If RMS finds a matching e-mail address for a user, the allowed rights will be granted in a Use License, which will persist inside a document or on a user’s machine until the rights expire. LDAP queries are only issued if cached values don’t exist or if they have expired. After an LDAP query is issued, the response is used to process the immediate request and the values are stored in the AD Cache for later use.

Although this caching process should “just work” initially, there are a number of tiers where user information can fall out of sync. First and foremost, does the signed-on user have an e-mail address in Active Directory that matches the SharePoint User Information List? What happens if this e-mail address changes, or if it didn’t match initially? How can we invalidate stale AD Cache values? How long does the AD Cache persist? What’s in it? What needs to be considered when turning it off? In many cases the default AD Cache values will be suitable, but operational processes should be orchestrated with AD Cache settings in mind, whatever they may be. Cache invalidation processes should also be understood before they need to be invoked. I will explore these considerations in more detail here.

Continue reading “RMS AD Caching for SharePoint 2010 Users”

RMS Publishing Permissions for SharePoint 2010 Application Pool Identities

In the previous posts in this series about SharePoint 2010 with Rights Management, I’ve been looking at the user information requirements to successfully bridge gaps between SharePoint and RMS. In this post I will focus on a poorly documented RMS configuration requirement that is often overlooked and seems to cause many deployment headaches. This is the point of contact where SharePoint first requests RMS.

Continue reading “RMS Publishing Permissions for SharePoint 2010 Application Pool Identities”

Inspecting an AD RMS Request from SharePoint 2010

In this series of posts on SharePoint with RMS, I’ve mostly focused on the ways things might go wrong if Active Directory data, User Profiles and User Information Lists are misaligned. Now, assuming SharePoint has a reliable Work E-mail value for a user, there are still a number of things that happen between the initiation of a request for RMS-protected content and interaction with it. In this post I will inspect a successful request for RMS-protected content from SharePoint 2010.

Continue reading “Inspecting an AD RMS Request from SharePoint 2010”

How SharePoint 2010 Authentication Provider Types Alter the Initial Population of Work E-mail Address Values

Continuing this series about the SharePoint 2010 IRM implementation, in this post I’ll keep looking at the Work E-mail Address attribute in the User Information List, but focus specifically on how the initial value in that field gets populated from different sources for different Authentication Provider Types. As with the fuller picture considered in the last post, this is a lot more complicated than anyone would expect at a glance, but it’s really the lynchpin of this functionality – thus the depth here.

Continue reading “How SharePoint 2010 Authentication Provider Types Alter the Initial Population of Work E-mail Address Values”

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.

Continue reading “How SharePoint 2010 Finds and Updates a User’s Work E-mail Address”

Protecting SharePoint 2010 with Information Rights Management

Overview

In recent weeks Information Rights Management (IRM) protections for SharePoint 2013 have received a fair amount of attention, as IRM is now configurable per-tenant, which brings the capabilities to SharePoint Online, supported by Windows Azure Active Directory Rights Management (AADRM). This is great, and I’ll have more to say about these new technologies, but I feel there’s a fair amount of missing public information about the way it’s been working on-premises for many years, which will prove to be foundational for the new stuff. I won’t go back in time to MOSS 2007 to describe that support, but I believe the Classic Windows Authentication scenarios that I will describe for SharePoint 2010 are largely the same as in the earlier implementation.

This first post focuses on the relationships of a few apparently-distinct topics and the effects that these considerations have for a user accessing Rights Managed content in SharePoint 2010. Namely:

How SharePoint publishes content with Rights Management protections using the User Information List’s Work E-mail value.
How that field gets initially loaded…
1. If an entry is added to the User Information List when a user is granted access to a SharePoint Site Collection by name.
2. If an entry is added to the User Information List when a user accesses a Site Collection for the first time, having been granted access by group or attribute previously.
3. How each of these events vary if the user is authenticated with a SAML Claim, and how Claim Mappings for a SAML Claim Provider’s Trust Relationship can alter this experience.
How the User Information List’s Work E-mail value can change after the User Profile to SharePoint Quick or Full Synchronisation Timer Jobs have run.
1. How the scope of users targeted by this timer job works by default.
2. How the scope of users targeted by this timer job can be modified and the possible effects of choosing to make this change.
How Active Directory Rights Management Server (AD RMS, or just RMS below) discovers and caches e-mail address values for a user.
How changes to an Active Directory user’s mail attribute can have an impact on access to RMS-protected content in SharePoint.

As is no doubt evident already, this is complicated stuff, but in my view, quite necessary to understand if using RMS with SharePoint. These considerations become more important if e-mail addresses are fluid, or at scale, and especially critical if authenticating SharePoint with SAML Claims while using RMS. I’ve produced a process diagram to explain these variations in a single view, but first I will provide background details.

Continue reading “Protecting SharePoint 2010 with Information Rights Management”

Ditching the Tablet: Windows 8 Revives Netbooks

Soon before Windows 8 tablets became available I wrote about my selection process, focusing on some of the key decisions that helped narrow my choices. This was largely a consideration of WindowsRT on ARM vs. Windows on Atom vs. Windows on i-Series processors. My first few weeks with this device have been a mixed bag. I’ve now returned the tablet, replacing it with a Netbook. I can’t say I saw any of this coming, so I thought it might be good to write about the issues I faced between the time that I decided on a Samsung ATIV Smart PC Pro and when I finally returned it after eight weeks. I’ll also revisit my criteria with some hands-on experience under my belt and consider how Ultrabooks/Netbooks with touch compare to ARM/Atom tablets for price/functionality/components, and how Windows 8 itself is disruptive to hardware refresh patterns. Although this post roams a bit, I hope it’s joined up by some common threads of unexpected/disruptive effects of Windows 8.

Continue reading “Ditching the Tablet: Windows 8 Revives Netbooks”

Choosing a Windows 8 Tablet

Note: since writing this, I’ve changed my view on a few of these requirements, and returned the machine I selected. I’d suggest reading this second post for more information.

Since the first Windows 8 devices were announced and I had a chance to work with the Developer Preview I’ve been looking forward to the day when I could get my mits on a Windows 8 tablet. During that time, my thoughts about what I really want have crystalised somewhat. There’s been plenty written about the new OS and the devices that will launch at or near General Availability this Friday, but there seems to be a dearth of comparative information other than some useful reference materials. As I see it, these materials are excellent once you know what you want, but they don’t really help you get there. And that’s the point of this post. I reckon someone might find it helpful to step through my thought process, even if they reach a different conclusion. This is quite subjective and somewhat rough and ready, but I often find that more useful than anything else.

Continue reading “Choosing a Windows 8 Tablet”

Failed Detection of PeopleILM Components and User Profile Synchronisation Service DCOM 10016 Errors

In my last post, I described some of the security considerations that influence an administrator’s response to event log clutter generated by DCOM errors. There are known remedial steps for most of these errors, but the impact of fixing them is often poorly understood, so I tried to clear some of that up. In this post, I’ll review how I’ve responded to the User Profile Synchronisation Service’s DCOM 10016 errors and the corollary MsiInstaller warnings with these security considerations in mind.

Failed Detection of PeopleILM Components

According to Microsoft KB article 2473430, these events occur, “while attempting to manage a User Profile Service Application”. To be more specific, the symptoms are described as:

When you attempt to manage the User Profile Service Application via Central Admin on a SharePoint Server 2010 with the User Profile Synchronization service started after an IISReset, the following warnings are logged in the application log of the SharePoint server…

Personally, I’ve never been able to pin down a firm cause of these events, so I’m happy to go with this Microsoft description, although I struggled to replicate this recently. Regardless, I’ve certainly seen the events in a large number, if not all User Profile Synchronisation Service instances I’ve encountered/built. One thing I find interesting is that these MsiInstaller warnings are accompanied by DCOM 10016 errors on the Windows Installer Service (DCOM component {000C101C-0000-0000-C000-000000000046}) and a few MsiInstaller warnings that closely resemble the Product Version Job DCOM permission errors I’ve spoken to before. This is what we’re looking at:

Continue reading “Failed Detection of PeopleILM Components and User Profile Synchronisation Service DCOM 10016 Errors”

DCOM Security for SharePoint Administrators

In a server administrator’s never-ending battle with log clutter, DCOM errors have proven to be some of the most persistent and poorly-understood events – especially with SharePoint. Our community has been building up remedial practices for the most common of these errors, but changes to the number and complexity of these fixes over the last few years call for a deeper look at what we’re changing, and the effects of these changes beyond a reduction in red and yellow icons in the event logs. In this post I’ll talk about some of the fundamental concepts from a Systems dude’s perspective and along the way I hope to convey a better understanding of Windows itself.

Continue reading “DCOM Security for SharePoint Administrators”