In some scenarios, you may have to control Cloud Based Discovery through a Group Policy Object (GPO). To disable Cloud Based Discovery, deploy the following registry settings on the client computer, depending on the client that you use:
For Lync 2013 (Skype for Business) client:HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Office\15.0\Lync
For Skype for Business 2016 client:HKEY_LOCAL_MACHINE \Software\Policies\Microsoft\Office\16.0\Lync
To disable cloud-based discovery logic, run the following command to set the
DisableCloudBasedDiscovery parameter as REG_DWORD to
1:
reg add HKLM\Software\Policies\Microsoft\Office\15.0\Lync /v DisableCloudBasedDiscovery /t REG_DWORD /d 1 /f
UPN Enforcement for OrgID
UPN Enforcement for OrgID now requires users to enter credentials in UPN format (user@domain.com) when an OrgID Authentication challenge is presented to the client. This feature is typically configured if Azure Active Directory (AAD) Federation is enabled for the domain in the UPN of the user. For example, if you configured Hybrid for Exchange, SharePoint, or Skype for Business, and if Modern Authentication (ADAL) is not enabled for the tenant, Office 365 uses OrgID authentication.
When an OrgID authentication challenge is detected, the client now enforces the UPN format (sipaddress@contoso.com) and no longer accepts the NTLM format (DOMAIN\USER).
For more information about Modern Authentication in Skype for Business Online, see
the authentication behavior for Office 2013 or Office 2016 client apps.
SIP Autodetection from Azure
This feature, also known as "Lync signs in second,” enables the client to use existing Office 365 stored credentials to authenticate to Azure Active Directory (AAD) and query for the user’s SIP address. If the query is successful, the client uses the SIP address and stored credentials to automatically sign in to Skype for Business Online.
In previous client versions, users were always challenged for their SIP address and credentials to access the Skype for Business Online tenant, even if they had valid Office 365 credentials stored on the computer.
If the stored credentials are not valid, or if the SIP address query to AAD fails, the client reverts to the previous behavior and challenges the user for valid credentials.