Pull to refresh

Аутентификация файловых серверов GNU/Linux в домене Windows на базе AD. Часть 1

Reading time10 min
Views20K

Аутентификация Samba в домене Windows



1. Введение. Обзор существующих публикаций

В последнее время системные администраторы сталкиваются с задачей объединения разнородных операционных систем в сети предприятия. В частности, одной из проблем является применение серверов GNU/Linux совместно с рабочими станциями и серверами под управлением Windows различных версий.
Обычно сеть небольшого предприятия включает в себя около 20-30 рабочих станций с операционной системой Windows 7, контроллер домена на базе Windows Server 2008 R2, маршрутизатор и нескольких специализированных серверов. Дальше мы будем рассматривать включение таких серверов на базе GNU/Linux в домен Windows Server 2008 R2 и порядок работы с такими серверами.
В качестве первой задачи рассмотрим организацию файлового сервера Samba в домене Windows Server 2008 R2. Проблеме создания файловых серверов на основе Samba посвящено множество статей и публикаций на различных форумах. В качестве примера можно привести документацию по Samba, опубликованную на официальном сайте проекта www.samba.org/samba/docs. Здесь приведены различные материалы, начиная со второго издания известной книги «Using Samba», написанной Джеем Ц (Jay Ts), Робертом Экштейном (Robert Eckstein) и Дэвидом Колльер-Брауном (David Collier-Brown) и выпущенной издательством O'Reilly & Associates. Третье издание этой книги, увидевшее свет в 2007 году, на сайте пока недоступно. Следует отметить и прекрасный набор руководств HOWTO и примеров конфигураций, представленный на сайте.
Немалое количество дополнительной информации о работе Samba можно получить и на сайтах производителей основных дистрибутивов Linux.
Стоит отметить и различные авторские материалы, опубликованные в в сетевых и печатных изданиях; например, статью Александра Фархутдинова в журнале Linux Format (http://wiki.linuxformat.ru/index.php/LXF123:Samba), Блог любителя экспериментов (http://www.k-max.name/) и целый ряд статей на таких известных ресурсах как www.opennet.ru и habrahabr.ru. Читатели могут сами убедиться в этом, задав поиск фразы «Включение samba в домен Windows» или «Включение Linux в домен Windows» и получив в итоге десятки и сотни тысяч ссылок.
Цель данной статьи – не только дать конкретные рекомендации по включению серверов GNU/Linux в доменную структуру Windows, но и рассмотреть работу тестовой сети, эмулирующую сеть небольшого предприятия. Мы постараемся рассмотреть большинство аспектов работы в такой сети и дать рекомендации по организации взаимодействия всех ее элементов.

2. Описание тестовой сети, домена Windows

Для организации тестовой сети мы будем использовать виртуальную среду VMware VSphere 5, реализованную на базе архитектуры гипервизора ESXi. Однако можно было бы воспользоваться и хорошо себя зарекомендовавшим Microsoft Hyper-V, а также любым другим аналогичным решением
Тестовая среда представляет собой, доменную сеть на базе Active Directory (Active Directory Domain Services – AD DS ), которая состоит из двух серверов инфраструктуры, работающих под управлением MS Windows Server 2008 R2 EE, и одной клиентской машины – MS Windows 7 Professional. Используются IP-адреса из подсети 192.168.7.0/24



Наименование домена – LAB.LOCAL Контроллер домена – LAB-DC1.lab.local Сервер Forefront Threat Management Gateway (TMG) 2010 – LAB-TMG.lab.local Клиент – LAB-CL1 .lab.local
На LAB-DC1 установлены роли
  • Службы сертификации Active Directory (Active Directory Certificate Services — AD CS)
  • Доменные службы Active Directory (Active Directory Domain Services — AD DS)
  • DHCP – сервер (Scope name: LAB.LOCAL; Address pool: 192.168.7.20-192.168.7.70)
  • DNS – сервер (Type: AD-Integrated; Dynamic updates: Secure only)
  • Веб-службы (IIS)


Примечание
Установка доменной службы AD DS выполнена в соответствии с рекомендациями, изложенными в статье technet.microsoft.com/en-us/library/dd378801(v=ws.10).aspx


3. Механизмы авторизации в домене Windows




Крайне важной частью протокола SMB являются методы аутентификации. Несоответствие их на сторонах клиента и сервера является причиной значительного числа проблем сетевого доступа. Всего существует четыре основных метода аутентификации.
Источник — wiki.linuxformat.ru/index.php/LXF123:Samba

Открытым текстом
По понятным причинам, этот метод аутентификации является и самым простым и самым ненадежным. Такая аутентификация использовалась старыми версиями Samba. В текущих версия пароль шифруется по умолчанию. Для отключения шифрования необходимо изменить значение параметра encrypted password в файле smb.conf на false. Так же этот метод применялся в клиентах для MS DOS а так же в старых версиях Windows NT. Уже в Windows 95 (и более новых версиях) для его активации необходимо править реестр. Для Windows 2000 и выше возможно включить этот метод аутентификации через локальные политики безопасности. Для этого необходимо установить выставить значение «Да» переключателя «Посылать незашифрованный пароль сторонним SMB-серверам». Еще раз заметим: использование этого метода сегодня ничем не оправдано и крайне не рекомендуется.

Методом LM (LAN manager)
Используется в Windows 95/98. Samba по умолчанию допускает аутентификацию по протоколу LM. При возникновении проблем с доступом к ресурсам под управлением Windows NT 4.0 и выше необходимо откорректировать локальные политики безопасности на Windows-сервере — установить переключатель «Уровень проверки подлинности LAN Manager» в положение «Отправлять LM и NTLM ответы».

Методом NTLM
Появился в Windows NT 3.5. В настоящее время используется в несколько переработанном и усовершенствованном виде — NTLMv2. NTLMv2 работает по схеме «запрос-ответ». Интересная особенность этого метода заключается в том, что сервер не хранит пароль не только в открытом, но и в зашифрованом виде. Хранится лишь его хэш, но и он по сети не передается, что очень хорошо с точки зрения безопасности.
Windows 95/98 могут работать с NTLMv2 после установки клиента Directory Services. Samba также поддерживает этот метод аутентификации.

С помощью службы Kerberos

Kerberos — мощная система, выполняющая аутентификацию и авторизацию пользователей, которая используется в домене Active Directory (AD) в качестве основной. Она также обеспечивает шифрование внутрисетевого трафика. Протокол Kerberos предлагает механизм взаимной аутентификации клиента и сервера перед установлением связи между ними, причём в протоколе учтён тот факт, что начальный обмен информацией между клиентом и сервером происходит в незащищённой среде, а передаваемые пакеты могут быть перехвачены и модифицированы. Другими словами, протокол идеально подходит для применения в Интернете и аналогичных сетях. Начиная с третьей версии, Samba может являться полноценным клиентом домена Active Directory.
На этот метод мы обратим особое внимание, так как наша статья посвящена интеграции Samba-сервера на Linux в домен AD, а значит работать необходимо именно с Kerberos.
В операционной системе Windows Server 2008 R2 Центр распределения ключей (Key Distribution Center, KDC) реализован как служба домена. В качестве базы данных учетных записей он использует Active Directory. Кроме того, некоторые данные о пользователях поступают в него из глобального каталога (Global Catalog).
Центр KDC, как и служба каталогов Active Directory, имеется в каждом домене. Обе службы автоматически запускаются подсистемой LSA (Local Security Authority – распорядитель локальной безопасности), которая установлена на контроллере домена. Они работают в пространстве процессов этого распорядителя. Ни одну из этих служб остановить невозможно. Чтобы гарантировать постоянный доступ к KDC и Active Directory, в Windows предусмотрена возможность развертывания в каждом домене нескольких равноправных контроллеров домена. При этом запросы на аутентификацию и на выдачу билета, адресованные службе KDC данного домена, может принимать любой контроллер домена.
Центр KDC (Key Distribution Service) представляет собой единый процесс, объединяющий две службы: службу аутентификации Authentication Service (AS) и службу выдачи билетов Ticket-Granting Service (TGS). В общих чертах процесс выглядит следующим образом:
При входе в сеть, клиент обращается к службе аутентификации того домена, где находится учетная запись пользователя, предоставляя ей логин и пароль. В ответ та выдает клиенту билет TGT — Ticket-Granting Ticket, разумеется, если логин и пароль верны. После этого в игру вступает TGS. Эта служба выдает билеты на доступ к другим службам своего домена или к службе выдачи билетов доверяемого домена. Чтобы обратиться в службу TGS, клиенту нужно сначала войти в контакт со службой выдачи билетов того домена, где находится учетная запись службы, представить свой билет TGT и запросить нужный билет. Если у клиента нет билета TGT, который открывает доступ к данной службе выдачи билетов, он может воспользоваться процессом переадресации (referral process). Начальной точкой этого процесса является служба того домена, где находится учетная запись пользователя, а конечной – служба выдачи билетов домена, где находится учетная запись требуемой службы.
Во многих источниках билеты называют «тикетами», «квитанциями» и даже «мандатами». Но смысл от этого не меняется- это «документ» подтверждающий право воспользоваться сервисом.
В среде Windows политика Kerberos определяется на уровне домена и реализуется службой KDC домена. Она сохраняется в каталоге Active Directory как подмножество атрибутов политики безопасности домена. По умолчанию вносить изменения в политику Kerberos имеют право только члены группы администраторов домена.
В политике Kerberos предусматриваются:
Максимальный срок действия пользовательского билета (Maximum user ticket lifetime). Под «пользовательским билетом» здесь имеется в виду билет на выдачу билетов (билет TGT). Значение задается в часах и по умолчанию равно 10 часов.
Максимальное время, в течение которого допускается обновление пользовательского билета (Maximum lifetime that a user ticket can be renewed). Задается в сутках; по умолчанию составляет 7 суток.
Максимальный срок действия служебного билета (Maximum service ticket lifetime). Под «служебным билетом» здесь имеется в виду сеансовый билет. Значение этого параметра должно быть более 10 минут, но менее значения Maximum user ticket lifetime. По умолчанию оно равно 10 часов.
Максимально допустимое отклонение в синхронизации компьютерных часов (Maximum tolerance for synchronization of computer clocks). Указывается в минутах; по умолчанию равно 5 мин.

Проверка ограничений при входе пользователя в систему (Enforce user logon restrictions). Если этот пункт помечен флажком, служба KDC анализирует каждый запрос на сеансовый билет и проверяет, имеет ли данный пользователь право на локальный вход в систему (привилегия Log on Locally) или на доступ к запрашиваемому компьютеру через сеть (привилегия Access this computer from network). Такая проверка занимает дополнительное время и может замедлить предоставление сетевых услуг, поэтому администратору предоставляется право ее отключения. По умолчанию она включена.
Сразу стоит упомянуть несколько подводных камней, с которыми можно столкнуться. В первую очередь расхождение часов на стороне клиента и сервера должно составлять не более нескольких минут (по умолчанию, как уже было сказано выше, не более пяти), иначе сервер признает квитанцию клиента недействительной и откажет ему в доступе. В этом случае на клиентской Windows-машине или сразу будет выведено сообщение «Доступ запрещен», или Windows раз за разом будет спрашивать логин-пароль без всякого видимого результата. Во-вторых следует помнить, что основу Active Directory составляют четыре технологии: DNS, LDAP, SMB и Kerberos. Все они работают в составе домена, но к каждой из них можно обращаться как самостоятельной службе. Несмотря на такую независимость служб, неверная работа хотя бы одной из них сделает включение клиента в домен невозможным. Особое внимание следует обратить на то, что если на стороне клиента неверно указаны сервер DNS, имя клиента или имя домена, то он не будет включен в домен AD. Причиной этого является тот факт, что DNS-сервер в составе домена Active Directory хранит SRV-записи, указывающие на расположение серверов KDC и LDAP.

4. Требуемые пакеты для GNU/Linux

Все упомянутые ниже пакеты нужны для развертывания OpenLDAP, Kerberos и Samba на сервере, работающем под управлением Ubuntu Linux 10.04.4 LTS 64 с графической оболочкой Xfce. Также приводятся сведения о необходимых для установки предустановленных пакетах в соответствии с официальной документацией для OpenLDAP, Kerberos и Samba

Для сборки OpenLDAP необходимы следующие пакеты:

  • Компилятор C, например gcc (обязательно)
  • Reentrant POSIX REGEX software (обязательно)
  • Cyrus SASL 2.1.21+ (рекомендуется)
  • OpenSSL 0.9.7+ (рекомендуется)


Необходимые пакеты можно установить командой sudo apt-get install имя_пакета.
Так же потребуется Oracle Berkeley DB версий 4.4 – 4.8 или 5.0 – 5.1. О том, как собрать ее из исходников, мы расскажем чуть позже, когда будем говорить о сборке OpenLDAP.

Для сборки Kerberos нам понадобятся пакеты flex и bison(sudo apt-get install flex bison), иначе при сборке вы получите ошибку “yacc – command not found”. Затем нам понадобится g++ (sudo apt-get install g++), так как в противном случае Kerberos снова не соберется, сообщив, что “g++ — command not found.”

К моменту сборки Samba у нас уже должны быть установлены и OpenLDAP и Kerberos, в этом случае установка дополнительных пакетов не потребуется.
Для установки пакетов gcc, g++, flex, bison можно воспользоваться менеджерами пакетов, установленной на Вашем дистрибутиве GNU/Linux. Обычно нужно просто отметить эти пакеты при первоначальной установке системы.
5. Сборка пакетов из исходных текстов.

Итак, переходим к самой части — сборке пакетов из исходников. Конечно, сборка из исходников не является распространенной практикой для современных дистрибутивов Linux, и представляет скорее исследовательский интерес. Мы рассмотрим сборку из исходников, так как этот процесс является, в целом, универсальным для любого дистрибутива Linux. В дальнейшем мы будем работать с репозиториями, что несколько проще.
Сборка OpenLDAP
Сначала с сайта Oracle скачиваем source-файлы Berkeley DB(далее — BDB) с сайта Oracle. www.oracle.com/technetwork/database/berkeleydb/downloads/index-082944.html В нашем случае все получилось с BDB 4.8
Компилируем и устанавливаем BDB:
	tar xvzf db-4.8.30.tar.gz
	cd db-4.8.30/build_unix
	../dist/configure #Если необходимы специфические параметры - /configure 	--help
	make
	sudo make install

Скачиваем исходные тексты OpenLDAP www.openldap.org/software/download
В нашем случае это была версия 2.4.30.
Компилируем и устанавливаем OpenLDAP:
tar -xzvf openldap-2.4.30.tgz
cd openldap
export CPPFLAGS="-I/usr/local/BerkeleyDB.4.8/include 	-D_GNU_SOURCE"
export LDFLAGS="-L/usr/local/BerkeleyDB.4.8/lib"
export LD_LIBRARY_PATH="/db-4.8.30.NC/build_unix/.libs/"
./configure --with-tls=no #если необходимы некие особенные опции установки — ./configure --help
make depend
make
make test #на этом шаге проверяется OpenLDAP. Времени это занимает много, можно смело попить кофе.
make install


Вот и все с OpenLDAP. Напоследок хочется упомянуть несколько наиболее распространенных ошибок:
configure: error: Berkeley DB version mismatch
Solution: скорее всего вы не экспортировали переменные LDFLAGS и LD_LIBRARY_PATH, как было сказано выше.
getpeereid.c:52: error: storage size of ‘peercred’ isn’t known
Вы, скорее всего забыли о флаге -D_GNU_SOURCE, который необходим для обхода несовместимости с glibc.
И еще раз внимательно проверьте все, ли необходимые пакеты установлены на вашей системе.
Сборка Kerberos

Скачиваем Kerberos web.mit.edu/kerberos/dist/index.html Мы использовали current release.
После этого распаковываем, собираем и устанавливаем программу:

t
ar -xzvf  krb5-1.10.1.tar.gz
cd /krb5-1.10.1/src
./configure --with-ldap=yes #здесь, если необходимо, указываем опции. Какие — можно поинтересоваться командой ./configure —-help.
make
make install
make check #проверяем результат наших трудов.

Если вы получите ошибку «yacc — command not found», значит, вы забыли поставить пакеты flex и bison.
sudo apt-get install flex bison
Если «g++ – command not found», значит, забыли про компилятор g++.
sudo apt-get install g++

Сборка Samba
Скачиваем исходники Samba c www.samba.org/samba/download. Нам нужна последняя версия, поэтому качаем samba-latest.tar.gz.
Разархивируем, собираем и устанавливаем Samba:

tar -xzvf samba-latest.tar.gz
cd samba-3.6.3
cd source3
./configure --with-ldap=yes --with-ads=yes  
make
make install

Скорее всего, если все предыдущие шаги были выполнены правильно, сборка и установка Samba пройдет без проблем. Если нет — в первую очередь проверьте, все ли зависимости корректно установлены. Если Samba чего-то будет не хватать, она заявит об это весьма ясно.
Конечно, сборка всех пакетов из исходных текстов трудоемкая процедура с невысоким коэффициентом полезного действия. Поэтому лучше всего установить требуемые пакеты с использованием менеджера пакетов Вашего дистрибутива GNU/Linux.
Итак, все пакеты установлены и пора переходить к настройке.
Tags:
Hubs:
+3
Comments3

Articles

Change theme settings