Lync Server 2013 integrates with many complementary servers (Exchange, SharePoint, and Office Web Apps) to deliver additional features (such as unified contact store and voice mail). Lync is able to use a server-to-server authentication protocol, the Open Authorization 2.0 (OAuth 2.0), to make it easier for the server to act on behalf of the user when required, and to pass a security token from a server to the other one instead of using the user's credentials.
The following are three server-to-server authentication scenarios (note that this kind of authentication is supported only with Exchange 2013, Lync 2013, and SharePoint 2013):
Server-to-server authentication on-premises uses a token server that is built-in Exchange 2013 and Lync 2013. Office 365 servers rely on a third-party token server.
We will see how to configure OAuth for a cross-premises Lync deployment, with our Lync users distributed on-premises and on the cloud. Information is available in this TechNet post Configuring Microsoft Lync Server 2013 in a cross-premises environment at http://bit.ly/1mK1Dts.
It is necessary to generate an OAuthTokenIssuer certificate that will be applied to the Lync Server. As explained in the There's more... section of this recipe, the same certificate will be used on all our Lync Server 2013 servers. The previously mentioned certificate could be a wildcard certificate (in our scenario, *.absoluteuc.biz
) or a multidomain (SAN) certificate, including the names of all our Lync Front Ends.
It is required to have a DirSync server in our on-premises deployment to manage the Lync Online-enabled users. It can be configured as we saw in the previous sections. It is important to note that the setup includes the Microsoft Online Services Sign-in Assistant and the Microsoft Online Services Module for Windows PowerShell.
https://accounts.accesscontrol.windows.net
, which is the Azure Active Directory (AD) endpoint for this kind of authentication and authorization.$TenantID = "absoluteuc.biz"
). The rest of the script will not require modifications. We will divide the statements in two parts to better understand the process:$TenantID = "absoluteuc.biz" $sts = Get-CsOAuthServer microsoft.sts -ErrorAction SilentlyContinue if ($sts -eq $null) { New-CsOAuthServer microsoft.sts -MetadataUrl "https://accounts.accesscontrol.windows.net/$TenantId/metadata/json/1" } else { if ($sts.MetadataUrl -ne "https://accounts.accesscontrol.windows.net/$TenantId/metadata/json/1") { Remove-CsOAuthServer microsoft.sts New-CsOAuthServer microsoft.sts -MetadataUrl "https://accounts.accesscontrol.windows.net/$TenantId/metadata/json/1" } }
https://accounts.accesscontrol.windows.net
URL. If another server with the same name already exists, it will be removed:$exch = Get-CsPartnerApplication microsoft.exchange -ErrorAction SilentlyContinue if ($exch -eq $null) { New-CsPartnerApplication -Identity microsoft.exchange -ApplicationIdentifier 00000002-0000-0ff1-ce00-000000000000 -ApplicationTrustLevel Full -UseOAuthServer } else { if ($exch.ApplicationIdentifier -ne "00000002-0000-0ff1-ce00-000000000000") { Remove-CsPartnerApplication microsoft.exchange New-CsPartnerApplication -Identity microsoft.exchange -ApplicationIdentifier 00000002-0000-0ff1-ce00-000000000000 -ApplicationTrustLevel Full -UseOAuthServer } else { Set-CsPartnerApplication -Identity microsoft.exchange -ApplicationTrustLevel Full -UseOAuthServer } } Set-CsOAuthConfiguration -ServiceName 00000004-0000-0ff1-ce00-000000000000
microsoft.exchange
with the New-CsPartnerApplication
cmdlet. If ApplicationIdentifier
is different from 00000002-0000-0ff1-ce00-000000000000
, the partner application is removed and redefined. If Microsoft.exchange
is not defined or is null, the script will create it with the right configuration. Authentication is based on the OAuthServer value that we defined in the first part of the statements. The previously mentioned ApplicationIdentifier
is the one we have if we launch only the Get-CsPartnerApplication Microsoft.exchange
cmdlet, as shown in the following screenshot:Import-Module MSOnlineExtended
: To load the Office 365 cmdlets.Connect-MsolService
: To connect to Office 365. An administrator's username and password will be required.AppPrincipalId
to retrieve a service principal or a list of service principals from Microsoft Azure AD for Exchange and Lync. The cmdlet to be used is Get-MsolServicePrincipal
, but it is advisable to save the required output in a text file, in our example, on the C: disk
:Get-MsolServicePrincipal | fl >> c: ext.txt
.cer
format) that we previously generated, and place it in c:certificates
, naming it, for example, Office365.cer
, to run the following cmdlets that will encode the certificate to make it usable to assign to our Office 365 principals:$certificate = New-Object System.Security.Cryptography.X509Certificates.X509Certificate $certificate.Import("C:CertificatesOffice365.cer") $binaryValue = $certificate.GetRawCertData() $credentialsValue = [System.Convert]::ToBase64String($binaryValue)
New-MsolServicePrincipalCredential -AppPrincipalId 00000004-0000-0ff1-ce00-000000000000 -Type Asymmetric -Usage Verify -Value $credentialsValue -StartDate 7/15/2014 -EndDate 7/3/2015
If you see an error like this New-MsolServicePrincipalCredential : Invalid value for parameter. Parameter name: Credential.EndDate, it is due to a difference in the time zone between your server and the Office 365 server. Our certificate expiration was on 7/4/2015 (at 01:00 AM), so we have to use 7/3/2015 due to the previously mentioned difference.
New-MsolServicePrincipalCredential -AppPrincipalId 00000002-0000-0ff1-ce00-000000000000 -Type Asymmetric -Usage Verify -Value $credentialsValue -StartDate 7/15/2014 -EndDate 7/3/2015
Set-MSOLServicePrincipal -AppPrincipalID 00000002-0000-0ff1-ce00-000000000000 -AccountEnabled $true $lyncSP = Get-MSOLServicePrincipal -AppPrincipalID 00000004-0000-0ff1-ce00-000000000000 $lyncSP.ServicePrincipalNames.Add("00000004-0000-0ff1-ce00-000000000000/lync.contoso.com") Set-MSOLServicePrincipal -AppPrincipalID 00000004-0000-0ff1-ce00-000000000000 -ServicePrincipalNames $lyncSP.ServicePrincipalNames
Doug Deitterick, in a blog post OAuth Certificate in Lync Server 2013 (http://bit.ly/1l1yWIL), clarified that the OAuth certificate for Lync 2013 is a global one and that it is replicated using the Central Management Store (CMS). While this kind of replication makes the management of the certificate easier, it also implies that the private key must always be available and that all the Lync Servers have to accept the certification path that released the certificate.
For a deep dive into OAuth and Lync integration, it is useful to watch Bhargav Shukla's presentation at the Microsoft Exchange Conference 2014, Integrating Exchange 2013 with Lync and SharePoint, which is available on Channel 9 (http://bit.ly/1rplwvg).
18.218.171.212