Содержание


Замена Active Directory

Часть 3. Централизованное управление рабочими станциями

Comments

Серия контента:

Этот контент является частью # из серии # статей: Замена Active Directory

Следите за выходом новых статей этой серии.

Этот контент является частью серии:Замена Active Directory

Следите за выходом новых статей этой серии.

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

Итак, некое гипотетическое предприятие использует GNU/Linux и MS Windows в качестве серверных ОС. На рабочих станциях также установлены Windows и Linux. Соответственно, администрировать придется компьютеры, работающие под управлением принципиально различных операционных систем. Поскольку основной объем работ системного администратора приходится на обслуживание Windows-компьютеров, с них мы и начнем.

Групповые политики (Group Policy) Active Directory

Компания Microsoft предлагает использовать групповые политики для централизованного управления компьютерами в домене Active Directory. Эта технология специфична для Windows (требуется Windows 2000 или более поздние версии) и не может быть использована для рабочих станций под управлением GNU/Linux в силу архитектурных различий операционных систем. С помощью групповых политик можно разрешать пользователям запуск только определенных приложений, настраивать минимальную длину пароля и множество других параметров. Все настройки находятся в объектах групповой политики (Group Policy Object, GPO) Active Directory, которые хранятся на контроллере домена и могут быть связаны с сайтом, доменом или OU (Organizational Unit, подразделение или организационная единица). Привязка GPO определяет область его действия. Любой объект содержит два раздела – Computer Configuration и User Configuration. Настройки первого применяются во время загрузки Windows. Второй раздел содержит настройки учетной записи, которые применяются во время входа пользователя в систему. Далее они обновляются каждые полтора часа, с вариацией в 30 минут. Политика действует только на объекты, находящиеся на уровне иерархии каталога (сайт, домен, подразделение), с которым связан GPO и ниже по древу (если не запрещено наследование). Порядок применения политик таков: локальные политики, политики уровня сайта, политики уровня домена, политики уровня OU. На всех уровнях GPO содержат одинаковые настройки, и действующим будет применившееся последним значение. Данное правило распространяется на все параметры кроме определенных как «Not Defined». Для последних Windows не предпринимает никаких действий. Единственное исключение – параметры настройки учётных записей и паролей могут быть определены только на уровне домена. Поскольку мы не преследуем цели написать руководство по настройке групповых политик в Windows, подробнее рассказывать о них не будем. Вместо этого сразу перейдем к настройке службы каталогов и контроллера домена, работающих под управлением GNU/Linux.

Поддержка групповых политик AD в Linux

Тема поддержки групповых политик AD в «серверном» ПО для GNU/Linux обсуждается уже давно. К сожалению, эта технология в свободных программах пока не реализована, а саму ее необходимость многие специалисты подвергают сомнению. Позволю себе с ними не согласиться – в корпоративных сетях часто возникает ситуация, когда Linux-серверы обслуживают рабочие станции под управлением Windows. В таком случае возможность работы с групповыми политиками будет не лишней.

Поддержка GP анонсирована в Samba 4, после ее появления наверняка будут созданы и средства настройки групповых политик. А пока системным администраторам придется ограничиться logon-скриптами или системными политиками NT4. Недостатком первого способа являются его ограниченные возможности. Искушенный читатель может сказать, что групповые политики, по сути дела, тоже основаны на сценариях и, теоретически, в скриптах можно реализовать весь необходимый функционал. Тем, кто так считает, мы посоветуем проверить теорию практикой. Это быстро охладит их энтузиазм. На самом деле, logon-скрипты пригодны только для решения несложных частных задач, наподобие подключения сетевых ресурсов при входе пользователя в систему. Повторить с их помощью весь функционал групповых политик AD практически нереально.

Второй способ предоставляет системному администратору несколько большие возможности, поэтому остановимся на нем подробнее. Настройки системных политик вносятся в реестр каждой рабочей станции. Для этого используется специальный сценарий (файл с расширением pol). Создать его можно программой «Редактор системных правил (Poledit)» от Microsoft. C ее помощью мы задаем правила для пользователя, доменной группы или компьютера. Все настройки хранятся в одном файле «ntconfig.pol», который нужно скопировать в папку netlogon нашего Samba-домена. Программа Poledit есть в официальном Sp4 к Windows 2000, и на сайте Microsoft предлагают распаковать ее оттуда. Если не хотите скачивать сервиспак целиком, программу можно взять отдельно: ftp://ftp.microsoft.com/Services/TechNet/samples/PS/Win98/Reskit/NETADMIN/POLEDIT/. Кроме нее, вам понадобятся темы common.adm и winnt.adm, которые необходимо скопировать в каталог %SystemRoot%\inf рабочей станции. Эти файлы отсутствуют на официальных серверах, поэтому ссылки на них мы давать не будем – ищите темы через любую поисковую систему, или выкачивайте и распаковывайте сервиспак (команда servicepackname /x).

Далее запускаем на рабочей станции POLEDIT.EXE и выбираем пункт меню «File -> New Policy». Появившаяся политика по умолчанию разделена на две части – параметры компьютера и параметры пользователя. Политики с префиксом Default действуют для всех объектов (по умолчанию там нет активных правил), кроме пользователей с правами администраторов. Создать политику для конкретного пользователя можно через меню «Edit -> Add User». Политики для групп и компьютеров создаются аналогично, через пункты меню: «Edit -> Add Group» и «Edit -> Add Computer». После того как политика создана, ее необходимо сохранить (File -> Save As) под именем «ntconfig.pol» и скопировать в каталог «netlogon» нашего Samba-домена. Разумеется, у пользователей должны быть права на чтение папки «netlogon» и файла «ntconfig.pol», иначе правила не будут работать. На этом настройка завершена. При входе пользователя в систему описанные в «ntconfig.pol» настройки будут применены на его рабочей Windows-машине.

Как говорилось выше, поддержка групповых политик AD в GNU/Linux пока не реализована. Поэтому, если вам нужна эта технология для управления рабочими станциями Windows – имеет смысл задуматься об установке доменного контроллера на Windows Server. Кому-то эта идея может показаться крамольной, однако лучшего контроллера домена AD, чем Windows Server, пока не придумали. И если вам нужны все возможности службы каталогов Microsoft (например, групповые политики) – другого выхода нет. Настроить же сопряжение сервисов Linux с доменом AD не так сложно. Например, файловый сервер Samba включается в Active Directory без особых проблем (на эту тему написано уже немало статей и сообщений в тематических форумах).

Следующая задача, о которой хотелось бы поговорить – централизованное управление Linux-клиентами. На первый взгляд здесь все просто – существует множество свободных программ, позволяющих удаленно администрировать ОС Linux. Автоматизация процесса не вызовет затруднений у опытных специалистов, но только в том случае, если компьютеров не очень много. Когда парк машин увеличивается до нескольких десятков, для их администрирования нужно что-нибудь посерьезнее обычного удаленного доступа по протоколу ssh и запускаемых через cron скриптов. К сожалению, среди свободных программ для GNU/Linux подходящее средство обнаружить не удалось. Поэтому мы будем говорить о коммерческих разработках.

Централизованное управление Linux-клиентами через групповые политики AD

В GNU/Linux пока нет интегрированного аналога Microsoft AD (Active Directory) и групповых политик (Group Policy), но попытки разработать подобные технологии предпринимаются. Мы хотим рассказать о компании Likewise Software (раньше она называлась Centeris) и продукте Likewise Enterprise, который позволяет настроить аутентификацию и управление Unix-станциями через Microsoft Active Directory. Программа состоит из двух частей: Likewise Console и Likewise Agent. Консоль управления устанавливается на Windows-станцию системного администратора и не требует наличия выделенного Unix-сервера. Она расширяет схему домена AD, включая в нее специфичные для Linux атрибуты. После инсталляции на компьютер Linux-агента администратор может присоединить рабочую станцию к «расширенному» домену AD. Данное решение позволяет настраивать через средства Group Policy параметры XML-системы конфигурирования GNOME, управлять инфраструктурами контроля полномочий SELinux (Security-Enhanced Linux), AppArmor и sudo. Кроме того, можно использовать сценарии и настраивать конфигурационные файлы операционной системы (например, обновление Linux из удаленных репозиториев). При стоимости $50 за управляемый клиент и $250 – за сервер, Likewise Enterprise поможет осуществить «крупные» инсталляции GNU/Linux в корпоративных сетях на базе Active Directory. Аналогичными возможностями обладают продукты Vintela Authentication Services фирмы Quest Software и DirectControl компании Centrify, позволяющие администраторам настроить аутентификацию Unix-систем через AD. Разработка Centrify также поддерживает управление рабочими станциями посредством Group Policy. По стоимости оба продукта близки к Likewise Enterprise. Увы, ни один из продуктов не позволяет реализовать работу с групповыми политиками с помощью «серверного» ПО для Unix/Linux – все они требуют наличия в сети доменного контроллера под управлением Windows Server. Это неудивительно, разработка Likewise (и ей подобные) являются всего лишь административными надстройками над существующим сервером каталогов. Предприятиям, по каким либо причинам не желающим использовать серверные ОС от Microsoft, придется ждать выхода Samba 4.

Одним из важных конкурентных преимуществ Likewise Enterprise является наличие Likewise Open – компонента с открытым исходным кодом, включающего только функции аутентификации в домене AD. Компонент Likewise Open скоро войдет в новые версии Red Hat Enterprise Linux и Ubuntu Linux. Likewise Enterprise поддерживает Novell SUSE Linux , Red Hat Enterprise и Fedora Linux, а также Ubuntu, Debian и CentOS. Кроме того, Likewise Enterprise работает под AIX, Solaris, HP-UX и Mac OS X.

На сайте проекта доступны бинарные пакеты Likewise Open для Ubuntu, Fedora и OpenSUSE. Поскольку его исходные тексты доступны, запустить Likewise Open можно и в других дистрибутивах.

Linbox Rescue Server (LRS)

Еще одна интересная задача – централизованная установка ПО и аудит рабочих станций. В серии статей о средствах резервного копирования мы уже рассматривали Linbox Rescue Server – пакет программ для централизованного создания «бекапов» и управления корпоративной IT-инфраструктурой. LRS позволяет вести полный учет используемого в корпоративной сети оборудования и программного обеспечения, а также осуществлять резервное копирование информации по сети, оперативное развертывание рабочих станций и удаленное управление ими. Напомню, что модульная архитектура LRS допускает наращивание функционала по мере необходимости. Поскольку подробное описание всех возможностей данного ПО – тема для отдельной статьи (или цикла статей), мы поговорим только о двух его модулях – Linbox Secure Control (LSC) и Hardware and Software Inventory Module.

Модуль LSC дает администратору возможность управлять файлами и каталогами рабочей станции, передавать данные с LRS на рабочую станцию, а также запускать скрипты и программы на целевых компьютерах. Кроме того, модуль обеспечивает удаленный доступ к компьютерам пользователей (экран/клавиатура/мышь) и ведет логи всех операций администратора. Для организации взаимодействия с сервером LRS используется OpenSSH. При этом сервис sshd должен быть установлен на каждом компьютере, которым необходимо управлять. Модуль LSC работает с MS Windows (NT, 2000, XP, 2003), MacOS X или любой UNIX-системой, где имеется SSH. Все функции доступны через простой в использовании и удобный Web-интерфейс. Перенос файлов, запуск программ и установку ПО можно запустить как на одном, так и на множестве клиентов, отобранных по определенному критерию (группа, подгруппа или профиль). Использование LSC вместе с другими модулями LRS позволяет использовать и другие интересные возможности, например осуществлять автоматическое развертывание рабочих станций из подготовленного образа диска.

Развертыванию Linbox Rescue Server в локальной сети компании будет посвящена отдельная статья, а пока мы расскажем о другом модуле LRS – Hardware and Software Inventory Module. Как видно из названия, он предназначен для организации аудита аппаратного и программного обеспечения сети. Инвентарный модуль доступен на главной странице Web-интерфейса вашего LRS. Для доступа к нему нужно нажать на соответствующую иконку инвентаризации клиента или группы. Для учета модуль использует агент «OCS Инвентаризация», доступный на сайте http://sourceforge.net/projects/ocsinventory/ (EN). Этот модуль дает полное описание аппаратной конфигурации клиентов, а также перечень установленного программного обеспечения.

Сервер осуществляет полный аудит машин и их окружения для всех подключенных компьютеров 24 часа в сутки: опись оборудования, периферии, а также программного обеспечения и сетевой информации (IP-адреса, выходы и т.п.). Администратор может получить предупреждение по электронной почте при изменениях между двумя сессиями учета. В заключение стоит отметить, что LRS выпускается в двух модификациях – полностью свободной и коммерческой с проприетарными компонентами и технической поддержкой от компании Mandriva.

Заключение

Мы определили круг типовых задач, которые придется решить системному администратору для настройки системы автоматизированного управления клиентскими компьютерами. Давайте еще раз взглянем на эти задачи и оценим преимущества и недостатки предложенных способов их решения. Первая и главная проблема – администрирование Windows-компьютеров. Оптимальный способ ее решения – использование групповых политик AD. Преимущество способа заключается в простоте настройки. Главный недостаток – технология не работает, если Вы используете серверное ПО под Linux. Вариантов решения два. Можно использовать системные политики либо организовать контроллер домена на Windows и включить Unix-сервисы в домен (с помощью открытого ПО или разработок, подобных Likewise Enterprise). Есть еще один вариант – дождаться выхода 4-й версии Samba (если верить анонсам, в ней появится поддержка GP). Следующая задача касается автоматизированного администрирования Linux-машин. Здесь у администратора тоже особого выбора нет – все существующие разработки корпоративного уровня являются платными, а настроить систему автоматизированного учета и контроля, используя только штатные средва GNU-Linux, в крупной сети очень непросто. С централизованной установкой/обновлением ПО и аудитом компьютеров дела обстоят получше – в качестве примера мы рассмотрели популярный пакет программ LRS. Есть и другие разработки для управления корпоративной IT-инфраструктурой.

Кстати, злые языки утверждают, что Linux-разработчики пытаются повторить технологии, разработанные в Microsoft. На самом деле это не совсем так – в Linux есть свои технологии, а здесь речь скорее идет о совместимости различных решений. И необходима эта совместимость в основном для управления Windows-компьютерами. Как бы то ни было, процесс разработки идет, и даже если сейчас системному администратору не хватает каких то технологий, они будут реализованы в обозримом будущем. Скажем, поддержка пресловутых групповых политик AD в серверном ПО для Linux вот-вот появится. В следующей статье мы подробно рассмотрим процесс установки и настройки одной из самых популярных свободных реализаций сервера каталогов – Fedora Directory Server (или, как его теперь называют, – 389 Directory Server).


Ресурсы для скачивания


Комментарии

Войдите или зарегистрируйтесь для того чтобы оставлять комментарии или подписаться на них.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Open source, Linux
ArticleID=438744
ArticleTitle=Замена Active Directory: Часть 3. Централизованное управление рабочими станциями
publish-date=10222009