Обновление: Записи доступны по ссылкам:
UC². Встреча №20. Александр Перчиков. Polycom + Skype for Business = законченное UC решение
UC². Встреча №20. Сергей Росин. Microsoft Teams, Skype Operations Framework, Skype для Бизнеса
UC². Встреча №20. Vadims Podans. AD CS Web Services
UC². Встреча №20. Сергей Груздов. Программно-определяемые сети

В очередной раз объединяемся с группой IT Pro. Докладчиков будет четверо. Формат встречи – онлайн. Дата встречи – как обычно, последний вторник месяца, 29 ноября. Начало – 15-00.

Расписание встречи следующее:

15:00-16:30 Polycom + Skype for Business = законченное UC решение. Александр Перчиков, Руководитель Центра Решений и Технологий Polycom.

  • Решения Polycom для реалистичной видеосвязи
  • Аудио и видео периферия для Skype For Business
  • Интеграция сред SfB и «классической» ВКС

16:30-18:00 Microsoft Teams, Skype Operations Framework, Skype для Бизнеса в составе пакета Click-To-Run. Сергей Росин, Technical Solutions Professional – Communications Microsoft Russia.

Будут затронуты следующие темы:

Microsoft Teams – Новое решение для совместной работы на базе мгновенных сообщений

  • Описание решения
  • Возможности
  • Рекомендации к развертыванию

Skype Operations Framework – Методология для корректного развертывания Skype для Бизнеса в облаке

  • Описание методологии
  • Описание набора документации в методологии

Skype для Бизнеса в составе пакета Click-To-Run. Уникальные возможности, которых нет MSI пакете Office 2016 Pro Plus.

18:00-19:30 ADCS Web Services – шаг в открытые сети. Вадимс Поданс, восьмикратный MVP.

План доклада:

  • Краткий экскурс в историю с основными вехами развития ADCS начиная с NT4 с обсуждением наиболее важных и насущных проблем совместимости и безопасности ADCS
  • Краткий обзор ADCS Web Services
  • Описание новых сценариев использования ADCS для недоменных клиентов
  • Более детальный разбор ADCS Web Services при внедрении
  • Демонстрация

Описание от автора: «Веб-службы ADCS позволяют раздвинуть границы использования Microsoft CA за пределы периметра с возможностью интеграции и совместимости со сторонними гетерогенными системами. Объясню. Расскажу. Покажу».

19:30-21:00 Эволюция SDN в Windows Server: Network Controller. Сергей Груздов, ведущий инженер, Dataline.

Тезисы: Новое Software Defined Network v2 в Windows Server 2016: Network Controller, Software Load Balancing, GRE/SSTP/IPSEC VPN, поддержка VXLAN

Идея виртуализации сетей берет свое начало со статических VLAN, однако облачная среда нуждается в более гибких и безопасных решениях сетевой виртуализации. Уже в Windows Server 2012 сетевая виртуализация Hyper-V поддерживала формат инкапсуляции NVGRE. Windows Server 2016 работает и с другим перспективным стандартом инкапсуляции – VXLAN, позволяющим обмениваться туннельными конечными точками (VTEP) между виртуальными машинами и физическими устройствами.  Network Controller, о котором пойдет речь в докладе, представляет собой программируемую среду для управления такими виртуальными сетями и применения детальных политик, определяющих доступ, балансировку нагрузки и Quality of Service. Многие производители включают поддержку стандарта VXLAN в свои сетевые адаптеры и активное сетевое оборудование.

Ссылка на мероприятие – тут.

Последние 5 лет с завидной периодичностью встречаю вопросы может ли Exchange использовать RODC (Read-Only Domain Controller) и, в частности, ROGC – RODC, которые содержат глобальный каталог. Ответ на этот вопрос уже давно дан:

  • Нет, Exchange не может использовать RODC/ROGC
  • Нет, Exchange не запустится в том сайте, где находятся только RODC/ROGC
  • Да, нужен полноценный контроллер домена, с правом на запись

Следующий вопрос, который может возникнуть – а почему нельзя использовать RODC/ROGC?

Здесь немного придётся погрузиться в историю. Exchange 2000/2003 использовал специальный компонент DSAccess, который отвечал за доступ к Active Directory (чтение конфигурации, внесение изменений итд). Кроме этого, DSAccess отвечал за составление списка контроллеров домена и серверов глобального каталога, который мог бы в дальнейшем использовать Exchange. Механизм построения списка выглядел следующим образом:

  • DSAccess обращался к DS Locator Service
  • Через него (через ldap-запрос к разделу конфигурации) получал список DC и GC локального сайта AD, в котором находился сервер Exchange
  • Пытался подключиться к каждому из серверов из полученного списка
  • Кешировал 10 доступных DC и 10 доступных GC
  • Перестраивал список таким образом, что в верх списка попадали GC, из того же домена, членом которого являлся сервер Exchange

Отсюда следуют достаточно очевидные выводы:

  • Как минимум один GC должен находиться в сайте, где расположен сервер Exchange
  • GC должен находиться достаточно близко к серверу Exchange. Если имеются две физические локации в одном сайте, то лучше бы сервер GC разместить в той же локации, где находится сервер Exchange
  • Для обеспечения высокой доступности имеет смысл держать 2 или больше GC в сайте, где находится сервер Exchange

В Excahnge 2007 компонент разбили на две части – AD Provider и AD Driver (оба работают в рамках одного сервиса – Active Directory Topology). Функциональность не изменилась. Они так же отвечали за работу с Active Directory. AD Provider отвечал за обращение к AD и поддержку работы кэша (с результатом обращений к AD). AD Driver отвечал за построение топологии DC.

Возвращаясь к нашему вопросу про ROGC. И AD Provider и DSAccess получают список контроллеров домена (включая GC) через специальный ldap-запрос в контейнере с сайтами в разделе конфигурации (CN=Sites,CN=Configuration,DC=domain, DC=local). Запрос для Exchange 2010 выглядит следующим образом:

(|(&(objectCategory=CN=NTDS-DSA,CN=Schema,CN=Configuration,DC=domain,DC=local)
(objectCategory=CN=NTDS-DSA-RO,CN=Schema,CN=Configuration,DC=domain,DC=local))
(&(objectCategory=CN=NTDS-DSA,CN=Schema,CN=Configuration,DC=domain,DC=local)
(objectCategory=CN=NTDS-DSA,CN=Schema,CN=Configuration,DC=domain,DC=local)))

Если внимательно посмотреть, то запрос возвращает только объекты, которые являются экземплярами класса NTDS-DSA (который представляет DSA на конкретном контроллере домена). И тут есть небольшая тонкость. RODC представлены другим классом – NTDS-DSA-RO, а следовательно, в процессе запроса списка контроллеров домена в этот список не попадают. То есть, Exchange вообще ничего не знает про контроллеры домена только для чтения. А следовательно, пользоваться RODC/ROGC в качестве контроллеров домена не умеет (что не исключает возможности их использования в качестве серверов DNS, например).

Полезные ссылки:
How DSAccess Builds the List of Cached Servers
Exchange 2000 SP2’s DSAccess Component
The AD Administrator’s Guide to Exchange 2007
AD Integration – from 2003 to 2007….
Windows 2008 Read Only Domain Controllers and Exchange 2007…

Протокол 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 »

С проблемой озвученной в заголовке столкнулся в процессе поиска решения проблемы с регистрациями рабочих станций во внутренней DNS-зоне домена. При вводе сервера в домен всё проходило штатно. Через некоторое время сервер переставал пинговаться, а его имя разрешаться в ip-адрес. При просмотре DNS имя сервера не находилось, хотя оно там должно было бы быть. Неприятная ситуация.

Теперь немного теории. Начиная с Windows Server 2003 доступны три варианта репликации DNS-зон с Active Directory:

  • “To all DNS servers in the AD forest”. DNS-зона при таком выборе будет реплицироваться на все DNS-серверы леса. Сам объект зоны с записями будет располагаться в разделе ForestDnsZones (полное имя – CN=MicrosoftDNS,DC=ForestDNSZones,DC=domain,DC=com). Репликация зоны будет происходить в рамках всего леса.
  • “To all DNS servers in the AD domain”. DNS-зона при таком выборе будет реплицироваться на все DNS-серверы домена. Сам объект зоны с записями будет располагаться в разделе DomainDnsZones (полное имя – CN=MicrosoftDNS,DC=DomainDNSZones,DC=domain,DC=com). Репликация зоны будет происходить в рамках домена.
  • “To all domain controllers in the AD domain”. DNS-зона при таком выборе будет реплицироваться на все контроллеры домена в домене. Сам объект зоны с записями будет располагаться в разделе Default Naming Context (полное имя – CN=MicrosoftDNS,CN=System,DC=domain,DC=com). Репликация зоны будет происходить между контроллерами конкретного домена. Этот вариант используется в домене, в котором присутствуют контроллеры домена на базе Windows 2000 Server. Последние не знают о наличии разделов ForestDnsZones/DomainDnsZones, соответственно не могут с ними работать.

Возникает вопрос – а что будет, если некоторая интегрированная с AD DNS-зона будет присутствовать в нескольких разделах приложений? Возможно ли такое вообще? Теоретически возможно:

  • У нас имеется домен на базе Windows 2000 Server (которые не знают о наличии разделов ForestDnsZones/DomainDnsZones). При вводе нового контроллера домена на базе Windows Server 2003 мы можем указать для DNS-зоны тип репликации, который не поддерживается старыми контроллерами домена.
  • При создании зоны вручную, мы можем выбрать любой из первых двух вариантов репликации. Затем, на другом контроллере домене, не дождавшись пока эта DNS-зона отреплицируется, создать её тоже вручную.
  • При вводе нового контроллера домена, автоматически может ставиться роль DNS-сервера. При этом, существующие зоны, находящиеся в разделах ForestDnsZones/DomainDnsZones, будут среплицированы на новый контроллер домена. Ничто не мешает нам, не дождавшись завершения такой репликации, вручную создать эти зоны.

Стоит заметить, что все эти варианты возникают из-за человеческого фактора и они более чем возможны. Таким образом мы можем относительно легко задублировать зоны, что как раз приведёт к эффекту пропадания записей в задублированной зоне. В ADSI Edit выглядеть задублированная зона будет примерно следующим образом:

Capture

Записи, начинающиеся с ..InProgress-[GUID], указывают на зоны, репликация которых не смогла завершиться успешно из-за наличия дубликатов с другим номером USN. Записи, содержащие CNF:[GUID], указывают на зоны, содержащие дупликаты в базе AD.

Что с этим делать? Дупликаты необходимо удалить. Проще всего это сделать через ADSI Edit, удалив записи, которые содержат ..InProgress-[GUID] и CNF:[GUID].

Подсмотрено здесь.

Вытащу ка я одну старую новость. Возможно не все об этом знают.

Существует некоторая общественная организация CA/Browser Forum, которая включает в себя большое количество поставщиков сертификатов и производителей браузеров. Цель существования данной организации выходит за рамки этой заметки. Более интересен документ, рождённый членами данной организации, который можно посмотреть здесь. Из названия документа (Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates) можно сделать вывод, что представляет он собой некоторое джентельменское соглашение о том, как должна выглядеть процедура выпуска и управления сертификатами внешними поставщиками сертификатов. Учитывая, что в организации участвуют и производители софта (в частности браузеров), то де-факто джентельменское соглашение рискует перерасти в некий стандарт.

Не менее интересно то, что этот документ может повлиять на процесс проектирования архитектуры Active Directory, Exchange Server, Lync Server. Теперь имеет смысл посмотреть на те тонкие моменты, которые уже имеет смысл учитывать про проектировании. Документ говорит:

9.2.1 Subject Alternative Name Extension

Certificate Field: extensions:subjectAltName

Required/Optional: Required

Contents: This extension MUST contain at least one entry. Each entry MUST be either a dNSName containing the Fully-Qualified Domain Name or an iPAddress containing the IP address of a server. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate.

Wildcard FQDNs are permitted.

As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Server Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Server Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Server Name.

9.2.2 Subject Common Name Field

Certificate Field: subject:commonName (OID 2.5.4.3)

Required/Optional: Deprecated (Discouraged, but not prohibited)

Contents: If present, this field MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate’s subjectAltName extension (see Section 9.2.1).

Значит это следующее:

  • Поле SAN теперь обязательно для всех сертификатов и должно содержать как минимум одну запись (FQDN или IP). Кроме этого:
    • Компания, выпускающая сертификат обязана проверять, что указанный FQDN/IP может использоваться клиентом. Делается это обычно через письмо на адрес, указанный в WHOIS для домена или через телефонный звонок.
    • Компания, выпускающая сертификат должна предупредить, что использование внутренних IP/FQDN в поле SAN с октября 2016 года не допускается. Все сертификаты с такими именами будут отозваны 1 октября 2016 года.
    • Компания, выпускающая сертификат не должна выпускать сертификаты с внутренними IP/FQDN в поле SAN, срок жизни которых истекает 1 ноября 2015 года и позднее.
  • Поле Subject Name в обозримой перспективе рискует исчезнуть совсем.

Говоря русским языком, скоро уже не получится запросить сертификат с именами из зон .local, .domain, .corp и тд. в поле SAN у внешних поставщиков сертификатов. Таким образом, если существует необходимость использования внутренних имён серверов во внешних сертификатах, придётся пересматривать архитектуру существующих систем.

Роль сервера DHCP является стандартной для многих корпоративных сетей, так как сильно упрощает процесс настройки клиентов. Это накладывает определённые требования по обеспечению доступности серверов DHCP в локальной сети предприятия. Обесепечние высокой доступности для серверов DHCP позволяет добиться следующих целей:

  • Любой авторизованный компьютер, который подключается к сети имеет возможность получить ip-адрес и дополнительные настройки сети от службы DHCP в любой момент времени
  • После получения ip-адреса, компьютер имеет возможность продлить аренду ip-адреса и продолжить использовать тот же ip-адрес

Windows Server 2012 предоставляет новый механизм обеспечения высокой доступности для роли DHCP. Два DHCP-сервера могут быть настроены для обеспечение высокой доступности сервиса DHCP через отказоустойчивость (failover relationship) (по аналогии с отказоустойчивым кластером). Отказоустойчивость имеет несколько параметров, влияющих на поведение серверов DHCP в случае сбоя: режим отказоустойчивой работы, области (scopes), защищённые отказоустойчивой связью. Последние полностью совпадают друг с другом в случае настройки отказоустойчивости. Если отказоустойчивость настроена, то DHCP серверы реплицируют информацию об арендованных ip-адресах и дополнитульную информацию о клиентах между собой, и, таким образом, всегда содержат актуальную информацию обо всех клиентах в сети. Если один из DHCP серверов становится по какой-то причине недоступен, то другие DHCP серверы будут содержать актуальную информацию о клиентах и смогут обслуживать их запросы. Continue Reading »

Scale-Out File Server (SOFS) – расширение роли обычного файлового сервера в Windows Server 2012. SOFS строится на базе отказоустойчивого кластера. В Windows Server 2012 отказоустойчивый кластер спроектирован для обеспечения непрерывной доступности (continuously available, CA) и поддержки масштабируемых хранилищ, используемых различными приложениями. SOFS использует протокол SMB 3.0, который предоставляет функции высокой доступности, производительности и отказоустойчивости.

Ключевые особенности:

  • Возможность динамического расширения ёмкости. SMB Scale-Out позволяет делать это с помощью настройки распределённого пространства имён (Distributed Namespace).
    • Низкая стоимость внедрения – SOFS может быть организован на базе двух узлов, и в дальнейшем расширен до четырёх. Так как используется отказоустойчивый кластер, то узлы могут добавляться и убираться из кластера без влияния на функциональность файлового сервера.
    • Масштабируемость, необходимая в данный момент времени – так как SOFS строится на базе модулей-узлов, то нет необходимости сразу закупать всё аппаратное обеспечение, начать можно с двух узлов. В дальнейшем, при увеличении нагрузки, можно закупить и подключить дополнительные ресурсы. Это позволяет уменьшить капитальные затраты на сервера и хранилища, снижает операционные расходы, упрощает администрирование и позволяет максимально задействовать используемое оборудование.
  • Высокий уровень использования аппаратного обеспечения. Все узлы кластера могут принимать и обслуживать клиентские SMB-запросы для всех общих папок SOFS. Это позволяет по-максимуму использовать доступную ширину канала между клиентом и сервером. Процесс обслуживания SMB-клиентов теперь ограничивается не производительностью узла кластера, а производительностью подсистемы хранения.
  • Постепенный процесс обновления технологии. При использовании кластеризованного файлового сервера в конфигурации “File Server for general use” им могут пользоваться старые клиенты. При этом предоставляется дополнительнная функциональность для новых клиентов Windows Server 2012.
  • Единая консоль управления. Позволяет управлять файловыми серверами, хранилищем и сетью с помощью новой консоли Server Manager.

SOFS представляет собой масштабируемое решение доступа к файловым ресурсам на базе протокола SMB, которое может использоваться предприятиями любых размеров. Continue Reading »

SMB Direct, он же SMB over RDMA, по сути описывает процесс передачи данных протокла SMB через высокоскоростные сетевые адаптеры, поддерживающие стандарт RDMA. RDMA (Remote Direct Memory Access) – стандарт передачи данных между приложениями. Приложения передают данные напрямую из памяти в обход процессора, что позволяет снижать на него нагрузку, и сильно увеличивает скорость передачи данных и производительность приложений.

На текущий момент существует три реализации этого стандарта:

  • InfiniBand
  • Internet Wide Area RDMA Protocol (iWARP)
  • RDMA over Converged Ethernet (RoCE)

Так как стандарт не предусматривает отказоустойчивости, то обычно SMB Direct рассматривают в связке с SMB Multichannel. Это позволяет строить хранилища на базе Windows Server 2012 по скоростям и производительности не уступающие сетям передачи данных (SAN).

Требования:

  • Как минимум два сервера с Windows Server 2012
  • Как минимум один поддерживающий RDMA сетевой адаптер на каждом сервере Continue Reading »

Windows Server 2012 поддерживает функцию SMB Multichannel, которая является частью протокла SMB 3.0 и позволяет сильно увеличить производительность и доступность файловых серверов.

SMB Multichannel позволяет файловым серверам использовать несколько сетевых подключений одновременно и предоставляет следующие возможности:

  • Увеличенная пропускная способность. Файловый сервер может при передаче данных использовать одновременно несколько сетевых подключений.
  • Отказоустойчивость к сбоям в сети. При использовании нескольких сетевых подключений клиент продолжает работать с файловым сервером, даже если несколько сетевых подключений перестанут работать.
  • Автоматическая настройка. SMB Multichannel автоматически обнаруживает существование нескольких доступных сетевых подключений и автоматически начинает их использовать по мере необходимости.

Требования. SMB Multichannel требует следующего:

  • Как минимум два компьютера с Windows Server 2012 или Windows 8

Нужна как минимум одна из следующих конфигураций:

  • Несколько сетевых адаптеров
  • Один или несколько сетевых адаптеров, подерживающих RSS (Receive Side Scaling)
  • Один или несколько сетевых адаптеров, объединённых в NIC Teaming
  • Один или несколько сетевых адаптеров, подерживающих RDMA (Remote Direct Memory Access) Continue Reading »

SMB Transparent Failover одна из ключевых функций протокола SMB 3.0. На файловых серверах на базе Windows Server 2012 можно хранить данные различных приложений (например, файлы виртуальных машин Hyper-V, базы данных сервера SQL). Указанные приложения предполагают, что их данные находятся в хранилище, которое надёжно и всегда доступно. В связи с этим они не обрабатывают ошибки ввода-вывода. В случае, если хранилище становится недоступным, данные могут быть повреждены, а дальнейшая их запись невозможна.

SMB Transparent Failover позволяет настраивать общедоступные папки при использовании отказоустойчивой кластеризации (Failover Clustering) таким образом, что они становятся высокодоступными. Это позволяет администраторам кластера проводить операции по поддержке узлов кластера без прерывания работы приложений, чьи данные хранятся на кластеризованном файловом сервере. В случае сбоя аппаратного обеспечения файловый сервер будет переключён на работающий узел без задержек, что так же позволит работать приложению, которое хранит свои данные на файловом сервере, не прерывать свою работу.

Требования:

  • Отказоустойчивый кластер на базе Windows Server 2012, состоящий как минимум из двух узлов. Мастер проверки конфигурации кластера должен отрабатывать на обоих узлах без ошибок.
  • Кластеризованный файловый сервер с одной или более общедоступными папками, работающими в режиме непрерывной доступности (continuously available).
  • Клиенты на базе Windows 8 или Windows Server 2012.

Чтобы использовать SMB Transparent Failover и клиент и сервер должны поддерживать SMB 3.0. На текущий момент эта поддержка реализована только для Windows 8 и Windows Server 2012. Клиенты использующие предыдущие версии SMB (1.0, 2.0, 2.1) использовать такие папки смогут, но не смогут использовать функцию SMB Transparent Failover. Continue Reading »