Сегодня гетерогенные сети не являются чем-то необычным: среди Windows-компьютеров гляди и найдется парочка *nix-серверов и рабочих станций, которые работают со специфическим ПО или выполняют специализированные задачи. Но наличие разнотипных ОС усложняет администрирование, ведь приходится отслеживать их состояние, синхронизировать учетные данные, права и многое другое. В статье рассмотрим, как можно заставить Windows и *nix-хосты работать в едином тандеме.

 

Обзор доступных технологий

Управление большим количеством разношерстных систем – дело весьма непростое, нужно контролировать их работоспособность и актуальность ПО, раздавать привилегии пользователям, отключать ненужные учетные записи, мониторить производительность и доступность системных ресурсов. Проблема синхронизации учетных записей и политик особенно остра. Если выполнять все настройки на каждой системе по отдельности, это займет не только больше времени, но и увеличит количество ошибок. Внедрив систему единой регистрации (single sign-on, SSO), мы получим возможность устанавливать все разрешения централизованно. Пользователям же не нужно будет каждый раз вводить логин и пароль при подключении к тому или иному ресурсу: файловому, прокси-серверу и т.д. С точки зрения безопасности это тоже плюс, так как все политики паролей наследуются из одной базы (например, Active Directory), а пользователь также меняет пароль один раз и в одном месте.

Если администратор знаком с *nix-системами, то, скорее всего, он выберет один из двух «традиционных» путей. Первый вариант – это использование сервера Samba (winbind) и Kerberos. Для интеграции с AD это более «правильный» способ, поэтому его рекомендуют разработчики многих OpenSource-проектов (например, Squid). Причем Samba-сервер в таком случае легко сможет заменить контроллер домена. Второй заключается в получении информации об учетных записях при помощи LDAP-сервиса. Это универсальный способ, так как позволяет работать с любым доступным LDAP-сервером и необязательно доменом AD. Оба варианта легко реализуются при помощи OpenSource-компонентов, то есть не требуют финансовых вложений в покупку софта. Минус – необходим некоторый опыт в настройке *nix-систем. Подобные схемы уже рассматривались на страницах ][, поэтому далее познакомимся с альтернативными реализациями, ориентированными, в первую очередь, на Windows-специалистов.

 

Служба управления идентификацией UNIX

В Microsoft понимают необходимость наличия удобных инструментов, позволяющих управлять различными системами в гетерогенной сети. И нужные разработки ведутся уже не один год. В результате сегодня по дефолту в состав ОС (с Win2k3R2) входит Служба управления идентификацией UNIX (Microsoft Server for NIS, AD Identity Management for Unix), являющаяся подкомпонентом роли контроллера домена. В Win2k8 установить ее можно обычным образом в Диспетчере сервера или при помощи консоли. Например, используя командлет PowerShell:

PS> Import-Module Servermanager
PS> Add-WindowsFeature ADDS-Identity-Mgmt -restart

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

Однако подключения к AD фактически не происходит, разработка MS обеспечивает лишь аутентификацию пользователя, не более. Все дело в том, что в процессе установки создается отдельный домен службы NIS (Network Information Service) с таким же именем, как и домен AD, в котором администратор и выполняет настройки, подключая учетные записи. Пользователи будут использовать для входа один и тот же пароль в Windows и *nix. В параметрах учетных записей AD появляются *nix'овские UID и GID. Главный минус такого решения заключается в том, что сервер NIS – это довольно старый и не отвечающий сегодняшним реалиям стандарт с весьма скромным количеством хранимых атрибутов (логин, пароль).

 

Управление при помощи SCOM 2007

Но это еще не все, что предлагают нам дядьки из Microsoft. Один из членов семейства System Center (о SCCM 2007 читай в статье «Начальник сети», опубликованной в ][ 08.2009) – System Center Operations Manager 2007 (OpsMgr 2007, microsoft.com/systemcenter/en/us/operations-manager.aspx) – предназначен для управления и мониторинга приложений, сервисов, серверов в гетерогенной среде. Программа призвана объединить информацию о функционировании различных компонентов IT-инфраструктуры, обеспечивая ее обобщенное представление в единой консоли.

Изначально OpsMgr 2007 был рассчитан на продукты MS, но в 2008 году стали доступны расширения Cross Platform Extensions (blogs.msdn.com/SCXplat), которые дают возможность мониторить состояние и производительность, а также управлять Linux x86/x64 (официально – RedHat, SUSE), HP-UX, AIX и Solaris SPARC/x86. CPE построены с использованием открытых стандартов: Web Services for Management (WS_Management), OpenPegasus и SSH. Последний обеспечивает авторизацию и безопасную связь между сервером и клиентами. Кроме того, посредством SSH осуществляется развертывание агентов на удаленных системах и управление сервисами. Используя OpsMgr, *nix-админ вдобавок ко всему получает удобную систему отчетов.

На сегодня стадия тестирования завершена, продукт можно свободно скачать по ссылкам на странице TechNet (technet.microsoft.com/en-us/systemcenter/scx/default.aspx).

После установки набора расширений и добавления *nix-систем в список OpsMgr можно управлять не только настройками ОС и некоторых популярных приложений (Apache, MySQL, syslog), но и ресурсами: дисками, сетью, CPU. Агенты устанавливаются централизованно из консоли управления OpsMgr при помощи мастера «Computer and Device Management Wizard - Unix/Linux Discovery Wizard» или вручную, используя пакетный менеджер дистрибутива. После чего на клиентской стороне стартуют два демона – scx-cimd и scx-wsmand, которые выполняют основную работу по сбору данных и запуску команд.

 

Сторонние разработки

На рынке доступны решения и от сторонних компаний. Среди самых известных: Centrify DirectControl/Centrify DirectManage, Likewise Enterprise/Likewise Open, Quest Authentication Services (ранее Vintela Authentication Services) и Quest One Identity Solution. Все перечисленные продукты обеспечивают аутентификацию пользователей *nix в службе Active Directory. К плюсам таких программ можно отнести простое развертывание и настройку, производимую, как правило, посредством графического интерфейса. Это очень удобно, ведь админу-виндузятнику не нужно вникать в особенности *nix-систем, разбираться в конфигах и так далее. Для пользователя *nix и Windows разницы в работе нет – после аутентификации он получает все права на доступ к ресурсам, которые делегированы ему в AD.

Минус – коммерческие реализации стоят денег, а значит, их внедрение придется хорошо обдумать и обосновать начальству. Хотя стоимость лицензии на один компьютер все равно получается меньше, чем покупать Windows. Поэтому выбрав *nix + один из продуктов, о которых рассказано далее в статье, можно немного сэкономить (не только на лицензировании ОС, но и на покупке антивирей и прочего сопутствующего софта).

Для выполнения своей функции сторонние решения обычно используют расширение схемы AD, а на клиентские системы устанавливается агент, который и отвечает за аутентификацию и взаимодействие с КД. Задача несколько усложняется тем, что в *nix нет единого стандарта присвоения UID и GID учетным записям пользователей и групп, поэтому в разных системах и дистрибутивах соответствующие цифры не совпадают. Как ты понимаешь, без ручной доводки здесь не обойтись, даже при наличии мощных средств автоматизации.

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

 

Likewise Open

  • Разработчик: Likewise Software
  • Web: likewise.com, likewiseopen.org
  • ОС: Linux 2.4/2.6 (x86/x64) RPM&DEB based, FreeBSD x86, Solaris 8+ (x86/x64, SPARC), OS X 10.4+, HP-UX PA-RISC/IA64, AIX

Продукт распространяется в двух версиях: бесплатной (Open) и коммерческой (Enterprise). Агент, устанавливаемый на клиентских компьютерах, обеспечивает SSO-аутентификацию пользователя посредством Kerberos 5 или NTLM. Агент используется для аутентификации и получения доступа к системам и ресурсам. Компьютер с установленным LO становится полноценным членом домена. Поддерживаются доменные политики паролей. Реквизиты кэшируются на клиентском компьютере, что позволяет работать без доступа к КД. Единый пароль работает и для других приложений (таких, например, как OpenSSH и Putty). Для настройки подключения к AD на клиентской стороне может использоваться графический интерфейс, который устанавливается отдельно. Список поддерживаемых систем и платформ насчитывает до 180 наименований.

Дополнительные функции, доступные в версии Enterprise, позволяют управлять тождеством *nix-идентификаторов в AD, применять групповые политики AD для *nix-систем, в том числе и управлять настройками рабочего стола Gnome GConf, политиками SELinux, AppArmor и sudo, использовать сценарии и настройку в конфигурационных файлах. Чтобы получить идентификатор пользователя и группы из AD, следует установить на рабочем месте администратора дополнительный модуль UID-GID (Likewise Management Console), который обеспечит нужное сопоставление. Кроме прочего, версия Enterprise снабжена удобной системой отчетов, позволяющей собрать и проанализировать текущие установки систем.

Инсталляция приложения не должна вызвать сложностей. Прекомпилированный пакет LO доступен в некоторых популярных дистрибутивах, например, Red Hat Enterprise Linux/Fedora/CentOS, Ubuntu, openSUSE. В Ubuntu набираем:

$ sudo apt-get install likewise-open likewise-open-gui

На офсайте выложены скрипты установки для дистрибутивов, использующих RPM и DEB. Например, в Ubuntu установка при помощи такого пакета проста:

$ sudo chmod +x ./LikewiseIdentityServiceOpen-5.3.0.7766-linux-amd64-deb.sh
$ sudo sh ./LikewiseIdentityServiceOpen-5.3.0.7766-linux-amd64-deb.sh

И GUI:

$ sudo chmod +x ./LikewiseDomainJoinGui-5.3.0.7766-linux-x86_64-deb-installer
$ sudo sh ./LikewiseDomainJoinGui-5.3.0.7766-linux-x86_64-deb-installer

Для чистоты операции систему лучше перезагрузить. Возможна также сборка из исходных текстов, что позволяет использовать LO-администраторам слаки, генту и другие системы. После установки в *nix-системе будет запущен ряд сервисов: lsassd (аутентификация), netlogond (поиск КД), dcerpcd (RPC), lwiod (работа с SMB) и eventlogd (сбор событий). Создаем в домене отдельную OU, в которую будут входить: *nix-пользователи, группа (она должна быть установлена как primary) и учетные записи. Затем подключаем компьютер к домену:

$ /opt/likewise/bin/domainjoin-cli join synack.ru admin

Ключ '--preview' позволяет просмотреть операции, выполняемые скриптом. В процессе подключения используем учетную запись администратора домена; если будут проблемы, попробуй указать имя в виде DOMAIN\\username.

 

Quest Authentication Services

  • Разработчик: Quest Software
  • Web: quest-software.ru
  • ОС: Linux x86/x64, Solaris x86/x64/SPARC, AIX, HP-UX, Mac OS X, HP-UX IA64/PA-RISC, IBM AIX x86/x64, SGI IRIX, Tru64, XenServer, VMware ESX Server

Решение QAS использует запатентованную технологию, расширяющую схему AD, позволяя *nix-системам стать полноценными членами домена. Поддерживается централизованное управление, GPO, SSO-аутентификация пользователей не-Windows ОС и некоторых приложений, использующих Kerberos и LDAP. Причем QAS поддерживает алгоритм шифрования ARC4 с 128-битным ключом, который более устойчив, чем стандартный 56-битный DES, используемый в Kerberos. При этом QAS позволяет пользователям *nix применять при регистрации в системе не только связку логин/пароль, но и смарт-карту. Предусмотрена возможность расширения групповых политик AD, в которые можно добавлять сценарии, файлы, ссылки, сообщение дня, системный журнал. В документации расписано, как самостоятельно создать политику под любую ситуацию. При наличии NIS-сервиса возможна миграция или хранение данных NIS в AD.

Установочные файлы распространяются в виде архива или ISO-образа (по составу они одинаковы). Сам процесс инсталляции прост, перед запуском установочного скрипта install.sh следует вызвать скрипт preflight.sh с именем домена в качестве аргумента. Скрипт проверит систему на совместимость с QAS и возможность подключения к домену. Собственно процесс установки на *nix производится при помощи текстового мастера и занимает пару минут. Все инсталлируемые пакеты в формате RPM/DEB находятся в подкаталоге client, в SDK – исходные тексты. На последнем шаге установки клиента происходит подключение к домену. Демон vasd обеспечивает аутентификацию и кэширует полученные данные, предоставляя доступ к требуемым ресурсам. Для управления работой vasd используется утилита командной строки vastool.

В Windows установка производится при помощи понятного графического интерфейса, в меню которого имеются ссылки на нужные приложения и руководства пользователя. Кроме этого, для версий ниже Win2k3R2, где нет схем для AD, позволяющих работать с Unix-атрибутами (UID, GID, оболочка по умолчанию, домашний каталог), следует запустить мастер Schema Wizard, исполняемый файл которого находится в подкаталоге Schema. При изменении схемы лучше перестраховаться и создать резервную копию, всякое ведь бывает.
Примечание: добавлять учетные записи для *nix-систем следует в отдельном OU.

 

Centrify DirectControl

  • Разработчик: Centrify Corporation
  • Web: centrify.com
  • ОС: Linux x86/x64, Mac OS X, Solaris/OpenSolaris x86/x64/SPARC, IBM AIX, SGI IRIX, HP-UX, VMWare ESX Server

Centrify DirectControl обеспечивает *nix-системам аутентификацию, управление контролем доступа и реализацию групповых политик. Как и в прочих решениях, на клиентских компьютерах устанавливается специальный агент, который отвечает за взаимодействие с AD. Полученные данные кэшируются, позволяя работать в автономном режиме без доступа к КД. Агенты созданы для большого количества систем и версий ОС, разработчики заявляют о поддержке 225 дистрибутивов; полный перечень можно найти по адресу centrify.com/directcontrol.

Непосредственное управление осуществляется при помощи Centrify DirectManage – набора Windows утилит и веб-консоли. Кроме этого, в свойствах объекта в консоли «Active Directory – пользователи и компьютеры» появляется дополнительная вкладка Centrify Profile, где можно выбрать домен, просмотреть свойства профиля: основную группу, логин, UID, домашний каталог. Здесь обнаруживается фишка DirectControl – зоны, которые представляют собой логические группы со своим уникальным набором учетных записей пользователей и админов, а также набором политик безопасности и прав доступа. Зоны могут создаваться по любому удобному признаку. Например, в зону можно включить системы в удаленном офисе или собрать все системы с определенной версией ОС. Наличие зон позволяет предельно точно контролировать права пользователей.

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

Наличие в *nix-системах множества однотипных параметров, но с разными идентификаторами, может вызывать конфликты. В DirectControl предусмотрена специальная функция разрешения конфликтов, настройки которой доступны в том числе и через GPO.
Установка как в *nix, так и в Windows не отличается сложностью, хотя и происходит в текстовой консоли. В дальнейших настройках (создание новой зоны, настройка *nix-идентификаторов, primary-группы и т.д.) администратору помогают многочисленные мастера, что заметно упрощает и ускоряет процесс интеграции *nix-систем в AD, а также уменьшает количество возможных ошибок.

 

Заключение

Как видишь, Windows и *nix могут спокойно уживаться в одной сети, работая в едином тандеме и, главное, не доставляя хлопот админу. Все описываемые решения понятны в установке и дальнейшей настройке, и обычно проблем с последующей доводкой не возникает.

 

Настройка обмена данными между Win2k8R2 и *nix

При наличии в сети серверов и рабочих станций Windows и *nix необходимо настроить обмен данными между ними. Для этих целей обычно используют один из двух протоколов: SMB или NFS. Первый является штатным для Windows, второй – для *nix. Другие протоколы вроде FTP, HTTP, SSH и т.д. менее удобны для обмена файлами в локалке. Монтировать в Linux сетевой ресурс можно при условии наличия модулей ядра, обеспечивающих поддержку файловых систем SMBFS или CIFS, и утилиты smbclient. В Ubuntu для этого следует установить пакет SMBFS, в CentOS – CIFS.

Просмотреть список доступных ресурсов можно при помощи команды:

$ smbclient -L winsystem

Некоторые файловые менеджеры *nix (Konqueror, Nautilus) поддерживают специальный протокол – smb://winsystem/.
Чтобы смонтировать ресурс при загрузке, прописываем в /etc/fstab:

//winsystem/share /mnt/win cifs user,uid=500,rw,suid,username=user,password=pass 0 0

Но монтировать сетевой ресурс удобнее, когда он действительно нужен, поэтому лучше использовать autofs. В /etc/auto.master добавляем описание новой точки монтирования:

/smbmount /etc/auto.smb

В файле /etc/auto.smb описываем ресурсы:

winsystem -fstype=cifs,rw,noperm,username=user,password=pass ://winsystem/share

И перезапускаем сервис командой «service autofs restart».

В *nix подключение по протоколу SMB организуется средствами сервера Samba (www.samba.org). Его настройка производится ручной правкой конфигурационного файла /etc/smb.conf, хотя в современных дистрибутивах уже доступны утилиты с графическим интерфейсом, позволяющие настроить сетевой ресурс буквально парой щелчков мышки (Nautilus, Konqueror, smb4k, XSMBrowser).

Начиная с Win2k3R2, в состав ОС входит компонент Microsoft Services for Network File System (ранее доступен в пакете Windows Services for Unix). В Win2k8 он является частью роли File Server. Включает клиентскую часть для подключения к NFS-каталогам в сети и серверную часть – для предоставления общего доступа. Установить NFS-сервер можно командой:

> Servermanagercmd –install FS-NFS-services

После установки в свойствах сетевой папки появится пункт NFS Sharing, в котором производятся основные установки.

Настройки NFS сервера в *nix расписаны достаточно подробно (например, см. пошаговое руководство www.openbsd.ru/docs/steps/nfs.html). Определяем в /etc/exports ресурсы для экспорта и монтируем в Windows сетевой ресурс как локальный диск:

> mount \\192.168.1.12\share Z:

Команда «showmount -e IP_server» выведет список доступных ресурсов.

 

INFO

О SCCM 2007 читай в статье «Начальник сети», опубликованной в ][ 08.2009.

 

WWW

 

WARNING

Чтобы без проблем подключить *nix к AD, следует на *nix-клиентах прописать в качестве DNS и NTP серверов контроллер домена.

  • Подпишись на наc в Telegram!

    Только важные новости и лучшие статьи

    Подписаться

    • Открыть комментарии
    Подписаться
    Уведомить о
    0 комментариев
    Межтекстовые Отзывы
    Посмотреть все комментарии