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 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.
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.
Microsoft recommendation is that if Exchange is deployed, then it is best to deploy Skype for Business in the same forest as Exchange.
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.
Aussie Joe said:
Nice article Paul! Glad to see you stay ahead of the game 🙂
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.
Paul B said:
Thanks James, appreciate the note. Updated 🙂
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…
Pingback: Skype Says User Not Found | Dumamey
Pingback: Skype for Business – Resource Forest and Surface Hub sign-in | ChrisHayward.co.uk