Назад | Перейти на главную страницу

Начало работы с Active Directory и облачными сервисами

Я «айтишник» в быстрорастущей компании, которая скоро достигнет 100 сотрудников. Моя основная работа - это внутренняя разработка наших веб-сайтов и сервисов; Я также занимаюсь настройкой и обслуживанием ПК для наших пользователей.

В настоящее время я просто создаю локальные учетные записи на машинах, устанавливаю их настройки внешнего вида и предварительно устанавливаю несколько приложений для пользователей, но управление этим выходит из-под контроля. И я едва успеваю за расширением, не говоря уже о фоновом «оттоке» найма и увольнений.

«Простое» решение - установить Windows Server и начать использовать Active Directory для управления учетными записями. Проблема в том, что наши сотрудники разбросаны по 12 местам. Сейчас я использую logmein для удаленного администрирования машин.

Я хотел бы перейти к некоторому типу входа в систему на основе домена, аналогичному традиционной настройке активного каталога, где я создаю и настраиваю учетные записи пользователей Windows в центральном месте, а затем конечные пользователи просто входят в систему на любой машине с DOMAIN / именем пользователя.

Я играл с Windows InTune, и она отлично подходит для управления машинами и развертывания политик, но на самом деле это не то, что мне нужно.

Я изучал Azure Identity, но это означает, что мне все еще нужен локальный контроллер AD для каждого местоположения. В идеале я бы хотел, чтобы эти сервисы существовали «в облаке». Я не знаю, комфортно ли мне иметь сервер на месте в каждом месте, поскольку эти места находятся в сельской местности, и я бы не хотел отправлять специализированное дорогостоящее оборудование на установку местному подрядчику.

Служба Active Directory / sso like, размещенная в облаке, кажется несложной задачей, и после чтения о таких продуктах, как InTune, Azure Identity и Office365, кажется, что это можно сделать ... Кто-нибудь сумел успешно развернуть подобную систему или знать пример / вскрытие того, кто это сделал?

Если бы это была моя среда, я бы подумал о следующем:

  • Приобретите недорогие устройства, которые могут выполнять завершение VPN в удаленных офисах, - устройства Ubiquiti EdgeRouter Lite или небольшую коробку, на которой можно запускать OpenWRT Linux.

  • Завершите работу VPN со всех удаленных сайтов в моем центральном местоположении.

  • Установите два экземпляра Windows Server, желательно работающих на отдельном физическом оборудовании и предпочтительно расположенных в разных физических местах, для обеспечения избыточности. Если можете, разместите один в центре, а другой - в наиболее укомплектованном удаленном месте, под замком.

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

  • Создайте лес и домен Active Directory на одном из экземпляров Windows Server, попутно установив DNS.

  • Повысить другой экземпляр Windows Server до контроллера домена (DC) во вновь созданном домене, используя первый DC в качестве DNS-сервера во время повышения. Установите роль DNS на втором контроллере домена и настройте оба контроллера домена на использование себя в качестве основного DNS-сервера, а другой контроллер домена в качестве дополнительного DNS-сервера.

  • Настройте второй контроллер домена как сервер глобального каталога.

  • Настройте ПК в удаленных офисах на использование обоих контроллеров домена в качестве DNS-серверов.

  • Если вас беспокоит потеря DNS в случае сбоя VPN, настройте оконечное устройство VPN в каждом офисе в качестве DNS-сервера. Настройте этот DNS-сервер для условной пересылки запросов для вашего домена Active Directory на DNS-серверы, размещенные на контроллерах домена, при отправке всех остальных DNS-запросов непосредственно в Интернет. Настройте всех клиентов в удаленном офисе на использование оконечного устройства VPN в качестве DNS-сервера. В случае сбоя VPN клиентские компьютеры на удаленном компьютере все равно будут иметь DNS. (В этой конфигурации у вас могут возникнуть проблемы с динамическими обновлениями DNS от клиентов.

Предполагая, что интернет-соединения в удаленных офисах не ужасны, вы должны увидеть разумное время входа в систему, когда начнете присоединять ПК в удаленных офисах к домену. Не сходите с ума от групповой политики, иначе вы начнете замедлять работу. Такие приятные вещи, как перемещаемые профили пользователей и перенаправление папок, вероятно, недопустимы в такой конфигурации. Возможно, вам придется изменить пороги обнаружения медленных ссылок групповой политики, чтобы даже обеспечить правильное применение групповой политики (в зависимости от того, насколько грубыми являются интернет-соединения удаленного сайта).

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