Одной из возможностей Skype for Business является обеспечение подключения не только внутренних пользователей, но и с внешними юзерами.
Внешними пользователями могут быть как сотрудники этой же компании, кто подключается извне; так и миллионы людей из внешний сетей: Google, AOL, Skype.

Как уже упоминалось в предыдущих материалах, для внешних подключений используется Edge roles.
Этих ролей несколько, поэтому edge topology может быть следующих видов:
◆ Single consolidated Edge with private IP addresses and NAT
◆ Single consolidated Edge with public IP addresses
◆ Scaled consolidated Edge and DNS load balancing with private IP addresses using NAT
◆ Scaled consolidated Edge and DNS load balancing with public IP addresses
◆ Scaled consolidated Edge with public IP addresses, with load balancers

Edge Server

Single consolidated Edge model несёт в себе следующие роли:

• Access Edge - специально разработанный сервис proxy для обработки проходящего SIP signaling traffic. В данном решении используются два интерфейса: внешний трафик терминируется на внешнем интерфейсе и затем на внутреннем интерфейсе устанавливается новая сессия SIP на внутренние ресурсы.
  Access Edge role обрабатывает все типы federation traffic: SIP, PIC, eXtensible Messaging and Presence Protocol (XMPP), Skype.
  Access Edge role не производит authentication, поэтому сервер не должен быть контроллером домена: аутентификация происходит на уровне Director pool или Front End pool.
• Web Conferencing Edge - это есть прокси сервис для трафика Persistent Shared Object Model (PSOM). Данный протокол используется для обеспечения доступа к conferencing content (whiteboards, poll pages), которая совместно используется внешними и внутренними пользователями.
• AV Edge - это реализация протокола Interactive Connectivity Establishment (ICE), который используется для преодоления NAT медиа-трафиком (методы STUN и TURN)

Как уже было сказано, Edge server должен быть оборудован минимум двумя интерфейсами: один внешний, другой внутренний.
На внешний интерфейс необходимо повесить три "белых" IP адреса для каждой Edge role. Также для каждой роли будут созданы три разных URL.
На внутренний интерфейс необходим один IP адрес, который должен быть доступен для внутренней сети предприятия.

Таким образом для Edge server необходимо четыре IP адреса и четыре FQDN.
Также при разворачивании нескольких Edge servers в нескольких сайтах, необходимо учитывать как лучше маршрутизировать внешний трафик.
Надо четко понимать, что federation traffic для определённого SIP domain идёт только по одному пути, который определяется DNS Service (SRV) record, поскольку эта SRV-запись указывает только на одну FQDN.
Другой Edge traffic (например real-time audio) лучше маршрутизировать с учётом расположения сайтов, т.е. при наличии нескольких офисов мы можем организовать соответственно несколько Edge pools работающих с своим Front End pools.

The Director

Director role обеспечивает аутентификацию юзеров и перенаправляет этих юзеров на их home pool.
Таким образом Director является ещё одним уровнем между Edge server и Front End server, что наёт несколько преимуществ:

• Если в организации настроено несколько pools, Director будет осуществлять registration/authentication requests и затем распределять трафик между этими pools и соответствующими Front End servers.
• Вторым плюсом являются вопросы безопасности. Director берет на себя аутентификацию внешних пользователей и является дополнительным барьером. В случае атаки denial of service (DoS) на аутентификацию, весь удар примет на себя Director, а Front End servers смогут нормально продолжать работать и обслуживать внутренних пользователей.

Reverse Proxy

Как мы уже рассматривали, Edge server и Director используются для доступа извне для SIP и media.
Помимо этого клиентам необходим доступ к WEB элементам, которые живут на IIS.
Важно понимать, что mobile clints используют для логина web подключения.
Внешние подключения через web используются для подключения к meeting conferences, download meeting content, download files from the Address Book server, obtain updates to client and device software и т.д.

Для публикования используется один из самых простых методов - simple URL.
URL публикуется на Director и формируются во время работы Setup.
Нам необходимо сформировать три simple URL: Meet URL, Dial-in URL, Admin URL.
При этом Admin URL опциональна, никогда не публикуется наружу, и необходима для работы изнутри Skype for Business Control Panel.

Meet URL нужна для каждого SIP domain.
Admin URL, Dial-in URL нужны для каждой organization.

Рассмотрим примеры вариантов реализации simple URLs:

• Dedicated simple URL for each site
  Это самый простой в реализации метод
  https://meet.rlscomms.net
  https://dialin.rlscomms.net
  https://admin.rlscomms.net
  Для каждого дополнительного домена SIP:
  https://meet.anotherdomain.com
  Как видно, для реализации данного метода нужно несколько записей DNS, а также несколько сертификатов.
• shared simple URL syntax - метод подразумевающий использование лишь одной записи DNS
  https://directorwebext.rlscomms.net/abc/meet/
  https://directorwebext.rlscomms.net/anotherdomain/meet/
  https://directorwebext.rlscomms.net/dialin/
  https://directorwebext.rlscomms.net/admin/
  Данный метод сложнее в настройке

Certificates

Вообще в Skype for Business Server 2015 можно встретить два типа сертификатов:
◆ Client-based certificates
◆ Server-based certificates

Client-based certificates используются для аутентификации клиента, мы же сейчас обсудим Server-based certificates.

Сертификаты необходимы как для внутренних серверов, так и для публикации Skype for Business Server 2015 наружу.
Сертификат нужен для доверительных отношений клиента и сервера, чтобы клиент мог удостовериться что взаимодействует с нужным сервером, а не с подменой.

Сертификаты используются на обоих интерфейсах Edge server:
на внешнем интерфейсе должен использоваться public CA trusted certificate на все три роли Meet URL, Dial-in URL, Admin URL. public CA trusted certificate необходим, поскольку такому сертификату клиенты уже доверяют.

Детали сертификатов задаются во время работы Setup в Certificate Wizard.
Есть некоторые рекомендации:
The subject of the external certificate is the Access Edge name. The subject name should also
be the first subject alternative name (SAN), and then further SANs should be used to include the
other required URLs, such as the FQDN of the Web Conferencing Edge. When running the wizard, you may notice that the AV Edge FQDN is not included on the certificate. This is because it
doesn’t need the name to use the certificate for encryption. This saves you the cost of an additional SAN.
For client autoconfiguration to work, the SANs should contain the sip.domainname.com URL
for each SIP domain supported because this is one of the failback URLs used by the clients. See
Chapter 4, “Desktop Clients,” to learn more.
As a rule, you should create the external certificate with an exportable private key. This is a
requirement if you are running a pool of servers because the certificate used for the AV Edge
authentication on the external interface must be the same on each server in the pool. It is also
needed if you create the certificate request on a server other than where it will be used.

DNS entries

Skype for Business использует два типа DNS entries A record и SRV record.
Обычно DNS для Skype for Business разворачивается в виде split-brain DNS implementation: когда внутри и снаружи настраиваются идентичные зоны, но с разными записями, что позволяет клиентам получать разные ответы, в зависимости от физического расположения клиента.
Split-brain гарантирует, что снаружи клиент получит адреса серверов external servers (Edge), в то же время изнутри да же DNS entry укажет на Front End pool.

С такой конфигурацией нужно удостовериться, что машины во внутренней сети правильно разрешают адреса; в особенности важно как Edge servers будут разрешать их запросы DNS.
Возможно выходом будет комбинация использования DNS и HOSTS file.
Также важно, что внутренние клиенты и сервера должны разрешать на внешний адрес для сервиса AV Edge service.

The Edge server should resolve as follows:

A computer on the internal network should resolve as follows:

The Front End server should resolve as follows:

A computer outside your network should resolve from external DNS as follows:

Media and Signaling Security

Skype for Business Server 2015 это объект, который может оказаться мишенью для множества атак, например:

• spoofing - когда кто-то представляется тем, кем на самом деле не является
• eavesdropping - прослушка трафика
• replay - подмена трафика аутентификации, с целью получения доступа. Например запись хеша из чужого разговора, и затем его replay для аутенитификации уже в своём разгововре.

Все эти атаки могут быть предотвращены через использование Mutual Transport Layer Security (MTLS) между серверами, а также Transport Layer Security (TLS) между клиентом и сервером.
TLS и MTLS позволяют выполнять и шифрование трафика и аутентификацию.

Касательно трафика SIP: Клиент должен validate сертификат сервера, для чего клиент должен доверять CA, которым был выдан этот сертификат. Таким образом клиент удостоверяется, что общается именно с нужным ему сервером, а не подставным лицом.
Сервера, при использовании MTLS обмениваются сертификатами и выполняют validate. Такая процедура выполняется между внутренними серверами, а также между Edge servers и внешним gateway.

Другие типы трафика также шифруются с помощью SSL, TLS: трафик AV media, gateways Mediation server, reverse proxy Skype for Business servers и др.

Media Traffic шифруется с помощью протокола Secure Real-Time Transport Protocol (SRTP), который специализируется для передачи media и поддерживает шифрование и аутентификацию.

Authentication

Один из наиболее важных вопросов безопасности - это аутентификация клиентов в систему.
Пользователь может зайти в систему используя несколько путей:
◆ Through an internal client
◆ Through an external client
◆ Via a web application
◆ Anonymously (conferencing or via a web application)
◆ Through an IP phone device
◆ Through a mobile device

Рассмотрим Standard Desctop Client.
Если клиент находится внутри сети, для аутентификации используется Kerberos V5.
Если клиент находится за пределами сети, используется менее безопасный NT LAN Manager (NTLM), поскольку Kerberos требует прямого доступа к AD.

Независимо от того, откуда приходит клиент, при первой аутентификации клиент загружает Skype for Business certificate, подписанный Front End server.
Каждый клиент загружает для себя свой персональный сертификат, который валиден в течение 180 дней; причем пользователь сможет логиниться даже в случае если учетка была disabled: такой метод логина был разработан на случай недоступности AD.

Другие типы клиентов могут использовать свой тип аутентификации.

Skype for Business Web App обеспечивает удалённый доступ к конференциям. Он также используется NTLM или KerberoS, в зависимости от того, где находится клиент.
Также может быть использовано Anonymous authentication, которая работает через использование Digest authentication protocol, который требует чтобы клиент для аутентификации предоставил свой meeting ID

Наконец может быть использована PIN authentication, т.к. когда юзер набирает extension и PIN.