Latest / M365.FM – подкаст о Microsoft 365, Copilot и ИИ на русском / Microsoft Entra Domain Services простыми словами: устаревшие приложения в Azure без своих контроллеров домена (ИИ-дубляж)

Transcript

Microsoft Entra Domain Services простыми словами: устаревшие приложения в Azure без своих контроллеров домена (ИИ-дубляж) · M365.FM – подкаст о Microsoft 365, Copilot и ИИ на русском

• 0:00
  Готовы к 10 дням погружения в Microsoft 365, Капайлот и Азур и знакомство с людьми,
• 0:05
  формирующими будущие работы? В этом январе конференция М365 возвращается,
• 0:10
  и мы ставим перед собой еще более масштабные цели. Присоединяйтесь к нам для участия в живых
• 0:14
  сессиях, просмотра реальных демонстраций и получения практических знаний от MVP и
• 0:17
  отраслевых экспертов со всего мира. Никаких общих слайдов, никаких бесконечных модных словечек.
• 0:22
  Мы решаем реальные задачи, Капайлот Студия, и агенты, фабрик, безопасность, управление и
• 0:28
  автоматизация. Независимо от того, являетесь ли вы это специалистом, разработчиком или бизнес-лидером,
• 0:33
  у нас есть сессии, созданные специально для вас. За 10 полных дней вы сможете изучить множество
• 0:37
  технологий и наладить связи с глобальным сообществом. Смотрите в прямом эфире и используйте
• 0:42
  полученные практические идеи в своей организации. Январь 2027 года. 10 дней. Единое сообщество
• 0:48
  Microsoft. Регистрация уже открыта. Переходите на m365con.net и забронируйте свое место уже сегодня.
• 0:56
  Это m365con.net. Присоединяйтесь сейчас на m365con.net и увидимся в прямом эфире в январе.
• 1:05
  Всем привет! Добро пожаловать на очередной выпуск Microsoft Knowledge на где-то здесь, на
• 1:08
  m365fm. Меня зовут Мирку Питерс. Представьте, что вы переносите старое бизнес-приложение
• 1:14
  с офисного сервера на виртуальную машину Азу. Приложение теперь в облаке, но оно все еще требует
• 1:18
  домен Windows. Ему нужно присоединиться к домену, искать пользователей через LDAP, входить в систему
• 1:22
  через Kerberos и применять групповые политики. Большинство людей полагают, что IntraID заменяет
• 1:27
  все функции Active Directory. Это не так. Современные облачные приложения позволяют войти через
• 1:31
  IntraID, но старые Windows-приложения по-прежнему ожидают тот же тип домена, что был в серверной.
• 1:36
  К концу этого выпуска вы поймете, где именно применяются IntraID, Active Directory и Intra Domain Services,
• 1:41
  и узнаете одну деталь, которая меняет подход к управлению всем этим. Информация об учетных
• 1:45
  записях передается только в одном направлении. Почему IntraID в одиночку не может запустить
• 1:49
  каждое устаревшее приложение? Начнем с того, с чем IntraID справляется отлично. Это стойка
• 1:53
  регистрации для ваших облачных сервисов. Она знает, кто вы, проверяет ваш вход и решает,
• 1:57
  можете ли вы войти в Microsoft 365 Teams, SharePoint или бизнес-приложение в облаке. Вы входите один раз,
• 2:03
  а затем перемещаетесь между сервисами, не вводя пароль снова и снова. Это единый вход в систему SSO.
• 2:08
  IntraID также может запросить повторную проверку через многофакторную аутентификацию,
• 2:12
  проверить устройство, которое вы используете, местоположение входа и правила доступа,
• 2:16
  установленные вашей компанией. Для современного приложения эта модель работает очень хорошо.
• 2:20
  Вы открываете браузер, приложение перенаправляет вас в IntraID, вы входите, подтверждаете запрос на
• 2:24
  телефоне, а затем IntraID отправляет приложению безопасное сообщение о входе в фоновом режиме.
• 2:28
  Приложение считывает это сообщение и предоставляет вам доступ. При таком подходе не требуется
• 2:32
  присоединение к домену, использование старых серверов Windows или поиск приложением данных в
• 2:36
  классическом корпоративном каталоге. Но старые приложения создавались в другом мире. Представьте
• 2:40
  финансовое приложение, которое годами работало на Windows Server, где пользователи входят в систему с компьютеров,
• 2:44
  присоединенных к домену. Приложение ищет данные сотрудников через LDAP, распространенный для
• 2:48
  старого по способ поиска в корпоративном каталоге. Оно может использовать Kerberos, старый метод входа
• 2:53
  в Windows, позволяющий системам доверять друг другу. Оно может полагаться на групповые политики,
• 2:57
  набор корпоративных правил, управляющих настройками компьютеров с Windows. Такое приложение не умеет
• 3:01
  распознавать современные облачные сообщения для входа. Оно ожидает обращения по сети и обнаружения
• 3:05
  традиционного домена Windows. И если его не находят, приложение может не войти в систему, не найти сервисную
• 3:10
  учетную запись или просто отказаться запускаться. Вы наверняка встречали подобную ситуацию и вне
• 3:14
  сферы ИТ. Новая розетка бесполезна, если вилка от старого прибора к ней не подходит. Электричество
• 3:19
  есть, но соединения нет. Теперь представьте, что компания переносит это финансовое приложение и его базу
• 3:23
  данных на виртуальные машины Azure. Серверы переместились, а старые потребности остались. Можно оставить
• 3:28
  актив в директории в офисе и подключить к ней Azure через VPN, защищенный сетевой туннель. Тогда приложение
• 3:33
  в Azure будет отправлять запросы через это соединение всякий раз, когда ему нужен домен. Это может работать,
• 3:38
  но приложение теперь зависит от сетевого канала и доступности локального контроллера домена. И если
• 3:42
  соединением возникнут проблемы, у облачного приложения они тоже появятся. Другой вариант — создать
• 3:47
  собственные виртуальные машины с контроллерами домена в Azure. Контроллер — это сервер, работающий
• 3:51
  с традиционным доменом Active Directory, который управляет каталогом, входами и другими задачами
• 3:55
  домена. Это тоже работает, но теперь вашей команде приходится обслуживать больше серверов. Кто-то должен
• 3:59
  устанавливать на них обновления и следить за их работой. Нужны резервные копии, планы восстановления,
• 4:03
  план синхронизации контролеров, а также защита мощных учетных записей администраторов, управляющих доменом.
• 4:07
  Некоторым компаниям такой уровень контроля необходим, а для других это лишняя работа ради того,
• 4:11
  чтобы старое приложение продолжало функционировать. Итак, разрыв невелик, но он реален. Приложение
• 4:15
  живет в Azure, но все еще говорит на старом языке Active Directory. Что же такое Microsoft Intradomain
• 4:21
  Services? Это управляемый домен Windows, который работает внутри вашей сети Azure. Вот такое простое
• 4:27
  определение. Контроллеры домена работают в фоновом режиме под полным управлением Microsoft, в то время
• 4:32
  как ваши виртуальные машины Azure и устаревшие приложения используют привычные доменные службы.
• 4:36
  Представьте свою облачную среду как офисное здание. IntraID — это стойка регистрации на входе.
• 4:41
  Она проверяет, кто вы, когда входите в Microsoft 365 или другое облачное приложение,
• 4:44
  и применяет правила компании к этому входу. Intradomain Services находится в запертом кабинете
• 4:48
  в глубине офиса. Устаревшим системам не нужно обращаться к стойке регистрации так,
• 4:51
  как это делают современные облачные приложения. Им нужен привычный каталог поблизости,
• 4:55
  который понимает их язык и может отвечать на их запросы. Этот кабинет в глубине офиса и есть
• 4:59
  управляемый домен. Суть в том, что вам не нужно создавать контроллеры домена самостоятельно. Вы не
• 5:03
  подключаетесь к ним через удаленный рабочий стол. Вы не решаете, сколько их запускать,
• 5:06
  не обновляете Windows на них и не управляете связью между ними. Microsoft берет все это на себя.
• 5:10
  Ваша задача — подключить нужные виртуальные машины Azure и приложения к управляемому домену.
• 5:14
  После подключения они смогут использовать привычные службы Active Directory. Виртуальная машина
• 5:18
  Windows может присоединиться к домену, а старое приложение может использовать LDAP для поиска
• 5:22
  пользователей, групп и данных каталога. Оно может использовать Kerberos — метод входа,
• 5:25
  который часто требует старые бизнес-приложения, когда одному серверу нужно доверять другому.
• 5:28
  Оно также может использовать NTLM, еще один устаревший метод входа в Windows, который до сих пор
• 5:32
  нужен некоторым приложениям. Управляемый домен также предоставляет DNS, что помогает системам
• 5:37
  находить нужный сервер по имени, а не по набору цифр. Он также поддерживает групповые политики,
• 5:40
  поэтому вы можете применять определенные настройки Windows к компьютерам и пользователям в этом
• 5:44
  управляемом домене. Я знаю, этот список звучит технически сложно. Представьте это как бюро переводов.
• 5:48
  Ваше приложение спрашивает на старом языке Windows, кто этот пользователь. Может ли этот сервер доверять
• 5:53
  тому серверу? Где находится база данных? Какие настройки должен использовать этот компьютер?
• 5:58
  Intra Domain Services понимает эти вопросы и дает ответ, который ожидает приложение,
• 6:02
  но не создает второй основной список сотрудников. Основная запись об идентификации остается в
• 6:06
  IntraID. Пользователи и группы из IntraID копируются в управляемый домен, чтобы устаревшее
• 6:10
  приложение могло видеть и использовать их в понятном ему виде. Если у вашей компании также есть
• 6:14
  локальный актив-директорий, идентификационные данные могут сначала попадать оттуда в IntraID,
• 6:17
  а затем копироваться в Domain Services. Здесь важно направление. Данные об идентификации поступают
• 6:22
  в IntraDomain Services. Они не передаются обратно. Поэтому, если пользователь из IntraID,
• 6:26
  вы управляете им в IntraID. Если пользователь изначально из вашей локальной актив-директории,
• 6:31
  вы управляете им там. Не стоит рассматривать Domain Services как место для редактирования
• 6:35
  основной карточки сотрудника. Это не дает управляемому домену превратиться в дублирующий
• 6:39
  архив с разными версиями данных об одном и том же человеке. Теперь о моменте, на котором многие
• 6:43
  спотыкаются при настройке пароли. Современный облачный вход в систему и старый вход в Windows
• 6:47
  используют пароли немного по-разному на внутреннем уровне. Для работы Kerberos и NTLM-службе
• 6:52
  Domain Services нужны защищенные данные паролей, поддерживающие эти старые методы.
• 6:55
  Microsoft никогда не хранит ваш пароль в открытом виде. Вместо этого службе требуется
• 6:59
  правильная защищенная информация о пароле, чтобы пользователь мог войти на виртуальную машину
• 7:03
  в домене или в старое приложение через управляемый домен. Для пользователей, работающих только в
• 7:07
  облаке, это часто означает, что им нужно сменить пароль после активации Domain Services.
• 7:12
  Это изменение пароля создает защищенный формат, необходимый для управляемого домена.
• 7:16
  До этого момента пользователь может отлично входить в Microsoft 365, но при попытке использовать
• 7:20
  домен старого образца его будет ждать ошибка. Сначала это может показаться странным.
• 7:24
  У пользователя уже есть учетная запись и работающий пароль, но старое приложение все равно
• 7:28
  его не принимает. Недостающее звено – неучетная запись пользователя. Это защищенный формат
• 7:32
  пароля, требуемый этими старыми методами входа. У Domain Services также есть четкие границы работы.
• 7:37
  Служба запускается внутри виртуальной сети Azure, которую часто называют VNet. Вашим виртуальным
• 7:41
  машинам Azure нужен сетевой доступ к этой сети, и они должны использовать DNS-настройки
• 7:45
  управляемого домена, чтобы найти его. Это не публичный каталог, к которому может обратиться
• 7:49
  любое устройство из интернета. Это частная доменная служба для рабочих нагрузок, подключенных
• 7:53
  к нужной сети Azure. Поэтому, когда приложению в Azure требуются возможности старой
• 7:57
  Active Directory, Domain Services предоставляет управляемую среду для доступа к ним. Это подводит
• 8:01
  нас к следующему вопросу. Какое место это занимает рядом с IntraID и вашим существующим
• 8:05
  доменом Active Directory? Названия звучат похоже, но их задачи сильно различаются.
• 8:09
  IntraID, Active Directory и Domain Services. Разные задачи. Их названия близки, поэтому легко принять
• 8:15
  их за разные версии одного и того же продукта. Это не так. Каждый из них отвечает за свою часть
• 8:20
  системы идентификации компании, и когда вы поймете назначение каждого, выбор станет гораздо
• 8:23
  очевиднее. IntraID отвечает за облачную идентификацию. Когда вы открываете Microsoft 365, Teams,
• 8:29
  SharePoint или современное бизнес-приложение, IntraID проверяет ваш вход и управляет доступом.
• 8:33
  Он также поддерживает многофакторную аутентификацию и правила доступа, например,
• 8:37
  запрашивая более строгую проверку при работе с неизвестного устройства. Он создан для облачных
• 8:41
  служб. Современному приложению не обязательно находиться в той же сети, что и IntraID,
• 8:45
  поскольку оно использует веб-методы входа в систему. Вы входите через браузер или приложение,
• 8:49
  IntraID подтверждает вашу личность, и приложение получает подтверждение того, что вам разрешен доступ.
• 8:53
  Это стандартная схема для новых облачных приложений. Актив-директорий Domain Services,
• 8:57
  часто сокращенно называемый актив-директорий, выполняет другую задачу. Это традиционный
• 9:00
  домен Windows, который многие компании используют в своих офисах, центрах обработки данных или
• 9:05
  серверных. Компания владеет контроллерами домена, выбирает способы их настройки и полностью
• 9:09
  управляет всем доменом. Он может контролировать ПК с Windows, поддерживать локальные серверы и
• 9:13
  предоставлять старые методы входа, которые требуются для давно используемых бизнес-приложений.
• 9:16
  Такой уровень контроля сопряжен с ответственностью. Ваша IT-команда управляет доменом,
• 9:21
  обслуживает серверы и решает, как каталог должен работать для компании.
• 9:24
  Intra Domain Services находится между этими двумя мирами. Он предоставляет рабочим нагрузкам
• 9:28
  Azure управляемый домен Windows, когда им требуется поддержка старых функций Актив-директорий,
• 9:32
  но администрирование контролеров домена берет на себя Microsoft. Вы используете домен для
• 9:35
  виртуальных машин Azure и старых приложений, не беря на себя всю работу по самостоятельному
• 9:38
  обслуживанию традиционного домена Актив-директорий. Представьте это как систему картотеки.
• 9:42
  Intra ID содержит основную запись сотрудника для облачной работы. Там компания хранит рабочие записи,
• 9:47
  используемые для Microsoft 365 и современных облачных входов в систему. Domain Services предоставляет
• 9:52
  старым приложением Azure совместимую копию необходимых им записей. Эти приложения могут открывать
• 9:56
  привычный тип картотеки и находить пользователей, группы и данные для входа в старом формате,
• 10:00
  который они понимают. Вам не нужно переделывать приложение только из-за того, что оно было перенесено в Azure.
• 10:04
  Компания, работающая только в облаке, также может использовать эту настройку.
• 10:07
  Представьте компанию, которая никогда не использовала локальные контроллеры домена. Все входят в
• 10:11
  Microsoft 365 через Intra ID, и бизнес начинает использовать виртуальные машины Azure для старого
• 10:15
  приложения Windows. Этой компании не нужно создавать локальный домен Актив-директорий только ради
• 10:19
  одного этого приложения. Вместо этого она может использовать Intra Domain Services для виртуальных
• 10:23
  машин Azure, которым требуется поведение домена, в то время как остальные сотрудники продолжают
• 10:26
  использовать Intra ID для обычной облачной работы. У гибридной компании отправная точка другая. Возможно,
• 10:31
  она уже использует Актив-директорий в своем офисе с пользователями и группами, которые синхронизируются с
• 10:35
  Intra ID. Эти пользователи затем могут появиться в Intra Domain Services для рабочих нагрузок,
• 10:38
  запущенных в Azure. Поток данных выглядит так. Существующий Актив-директорий компании отправляет
• 10:43
  данные об идентификаторах в Intra ID, а Intra ID предоставляет совместимую копию в Domain Services.
• 10:48
  Это не означает, что Domain Services заменяет исходный локальный домен. Офису все еще может требоваться
• 10:53
  собственный домен Актив-директорий для локальных ПК, серверов, заводских систем или приложений,
• 10:58
  работающих на месте. Domain Services обрабатывает только ту часть Azure, где управляемое поведение
• 11:02
  домена старого типа подходит для рабочей нагрузки. И это также не превращает Intra ID в полноценный
• 11:06
  Актив-директорий. Intra ID остается облачной службой идентификации. Domain Services добавляет
• 11:11
  управляемый домен для некоторых устаревших потребностей, но не предоставляет всех возможностей
• 11:15
  и уровней контроля, которые есть при самостоятельном запуске Актив-директорий. Итак, представьте
• 11:19
  себе три отдельные задачи. Intra ID отвечает за современный вход в облако. Актив-директорий отвечает за
• 11:24
  домен Windows, который ваша компания поддерживает самостоятельно. Intra Domain Services отвечает за устаревшие
• 11:29
  рабочие нагрузки Azure, которым все еще нужен домен Windows, не требуя от вас
• 11:32
  управления контроллерами домена. Можно задать гораздо более правильный вопрос. Когда Domain Services
• 11:37
  подходит для рабочей нагрузки, а когда стоит выбрать что-то другое? Когда Domain Services
• 11:41
  подходит, а когда нет? Начните с приложения, а не с названия продукта. Если старое приложение
• 11:46
  использует LDAP, это старый протокол для проверки имен пользователей и паролей, и вы переносите его в
• 11:50
  Azure, Domain Services может отлично подойти. Приложение продолжает использовать то, что оно уже понимает,
• 11:54
  без необходимости полной переработки. Это важно, когда приложение работает, оно нужно бизнесу,
• 11:58
  а переписывание кода авторизации потребовало бы слишком много времени или денег. Другой распространенный
• 12:02
  сценарий. Группе виртуальных машин Azure нужно вести себя как обычным доменным компьютером.
• 12:06
  Сотрудникам может потребоваться вход в Windows с использованием их рабочей учетной записи.
• 12:09
  Службе может потребоваться сервисная учетная запись, учетная запись, которую приложение использует
• 12:13
  для подключения к другой системе, например, в базе данных. Вам могут понадобиться групповые политики
• 12:16
  для применения настроек компании к этим виртуальным машинам. В этих случаях Domain Services обеспечивает
• 12:20
  виртуальным машинам Azure ожидаемое имя поведения домена. Служба удаленных рабочих столов тоже
• 12:24
  подходит сюда. Представьте, что сотрудники подключаются к общим рабочим столам Windows или
• 12:28
  приложениям Azure. Такие системы часто зависят от домена Windows для входа пользователей и управления
• 12:33
  компьютерами. Domain Services предоставляет этот доменный уровень, избавляя вашу команду от
• 12:37
  создания виртуальных машин-контролеров домена с нуля. Старые приложения часто состоят из
• 12:40
  нескольких частей. Может быть веб-сервер в начале, сервер приложений в середине и база данных в конце.
• 12:45
  Сервер приложений должен подтвердить свою личность, прежде чем база данных примет соединение.
• 12:49
  Когда это доверие опирается на сервисные учетные записи Windows, Domain Services сохраняет
• 12:53
  работоспособность этих подключений после переноса. Суть в том, что ваша команда получает устаревшее
• 12:57
  поведение домена, необходимое для рабочей нагрузки, в то время как Microsoft берет на себя работу
• 13:02
  по обслуживанию контролеров домена. Но не выбирайте Domain Services только потому, что вы используете
• 13:07
  Azure. Новое облачное приложение должно выполнять вход напрямую через IntraID. Если оно поддерживает
• 13:11
  современные методы входа, оно направляет пользователей в IntraID, получает подтверждение входа и
• 13:15
  использует преимущество облачных правил доступа и многофакторной аутентификации. Это более чистый
• 13:19
  путь для нового программного обеспечения. Доменные службы помогают приложению, которое,
• 13:23
  говорит, на старом языке. Это не повод обучать новые приложения этому старому языку. Также
• 13:26
  существуют жесткие ограничения, которые необходимо проверить в первую очередь. Некоторые приложения
• 13:30
  не просто читают данные из Active Directory, они записывают их обратно. Например, приложению может
• 13:34
  потребоваться создавать или изменять записи в каталоге в ходе своей обычной работы. Доменные службы
• 13:38
  не подходят, если приложению требуется доступ для записи по протоколу LDAP. То же предупреждение
• 13:43
  касается случаев, когда приложению нужно изменить схему Active Directory, набор полей, определяющих,
• 13:47
  что именно может хранить каталог. Некоторое старое программное обеспечение требует
• 13:50
  добавить собственные поля перед запуском. Управляемый домен не позволяет изменять эту базовую
• 13:54
  структуру. Вам также стоит остановиться и подумать, если вашей команде нужен полный контроль над
• 13:57
  самим доменом. Возможно, вам нужен прямой доступ к контроллерам домена. Возможно, вам нужны права
• 14:02
  администратора домена, которые дают очень широкие полномочия. Или, может быть, вам нужна сложная
• 14:05
  структура каталога, которую вы хотите создать и поддерживать самостоятельно. Это указывает на
• 14:09
  необходимость самостоятельного запуска Active Directory либо локально, либо на виртуальных машинах в АЗУ.
• 14:14
  Доменные службы намеренно предоставляют меньше контроля, поскольку базовую доменную службу обслуживает
• 14:18
  Microsoft. Поэтому задайте один простой вопрос, прежде чем выбрать путь. Нужен ли этой рабочей
• 14:22
  нагрузке старый язык Active Directory или она может работать с современным IntraID? Если она может
• 14:26
  использовать современный IntraID, начните с него. Если ей нужно старое поведение домена, но вам не
• 14:30
  требуется полный контроль над всеми его частями, доменные службы могут подойти очень хорошо. А если
• 14:34
  приложению нужно перезаписывать каталог, изменять его схему или предоставлять вашей команде полный
• 14:38
  контроль, ему нужно другое решение. Выбор управляемого домена означает принятие компромисса.
• 14:43
  Microsoft берет на себя обслуживание контролеров домена, а вы отказываетесь от части контроля, который был бы
• 14:47
  при их самостоятельной эксплуатации. Компромиссы управляемых служб, о которых вам нужно знать.
• 14:50
  Этот управляемый подход экономит усилия, но также меняет то, что может контролировать ваша IT-команда.
• 14:55
  Microsoft управляет контролерами домена, поддерживает их синхронизацию, применяет исправление и
• 14:59
  обеспечивает доступность в фоновом режиме. Вам не нужно планировать размещение каждого контролера
• 15:03
  домена или восстанавливать их после сбоя сервера. Вот почему многие команды выбирают этот вариант,
• 15:07
  но вы не можете подключиться к этим контролерам по удаленному рабочему столу, и у вас нет прав администратора
• 15:11
  домена или предприятия, так как они дали бы контроль над частями, которыми управляет Microsoft.
• 15:15
  Вместо этого Microsoft предоставляет группу под названием «Администраторы интро-домейн-сервисес».
• 15:19
  Добавьте людей, которым нужно управлять доменом, в эту группу, а затем используйте виртуальную
• 15:23
  машину управления, присоединенную к управляемому домену. С этой машины можно использовать
• 15:26
  привычные инструменты Active Directory для управления тем, что разрешает Microsoft.
• 15:29
  Например, вы можете создавать собственные организационные подразделения или OU. Представьте
• 15:33
  их как папки для объектов домена, таких как компьютеры или сервисные учетные записи.
• 15:37
  Вы можете управлять записями DNS, создавать и применять групповые политики для поддерживаемых параметров.
• 15:41
  Вы также можете управлять компьютерами, присоединенными к домену, что часто является основной причиной
• 15:44
  использования этой службы. Эти ограничения установлены намеренно. Вы не можете добавлять
• 15:48
  новые контроллеры домена, изменять схему Active Directory или рассматривать управляемый
• 15:51
  домен как место, откуда изменения передаются обратно в IntraID. Поэтому управляйте пользователями
• 15:55
  и группами в исходном каталоге. Для компании, работающей только в облаке, таким источником
• 15:59
  является IntraID. Для гибридной компании это локальный Active Directory, который синхронизируется
• 16:04
  с IntraID. Это правило предотвращает ошибку, которую мы часто наблюдаем. Кто-то видит пользователя
• 16:08
  в управляемом домене и вносит изменения, полагая, что они сохранятся. Но это изменение не станет
• 16:13
  корпоративной записью в IntraID или локальном Active Directory. Держите управляемый домен
• 16:17
  закрытым внутри сети Azure. Он должен поддерживать только те рабочие нагрузки, которым он необходим,
• 16:22
  а не становиться общим каталогом компании. Ограничьте сетевой доступ, защитите машину управления
• 16:26
  и предоставьте права администратора только тем, кому они нужны. Вы выбираете службу с защитными
• 16:30
  механизмами. Эти механизмы снимают часть нагрузки, не позволяя вам изменять компоненты,
• 16:34
  принадлежащие Microsoft. Простая история миграции в Azure. Представьте финансовую
• 16:39
  компанию, использующую старое приложение на серверах в собственном офисе. Это приложение
• 16:42
  полагается на LDAP для поиска сотрудников. Оно использует Kerberos при входе пользователей
• 16:46
  в систему, а его сервер проходит проверку подлинности с помощью сервисной учетной записи для
• 16:49
  доступа к финансовой базе данных. Компания хочет перенести и приложение, и базу данных на
• 16:53
  виртуальные машины Azure. Один из вариантов — сохранить подключение приложения к офисному
• 16:57
  домену через VPN, но тогда приложение в Azure будет ежедневно зависеть от сетевого
• 17:00
  подключения и локальных контролеров домена. Другой вариант — запустить новые виртуальные
• 17:04
  машины контролеров домена в Azure. Это позволяет сохранить больше трафика внутри Azure,
• 17:07
  но добавляет серверы Windows, которые этой команде придется обновлять, отслеживать,
• 17:11
  архивировать и восстанавливать. Команда выбирает другой путь. Их пользователи и группа уже
• 17:14
  синхронизированы с IntraID. Они включают службы домена Intra, подключают виртуальную сеть Azure.