Настройка прокси skype for business
Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!
Для вышестоящей картинки
A для FW список портов вот тут Port summaries.
PS. Я бы импортировал root CA, sub CA и CRL последний. :)
MCITP, MCSE. Regards, Oleg
Как-то так должно быть.
Внешний интерфейс для пограничной службы доступа. Потребуется один интерфейс для каждого домена SIP с пользователями Skype для бизнеса.
Внешний интерфейс для службы пограничного сервера веб-конференций.
Внешний интерфейс для службы пограничного сервера веб-конференций.
Внешний интерфейс для пограничной службы доступа. Эта SRV-запись требуется для внешней работы клиентов Skype для бизнеса Server 2015, Lync Server 2013 и Lync Server 2010. Потребуется одна запись для каждого домена с пользователями Skype для бизнеса.
Внешний интерфейс для пограничной службы доступа. Эта SRV-запись требуется для автоматического обнаружения DNS-записей федеративных партнеров, также называемых "Разрешенные домены SIP". Потребуется одна запись для каждого домена с пользователями Skype для бизнеса.
По портам. Если вы используете один внешний IP-адрес, то как рекомендует Microsoft:
Если установлен флажок Использовать единое полное доменное имя и IP-адрес , потребуется ввести единое внешнее полное доменное имя в поле Доступ SIP . Затем следует ввести разные номера портов для всех пограничных служб: это обеспечивает их независимое подключение. Рекомендуется назначить номер порта 5061 пограничной службе доступа по протоколу SIP , 444 – пограничной службе веб-конференций и 443 – пограничной службе видео-/голосовой связи .
И т.к. вы используете NAT - убедитесь, что в топологии это указано. Там нужно указать соответствующую опцию и прописать внутренние адреса служб EDGE и внешний публичный NAT. Судя по скриншотам - у вас так не сделано. Например:
А дальше ниже там идёт указание публичного белого IP-адреса NAT.
Но это ещё пол дела. Вам нужно ещё опубликовать через обратный прокси веб-сервисы S4B. Там несколько доменных имен (которые вы заполняли в топологии) - которые так же надо будет добавить в сертификат. Инфы по этому вопросу достаточно. Хотя бы даже на том сайте, с которого вы брали инфу)
Но будьте внимательны - все эти URL-адреса (meet, dialin, S4BWEB) и порты (например 4443) - могут отличаться от вашего случая. Всё зависит от того, что вы прописали в топологии.
У меня именно так и настроено, только вопрос, на микротике проброс портов делать на External IP, который я указал на EDGE , то есть 10.47.1.138 ? Internal у меня 10.47.0.138..
А здесь Public NAT , это единственный публичный IP на микротике
Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!
Мне на данном этапе реверсивный прокси пока не нужен, а только проверить доступность S4B клиента с ПК пользователя не в домене , где то дома.. Если все это будет работать, поеду дальше, что бы подключить и мобильных клиентов. Мне по сути нужна только переписка, видео, аудио и конференции пока не приоритетны!
Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!
По IP-адресам всё верно.
А Reverse Proxy нужен по любому. Во первых через него отрабатывает autodiscover за пределами вашей организации. Во вторых для мобильных устройств не обойтись без обратного прокси:
It's expected that the external Autodiscover requests will go through the reverse proxy you've configured for Skype for Business Server 2015. However, both the internal Mobility service URL and the external Mobility service URL are associated with the external Web Services FQDN. Therefore, regardless of whether a mobile device is internal or external to your network, the device always connects to the Skype for Business Server 2015 Mobility service externally, through your reverse proxy.
Выставляем нужный VLAN:
Добавляем DVD:
Выставляем очередность загрузки:
Подсовываем дистрибутив и запускаем:
Партиции распределяем вручную:
Жмём save, done, затем
Выставил
Root password:
nguser:
Заходим под рутом.
Устанавливаем редактор и командер
Делаем полное обновление с обработкой дополнительных возможностей пакетов и их зависимостей;
Проверяем версию centos
Установка snmpwalk
Установка traceroute
Устанавливаем архиватор
Добавляем пользователя в
nano /etc/sudoers
Перезахожу под этим юзером
Отключим SELINUX
sudo nano /etc/sysconfig/selinux
sudo yum -y install nginx
Nginx, для работы SSL требует установить сертификат на инефейс.
Нам подойдёт тот же сертификат, который мы установили на Edge.
Экспортируем сертификат, идём на сервер Edge.
MMC - Certificates - Local Computer
Открываем нужный сертификат
Далее выбираем Deatils - Copy to file
Далее мы используем программу openssl.exe:
Выводим из pfx файл с закрытым ключом:
C:\PROGRA~2\GnuWin32\bin\openssl.exe pkcs12 -in "C:\cert\reverse_proxy\01_pfx.pfx" -nocerts -out "C:\cert\reverse_proxy\ciscomaster_ru.key"
Выводим из pfx файл с сертификатом:
C:\PROGRA~2\GnuWin32\bin\openssl.exe pkcs12 -in "C:\cert\reverse_proxy\01_pfx.pfx" -clcerts -nokeys -out "C:\cert\reverse_proxy\ciscomaster_ru.crt"
Выводим файл с закрытым ключом, но без пароля:
C:\PROGRA~2\GnuWin32\bin\openssl.exe rsa -in "C:\cert\reverse_proxy\ciscomaster_ru.key" -out "C:\cert\reverse_proxy\ciscomaster_ru_open.key"
Нас интересуют файлы:
ciscomaster_ru_open.key
ciscomaster_ru.crt
Создаём директорию, и помещаем туда файлы:
sudo cp /home/nguser/ciscomaster_ru_open.key /etc/nginx/ssl/
sudo cp /home/nguser/ciscomaster_ru.crt /etc/nginx/ssl/
Сам файл находится здесь:
/etc/nginx/nginx.conf
nginx состоит из модулей.
Модули настраиваются директивами.
Директивы бывают простые, которые заканчиваются ";", например:
Директивы бывают блочные, с фигурными скобками, например:
Внутри одной блочной директивы можно задавать другие директивы.
Самый корневой контекст - это main.
Нас интересует директива upstream, например:
Директива upstream описывает сервера, на которые мы будем проксировать трафик (с помощью директивы proxy_pass).
Также понадобится директива server. Которая определяет на каком порту прослушивается входящий трафик, а также куда этот трафик будет проксироваться.
После подготовки файла /etc/nginx/nginx.conf проверяем его на ошибки:
Проверка статуса сервиса:
Включаем автозапуск сервиса:
sudo systemctl enable nginx
Система должна возвратить:
Далее остановим nginx:
В этом случае ничего не откроется.
Следующий этап - это попытка подключения к скайпу с мобильного телефона, и проверка успешности звонка.
Если звонок прошел удачно, можно считать, что Reverse Proxy установлен успешно.
Развёртывания внутреннего пула или стандартного сервера даст нам только "внутренний" функционал, но не даст возможности подключаться извне.
Edge Server или пограничный сервер, позволяет значительно расширить функционал:
- Подключение клиентов SfB из интернета
- Подключение мобильных клиентов (SfB mobile)
- Подключение Web-клиентов (Подключение к конференциям через браузер)
- Федерация с другими компаниями Lync/SfB
- Федерация со Skype
- Федерация с Office 365
Итак, для SfB, Edge Server является обязательным компонентом для реализации всего перечисленного выше функционала.
Как уже было сказано, функции для удаленного доступа реализуются с помощью Edge Server.
Edge Server является ролью SfB и его нельзя совместить с Front-End Server или со Standard SfB Server. Т.е. без Edge Server обойтись нельзя.
Edge Server не является членом домена и находится в DMZ.
Для реализации удаленного доступа нам также понадобится Reverse Proxy. Reverse Proxy - это не роль SfB, и может быть реализован различными продуктами.
С точки зрения архитектуры нам понадобятся белые IP адреса.
Рекомендуется 4 IP:
- 1 Для Reverse Proxy
- 3 для Edge server
Минимально 2 IP:
- 1 Для Reverse Proxy
- 1 для Edge server
Edge требует два интерфейса: внешний и внутренний
Edge также требует установки двух сертификатов: один на внешнем интерфейсе, другой на внутреннем.
Все клиенты, кто подключаются из интернета, подключаются к Edge. И Edge проксирует Media traffic, SIP traffic от клиента на внутренний Front-End.
Для шифрования коммуникаций, необходимо иметь коммерческий, публичный, доверенный сертификат на внешнем интерфейсе Edge.
На внутреннем интерфейсе Edge можно использовать внутренний сертификат.
Понятно, что для правильной работы необходимо корректно настроить правила Firewall.
На Edge мы имеем три внешних сервиса, каждый из которых использует отдельный белый IP:
- Access Edge Service - к нему подключаются внешние клиенты. С этим сервисом устанавливается подключения при федерации между Edges разных компаний.
Для Access Edge Service должен быть закреплён отдельный IP, и на нём должно быть открыто несколько портов:
- SIP/TLS(TCP:443) - по этому порту подключаются внешние клиенты к Edge.
- SIP/MTLS(TCP:5061) - по этому порту подключаются федерации. Для федераций с системами XMPP дополнительно используется порт 5269 - Web Conference Edge Service
Использует только один порт:
- PSOM/TLS(TCP:443) - AudioVideo Edge Service - интерфейс, по которому идёт media трафик.
- STUN(UDP:3478) - Передача media-трафика от клиента.
- STUN(TCP:443)
- RTP(UDP/TCP:50000-59999) - Федерация с Office Comunication Server (старые системы)
Также имеем сервисе Reverce Proxy:
Как видно, во внешнюю зону понадобится добавить группу DNS записей.
Также понадобится несколько записей SRV
На практике используют следующие имена:
Как итог:
Наиболее часто используют следующие имена:
Реально в DNS для тестовых целей было добавлено:
Reverse Proxy - обязательный компонент, поскольку без него очень многое не будет работать.
Трафик сигнализации мобильных клиентов идёт через Reverse Proxy (Media идет через Edge)
Также через Reverse Proxy клиенты подключаются через Internet Browser (ссылка на конференцию)
Обеспечение работы Службы автообнаружения
Скачивание адресной книги
Развертывание группы рассылки в контакт-листе.
Скачивание содержимого конференции
Reverse Proxy - принимает подключения по порту 443, и перенаправляет это подключение на Frontend на порт 4443. Также он принимает входящий порт 80 и перенаправляет это подключение на Frontend на порт 8080.
На Reverse Proxy стоит отдельный публичный сертификат, в котором имеются все необходимые имена, по которым подключаются клиенты к Reverse Proxy.
Здесь нужен коммерческий сертификат.
или в DNS мы пропишем:
Мы рассматриваем ситуацию с использованием 3-х адресов под Edge и 1 адрес под Reverse Proxy.
- Kemp Loadmaster 2600
- TMG 2010
- IIS ARR
- Web Application Proxy
- Sophos UTM
- Другие решения
Одной из возможностей 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
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.
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 смогут нормально продолжать работать и обслуживать внутренних пользователей.
Как мы уже рассматривали, 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:
Вообще в 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 необходим, поскольку такому сертификату клиенты уже доверяют.
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:
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 и поддерживает шифрование и аутентификацию.
Один из наиболее важных вопросов безопасности - это аутентификация клиентов в систему.
Пользователь может зайти в систему используя несколько путей:
◆ 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.
Abstract: If you wish to setup a fully supported Skype for business (=SfB) environment you could use a hardware loadbalancer (for example Kemp or F5) or use the Microsoft Web Application Proxy [=WAP] (which is part from Windows Server 2012 R2).
This short howto will explain the steps which must be taken in order to replace a former hardware loadbalancer (used for the Lync Webservices) with the Microsoft Web Application Proxy (which is now supported) for the SfB Webservices.
Note: We will use the Web Application Proxy for SfB, however you might use it later one also for MS Exchange or Office Web Apps / Office Online Server. But this config isn´t covered in this howto.
Preparation:
– Setup a ADFS as mentioned (Install ADFS Server on Windows 2012 R2). Note: For SfB we do not need any authentication configurations.
– Setup a server in the DMZ (our Web Application Proxy server) based on Windows 2012 R2. On that Server:
* Assign one external IP Address (we use the internal DNS server in that howto) [If you wish to replace a old hardware loadbalancer you can assign the IP here]
* A public trusted certificate (e.g. from Comodo, Verisign, …) [If you wish to replace a old hardware loadbalancer you can export it from there and reuse it here]
* The server does need to be domain joined, but if you want to publish non-claims aware applications using KCD (Kerberos Constrained Delegation) it need to be domain joined
– For the LAB configuration here, you need to be a domain administrator
– Configure the proxy (as mentioned here) on the server correctly, so that the server is able to reach the internal server
Firewall:
– the Web Application Proxy should have access to the internal DNS server
– the Web Application Proxy server must reach the SfB Frontend Server / the Hardware LoadbLanancer via 4443
Implementation steps:
1.) If you didn´t use Split DNS, then you might need to adjust the host file on the WAP server and point the ADFS DNS name to the internal server
2.) On the Microsoft Web Application Proxy [=WAP] Server import the public SSL certificate at first via MMC (into the Personal certificate store)
3.) start a powershell (run as admin) and enter:
Install-WindowsFeature Web-Application-Proxy,RSAT-RemoteAccess-Mgmt, RSAT-RemoteAccess-PowerShell, GPMC, CMAK
4.) After the installation finished, open the Web Application Proxy Configuration Wizard in the Server Manager
5.) Click on next
6.) Enter the federation service name you defined when you setup the ADFS Server. Enter also a username and password. Then press next.
7.) Select now the certificate which should be used. Then press next.
8.) In the confirmation make sure the info´s are correct, then click on configure
9.) If you see the screen below the web application proxy was configured successfully.
10.) Your Microsoft Web Application Proxy [=WAP] is now ready to be used. So we can now start to publish our web applications.
11.) Now open the Remote Access Management Console and click Publish
12.) Press next in the following screen
13.) As PreAuthentication we need to use “Pass-Trough”
14.) Inside the Publishing settings, enter a useful name (A), choose the external URL which you entered in the topology (B), choose the certificate you imported (C), and define the backed URL (D) this is normally your internal Frontend pool which is listening here on 4443. So make sure you use the correct hostname and port.
You can also check on the WAP server via telnet if the port from there to the internal server is open.
15.) If you are fine with the summary seen there, press on “publish”
16.) Once successfully published click on “close”
17.) Now you need to disable the DisableTranslateUrlInRequestHeaders to avoid issues mentioned here.
17a.) At first we need the Application ID, so run the following comand and make a note from the ID.
Get-WebApplicationProxyApplication | Format-Table ID, Name, ExternalURL
17b.) Once done and once you have the ID check the configuration via:
get-WebApplicationProxyApplication –ID | fl
this should show something like (DisableTranslateUrlInRequestHeaders is currently on false):
17c.) To fix that we need now to set the DisableTranslateUrlInRequestHeaders to true via:
Set-WebApplicationProxyApplication -id -DisableTranslateUrlInRequestHeaders:$true
18.) If you wish to use the web application proxy for other services, then you need to repeat the steps. You can refer to the Official Microsoft howto here. Or check the “Configuring Office Online Server with Skype for Business” article here.
Читайте также: