Understanding User Mapping in a Skype for Business Resource Forest

Published by

on

Lync Resource Forest

Resource Forests and Skype for Business

Lync Resource Forest
Final Solution

In this particular deployment the customer has requested that Skype for Business be installed in a new forest to provide access to users across multiple legacy domains.

Single Sign On is required (Using the users credentials in the User Forest to authenticate to Skype user account resource in the Resource Forest)

Users will continue using their existing credentials in their current forests to sign on to Skype for Business (located in the new Forest).

To make thing interesting, the customer has started a migration to office 365 for mail. This means that UM will be delivered via Office365.

What is considered as a Resource Forest model?

In the resource forest model, a separate forest is used to manage resources. Resource forests do not contain user accounts other than those required for service administration and those required to provide alternate access to the resources in that forest if the user accounts in the organizational forest become unavailable. Forest trusts are established so that users from other forests can access the resources contained in the resource forest.

Deploying Skype for Business in a resource forest while users (and the associated user authentication) exist in their respective user forests, is supported.

In fact, there are 2 potential scenarios that are supported.

Scenario 1

Lync Resource Forest
Scenario 1: Skype for Business and Exchange in the same Resource Forest

Both the Skype for Business Servers and the Microsoft Exchange Server are deployed in the same Active Directory forest (Resource Forest) while all logon-enabled user accounts are located in a separate Active Directory forest (user forest).

In this case the resource forest hosts only servers and do not contain any primary user accounts. The primary user accounts from the user forests are represented as disabled user accounts in the resource forest.

The ObjectSID of the primary user account (from the user forest) is mapped to the corresponding disabled user account’s msRTCSIP-OriginatorSID attribute in the resource forest (aka user mapping) to allow for single sign in.

These disabled user accounts are enabled for Skype for Business and mail-enabled for Exchange.

NOTE

Microsoft recommendation is that if Exchange is deployed, then it is best to deploy Skype for Business in the same forest as Exchange.

Scenario 2

Lync Resource Forest
Scenario 2: Skype for Business and Exchange in different Forests

In this scenario, Skype for Business Server and Microsoft Exchange Server are deployed in different forests. Microsoft recommend that Microsoft Forefront Identity Manager or Microsoft Identity Lifecycle Manager be used to synchronize users from the different user forests as disabled user accounts to the resource forest where Skype for Business Server is deployed.

To enable Exchange Unified Messaging (UM) and other Skype for Business Server to office integration scenarios, the msRTCSIP-PrimaryUserAddress has to be added to both Microsoft Exchange Server and Skype Server forests user attribute proxyAddresses (so that the proxyAddresses attribute is the same in both forests) . A two-way trust should be established between both forests.

Understanding User Mapping

To assist with the explanation I will be referring to the user account in the user forest as the Primary User Account, and the disabled user account in the Resource Forest as the Resource User Account.

The Lync 2013 ResKit ships with a script called SIDMap.wsf, its primary function is mapping users between User and Resource Forests…sort of but not quite..

Actually it only copies the msExchMasterAccountSid attribute to the msRTCSIP-OriginatorSID attribute on the Resource User Account

The Resource User Account msExchMasterAccountSid attribute is populated from the objectSID of the Primary User account (still following?).

So in Scenraio 1 you would have to copy the objectSID of the Primary User Account in the User Forest to the Resource User Account  msRTCSIP-OriginatorSID attribute of the disabled user in the Resource Forest.

This effectively Maps the Resource User Account back to the Primary User Account. Of course it needs to be done for each user.

The result, you have the ability to sign in to Skype for Business in the Resource Forest with credentials from the User Forest.

References

https://technet.microsoft.com/en-us/library/dn933910.aspx

http://blog.danovich.com.au/2009/11/05/improving-the-sidmap-wsf-script-for-ocs-attribute-synchronization/

https://actionxp.wordpress.com/2011/09/04/deploy-lync-server-2010-in-a-resource-forest-topology-part-1-2-2-2/

6 responses to “Understanding User Mapping in a Skype for Business Resource Forest”

  1. Aussie Joe Avatar
    Aussie Joe

    Nice article Paul! Glad to see you stay ahead of the game 🙂

    Like

  2. James Avatar
    James

    Hi Paul, Nice post! Just to clarify, there is no attribute called “userSID”. The attribute that maps to “msRTCSIP-OriginatorSID” is “objectSid”. So maybe update the post to say the “Primary User’s objectSid” instead of userSID.

    Cheers,
    James.

    Like

    1. Paul B Avatar

      Thanks James, appreciate the note. Updated 🙂

      Like

  3. habibalby Avatar

    We are in the same boat and wanted to deploy Skype for Business and at the same time change the domain identity from two separate forest…

    Like

  4. […] Understanding User Mapping in a Skype for Business … – Resource Forests and Skype for Business In this particular deployment the customer has requested that Skype for Business be installed in a new forest to provide … […]

    Like

  5. […] a great article here: https://ucsorted.com/2015/08/31/understanding-user-mapping-in-a-skype-for-business-resource-forest/ explaining how a Resource Forest model […]

    Like

Leave a comment

A WordPress.com Website.