The resource forest hosts disabled user accounts (used to enable access to Lync services). It is required that the msRTCSIP-OriginatorSID attribute for the disabled accounts maps to the ObjectSID of the account in the user forest. The resource forest topology has a higher level of isolation between Lync and the users' forest, but the increased security also implies increased administrative complexity.
This can be summarized as follows:
Also, if we have not talked about this aspect before, we have to add another point to the list.
If we have already deployed Exchange in our resource forest, we can take advantage of the attribute msExchMasterAccountSid
that works as the previously mentioned msRTCSIP-OriginatorSID
.
The msExchMasterAccountSid
attribute is used to grant Exchange services to the user forests via a disabled account. As we shall see, msExchMasterAccountSid
joins with the ObjectSID. Exchange has a practical wizard that helps to map Linked Mailboxes (mailboxes that are accessed by users in a separate, trusted forest) to user accounts in their originating forest. The same operation is available using the Exchange Management Shell. We will be able to use msExchMasterAccountSid
to populate the msRTCSIP-OriginatorSID
attribute required for Lync. The outline of the laboratory that we will use is shown in the following image:
This is the recipe we will see for planning the steps required to deploy Lync in a resource forest that already contains an Exchange deployment.
Our scenario is based on the assumption that a working Exchange 2013 deployment is already available in the resource forest. In addition, we will use the Lync 2013 Resource Kit (http://www.microsoft.com/en-us/download/details.aspx?id=36821). In a folder inside the installation path of the resource kit, LCSSync
, we have a script called sidmap.wsf
. This utility takes the existing SID information from the mxEXCHMasterAccountSID
attribute (populated by Exchange when we have defined a linked mailbox) and uses this value to fill the msRTCSIP-OrginatorSID
attribute, as shown in the following screenshot:
https://<CASServerName>/ecp
), in the Recipients menu, open Mailboxes.msExchMasterAccountSid
attribute, as shown in the following screenshot:mxEXCHMasterAccountSID
attribute with the msRTCSIP-OrginatorSID
attribute for the user account that we have SIP-enabled in the previous step. We will use the sidmap.swf
script. In our example, the users will be located in the LyncEnabled OU (OU=LyncEnabled,DC=wonderland,DC=lab). The path to the sidmap.wsf script is C:Program FilesMicrosoft Lync Server 2013ResKitLcsSync
.cd "C:Program FilesMicrosoft Lync Server 2013ResKitLcsSync" wscript //h:cscript sidmap.wsf /OU:"OU=LyncEnabled,DC=wonderland,DC=lab" /logfile:c:sipmap.txt
We can verify the result of the script both on the command prompt and on the sipmap.txt
file, as shown in the following screenshot:
Users that are not mail-enabled have no data in the msExchMasterAccountSid
attribute. We will have to manually map the active user's SID to the msRTCSIP-OriginatorSID
attribute of the disabled account every time there is no linked mailbox.
The following code is an example of a script we can use to align msExchMasterAccountSid
to msRTCSIP-OriginatorSID
. We should save the text inside a .ps1
file (for example, enableUC.ps1
) and launch it using the following cmdlet .enableUC.ps1 –name "username" –pool "LyncPoolName"
:
Param([String] $Name, [String] $Pool) $user = Get-ADuser $name -Properties msExchMasterAccountSid,msRTCSIP-OriginatorSid,proxyAddresses if (Get-CsUser $user.UserPrincipalName 2> $null) { echo "User Already Enabled" Get-CsUser $user.UserPrincipalName exit } foreach ($smtp in $user.proxyAddresses) { if ($smtp -clike "SMTP:*") { $sip = $smtp.ToString() $sip = $sip.Replace("SMTP", "sip") $sip } } if ($user.msExchMasterAccountSid -notlike $null) { Set-ADUser -Identity $user -Add @{"msRTCSIP-OriginatorSid" = $user.msExchMasterAccountSid.Value.ToString() } enable-CsUser -Identity $user.UserPrincipalName -RegistrarPool $Pool -SipAddress $sip echo "User Enabled to Lync" Get-CsUser $user.UserPrincipalName exit }
Shawn Cathcart wrote a couple of handy scripts to automate the enabling of the cross-forest Lync user and the SID attributes' verification. They are available in the User Enabling in a Lync Resource Forest Deployment post at http://thecathcart.blogspot.it/2012/07/user-enabling-in-lync-resource-forest.html.
In the previously mentioned post, there is also important information about Lync RBAC in a resource forest scenario. The forest preparation step of the Lync 2013 installation creates the Role-Based Access Control (RBAC) groups (we have mentioned them in the Controlling administrative rights with RBAC and custom cmdlets recipe of Chapter 1, Lync 2013 Security). RBAC makes it easier to delegate administrative tasks that grant limited permissions and tools to the user that receives the delegation. In a resource forest scenario, the forest preparation is executed only in the forest that hosts the Lync services. Lync RBAC Roles are associated with Universal Security groups in the resource forest. Only local security groups can take members and groups from a trusted forest, but we are not able to add them in a universal security group. The creation of a domain local group, inserting a user forest's account, and adding the local group in the RTCUniversalReadOnlyAdmins
group is shown in the following screenshot:
So, while there are some ways to overcome this problem with Exchange in a resource forest (see the Understanding multiple-forest permissions post at http://technet.microsoft.com/en-us/library/dd298099(v=exchg.150).aspx), the only way to administer Lync is to have an account in the same forest as the servers that are deployed.