Очередная встреча UC² под номером 26 состоится через две недели, 30 числа, как обычно с 18-00 до 21-00. Встреча будет проходить и в ОНЛАЙН-режиме. А вот кто будет выступать:

  • Михаил Переяславский, Инженер группы технической поддержки отдела продаж, Integrated Research UKI Ltd

Тема: Подходит ли ваша сеть для Skype for Business Online?

Подзаголовок: IR Prognosis UC Assessor.

Краткое содержание: Переход на облачные решения, как то Office 365 и, в частности, Skype For Business Online, накладывает определённые требования на сетевую инфраструктуру. Соответствует ли она этим требованиям?  Как IR Prognosis UC Assessor (Microsoft certified IT Pro Tool) поможет ответить на этот вопрос – об этом пойдёт речь на семинаре.

  • Александр Журавлев, Руководитель лаборатории, UCLAB

Тема доклада: Решения AudioCodes для Skype Operations Frameworks.

Краткое содержание: В докладе будет рассмотрена актуальная версия методологии Skype Operations Frameworks V4 (SOF) и будут рассмотрены решения AudioCodes (с практическими примерами и демонстрациями) и их роли в методологии SOF .

  • Mediant CCE Appliance (Skype for Business Cloud Connector Edition
  • IP Phones для Skype for Business / Skype for Business Online (Firmware 3.X)
  • IP Phone Manager

Регистрация на встречу как обычно тут.

Очередная встреча UC² под номером 25 состоится через неделю, 25 числа, как обычно с 18-00 до 21-00. Встреча будет проходить и в ОНЛАЙН-режиме. А вот кто будет выступать:

  • Борис Лохвицкий, Microsoft

Тема: Архитектура Exchange Server 2016.

Борис будет рассказывать знаменитый доклад Росса Смита, с которым последний выступает на всех крупных мероприятиях в течение последних нескольких лет. Впервые на русском языке.

  • Олег Крылов, UC User Community Russia

Тема доклада: Управление локальными учетными записями в доменной среде

Олег расскажет про использование уже не нового, но до сих пор крайне актуального инструмента LAPS (Local Administrator Password Solution).

Регистрация на встречу как обычно тут.

Обновление. Записи доступны по ссылкам:
UC². Встреча №25. Борис Лохвицкий. Архитектура Exchange Server 2016

Обновление2: Записи доступны по ссылкам:
UC². Встреча №18. Димо Илиев. Cильные и слабые стороны KEMP Technologies
UC². Встреча №18. Дмитрий Плохих. Современные общие папки: под капотом

Обновление: мероприятие так же будет проходить в оффлайн-режиме в МТЦ.

Очередная встреча UC² под номером 18 состоится уже через неделю, в последний вторник сентября – 27 числа, как обычно с 18-00 до 21-00. Встреча будет проходить в ОНЛАЙН-режиме. А вот кто будет выступать:

  1. Дмитрий Плохих (Microsoft, PFE Exchange Server)

    Тема: Современные общие папки: под капотом.
    – Обзор архитектуры, отличия от «классических» общих папок
    – Репликация иерархии
    – Клиентский доступ и современные общие папки
    – Поиск неисправностей в работе репликации и клиентском доступе
    – Обзор процесса миграции

  2. Димо Илиев (KEMP Technologies)

    Тема: Cильные и слабые стороны KEMP Technologies согласно “Gartner 2016 Magic Quadrant Application Delivery Controllers”.
    – Аналитика и обзор рынка
    – KEMP Technologies, сильные и слабые стороны согласно “2016 Magic Quadrant Application Delivery Controllers”
    – “Важнейшие возможности”:

    Infrastructure Load Balancing
    Standard Enterprise Apps
    Customized Enterprise Apps
    Mid-Market ADC
    Mode 2 App Development
    Mode 1 / Mode 2 Hybrid ADC

Регистрация на встречу как обычно тут.

Очередная встреча UC² будет совмещена со встречей сообщества IT Pro. В связи с этим встречаемся не в последний вторник месяца, а в последний четверг месяца, то есть 23 июня с 19-00 до 21-30. Встреча будет проходить в Технологическом Центре Microsoft (MTC) и транслироваться средствами Skype for Business Online. А вот кто будет выступать:

  1. Вадим Поданс, “Миграция с SHA1 на SHA2, мифы и реальность”

    В процессе доклада Вадимс опишет проблематику (уязвимость SHA1 на предмет коллизий) и политику вендоров в отношении SHA1. Обозначит стратегии миграции (обновление существующей инфраструктуры или миграция в новый PKI) и какие критерии будут влиять на выбор. А так же расскажет, как планировать и производить миграцию при обновлении существующей инфраструктуры с использованием демонстрации.

  2. Олег Крылов, “Управление Exchange Server с помощью Desired State Configuration”

    В докладе будет рассмотрена концепция применения декларативных конфигураций на базе технологии Desired State Configuration с использованием кастомного модуля PowerShell в условиях on-premise инсталляций. Будут разобраны как технические, так и архитектурные моменты. И все это с живой демонстрацией работы данной концепции.
    Это доклад, который Олег по техническим причинам не успел подготовить для MVP Community Roadshow, проходившем в Санкт-Петербурге 7 июня.

Регистрация на встречу как обычно тут.

Обновление. Записи доступны по ссылкам:
UC². Встреча №15. Олег Крылов. Управление Exchange Server с помощью Desired State Configuration

1285223681_nerd_party_001

Картинка кликабельна. Будем дико угорать по Керберосу 🙂

ORF –  достаточно лёгкий антиспам, который позволяет, не сильно загружая систему, хорошо прореживать трафик нежелательной корреспонденции. Он имеет замечательный фильтр, название которого я вынес в заголовок – HELO Domain Blacklist.

Простейшая smtp-сессия выглядит следующим образом:

1 220 my.server1.name Microsoft ESMTP MAIL Service ready
2 EHLO remote.server2.name
3 250 my.server1.name Hello [2.2.2.2]
4 MAIL FROM:user@remote.server2.name
5 250 2.1.0 Sender OK
6 RCPT TO:user@my.server1.name
7 250 2.1.5 Recipient OK

Фактически, уже на втором шаге мы имеем информацию по серверу отправителю, на основании которой мы можем делать заключение – хотим мы принимать от него сообщения или нет. Для этого мы можем использовать либо базы DNSBL, которые содержат адреса нехороших серверов, либо на основе каких-то правил самостоятельно анализировать имя сервера, который открыл с нами smtp-сессию. Фильтр HELO Domain Blacklist в ORF как раз и позволяет сформулировать такие правила и на основе их выполнения сбрасывать smtp-сессию, либо продолжать её (пометив письмо).

Фильтр содержит набор предопределённых условий:

  • Blacklist if the HELO/EHLO domain… is malformed – помечать в случае использования “неправильного” имени домена в HELO/EHLO
  • Blacklist if the HELO/EHLO domain… is the same as the recipient domain – помечать, если домен внешнего сервера отправителя совпадает с доменом сервера получателя
  • Blacklist if the HELO/EHLO domain… is not an FQDN – помечать, если в HELO/EHLO содержится не FQDN-имя

И набор условий, которые заданы пользователем (User-Defined HELO domain blacklist). Я использовал следующие регэкспы:

  1. .*(d{1,3})D(d{1,3})D(d{1,3}).*..*$
  2. .*(-|.|^)(access|adsl|athedsl|broadband|cable|catv|chello|client|clients|cpe|dhcp|dial|dialup|dsl|dyn|dynamic|dynamicIP|mod em|modems|node|pool|pools|ppp|pppd|pppoe|pppool|range|static|staticIP|user|xdsl|0x[0-9abcdef]{8})(-|.|d).*..*$
  3. .*(d{7}).*..*..*$
  4. .*(.|^)(home.nl|shawcable.net|fallback.pochta.ru|tpnet.pl|net.pl|net.il|pppool.de|chello.DD|orange.DD|ne.jp|rr.com| mundo-r.com|volia.net|free.fr)$
  5. .*(?<!.ad|.ae|.al|.am|.at|.au|.az|.ba|.be|.bg|.biz|.bs|.by|.ca|.ch|.cn|.com|.cy|.cz|.de|.dk|.dm|. do|.dz|.edu|.ee|.eg|.er|.es|.et|.fi|.fr|.ge|.gi|.gov|.gr|.hk|.hr|.ht|.hu|.ie|.il|.in|.is|.it|.jm| .jo|.kg|.kr|.kw|.kz|.li|.lt|.lu|.lv|.ma|.mc|.md|.mn|.mt|.mv|.my|.net|.nl|.no|.org|.pt|.qa|.ro|.r u|.sa|.se|.sg|.si|.sk|.su|.sy|.sz|.tj|.tm|.tr|.tw|.ua|.uk|.us|.uz|.va|.ye|.yu)$
  6. .*[^a-z0-9-.].*
  7. .*..*..*..*..*..*

Подробнее:

  1. Комбинация из “(1-2-3 значное число)(не цифра)(1-2-3 значное число)(не цифра)(1-2-3 значное число)”. Если имя сервера попадает под это условие – то потенциально оно сформировано на базе ip-адреса и, скорее всего, сервер с таким именем будет слать спам.
  2. В имени отправляющего сервера содержится любое слово из access, adsl, athedsl, broadband, cable, catv, chello, client, clients, cpe, dhcp, dial, dialup, dsl, dyn, dynamic, dynamicIP, modem, modems, node, pool, pools, ppp, pppd, pppoe, pppool, range, static, staticIP, user, xdsl, а также конструкцию, похожую на шестнадцатеричный ip-адрес. То есть сервер отправитель с очень большой вероятностью является клиентом домашних сетей, либо некорпоративным клиентом интернет-провайдеров. То есть с очень большой вероятностью не должен слать почту на внешние smtp-серверы. И скорее всего он будет рассылать спам.
  3. В имени отправляющего сервера содержится конструкция из семи цифр подряд в имени хоста (не домена). То есть отправитель умудрился скорее всего засунуть в имя сервера свой номер телефона, что вроде как запрещено по RFC. Поэтому сервер скорее всего рассылает спам.
  4. Список доменов, с которых не хотим принимать почту.
  5. Список доменов первого уровня, с которых хотим получать почту. Фактически регэксп содержит отрицание списка, то есть если сервер отправителя не содержится в одном из этих доменов, то он потенциальный спамер.
  6. В имени сервера отправителя содержатся символы, которые не входят в набор разрешённых (латинские буквы, цифры, знаки “-” и “.”). Сервер – потенциальный спамер.
  7. Домены слишком глубокой вложенности (host.subdomain1.subdomain2.subdomain3.subdomain4.subdomain5.com).

Регэкспы не мои.

Какие-то из них можно применять, какие-то нет. Категорически рекомендую их перенастраивать под себя. Очень полезны – первый и второй. Скоро станет бесполезен шестой (когда массово можно будет использовать нелатинские символы в именах почтовых серверов). Когда я использовал ORF, фильтрация по HELO/EHLO отбивала примерно 45% входящего smtp-трафика, примерно столько же приходилось на DNSBL. Остальные механизмы давали единичные срабатывания.

Exchange Management Shell в Exchange 2010 запускается следующим скриптом (посмотреть можно в свойствах ярлыка):

... -command ". '.RemoteExchange.ps1'; Connect-ExchangeServer -auto"

Фактически при запуске шелла используется функция Connect-ExchangeServer с ключом auto. Сама функция описана в скрипте ConnectFunctions.ps1, который находится в папке с бинарными файлами (там же где и скрипт RemoteExchange.ps1). Ключ auto в свою очередь обращается к функции _AutoDiscoverAndConnect, которая описана в том же файле:

if ($Auto)
{
_AutoDiscoverAndConnect $credential $Forest -useWIA:$useWIA
}

Теперь самое интересное – при запуске этой функции мы используем функции, которые позволяют определить хост, на котором запускается скрипт, лес и структуру окружающих его сайтов с тем, чтобы подключить клиента к “ближайшему” серверу Exchange. Почему я написал “ближайший” в кавычках станет ясно в конце этой небольшой статьи. Итак, по порядку.

Хост получаем через функцию _GetHostFqdn примерно следующим образом:

[System.Net.Dns]::GetHostByName("LocalHost").HostName

Лес определяем через функцию _GetLocalForest:

[System.DirectoryServices.ActiveDirectory.Domain]::GetComputerDomain().Forest.Name

Сайты ищем через функцию _GetSites. Функция эта фактически возвращает массив, состоящий из имён сайтов. Первый член массива – текущий сайт, в котором находится сервер, с которого мы запускаем EMS:

$localSite=[System.DirectoryServices.ActiveDirectory.ActiveDirectorySite]::GetComputerSite()

Следующие – так называемые смежные сайты (AdjacentSites). Здесь мы берём все сайт-линки для нашего текущего сайта (фактически те, в которых он имеется в наличии) и вытаскиваем из них либо первый, либо второй сайт и добавляем его имя в наш массив. Выглядит это следующим образом:

if ($localSite.SiteLinks -ne $null)
{
foreach ($siteLink in $localSite.SiteLinks)
{
$siteDN = $null
# block going backwords
if (($siteLink.Sites[0] -ne $null) -and ($siteLink.Sites[0].Name -ne $localSite.Name))
{
$siteDN = $siteLink.Sites[0].GetDirectoryEntry().DistinguishedName
}
elseif ($siteLink.Sites[1] -ne $null)
{
$siteDN = $siteLink.Sites[1].GetDirectoryEntry().DistinguishedName
}
if ($siteDN -ne $null)
{
[void] $SiteList.Add($siteDN)
}
}
}

Ну и наконец, добавляем в массив символ *, которым будут обозначаться все остальные сайты, не попавшие в смежные сайты:

[void] $SiteList.Add("*")

Тут возникает первый момент, который пока мне остался непонятным. Если у нас сайт-линков несколько, то они попадают все в свойство SiteLinks нашего текущего сайта. Выглядеть это будет примерно так:

[PS] C:Windowssystem32>$localSite | fl SiteLinks

SiteLinks : {SITELINK1, SITELINK2, SITELINK3}

То есть фактически это будет массив. Как в нём группируются сайт-линки (в каком порядке перечисляются) – непонятно. А ведь от этого зависит какой сайт-линк будет обрабатываться первым, какой вторым итд. Аналогичный момент возникает с массивом сайтов в сайт-линке:

[PS] C:Windowssystem32>$localSite.SiteLinks[0] | fl Sites

Sites : {SITE1, SITE2, SITE3}

Сайтов обычно будет несколько, и в каком порядке они перечисляются тоже не совсем ясно.

Возвращаясь к нашей функции. После получения списка сайтов мы пробуем получить список серверов Exchange в каждом из них через функцию _GetExchangeServersInSite. Функция эта ищет все объекты класса msExchExchangeServer в сайте старше определённой версии. Например, для Exchange Server 2010 SP3 это будет выглядеть так:

$configNC=([ADSI]"LDAP:/$Forest/RootDse").configurationNamingContext
$search = new-object DirectoryServices.DirectorySearcher([ADSI]"LDAP:/$Forest/$configNC")
$search.Filter = "(&(objectClass=msExchExchangeServer)(versionNumber>=1937801568)
(msExchServerSite=$siteDN))"
$search.PageSize=1000
$search.PropertiesToLoad.Clear()
[void] $search.PropertiesToLoad.Add("msexchcurrentserverroles")
[void] $search.PropertiesToLoad.Add("networkaddress")
[void] $search.PropertiesToLoad.Add("serialnumber")
$search.FindAll()

И наконец со списком серверов доходим до функции _ConnectToAnyServer, которая и занимается созданием удалённого (через New-PSSession) подключения к первому доступному из списка серверу Exchange. Причём, сначала пытаемся подключаться к серверам с ролью CAS, затем ко всем остальным.

К чему я это веду. А к тому что, данная процедура не предусматривает оценки стоимости сайт-линков, а тупо перебирает доступные объекты. В итоге администратор удалённого сайта может попытаться подключаться к серверам Exchange, которые находятся совсем не в ближайшем к нему (по стоимости) сайте, а совсем даже на другой континент, например.

Это к слову о пользе правильной архитектуры сайтов AD.

Недавно сталкивался с одной проблемой, связанной с недоконфигурацией NLB. Исходные данные: каждый сервер имеет два сетевых адаптера, помещённых в одну подсеть/вилан. Один из сетевых адаптеров используется для обработки клиентского трафика, второй для коммуникации между узлами NLB-кластера. На базе второго адаптера строится NLB-кластер, дефолтный шлюз прописан, соответственно, на адаптере для обработки клиентского траффика. Примерная схема может выглядеть так:

nlb-2nic

В этой схеме, начиная с Windows Server 2008 мы будем иметь следующее:

  • связь с кластерным ip-адресом из той же сети, где расположены узлы NLB, будет работать без каких-либо проблем
  • связь с кластерным ip-адресов из внешней сети (клиент обращается через маршрутизатор) будет отсутствовать
  • если мы переносим дефолтный шлюз с клиентского адаптера на кластерный, то связь с кластерным ip-адресом появляется

Внешний клиент пытается попасть на кластерный адаптер, но так как шлюза на нём не прописано, то пакет отбрасывается. Связано это с тем, что IP forwarding, включенный по умолчанию в Windows 2003 Server, позволявший отвечать клиенту через дефолтный шлюз, начиная с Windows Server 2008 выключен по умолчанию. А раз он выключен, то надо его включить. Например через netsh:

netsh interface ipv4 set interface "Cluster NIC" forwarding=enabled

или сразу через ключ в реестре:

Key name: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters
Value Name: IpEnableRouter
Data Type: REG_DWORD
Value: 1

Полезные ссылки:
Balancing Act: Dual-NIC Configuration with Windows Server 2008 NLB Clusters

Протокол Kerberos достаточно хорошо описан в документе «How the Kerberos Version 5 Authentication Protocol Works». Реализация протокола Kerberos в Windows Server 2003 компанией Microsoft достаточно близка к стандарту RFC 1510. С тех пор прошло 10 лет. Успели выйти Windows Server 2008, 2008 R2, 2012, готовится к выходу Windows Server 2012 R2. Сам стандарт обновился до версии RFC 4120, к которому уже согласовано большое количество дополнений. К сожалению, я нигде не видел (возможно плохо искал) документа, описывающего изменения произошедшие в протоколе Kerberos и в его реализации компанией Microsoft. Поэтому попробую восполнить этот пробел.

Так как меня интересует реализация конкретного вендора, то изменения прежде всего будут привязаны к операционным системам Windows. Continue Reading »

Ранее писал заметку про использование дополнительного компонента IIS – Application Request Routing. Для настройки полноценного RP для сервера Lync совершаем следующие дополнительные шаги:

  • В свойствах фермы в Routing Rules включаем параметр Use URL Rewrite to inspect incoming requests:

  • В настройках правила, созданного по умолчанию при создании фермы (ARR_FarmName_loadbalance) в Match URL вносим следуюший шаблон, не забывая переключиться на использование регулярных выражений (в выпадающем списке Using в Match URL выбираем Regular Expressions):
((?:dialin|meet|Fonts|Abs|Autodiscover|CertProv|ColabContent|GroupExpansion|
LMStaticData|Mcx|MeetingContent|MeetingFiles|Reach|RequestHandlerExt|RgsClients|
WebTicket).*)
  • В настройках правила, созданного по умолчанию при создании фермы (ARR_FarmName_loadbalance) в Action Properties в списке Scheme выбираем https://

Для публикации сервера Exchange можно использовать следующий шаблон:

((?:owa|OAB|Microsoft-Server-ActiveSync|EWS|ecp|Autodiscover).*)

Взято здесь.