суббота, 30 октября 2010 г.

Настройка сквозной аутентификации в терминальной среде Windows Server 2008 R2

Итак, имеем следующую структуру терминального решения.
  1. 1. Шесть бездисковых серверов IBM Blade Server HS22 с подключением к SAN и удалённой загрузкой с системы хранения IBM DS5300. 
  2. 2. Первый сервер имеет два камня и 12Гб мозгов, на нём работает Session Broker и он является членом фермы с коэффициентом участия 30. 
  3. 3. Три сервера имеют по два камня и 24Гб мозгов, два из них являются членами фермы с коэффициентом участия 100, третий - сервер RemoteApp (в т.ч. и установленных на виртуальных машинах, поэтому на нём поднята роль Hyper-V)
  4. 4. Пятый сервер имеет один камень и 6Гб мозгов, выполняет роль выделенного принт-сервера в системе печати Thinprint
  5. 5. Шестой сервер имеет два камня и 6Гб мозгов, является хранилищем пользовательских профилей.

Терминальные сервера имеют имена terminal-01 - terminal-03, сервер RemoteApp - termapp1, сервер печати - termdps, хранилище профилей - tprofile. Ферма терминальных серверов имеет имя terminal. (О назначении имени ферме можно почитать тут) Все сервера являются членами одного домена.

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

В клиенте RDP пользователь набирает имя terminal и выполняет подключение. Session Broker перенаправляет пользователя на соответствующий терминальный сервер. Предположим, на рабочем столе в сессии пользователя есть два ярлыка - один на удалённое приложение, развёрнутое на сервере termapp1, второй - на 16-разрядное приложение DOS, развёрнутое на виртуальной машине, работающей на сервере termapp1.

Таким образом, в случае, если мы вообще ничего не трогаем, для того, чтобы добраться до своего DOS-приложения (в независимости от того, какая ОС стоит у клиента), клиент должен будет вводить свои учётные данные четыре раза: для доступа к Session Broker, для доступа к тому терминальному серверу, на который его отправит Session Broker, для доступа к серверу RemoteApp и наконец для доступа к виртуальной машине, на которой работает его DOS-приложение.

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

Опишу процесс реализации этого механизма.

Начальные условия для реализации:
1. В домене должна быть развёрнута структура PKI.
2. На все компьютеры домена должны быть распространены два сертификата: сертификат корневого центра должен находиться в доверенных центрах сертификации компьютера (не пользователя, а именно компьютера), сертификат промежуточного центра (обычно это контроллер домена) - в промежуточных центрах сертификации. Сделать это можно по разному, в нашем случае это сделано при помощи GPO.

воскресенье, 10 октября 2010 г.

Установка Icinga 1.2.0 на CentOS 5.5

Итак, как вы уже поняли, речь у нас будет идти в основном об Icinga на базе CentOS (ну и любой другой RHEL-подобной операционной системе).
Рассказывать о том, что такое Icinga, не буду - раз вы сюда забрались, значит уже в теме и просто ищете информацию. Поэтому сразу к делу.
 В этой части мы проходим процесс установки Icinga 1.2.0 в режиме core с классическим web-интерфейсом на базе CGI и интеграцией с IDOUTILS (для хранения данных Icinga в базе SQL)

Поехали.

Устанавливаем CentOS 5.5 в минимальной конфигурации, без иксов, дополнительных сервисов, серверов и т.д. Чем меньше соберём в процессе установки, тем быстрее потом всё будет работать. В моём случае из пакетов, не относящихся на первом этапе к делу, я оставил только текстовый редактор nano и Midnight Commander (MC). Сама установка может проходить как на выделенный сервер, так и на виртуальную машину (в моём случае это виртуальный сервер под управлением Microsoft Hyper-V в режиме core на платформе MS Server 2008R2 - со временем выложу howto и по этому процессу).

Не повторяйте моих ошибок! Не надо ставить 64-разрядные версии ОС, кроме геморроя вы себе ничего не приобретёте. Во-первых, даже во время ядерной войны вам вряд-ли потребуется на этом сервере более двух гигов оперативки, во вторых вы поймёте, что совершили крупную ошибку не сразу, а только на этапе установки mysql и php, которые удивительным образом будут отказываться вставать на вашу систему и в доказательство этого будут валить вам ТАКИЕ ошибки, поиск и устранение которых займёт у вас намного больше времени, чем вы планируете прожить. :-)

После первой перезагрузки вам будет предложена утилита первоначальной настройки системы. Найти её можно в любое время по адресу /usr/sbin/setup В этой утилите, в разделе Firewall Settings, необходимо выключить SELinux - он будет только мешать. Заодно настройте встроенный firewall на приём запросов по http.

Определяемся, что для исходников будем использовать папку /usr/src

cd /usr/src
Качаем и подключаем два необходимых нам в дальнейшем репозитария: remi и EPEL

wget http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm
wget http://rpms.famillecollet.com/enterprise/remi-release-5.rpm
rpm -Uvh remi-release-5*.rpm epel-release-5*.rpm

Качаем GPG-ключ репозитария и устанавливаем его:

rpm --import RPM-GPG-KEY-remi

Ставим требуемые библиотеки и пакеты:

yum install httpd httpd-devel gcc glibc glibc-common gd gd-devel
yum install libjpeg libjpeg-devel libpng libpng-devel
Ставим mysql. Для этого используем ранее установленный репозитарий remi - это связано с тем, что официальные пакеты CentOS для mysql и php оччень сильно отстают по версиям, а в дальнейшем нам потребуется всё самое свежее и вкуссное. :-)

yum --enablerepo=remirepo install mysql mysql-devel mysql-server 
yum --enablerepo=remirepo installlibdbi libdbi-devel libdbi-drivers libdbi-dbd-mysql
Создаём пользователя для системы мониторинга, определяем его пароль:

useradd -m icinga 
passwd icinga 
Создём группу для передачи команд из web-интерфейса в систему мониторинга, включаем в неё пользователей icinga и apache

groupadd icinga-cmd
usermod -a -G icinga-cmd icinga
usermod -a -G icinga-cmd apache
Качаем дистрибутив Icinga

wget http://sourceforge.net/projects/icinga/files/icinga/1.2.0/icinga-1.2.0.tar.gz
Устанавливаем:

tar xvzf icinga-1.2.0.tar.gz 
cd icinga-1.2.0
./configure --with-command-group=icinga-cmd --enable-idoutils
make all
make fullinstall

Проверяем, что установился Icinga-API (это нам потребуется, когда мы будем натягивать на Icinga красивую web-морду, об этом в следующем посте). Для этого просто констатируем наличие папок по пути /usr/local/icinga/share/modules/icinga-api 
Если их там нет, выполняем установку Icinga-API вручную:
cd /usr/src/icinga-1.2.0
make install-api

Открываем на редактирование файл /usr/local/icinga/etc/objects/contacts.cfg и правим там строку с адресом электронной почты - вписываем адрес себя любимого, как администратора всего создаваемого добра.

nano /usr/local/icinga/etc/objects/contacts.cfg
# Just one contact defined by default - the Icinga admin (that's you)
# This contact definition inherits a lot of default values from the 'generic-contact' 
# template which is defined elsewhere.

define contact{
contact_name icingaadmin  ; Short name of user
use  generic-contact ; Inherit default values from generic-contact template (defined above)
alias  Icinga Admin  ; Full name of user

email  you@youdomain.com ; <<***CHANGE THIS TO YOUR EMAIL ADDRESS ***>>
}
(Сохраняемся в nano  комбинацией Ctrl-X, Y, Enter - выйти, сохранить изменения, подтвердить сохранение в открытый файл)

 Создаём конфиги для IDOUTILS (точнее - используем уже готовые, приведённые в качестве примера):

cd /usr/local/icinga/etc/
mv idomod.cfg-sample idomod.cfg
mv ido2db.cfg-sample ido2db.cfg
В основном конфиг-файле Icinga включаем обработчик IDOMOD, для этого в файле /usr/local/icinga/etc/icinga.cfg раскомментируем строку:

nano /usr/local/icinga/etc/icinga.cfg 
broker_module=/usr/local/icinga/bin/idomod.o config_file=/usr/local/icinga/etc/idomod.cfg
Запускаем сервис mysqld и включаем его в автозагрузку

service mysqld start
chkconfig mysqld on

Выполняем скрипт настройки безопасности для mysql, обязательно присваиваем руту пароль (желательно не пять единиц... :-) )

/usr/bin/mysql_secure_installation

Создаём базу данных для Icinga и пользователя, который будет иметь в этой базе права SELECT , INSERT , UPDATE , DELETE :

mysql -u root –p

mysql> CREATE DATABASE icinga;
GRANT USAGE ON *.* TO 'icinga'@'localhost' IDENTIFIED BY 'icinga' WITH MAX_QUERIES_PER_HOUR 0 MAX_CONNECTIONS_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0;
GRANT SELECT , INSERT , UPDATE , DELETE ON icinga.* TO 'icinga'@'localhost';
FLUSH PRIVILEGES;
quit


Теперь возвращаемся к нашему первоисточнику, из которого мы ставили Icinga, и импортируем из него структуру базы данных:

cd /usr/src/icinga-1.0.1/module/idoutils/db/mysql
mysql -u root -p icinga < mysql.sql
Открываем файл /usr/local/icinga/ido2db.cfg и убеждаемся, что соответствующие параметры имеют соответствующие значения:

db_servertype=mysql
db_port=3306
db_user=icinga
db_pass=icinga

Создаём файлы конфигурации для web-сервера

cd /usr/src/icinga-1.2.0
make install-webconf

Запускаем web-сервер и включаем его запуск в автозагрузку:

service httpd start
chkconfig httpd on
Создаём веб-админа системы мониторинга admin (ну или какого вы там ещё придумаете)

htpasswd -c /usr/local/icinga/etc/htpasswd.users admin

Редактируем файл /usr/local/icinga/etc/cgi.cfg - замняем везде пользователя icingaadmin на пользователя admin (ну или кого вы там ранее придумали... :-) )

Перезапускаем сервис web-сервера

service httpd restart
Качаем и устанавливаем Nagios-плагины (Icinga, будучи форком Nagios, пользует их для своих целей точно также, как и Nagios)

cd /usr/src
wget http://sourceforge.net/projects/nagiosplug/files/nagiosplug/1.4.15/nagios-plugins-1.4.15.tar.gz
tar zxvf nagios-plugins-1.4.15.tar.gz
cd nagios-plugins-1.4.15
./configure --prefix=/usr/local/icinga --with-nagios-user=icinga 
make 
make install

Всё. Пришло время запускать сервисы и любоваться плодами своего труда. Перед запуском маленькое отступление.
В скриптах запуска обоих основных сервисов - ido2db и icinga, указан равноправный порядок запуска. Это часто приводит к тому, что сервис Icinga стартует раньше ido2db. А это приводит к появлению ошибок в логах, связанных с невозможностью Icinga подключиться к базе данных. Для исправления этой ситуации перед первым запуском принудительно изменим порядок запуска, поставив ido2db впереди Icinga.
Для этого открываем файл /etc/rc.d/init.d/ido2db  и правим следующую строку:

# chkconfig: 345 99 01
на строку следующего содержания:

# chkconfig: 345 98 02
Теперь точно всё, стартуем сервисы и включаем их в автозагрузку.

service ido2db start
service icinga start
chkconfig ido2db on
chkconfig icinga on
Для просмотра того, что мы только что сделали, заходим на страничку

http://имя_вашего_сервера/icinga
и получаем счастье.
Работа закончена.

В следующем посте я расскажу, как на установленную Icinga натянуть её новую web-оболочку Icinga-WEB.

Всем удачи.