Lync Central Forest Topology with Forefront Identity Manager (FIM)

The idea of this article is to explain what role FIM plays in multiple forest Lync deployments, and how it does it. This is going to be another long article, so shall we get the awkward bit over with, and let me tell you a story of how I first came to know FIM.

On the first day at a new place, during my induction. I was being shown around, and having the usual introductions with lots of people which I had no chance of remembering their names or faces. As I was being introduced to the resourcing manager, they asked “Do you know Fim?”… my awkward response was “Er, I don’t think I’ve been introduced yet”. People chuckled.

Yes, yes, yes… I know NOW.

Let’s begin with a quick glance at the eventful history, and get ready for a lot more names which I’ll never remember.

Identity and Access Management

Forefront Identity Manager started when Microsoft purchased Zoomit VIA back in 1999, and called it Microsoft Metadirectory Server (MMS), then Microsoft Identity Integration Services (MIIS). Microsoft then combined another purchase, Alacris IDNexus, as a feature called Certificate Lifecycle Manager into the newly named Identity Lifecycle Manager 2007. Until finally it was brought into the Forefront suite as Forefront Identity Manager 2010. Then a second release of FIM (2010 R2) added extensive user self-service features. FIM 2010 R2 SP1 included a component of yet another purchase, this time BHOLD, to provide an overlay of Role Based Access Controls as well as Analytics & Reporting and more.

FIM currently sits in Microsoft’s Identity and Access Management solutions stack, which also includes Active Directory Federation Services (ADFS), Rights Management Services (RMS), as well as the quickly disappearing security products; Threat Management Gateway (TMG), and Unified Access Gateway (UAG).

Microsoft’s roadmap shows that yet another re-branding is in store, to Microsoft Identity Manager, so we can look forward to that in the next version, along with some rather interesting advancements towards a Software-as-a-Service vision with support for Azure Active Directory (some support for this was added in Autumn 2013 with the Azure AD Management Agent, formally released in Feb 2014), also with a tease of multi-tenant capabilities. The roadmap also mentions hybrid scenarios that deliver cloud based services, including Multi-Factor Authentication, Azure Active Directory application integration, and further analytics and reporting. And it sounds like it’s getting a facelift with “support for the latest mobile platforms with modern user interfaces”.

What does it do?

The idea of Identity Management is to… well… manage identities… identities across disparate systems in heterogeneous environments. Imagine a bespoke Human Resource system that maintains its own database with details of all your staff, and a payroll system with it’s own database, an expenses and time-sheet application, and an ID Card system, again, all with their own databases. Across which, exist many duplicate ‘objects’ that all relate to a single unique person, potentially with different logins and passwords. Then there’s Microsoft’s Active Directory, which in an ideal world should be the authoritative source, and central storage place for all company-wide accounts and personnel information.

With multiple points of administration, usually split between different departments, comes the opportunity to introduce human errors, data disparities, and security risks from unused accounts that have not been disabled across the board.

Not that hard to imagine, because it sounds like how most companies run their IT systems, right?

That’s where FIM comes in, it’s oldest and what I see as its primary feature is to provide a synchronisation engine that can be extended to integrate with data sources in the form of Management Agents. Either written by developers, or ‘bundled in’ with FIM, such as for Active Directory, Exchange Global Address Lists, Databases (Oracle / SAP / Microsoft SQL Server), LDAP Data Interchange Format (LDIF), IBM and Novel Directory Servers, Powershell connectors, and a range of plain text agents (that can read CSV / Fixed Width / Delimited / Attribute-Value pair), and more.

Another aspect that FIM covers is its role-based access control, automatic provisioning, and some would argue the most significant feature – a self-service portal, including features like password management and certificate provisioning etc. Which we won’t be even remotely touching on in this article.

What does that mean for Lync?

Getting back to the title of this article, Central Forest implies a topology where there are multiple forests which trust each other, one where Lync Servers are deployed, and all forests having active users. This is probably the most common scenario you’ll come across. For example we’re talking about when organisations merge, or large previously independent departments begin to consolidate their ADs.

Central Forest Topology Diagram

The other similar scenario is the Resource Forest topology, this is where Lync is deployed in a dedicated forest (or perhaps with Exchange Servers), but the main difference is that there are no active user accounts in that forest at all. This is usually done due to the organisations’ security standpoint.

Resource Forest Topology Diagram

Either way, Lync cannot enable users across forests (those in green). Lync can only read and write attributes in the forest where it was deployed (and where the Schema was extended).

Even though the forests trust each other, they are still separate and each represents an independent data source. As you can probably guess, this is where FIM comes in, and is used to synchronise AD objects and their attributes between forests, so that Lync sees a ‘local’ object in AD that it can get its hands on. Kind of like a ‘proxy object’ if you want to think of it that way. If you are familiar with Linked Mailboxes in Exchange with Resource Forests, this is essentially the same thing. However Lync doesn’t provide a nice and easy way to create nor manage this like Exchange does.

In my experience, once you start talking about multiple forests and forest trusts, you’re into high number of users, and you’d want something that can be automated so that corresponding accounts are created, provisioned, updated, disabled, and deleted the same time as the original object in the source forest.

Therefore in this article, we’re going to look at the Active Directory Management Agent, and how FIM works between two forests to associate accounts and to merge and synchronise their attributes. We’re not going to touch the other capabilities mentioned above.

Lync Central Forest Topology

To bring this into the real world, let’s say Big Corp has been on a shopping spree and just purchased Little Org. Big Corp already has Lync deployed and obviously has users in their forest that are Lync Enabled, this is known as the Central Forest. Little Org is then known as a User Forest. With a Central Forest topology, you can have as many User Forests as you like, but we’ll just have one for now.

Let’s crack open a new Visio document and see an overview of what we’re trying to achieve.

FIM - Central Forest Topology

The basics of FIM Sync

A Management Agent is a piece of software that is responsible for communicating with a Connected Data Source, and the resulting attribute flow that brings that information into FIM’s Connector Space which provides an ingress and egress point, and acts like a staging area for the synchronisation process and attribute flow. The Connector Space also handles information on additions, deletions, and updates so a full transactional history can be maintained.

Each Management Agent has its own dedicated area of the Connector Space. Once all Management Agents have pulled their information from their Connected Data Source into the Connector Space, it is then mixed, merged, poked, and prodded together into the (cool sounding) Metaverse. Rules and filters can be applied to interpret, format, and add intelligence with regards to mapping the attributes as required.

The Metaverse is essentially a collection of tables that contain the combined attributes and values for each object that represents a person, resource, or any object being synchronised.

Lync Server Sync Tool (LCSSync)

This is included in the Lync Server Resource Kit under a folder called LCSSync, in there is everything you need to add to configure your FIM installation to get going.

** If you’re looking for a detailed how-to guide, I’d recommend taking a look at Tim Day’s Lync Me Blog, he has a very detailed step by step walk-through – Lync 2013 Resource Forest FIM Syncronization Guide.

LCSSync is comprised of several files, there is the extension itself (a DLL file that contains functions designed to be called by FIM), which contains both Metaverse and Management Agent rule extensions. Also a Metaverse Schema extension XML file, this instructs FIM of the new fields and data-types that need to be added to the Metaverse tables so it can then hold the information being synchronised. And it also contains XML files which describe the attribute flow, and configuration for the Active Directory Management Agents we spoke about earlier.

So really, all the hard work has been done for you, what could there possible be left to do….. except understand what the hell is going on!

What is going on

To recap… As far as Lync is concerned, it needs is an object in the same forest that it can get to with permission to read and write its attributes. Therefore, all that’s required is a one-way synchronisation of the few specific attributes from the User Forest, nothing has to be pushed back to Little Org. Contacts objects in AD are used to populate the visible attributes, and more importantly the specific hidden attributes that let Lync know which user object in Little Org that the Contact Object is associated with (more on those attributes later).

Now let’s see what we’ve been talking about, this shows an overview of how the objects and their attributes end up in Big Corp, so they can be enabled for Lync.

FIM - The Basics

The general flow can be broken down into the following steps…

1 – Import from Big Corp (the “Central Forest” with Lync deployed) into the Connector Space.
2 – Import from Little Org (the “User Forest”) into the Connector Space.
3 – Synchronisation between the Connector Space for Big Corp and the Metaverse.
4 – Synchronisation between the Connector Space for Little Org and the Metaverse.
5 – Export from the Metaverse to Big Corp.

Obviously the first time this process runs through, steps 1 and 3 won’t do much at all. But it helps with keeping the Metaverse updated on subsequent runs, without overwriting newer information with that from Little Org.

Now you can use PowerShell to enable them for Lync by specifying the DN of the Contact Object in Big Corp. Technically, this doesn’t enable the user account in Little Org, remember we said nothing gets written back, but what it does do is when a Little Org Users authenticates to Lync, it knows to look for an object locally to use instead (the synchronised Contact Object).

The Objects, Attributes, and Flow

LCSSync synchronises two types of objects, users, and groups. For the new objects to be useful you’d expect the visible attributes such as Name, Department, Company and so on to get pulled across.. and they do. Those are called ‘Direct Mappings’, the majority of all the attribute flows needed here are basically A=>B.

Before we look at them, there are two types of ‘user’ account objects that are imported, ‘user’ (normal AD Account Type), and ‘inetOrgPerson’ (used by some non-Microsoft LDAP and X500 directory services) but is a class derived from ‘user’ so it can be used in the same way, basically there for compatibility.

Let’s look at the attribute flow…

For inetOrgPerson and user object classes.

AD Attribute Description Type Metaverse Attribute
department direct → department
manager direct → manager
thumbnailPhoto Account Photo direct → photo
dn Distinguished Name direct → Ms-DS-Source-Object-DN1
otherTelephone direct → otherTelephone
otherPager direct → otherPager
otherMobile direct → otherMobile
otherHomePhone direct → otherHomePhone
ipPhone direct → ipPhone
pager direct → pager
mobile direct → mobile
homePhone direct → homePhone
userAccountControl direct → userAccountControl
title User's Job Title direct → title
telephoneNumber direct → telephoneNumber
st Stage, Province, or County direct → st
sn Surname direct → sn
physicalDeliveryOfficeName direct → physicalDeliveryOfficeName2
objectSid Security ID of the Object direct → msRTCSIP-OriginatorSid1
mail Email Address direct → mail
l Location or City direct → l
givenName First Name direct → givenName
company direct → company
cn Canonical Name direct → cn
c Country or Region direct → c
proxyAddresses Additional email addresses rules extension → proxyAddresses3

And for group object class.

AD Attribute Description Type Metaverse Attribute
cn Canonical Name direct → cn
displayName direct → displayName
mail Email Address direct → mail
objectSid Security ID of the Object direct → msRTCSIP-OriginatorSid1
groupType direct → groupType
dn Distinguished Name direct → Ms-DS-Source-Object-DN1
managedBy direct → manager

1 = notice the source and destination attributes are different, that is because these are the ‘unique’ or ‘identifiable’ attributes in the User Forest that we want to keep, but we don’t want to overwrite those attributes in the Central Forest. For example, the DN of the resulting Contact Object, will be just that… the distinguished name of the contact object, and we can’t change that. What Lync is expecting is the DN of the originating object to which it’s providing services to, therefore Lync knows to look in the msDS-SourceObjectDN attribute (this is what the attribute is called in the Central Forest, for some reason in the Metaverse adds some dashes to the ms-DS-Source-Object-DN), and for the ObjectSid Lync looks in the msRTCSIP-OriginatorSid attribute.

2 = inetOrgPerson doesn’t have an attribute called physicalDeliveryOfficeName so that only appears for the user attribute flow.

3 = Rather than a direct mapping for proxyAddresses, a Rules Extension is needed. Unlike the rest of the attributes listed above (that are perfectly happy being direct mappings, i.e. one way), when a user is enabled for Lync, their SIP Address gets added to the multi-value ProxyAddresses attribute, and we don’t want that getting wiped out on the next sync with the attribute from the user forest, which is why it is pushed back up to the Metaverse, so FIM can merge the attribute and it can persist across synchronisations, rather than being overwritten.

I won’t bore you with a table showing the Management Agent’s Attribute Flow for the Central Forest, it’s basically the same as above but in reverse, this time the Management Agent pulls the information out of the Metaverse back into the Connector Space, ready for exporting to the Central Forest’s Active Directory. But both the ‘person’ and ‘group’ objects in the Metaverse are created as Contact Objects in the Central Forest.

Source / User Forest Metaverse Destination / Central Forest
user person contact
inetOrgPerson person contact
group group contact

Joins and Projections

A ‘join’ is where FIM looks in the Connector Space of the Management Agent and tries to find its corresponding object in the Metaverse. This association is important, imagine if each time you changed a name in Little Org, you ended up creating a NEW contact over in Big Corp. I wouldn’t really call that “synchronising”, would you?

A ‘projection’ is where there is no corresponding object in the Metaverse, so rather than joining the objects together, the object in the Connector Space is ‘projected’ into the Metaverse. The choice of words here is important, because ‘copy’ would imply there will be 2 objects afterwards, whereas ‘projection’ is supposed to imply that it’s just ‘view’ or a reflection of the object.

Because we’re dealing with AD, it has its own attribute, objectSid (Object Security Identifier), which is a unique way to identify any object such as a user account, or group. Which is what’s used for the joins.

Although the object’s SID is unique, it is not static. That’s because part of a SID is made up with an ID of the domain that it’s related to. When a user is moved between domains (in the same forest) they are given a new SID, and their old SID is added to their sIDHistory attribute so existing security permissions are still valid. Therefore no matter how many times a user is moved, and new SID allocated, they will have a record of all their past SIDs to be matched up to the object in the Metaverse.

Object Type Source Attribute Metaverse
user User Forest objectSid msRTCSIP-OriginatorSid
user User Forest sIDHistory msRTCSIP-OriginatorSid
inetOrgPerson User Forest objectSid msRTCSIP-OriginatorSid
inetOrgPerson User Forest sIDHistory msRTCSIP-OriginatorSid
group User Forest objectSid msRTCSIP-OriginatorSid
contact Central Forest msRTCSIP-OriginatorSid [larr] msRTCSIP-OriginatorSid

For example, if a user, inetOrgPerson, or group’s objectSid (their current SID) or any of the entries in the sIDHistory attribute (which contains all previous SIDs), match up with the msRTCSIP-OriginatorSid in the Metaverse it is considered to be the same object, and joined.

If no match is found, then it’s created in (projected into) the Metaverse.

Rules Extensions in LCSSync

Rules Extensions are a way for FIM to add some ‘cleverness’ to the synchronisation process. Most Management Agents come with their own Rules Extensions. FIM also provides a sample project for Visual Studio that contains a template class with empty functions, you can then add your own code to work on the objects and gain control over the process.

There are two types of Rules Extensions…

Metaverse Rules Extensions – you can only specify one MVExtension in FIM, the only official supported way to get around this is to write a wrapper that dynamically loads other DLL files and calls their functions in turn – “MSDN: How to create rules extensions from multiple sources

The functions that LCSSync provides are to Provision objects into the Metaverse, and to check whether an object should be deleted, by checking if it has any associations with objects in the Connector Space (and therefore the Connected Data Source, i.e. Active Directory). It also checks to see if the associated user is still enabled for Lync, if so, it won’t delete the object, even if all the Connectors have been removed.

Management Agent Rules Extensions – each Management Agent has its own MAExtension, this is usually the same DLL file i.e. it contains classes for both MA and MV Extensions.

LCSSync provides a function that checks whether an object should be projected to the Metaverse. If a user or inetOrgPerson is disabled, then it does not get projected.

Missing bits

I’ve deliberately skipped some areas because I don’t think they need any coverage for the scope of this article, either because they don’t really play a part, or because they are self-explanatory, for example…

Partition and Containers – Each Active Directory Management Agent needs to know which AD Partition to look in (i.e. Default Naming Context), and you can also limit access to a single OU, or list of specific OUs.

Connector Filters – some logic to which objects get picked for synchronisation. The only filter that LCSSync has configured automatically is that a group must have its mail attribute populated.

Making it do something useful

If you’ve read down this far and are still confused, I’m sure you’re not alone. FIM is a complicated product, with some unusual terminology, but is a flexible, elegant, and mature synchronisation solution, so perhaps it is a little over-complicated for AD to AD situations like this, but it can do so much more.

We’ve seen how Little Org’s user accounts get from the User Forest via it’s Active Directory Management Agent and through it’s Connector Space, joined and synchronised, or projected into the Metaverse, from there it’s a reverse journey to Big Corp’s Active Directory Management Agent’s Connector Space, and then exported as Contact Objects in the Central Forest.

Then, once your Central Forest has a bunch of new Contact Objects appear, you can enable them for Lync. But only by using PowerShall, you can’t do this with the Lync Server Control Panel.

I’m assuming you’ve done the necessary steps to add the new domain as an accepted SIP Domain, and created the relevant DNS SRV Records etc. Once that’s all done, you can get about enabling those new Contact Objects…

First of all, get the DN of a Contact Object that now exists in Lync’s Forest.

And then enable it for Lync, in the normal way.

Then the user will be able to sign in just like any other user, as if Lync was deployed in their own forest.

Couldn’t be easier, once you know.

To be honest, it feels like a bit of an anti-climax, reaching the end of this journey, and the ‘magic’ happens in one or two PowerShell cmdlets. But like most tricks, it’s all the preparation that makes ‘The ‘Prestige’ all the more impressive.


Thanks for reading.

Tweet about this on TwitterShare on LinkedInShare on Facebook
Pin on PinterestShare on Google+Digg thisShare on RedditShare on StumbleUponEmail this to someone

About Graham Cropley

Working as a Senior Consultant for Skype for Business, Exchange, and Office 365.

One Comment

Leave a Reply

Your email address will not be published. Required fields are marked *