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

Удаленные филиалы и контроллер домена

У меня очень маленькая, но распределенная сеть. В центральном офисе есть виртуальная машина Windows Server 2008 R2 с несколькими виртуальными машинами Linux, работающими на одном компьютере. Есть два клиентских компьютера под управлением Windows7. В удаленном месте есть один клиентский компьютер, который в настоящее время подключается к центральному офису с помощью OpenVPN через один из серверов Linux.

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

На мой взгляд, мне нужно принять несколько решений, каждое из которых имеет несколько вариантов.

На каком сервере работает домен

  1. Windows Server 2008
    • Традиционное решение AD
    • Невозможно добавить резервный контроллер без другой лицензии
    • Сервер Windows также выполняет функции FTP и AS; Серверы AD обычно просто размещают AD.
  2. Один из ящиков Linux с Samba)
    • Не традиционное решение AD (отказываюсь ли я от каких-либо функций?)
    • Можно легко (читай: дешево) добавить резервный контроллер
    • При необходимости (не идеально) можно добавить DC в удаленном месте

Как аутентифицировать / авторизовать удаленные местоположения

  1. Добавить удаленный Linux DC в удаленном месте (кажется излишним для одного удаленного клиента)
  2. Как-то подключиться к VPN до входа в Windows (возможно ли это вообще?)
  3. Выставить мою AD в Интернет без VPN. (кажется ужасной идеей)

Есть ли какие-то варианты, которые мне не хватает? Это должно быть довольно распространенная ситуация для малого бизнеса, я не могу себе представить, что эти компании без ИТ покупают несколько серверов WinServer для установки традиционного решения автономного AD, автономного резервного AD, а затем еще одного модуля для размещения всего остального ....

Я парень, работающий с Linux, и у меня нет проблем с грязными руками, но у меня нет большого опыта в сфере ИТ.

Идеальным решением было бы настроить VPN-туннель типа "сеть-сеть" и обработать всю аутентификацию с помощью контроллеров домена на главном сайте. (Это, конечно, будет зависеть от вашего сетевого оборудования или любых серверов шлюзов, которые вы можете настроить на каждом сайте.)

Если вы разместите второй контроллер домена на удаленном узле, у вас будут те же проблемы с подключением двух узлов, чтобы контроллеры домена могли общаться друг с другом. И да, раскрывать AD в общедоступной сети - это самая худшая идея. И позвольте мне добавить, что использование Linux в качестве вторичного DC тоже кажется мне очень плохой идеей. Бьюсь об заклад, это можно сделать, но я бы не хотел быть рядом, когда Windows DC выходит из строя, и вам нужно попытаться восстановить свой единственный Windows DC. Может быть, «достаточно хорошо», но, как я уже сказал, я бы не стал ему доверять, а если я не могу ему доверять, зачем вообще его иметь?

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

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