Миграция домена с windows на linux

«Механик заводит машину. Хирург открывает капот и говорит механику: «Вот видишь, двигатель работает, поменяй!»

Введение

Задача миграции с одной операционной системы на другую, на первый взгляд, кажется понятной. Удаляем Windows, устанавливаем понравившийся отечественный дистрибутив на базе Linux, ставим офисный пакет, почтовый клиент, выбираем браузер и антивирус (кому нужно), настраиваем средство электронной подписи (ЭП), подключаем принтеры – всё, задача решена. Отчитываемся об успешном импортозамещении, получаем благодарность от руководства и уважение коллег.

Именно такой подход мы видели все прошлые годы. Это сугубо лоскутное замещение, которого абсолютно недостаточно, чтобы говорить о технологической независимости, устойчивости и достижении итоговой цели – кибербезопасности. Как можно рассуждать о независимости, если у нас около 90% информационных систем (ИС) построены на базе Windows Server Active Directorу (AD) и глубоко интегрированного с ними центра сертификации Microsoft Certificate Services? Кто может быть уверен в том, что эти сервисы просто не остановятся по внешним командам? Многие отвечают, что «выключим обновления, спрячем за firewall». Нет, это не работает, уже есть прецеденты с отключением оплаченных западных продуктов. А ведь на серверной стороне сосредоточены все информационные активы организации – от списка объектов самой ИС (учетных данных пользователей, компьютеров, серверов, сервисов) до критических для функционирования данных, сосредоточенных в СУБД бизнес-приложений.

Как и с любым переездом, когда часть вещей признаются ненужными и утилизируются, а новые организуются так, как давно хотелось, имеет смысл провести аудит текущей системы и средств аутентификации в ИС. В разделе 1 мы подробнее расскажем о способах аутентификации, используемых протоколах, а также о том, какие способы стоит использовать для разных групп пользователей и устройств.

Раздел 2 посвящен выбору средств аутентификации, отвечающих задачам по импортозамещению и применимых в государственных информационных системах и объектах критической информационной инфраструктуры.

Последний раздел (3) посвящен уже обзору самой задачи и методов ее реализации.

Раздел 1. Обзор способов аутентификации

Если говорить о домене безопасности как о цельной структуре с единой политикой безопасности, то стоит упомянуть про стандарт де-факто для организации пространства доверия и применения встроенных механизмов и протоколов, единых для всех компонентов домена безопасности, — это, конечно же, протокол аутентификации Kerberos и реализация технологии единого входа (Single Sign-On, SSO). SSO – это метод аутентификации, который позволяет пользователям, приложениям и сервисам безопасно аутентифицировать друг друга при взаимодействии внутри домена безопасности. Он применим в различных вариантах, например «один к одному» или «один ко многим», то есть в нескольких приложениях и сайтах сразу, используя один набор учетных данных. Также немаловажно понимание технологий аутентификации, применяемых в связке с Kerberos.

Самой популярной и широко распространенной технологией является связка логин/пароль, но она одновременно и самая небезопасная. Для примера посмотрите, сколько времени займет выяснение пароля пользователя длиной 8 символов с учетом того, что будут применяться цифры, буквы в различных регистрах и спецсимволы. В качестве суперкомпьютера хакера будет применяться обычный системный блок, но с топовой видеокартой, которую сейчас используют все уважающие себя майнеры.

Итак, всего 7 минут. А ведь именно такие требования стандартно применяются администраторами для парольной политики в домене. При этом смена пароля обычно регламентируется раз в 42 дня. Кто-то еще добавляет спецсимволы. Всё это существенно увеличивает время аутентификации вплоть до 39 минут. Однако при смене пароля раз в ~40 дней это роли не играет, но сильно раздражает пользователей – им приходится помнить сложные пароли.

Вы возразите, что у вас в организации используются сильные хэши и достать их так просто не получится, плюс блокировка при вводе неверного пароля и т. д. Но задумайтесь вот над чем: чтобы пользователю запомнить пароль с большой энтропией от доменного ПК, он обычно или его куда-то записывает, или использует, чтобы не забыть, еще и при заказах в интернет-магазинах. Какая там защита? Верно, никто не знает, и обычно она там почти отсутствует.
https://haveibeenpwned.com/ – полезный сервис, который позволяет посмотреть, не хакнули ли еще ваши логин/пароль и нет ли их в базах даркнета. Если ваш пароль уже утек, то табличка будет выглядеть вот так:

Как правило, пользователям предоставляется возможность сменить пароль самостоятельно, и тут есть лайфхак – надо запомнить всего три сложных пароля на всю жизнь. Почему три? При смене ввести предыдущий пароль обычно не разрешается, а вот ввести применяемый на один ранее – запросто.

В
публикации приведены данные о времени взлома паролей пользователей. Подчеркнем, что приведенные показатели достигнуты на домашнем и доступном оборудовании, в статье есть расчеты при использовании недорогих облачных сервисов, а также сравнение данных с учетом развития технологий. Даже за два года развития рынка видеокарт сокращение времени взлома пугает. А что будет дальше?

Мы в «Аладдин Р.Д.» уже давно говорим, что самое удобное и реально работающее решение этой проблемы –– использование многофакторной аутентификации: она сейчас стоит недорого, внедряется за несколько часов и полностью снимает эту проблему. Для реализации многофакторной аутентификации есть только две базовые технологии (остальные являются производными от них) – это использование одноразовых паролей или цифровых сертификатов с закрытыми ключами. И там и там используются криптографические протоколы и криптографические ключи, распределенные между участниками взаимодействия. В каждом подходе есть как плюсы, так и минусы, но самое важное, на что стоит обратить внимание, – это схемы применения, уровень получаемой безопасности, удобство эксплуатации, стоимость и сложность внедрения.

Одноразовые пароли (One Time Password, OTP) – это технология, позволяющая обеспечить защиту доступа по периметру сети и домена безопасности, ее удобно использовать на мобильных устройствах, как правило, нет проблем с логистикой. ОТР обычно применяются совместно со связкой логин/пароль, но срок действия ОТР – только один-единственный раз, поэтому взламывать значение ОТР бессмысленно. У ОТР есть несколько минусов. Во-первых, это более низкий уровень безопасности, требующий как повышенной защиты первого шага при инициализации генератора ОТР, так и защиты секрета на серверной стороне. Во-вторых, это по большей части периметровая защита на границе сети. Например, доступ к порталам из внешней сети или же аутентификация в VPN-сессиях, как правило, работает через протокол RADIUS. Это очень популярная технология для B2B- или В2С-сервисов, а также для организации доступа пользователей к опубликованным в Интернете корпоративным сервисам.

Если говорить про цифровые сертификаты, то эта технология на текущий момент обеспечивает максимальный уровень безопасности при доступе к различным информационным системам, а также позволяет закрыть как периметровые, так и внутренние задачи аутентификации с реализацией SSO. То есть она поддерживается как при аутентификации вне сети в различных веб-приложениях, VPN-шлюзах, VDI-решениях, так и внутри домена в рамках Kerberos-аутентификации. Единственная особенность – наличие аппаратной части, что требует решения логистических вопросов.

Раздел 2. Выбор средств аутентификации

Если ваш выбор – использование ОТР, то популярным инфраструктурным решением от «Аладдин Р.Д.» является автономный высокопроизводительный сервер аутентификации JaCarta Authentication Server (JAS). Это наш лидер продаж, так как позволяет быстро заместить западные ОТР-решения. Решение поддерживает генерацию ОТР-значения с помощью приложения на смартфоне, передачи через СМС или Push, а также поддерживает все известные «железные» токены-брелоки с кнопкой или экраном для генерации OTP по стандартам RFC 4226 (HOTP) и RFC 6238 (TOTP), в том числе наш собственный токен JaCarta WebPass. Основные отличия от западных конкурентов – простота внедрения, поддержка самых распространенных прикладных сервисов, удобный и понятный «личный кабинет» для пользователя, универсальное мобильное приложение Aladdin 2FA. Также несомненно большим плюсом является наличие у JAS сертификата ФСТЭК России, соответствующего уже новым требованиям на УД-4. JAS обеспечивает безопасные механизмы передачи секрета для инициализации генератора ОТР в приложении Aladdin 2FA, при этом позволяет работать и с любыми другими приложениями типа Google Authenticator, «Яндекс. Ключ» в стандартном режиме. Сейчас многие, кто использовал для таких целей импортные решения, уже столкнулись с проблемами блокирования этих сервисов.

Построение отечественной инфраструктуры открытых ключей (PKI)

В отличие от домена на базе Microsoft AD DS, в отечественных решениях для построения доменов нет встроенного центра сертификатов, такого как Microsoft CS. Несколько лет назад мы начали работу с производителями отечественных операционных систем и достигли больших успехов в построении комплексной экосистемы. Коллеги фокусировались на замещении каталога пользователей, контроллера домена и СУБД такими решениями, как Samba DC или FreeIPA, СУБД Postgres Pro или Jatoba, а мы сосредоточились на замещении средств аутентификации, инфраструктуры PKI и организации SSO. Эта работа велась на уровне проектирования и разработки решений, то есть так же, как и у Microsoft, мы ставили задачу тесной интеграции служб организации домена и центра сертификации и разработали отечественный корпоративный центр выдачи и обслуживания сертификатов доступа Aladdin Enterprise Certificate Authority (Aladdin eCA), способный заменить импортный Microsoft CS.

Aladdin eCA позволяет «из коробки», без дополнительных настроек, разворачивать домены безопасности и обслуживать цифровыми сертификатами контроллеры доменов, серверы, сетевое и IoT/M2M-оборудование, пользователей, обеспечить непрерывность и связанность сервисов при миграции с Windows на Linux. Решение является корнем доверия, без которого невозможно получить действительно санкционно независимую базовую инфраструктуру ИТ-организации. С учетом глубокой проработки методики миграции Aladdin eCA, интегрируясь с контроллерами доменов как на базе AD, так и на базе Linux, данное решение позволяет одновременно поддерживать работу старой PKI на Microsoft CS и новой на базе Aladdin eCA. Это дает возможность плавно перенести пользователей в новые домены с выпуском новых цифровых сертификатов с отечественного центра сертификации Aladdin eCA и не требует одномоментного выключения старой работающей инфраструктуры.

Но и это не всё. Для корректной работы SSO нами было разработано клиентское ПО Aladdin SecurLogon, которое позволяет добавить недостающие компоненты на клиентские версии любой сертифицированной ОС и автоматически сконфигурировать клиентские АРМ для задач единого входа в различных вариантах построения доменов – как на базе Samba DC, FreeIPA, так и на базе Microsoft AD, если требуется временно сохранить AD. Aladdin SecurLogon также позволяет добавить аутентификацию по цифровым сертификатам в такие распространенные протоколы и сервисы, как SSH, RDP, почтовые клиенты, браузеры, подпись и доступ в СЭД. Для больших инсталляций остро стоит задача автоматической централизованной конфигурации клиентских АРМ, так как привычных групповых политик в Linux пока еще нет. Для этого мы реализовали отдельный мастер групповой настройки, который позволяет легко настроить тысячи АРМ за минуты: установить ПО, сконфигурировать ОС, добавить корневые сертификаты в список доверенных, распространить информацию о CRL, настроить SSH и т. д.

Раздел 3. Процесс миграции

При планировании процесса миграции необходимо:

1. Обеспечить непрерывность деятельности предприятия, так как нельзя ни на минуту остановить бизнес-процессы даже на этапе замещения доменной инфраструктуры.

2. Предусмотреть возможность модернизации систем аутентификации предприятия и процессов в соответствии с актуальными угрозами.

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

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

Первая связана с тесной интеграцией Aladdin eCA и контроллера домена на базе Microsoft Server. Aladdin eCA поддерживает аналогичный механизм работы, и его можно ввести в эксплуатацию и пользоваться им, пока происходит миграция остальной серверной инфраструктуры или пока действуют сертификаты, выпущенные в старой системе.

Второй вариант основан на том, что производителями ОС ведутся работы по модернизации Samba DC в части поддержки действующей схемы леса AD. Это самая удобная с точки зрения миграции схема, где новые контроллеры домена на базе Samba DC вводятся в действующий домен AD DS с репликацией пользователей на новые контроллеры. Таким образом, в ИС одновременно присутствуют контроллеры домена (и AD DS, и Samba DC), поддерживающие функционирование как старой PKI на базе Microsoft CS, так и новой, на базе Aladdin eCA. Это позволяет без единовременного перевыпуска всех сертификатов постепенно выводить из эксплуатации сертификаты с истекшим сроком действия, генерируя новые на базе отечественного Aladdin eCA. С учетом того, что домены также реплицируются, получаем бесшовный переход на полностью отечественное ПО.

Третья методика основана на механизме «доверительных отношений» (Active Directory Trust Relationship). Разворачивается новый целевой домен, который интегрируется с Aladdin eCA. Настраиваются доверительные отношения, и далее осуществляется перенос учетных записей пользователей. Возможно проводить эти работы совместно с миграцией ОС на АРМ сотрудников. Это актуально как для Samba DC, так и для каталогов, построенных на базе FreeIPA и ALD PRO. В этом случае реализуется построение новой параллельной инфраструктуры.

*    *    *

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

Помогите с  переходом сети от MS Windows к AltLunux!

В интернете, как водится, навалом разбросанных статей о настройках той или иной службы или части сервера различных Unix систем. НО! Пора бы отечественному производителю ОС (не говоря уже о господдержке ИТ среды вообще) создавать полноценный FAQ по планомерному переходу корпоративных сетей и вообщем-то нарабатывать комплексные решения для самых  насущных задач запутавшихся в сетях Windows. Сделать хотя бы раздел посвященный именно этой теме.

Вот стандартная ситуация моей классической сети  постперестроечного полугосударственного Российского предприятия среднего типа (горавтотранспорт):
1   150 ПК (MS Windows 2000-XP, половина в AD половина  в одноименной группе).
2   12 Серверов MS Windows 2000-2003:
Домен Active Directory  — 1на штука;

Контролер домена AD-DNS-DHCP основной (W2k3) — 1 штука;
Контролер домена AD резервный  (W2k) он же держит основные Файловые БД – 1 штука с большой и сложной в глубину структурой каталогов и прав доступа к ним;
Дополнительный Файловый сервер – 3 штуки (по разным подразделениям, дабы не грузить основной сервер БД);
SQL Сервер 2000 и 2005 – 3 штуки в сумме (1С, туристическая и СоцСистемы);
Терминальный сервер – 2штуки (1-н для удаленников 1С и 1-н под спец программы техслужб);
Прокси-фаер с подсчетом трафика  (всетаки не Москва) и объединением сетей – 3 штуки, на 3 удаленных офиса.

В процессе жизнедеятельности сети, а особенно её электрической части (не взирая на 3 1,5 КВт IPPONа и общий  9КВт стабилизатор марки Штиль, часто зависающий по утрам по вине разработчиков (не защитили собств. схему управления)) умирает AD на 2м, резервном сервере со всей основной БД и доками, так что он работает теперь лишь в бесполезном режиме восстановления службы каталогов, сохраняя авторизацию пользователей к шарам снаружи, но без возможности даже изменить права доступа к каталогам внутри себя. Шары работают круглые сутки без возможности остановки (такова жизнь) и даже если весь их объем перенести за 2ру-3ку часов на другой сервер, то оббегать все 150 клиентов, меняя им настройки сетевых дисков, без которых их работа почти теряет смысл, просто некогда да и нет смысла, в виде того, что все ровно за сервак под MS ни кто платить за лицензирование не собирается (не по карману). И по сему стоит боевая задача:
   Всему администраторскому составу, а именно: мне (админу), моему начальнику (немного админу) и еще меньшему админу – программисту перевести всё это хозяйство серверов (хотя бы 2) на Линукс (Linux), сохраняя при этом бесперебойную работу сети круглые сутки. О пользователях (особенно бухгалтерах и экономистах) речь пока не идет вообще, так, как они знают даже Windows немного больше моей мамы, с ним вообще не знакомой, и про Линукс им даже заикаться не стоит, особенно с работой  в Dos FoxPro 2,6.

Что для этого необходимо сделать:

1.   Поднять на новом, сертифицированном под Unix сервере (IBM eServer x3400) AltLinux Server 4.0 или его офисный аналог с конфигурацией:
2-й PDC;
SMB интегрированный в AD с переносом в него сложной структуры прав доступа  на каталоги пользователей и подразделений;
2.   Поднять на новом HP Compac dx7300 линуксовый Proxi-Nat-DNS-DHCP-Vpn сервер с подсчетом траффика пользователей AD.
3.   Перенести весь AD окончательно на 1-й Linux и подключить к нему остальные сервера из AD (SQL, Terminal) и повторить эту структуру AD-DNS-Proxi в 2-х оставшихся удаленных офисах на где новых, а где и отбитых у MS серверах.

Теперь о совсем неприятном.

Мы пробовали различные дистрибутивы Linux (SUSE 10-11 и SLES 10, CentOs 5, Fedora 6-9, Mandriva ES… и ALT 4.0 с Office вариантом тоже), но в домен войти смог тоьлко бесполезный в настройке прав доступа и еще меньшей надежностью хранения информации чем даже MS FreeNas от Synology Cube-5… увы более бесполезной в плане настройке уровня доступа и структуры каталогов системы я еще не встречал,  а то, что при перепрошивке или восстановлению ОС (как и переносе на другой аналогичный «кубик» жестких дисков) он предлагает лишь заново все отформатировать и ни как иначе! И за эту Linux-овую ересь мы отдали 1200уе не считая стоимость HDD!!!…

Хорошо лишь одно – Линукс таки входит в AD в его тяжелом состоянии, пусть и самым своим тупым представителем. Боле ни кто кроме вроде бы AltDesktop 4 и какой-то десктопной Ubuntu в AD не вхож не консольными методами.

Кто может дать человеческий совет (а заодно и составить черновой вариант FAQ этого процесса от и до)

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

И, не плохо бы сообразить по этому поводу сконфигуренный дистриб или необходимую часть готовой Samba-Ad, чтоб другим было легче тоже потом повторять. … Нас много таких в России, а комплексных решений официальных что-то не наблюдается…

БлагоДарю за внимание и надеюсь на понимание и посильную помощью.
Убедительная просьба — отвечать по существу. Тема касается не просто вопроса о частном случае, а о решении, как помочь в снятии с иглы Майкрософт регионы страны, где нет и не может быть крутых специалистов, помогающих, если не за свой счет, то за весьма условное вознаграждение. (добавлено автором после 3-х страниц темы)

PS: кстате, сервер Alt 4.0 мы спец купили аж год назад, но так вот и не удалось применить пока (даже как прокси, тупо не работает NAT), при этом нам помогал один знающий человек, но немного поковырявшись, он таки настроил все на другой системе…

Z-Root Извините за стилистическую правку вопроса .  Некрасиво, когда вопрос набран большими буквами — это некрасиво и воспринимается как крик.
Rudlandh
[/list][/list][/list][/list][/list]

История о том, как я осуществил миграцию своего офиса с Windows на Linux, началась пару лет назад, когда я познакомился с сообществом системных администраторов форума forum.sys-adm.in. Тогда-то меня и стали посещать мысли о начале изучения linux-систем.  Буквально через полгода решил подойти к этому вопросу основательно. Благо полигон подходящий был. Да и как по мне, изучать любую систему эффективнее в полевых условиях.

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

Ставим задачи и планомерно решаем их

1. Сбор исходных данных об имеющемся оборудовании и ПО
2. Выбор и установка дистрибутива ОС на рабочие станции
3. Подбор аналогов проприетарных программ для сотрудников
4. Выбор, установка и настройка сервера

Сбор исходных данных об имеющемся оборудовании и ПО

Первым делом необходимо обсудить идею с руководством. При этом нельзя забывать о рядовых сотрудниках. Ибо слово «бесплатно» зажигает огонь в глазах директора. Но он не знает чем это обернётся для менеджеров.

Для начала стоит подумать о структуре будущей системы. Так как парк машин небольшой около 20 ПК, в моем случае подошла простейшая схема ЛВС, без домена, с тремя рабочими группами, терминальным сервером 1С, Proxy-сервером и сервером-комбайном.

Так как я ленивая жопа ответственный сотрудник, то на скорую руку набросал опросный лист для сотрудников следующего вида (пусть сами напишут и принесут):

Методом анкетирования были выделены основные программные продукты, необходимые сотрудникам. Ими стали Word, Excel, интернет браузер, PDF Creator, AutuCAD, Mail.ru агент и некоторые специфические программы, не имеющие аналогов для Linux систем.

Выбор и установка дистрибутива ОС на рабочие станции

Очень кстати пришлась сборка xubuntu с оформлением в стиле Win7. Её автор проделал огромную работу, за что ему огромное спасибо. Данную сборку можно найти на форуме Ubuntu. Некоторые менеджеры и вовсе не сразу понимали, что перед ними совершенно другая ОС. Многие могут осудить выбор подобной сборки, но она явилась неким удобным компромиссом в плане юзабилити интерфейса.

Стоит сразу оговориться, что перевести всех и вся на xubuntu не получилось, так например бухгалтерия осталась на Windows. Уж больно проблематично (а в некоторых случаях невозможно) настроить все их банк-клиенты, электронные счета фактуры и т.д. и т.п. Однако же 80% ПК перешло на OpenSource ПО без вреда для производственного процесса.

Подбор аналогов проприетарных программ для сотрудников

Офисный пакет от microsoft был заменён на WPS Office, браузером выбран Google Chrome, абсолютное большинство софта для работы с документацией в linux-системах умеет экспорт в PDF из коробки. А если есть необходимость редактировать PDF, то тут есть только Master PDF Editor.  В качестве ПО для работы с чертежами отлично подошел DraftSight. Ну а мессенджер от mail.ru отлично заменяется Pidgin с плагином mrim-prpl. Для тех кто не смог GIMP подойдёт MyPaint. Remmina в качестве клиента подключения по RDP — лучший выбор ИМХО.

В компании также есть сервер на Windows Server 2008R2. В нём терминально работают бухгалтера и менеджеры в 1с8. Так как сервер уже имеется, а настроить терминальное подключение из xubuntu в него не составляет труда, было принято решение перенести спецпрограммы, не имеющие аналогов для linux, туда. Благо реальная необходимость возникает не чаще одного раза в месяц.

Итак, систему поставил, софт накатил, теперь настроим взаимодействие между участниками рабочего процесса. Так как получился “гибридный” офис, то без SMB и настроенных шар ни куда. Далее настраиваем принтеры, доступ в интернет и архивацию рабочих документов. У меня все принтеры HP, так что ставил HPLIP.

где настраиваем доступ к принтеру.

Для архивации устанавливаем SBackup. Бэкапиться будем по ftp на локальный сервер-комбайн (о нем ниже).

Часть пользователей будет ходить в интернет через локальный proxy usergate (достался в наследство) работает исправно, чего его трогать? Пусть будет. Остальные “высокопоставленные товарищи” будут иметь прямой доступ в паутину без преград. К ним относится руководство, бухгалтерия ну и разумеется я. Дело в том, что в xubuntu нет GUI-интерфейса для настройки параметров proxy на машине. Так что нашел на просторах интернета замечательную утилиту  gtk-proxy-config. Устанавливается она из репозитория FSnow. С её помощью настройка производится легко и непринужденно, без необходимости лезть в конфиги NetworkManager’а.

Выбор, установка и настройка сервера

Теперь о сервере-комбайне для локальной сети. Так как я только в начале пути изучения открытых систем и поднимать сервисы на голой системе из исходников только учусь, то в качестве серверной системы выбрал ClearOS, этот комбайн отлично подходит для моих задач:

1. Шлюз в интернет с Multi-WAN
2. SAMBA-сервер
3. VPN-сервер
4. FTP-сервер
5. Для экспериментов над локальной копией корпоративного сайта)

Инструкций по настройке этого сервера в интернетах видимо-невидимо, так что расписывать не буду, скажу, что все вышеперечисленное из списка было настроено именно на ClearOS, где любой модуль устанавливается в пару кликов в вэб-морде. Единственное, что хочется отметить, так это отсутствие доступа ко многим параметрам из вэб-интерфейса, но консоль никто не отменял, а так как в основе этого дистрибутива лежит CentOS и его репозитории, то настройке поддаются практически все необходимые параметры. Если все-же возникнут вопросы по настройке, то пишите или в комментариях или на форум или в нашу Telegram группу.

Что в итоге?

Вся эта эпопея заняла примерно 4 месяца и вот уже почти год офис работает, как будто так было всегда. Первые пару месяцев пришлось попотеть в поисках решений возникающих у пользователей проблем, да и у меня в том числе. Но как я сказал в самом начале, это только усилило желание работать в linux-системах и изучать их. С той поры сменились некоторые сотрудники в компании. И пришедшие на их место люди, ранее работавшие только в windows, на редкость быстро втягиваются в рабочий процесс.

Что касается моей рабочей машины… Мне быстро наскучила xubuntu и я перешел на Debian. И это ещё один горизонт

Благодарности

Хочу сказать и говорю спасибо, сообществу https://forum.sys-adm.in за помощь в осуществлении этого проекта!

Падение контроллера домена

Что же случится если наш прекрасно работающий контроллер домена упадёт? Начнётся хаос. Многие департаменты не смогут работать. Пользователи начнут терять возможность авторизовываться в сети, терять человечность. Доступы к шарам начнут пропадать и становиться такими же мифическими как пользовательское самосознание. Бугалтера не выходя из в бугалтерского исступления, будут как зомби сидеть перед компьютерами. Биться головой о клавиатуры. Из разных углов будет раздаваться всяческий скулёж, стоны и содомия. Фирма погрузится в постапокалиптическую реальность. Миленькая, ещё вчера, секретарша Ксюша, будет жадно обгладывать остывший труп несчастного клиента. Ведь она не смогла зарегистрировать его визит. Система то висит. Потому для решения своей проблемы она не нашла более подходящего способа чем устранить её физически. Ведь контроллер то упал, DNS не работает и загуглить что делать она тоже не смогла.

Для решения возникшей проблемы, к несчастью, недостаточно собирать совещания. Принимать «эффективные» решения. Обсуждать проблему. Решить проблему сможет только человек умеющий читать, анализировать, понимать и думать. Решить проблему сможете вы, читая данную инструкцию.

Все домены Active Directory равны

Это не какой-то розовый sjw гон. В Active Directory нет разделения контроллеров домена на роли. Такое разделение было в NT4. В NT4 был PDC и BDC. Праймари и Бэкап контроллеры доменов. В Active Directory все контроллеры доменов равны. За исключением наличия у контроллеров FSMO ролей. Потому когда я говорю «резервный контроллер домена», я подразумеваю дополнительный контроллер домена Linux который мы добавляем в уже работающий домен. Домен Linux Active Directory, находящийся под управлением Samba4 (4.7.x на момент написания статьи). Установленной на Ubuntu Server 18.04 и настроенной в соответствии с моими статьями. Для Samba 4.8 и более новой данная инструкция может оказаться и скорее всего окажется не применимой. Либо применимой с некими оговорками правками. Так что подсказать про Samba 4.8+ я не смогу, я просто не рассматривал этот вопрос на текущий момент.

Резервный контроллер домена Linux — Что нужно знать

1. Добавление в существующий домен дополнительного контроллера  и инициализация домена разные вещи. В смысле совершенно очень разные вещи.
2. Не пытайтесь инициализировать новый контроллер домена внутри локальной сети с уже имеющимся контроллером домена. Рискуете получить два кирпича, старый и новый.
3. Чтобы создать дополнительный контроллер домена, необходимо иметь уже работающий домен с контроллером домена.

В данной статье мы работаем только с новым настраиваемым контроллером домена

Имя нового контроллера домена: ag-dc-2

Полное имя нового контроллера домена: ag-dc-2.adminguide.lan

IP адрес нового контроллера домена: 192.168.1.101

Все остальные параметры взяты из Серии статей про настройку контроллера домена Linux

Применяйте данную серию статей про настройку резервного контроллера домена Linux, только для доменов настроенных по приведённой выше серии статей. В остальных случаях применяйте её на свой страх и риск.

Если не уверены, заходите на телеграм канал, возможно вы найдёте ответ там.

Настройка Ubuntu Server 18.04

1. Устанавливаем Ubuntu Server 18.04
2. Изменяем имя дополнительного контроллера домена
3. Устанавливаем статический IP адрес

Резервный контроллер домена Linux — Подготовка к установке Samba

1. Проверяем содержимое файла hosts

   sudo nano /etc/hosts

   Для сервера с именем ag-dc-2, содержимое должно выглядеть следующим образом:

   127.0.0.1       localhost.localdomain   localhost
   192.168.1.101   ag-dc-2.adminguide.lan  ag-dc-2

   Убеждаемся что команды

   ping ag-dc-2 -c 4
   ping ag-dc-2.adminguide.lan -c 4
   

   резолвятся на IP 192.168.1.101

   ping localhost -c 4

   резолвится на 127.0.0.1

2. Проверяем что IP адрес сервера статический.

   sudo nano /etc/netplan/*.yaml

   Для сервера с IP адресом 192.168.1.101, шлюзом  расположенном на роутере 192.168.1.1 и днс сервером на контроллере домена, они должны выглядеть следующим образом:

   network:
   ethernets:
   ens160:
   dhcp4: no
   dhcp6: no
   addresses: [192.168.1.101/24, ]
   gateway4: 192.168.1.1
   nameservers:
   addresses: [192.168.1.100, ]
   version: 2

3. Резервный контроллер домена Linux — Валидный resolv.conf

   Никакие утилиты не должны модифицировать файл /etc/resolv.conf.
   Команда

   ls -l /etc/resolv.conf

   должна выводить следующее. Полноценный независимый фаел:

   -rw-r--r-- 1 root root 47 окт 16 20:07 /etc/resolv.conf

   Если вместо нормального вывода вы видите симлинк:

   lrwxrwxrwx 1 root root 39 Nov  6 10:24 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

   Необходимо отключить и убрать из автозапуска systemd-resolved

   sudo service systemd-resolved stop
   sudo systemctl disable systemd-resolved.service

   Убить симлинк

   sudo rm /etc/resolv.conf

   И создать чистый файл

   sudo nano /etc/resolv.conf

   Указав в нём адрес локального DNS сервера способного разрешать имена локальной зоны. Для сервера ag-dc-2, находящегося в домене adminguide.lan. Под управлением контроллера с именем ag-dc-1 и IP 192.168.1.100. На данном этапе, содержимое /etc/resolv.conf должно быть следующим:

   nameserver 192.168.1.100
   search adminguide.lan

   192.168.1.100 — адрес уже работающего в сети DNS сервера поднятого на первом контроллере домена.
   Обязательно перезагрузите сервер и убедитесь что resolv.conf и его содержимое остались на месте.

4. Убеждаемся в отсутствии самбовых процессов

   ps ax | egrep "samba|smbd|nmbd|winbindd"

   Если что-то есть — на нож. Весь сервер. Потом переходим к пункту «Устанавливаем Ubuntu Server 18.04»

5. Убеждаемся что вы настраиваете Ubuntu Server 18.04.

   Чистый, только что установленный. Который не использовался ранее ни под какие нужды. Что это не ваша домашняя станция на какой-нибудь богомерзкой макоси. Не сервер в продакшене под полезной нагрузкой. Что вы знаете что делаете и зачем это делаете. А то мало ли. Были прецеденты. Потом люди обижаются. В стиле «У вас тут написано «На только что развёрнутом сервере, зайдите в домашнюю папку и выполните sudo rm rf ./*». Я сделал ровно это же только на своём домашнем NAS сервере в папке где у меня хранятся все все все мои самые ценные данные за всю мою жизнь и всё удалилось! Как вы можете писать такое в мануалах!». Потому убедитесь что это ваш чистый, только что поднятый сервер. Если вы делаете всё в первые, убедитесь что это не прод!

Резервный контроллер домена Linux — Устанавливаем Samba4

Для установки воспользуемся следующей командой:

sudo apt-get install acl attr samba samba-dsdb-modules samba-vfs-modules winbind krb5-config krb5-user dnsutils ldb-tools apparmor-utils -y

Когда всё выполнено — переходим к следующей статье.

Ещё больше интересного контента в моём блоге в Zen и на моём канале YouTube. Подписывайтесь на канал, ставьте лайки, делайте репосты, это поможет развитию контента проекта AdminGuide.Ru