SfB Server: Verification Level on Allowed Domains

In Lync Server 2010/2013 when we added a federated partner sip domain to the Allowed Domains list we didn’t had the option to configure the Verification Level for each federated sip domain.

This means that for Lync Server 2010/2013 the default Verification Level was UseSourceVerification for allowed domains.

If we had an open federation, then we could change this in the Access Edge Configuration, however this was Global Setting:

Please note that we can also specify the Verification Level for each Hosting Providers:

So, in Lync Server 2010/2013 the only way to control this for each sip domain was to build a MSPL Script or use a 3rd Party Application.

In Skype for Business Server 2015/2019 there is setting that will allow to configure the Verification Level for each Allowed Domain.

Here are the two common options:

Verification Level Description
UseSourceVerification Default setting, federated users can see presence and send IMs.
AlwaysUnverifiable Federated users need to be added to the contact list to be allowed to see presence.

Please note that the Verification Level for the Allowed Domain is only valid for Edge Server running Skype for Business Server 2015/2019. The Lync Server 2010/2013 Edge Servers will ignore this setting.

We cannot use SfB Control Panel to configure the Verification Level for the Allowed Domains:

To manage this setting we need to use PowerShell:

Adding a new Allowed Domain:

New-CsAllowedDomain -Identity microsoft.com -VerificationLevel AlwaysUnverifiable
https://docs.microsoft.com/powershell/module/skype/new-csalloweddomain

Changing an existing Allowed Domain:

Set-CsAllowedDomain -Identity microsoft.com -VerificationLevel AlwaysUnverifiable
https://docs.microsoft.com/powershell/module/skype/set-csalloweddomain

Apply AlwaysUnverifiable to all Allowed Domains:

Get-CsAllowedDomain | Set-CsAllowedDomain -VerificationLevel AlwaysUnverifiable

Get-CsAllowedDomain
https://docs.microsoft.com/powershell/module/skype/get-csalloweddomain

Here is user experience for AlwaysUnverifiable:

If we look at the federated user UCAPI client logs we that the SUBSCRIBE fails with 403 Forbidden:

SIP/2.0 403 Forbidden
ms-diagnostics: 1027;reason=”Cannot route this type of SIP request to or from federated partners”;source=”sipfed.microsoft.com”

After adding the user to the contact list both users can see each other presence and send Instant Messages:


In most cases we won’t need to change the default Verification Level settings, this would be the same behavior as Lync Server 2010/2013.

There are two scenarios that this setting might be useful, Open Federation with default AlwaysUnverifiable.

The other scenario is Closed Federation with some federated domains configured for AlwaysUnverifiable.

Open Federation

In this scenario we will configure all federated domains as AlwaysUnverifiable, this means that our internal users will have to add the federated contacts to their list.

Set-CsAccessEdgeConfiguration -UseDnsSrvRouting -EnablePartnerDiscovery $true -DiscoveredPartnerVerificationLevel AlwaysUnverifiable

After replication we should get the Event 14476 in the Edge Server:

Log Name: Lync Server
Source: LS Protocol Stack
Date: 1/22/2019 8:12:21 AM
Event ID: 14476
Task Category: (1001)
Level: Information
Keywords: Classic
User: N/A
Computer: sfbedge.uclobby.com
Description:
Discovery of federation partners was enabled. The user validation level setting was set to [AlwaysUnverifiable].

Then we can create an exception for a specific domain by adding it to the Allowed Domains list, by default, it will have the UseSourceVerification:

New-CsAllowedDomain -Identity microsoft.com

Closed Federation

With closed federation we also have two options, one is like in Lync Server 2010/2013 where we simply add the federated domain to Allowed Domains list:

New-CsAllowedDomain -Identity microsoft.com

The other option is to add/change a federated domain as AlwaysUnverifiable:

New-CsAllowedDomain -Identity microsoft.com -VerificationLevel AlwaysUnverifiable

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.