In case of multiple forests, Skype for Business Server must be deployed in the Skype for Business Server forest only. You don’t need to deploy Skype for Business Server in external user forests or extend the Active Directory schema with Skype for Business Server attributes in those forests. For further details about multi-forest topology options, see Multiple forests - Resource forest and Multiple forests - Central forest earlier in this document.
Active Directory forest trust
The multi-forest topology option requires a one-way trust relationship between the Skype for Business Server forest and each user forest so that users can authenticate to the user forest but access services in the Skype for Business Server forest. Create a “forest” trust instead of an “external” trust because an external trust only supports NTLM, while a forest trust supports both NTLM and Kerberos, and therefore won’t limit Skype for Business client authentication options.
Trusts are configured as one-way to prevent unauthorized access to the user forest from the Skype for Business Server forest. For details, see "How Domain and Forest Trusts Work" at http://technet.microsoft.com/library/cc773178.aspx.
Skype for Business Server contact management rights
In case of central forest deployment, you need to grant Skype for Business Server contact management rights on the container that is intended to hold shadow accounts (contacts enabled for Skype for Business Server in the Skype for Business Server forest). Otherwise, Skype for Business Server security groups do not have sufficient rights to manage contact objects, which causes an “access is denied” condition when Active Roles attempts to enable a shadow account for Skype for Business Server.
To grant Skype for Business Server contact management rights, use the following command in Skype for Business Server Management Shell:
Grant-CsOUPermission -OU "<DN of container>" -ObjectType "contact"
Replace <DN of container> with the Distinguished Name of the container that is intended to hold shadow accounts, for example: OU=Shadow Accounts,DC=Skype for BusinessServer,DC=lab. If the domain does not have permission inheritance disabled (which is the default case), then you can supply the Distinguished Name of the domain rather than container:
Grant-CsOUPermission -OU "DC=Skype for BusinessServer,DC=lab" -ObjectType "contact"
You must be a domain administrator in order to run the Grant-CsOUPermission cmdlet locally.