Аутентификация файловых серверов SUSE Linux в домене Windows на базе AD

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

    Мы продолжаем серию статей про взаимодействие Linux и Windows. Теперь мы рассмотрим задачу введения в домен Windows 2008 сервера с операционной системой SUSE Linux (версия 12.1). Сразу следует упомянуть, что пользоваться будем штатными средствами openSUSE Linux — утилитой конфигурирования и управления пакетами YaST. Более подробно о YaST можно прочитать на сайте
    На сайте проекта openSuSE можно найти информацию о настройке Samba, но эти сведения касаются, в основном, старых версий (openSuSE 11) и охватывают небольшое количество примеров конфигурации.
    Для организации тестовой сети мы будем использовать виртуальную среду VMware VSphere 5, реализованную на базе архитектуры гипервизора ESXi. Однако можно было бы воспользоваться и хорошо себя зарекомендовавшим Microsoft Hyper-V, а также любым другим аналогичным решением.
    Тестовая среда представляет собой доменную сеть на базе Active Directory (Active Directory Domain Services — AD DS ), которая состоит из двух серверов инфраструктуры, работающих под управлением MS Windows Server2008 R2 EE, и одной клиентской машины — MS Windows 7 Professional. Используются IP-адреса из подсети 192.168.7.0/24.
    Название домена — LAB.LOCAL
    Сервер ForefrontThreat Management Gateway (TMG) 2010 — LAB-TMG.lab.local
    Клиент — LAB-CL1.lab.local
    На LAB-DC1 установлены роли:
    cлужбы сертификатов 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).
    Тестовая сеть и описания протоколов взаимодействия приведены в статье . В отличиe от предыдущей статьи, мы постараемся решить ту же задачу, не прибегая к редактированию файлов и применению командной строки в Linux.

    Настройка сетевого адаптера

    После того, как мы установили SUSE Linux, необходимо настроить сетевое соединение. Заметим, что мы используем статические IP-адреса.
    Через раздел Network Devices выбираем пункт Network Settings. YaST предложит нам список имеющихся сетевых адаптеров; выберем необходимый и нажмем кнопку Edit. Теперь мы внесем нужные данные, как показано на рис. 1.
    image
    Мы установили статический IP-адрес 192.168.7.9 с маской 255.255.255.0. Это один из наиболее типичных вариантов настройки сетевого соединения. В зависимости от конфигурации сети эти настройки могут меняться.
    Кроме IP-адреса, необходимо указать параметры DNS (см. рис. 2).
    image
    Параметры маршрутизатора по умолчанию устанавливаются в зависимости от конфигурации вашей сети. У нас его адрес 192.168.7.3.
    Нажимаем кнопки OK и подождем, когда система будет сконфигурирована. Чтобы проверить корректность работы, лучше перезагрузиться. Перезагрузка системы не является обязательной, но при перезагрузке мы сможем проверить корректность работы стартовых файлов. Можно перезапустить необходимые сервисы (network) вручную.

    Необходимые пакеты

    Как уже говорилось в предыдущих статьях, кроме Samba, для работы нам потребуется LDAP и Kerberos. Конечно, эти пакеты следует выбрать при инсталляции системы. Но YaST позволяет устанавливать пакеты по мере необходимости — лишь бы были доступны репозитории, где эти пакеты хранятся. Используя в YaST раздел Software и пункт Software Management, проверим, какие пакеты у нас установлены.
    Сначала Samba (рис. 3).

    Не забудем про Kerberos (рис. 4).

    В наличии LDAP нет серьезной необходимости, но мы все же поставим его: он пригодится нам в дальнейшем, при возможном расширении функциональности нашего сервера. Например, мы можем получать через LDAP списки пользователей для настройки почтовых систем. На рис. 5 показан список пакетов LDAP, но он шире минимально необходимого набора.


    Конфигурация NTP

    Все пакеты в системе установлены, и мы можем приступить к настройке. Начнем с корректной установки времени. В YaST выбираем Network Services > NTP Configuration. Не забываем, что наш контроллер домена 192.168.7.2 является и сервером NTP. Результатом настройки является следующая картинка (рис. 6). Напомним, что корректная синхронизация времени с контроллером домена необходима для правильной работы Kerberos.

    Выбрав кнопку “Now and On Boot”, мы запускаем демон NTP на нашем сервере SUSE Linux. Тем самым и наш сервер может выступать как сервер времени. Выбрав пункт “Synchronize without Daemon”, мы запустим через crontab периодическое (раз в 5 минут) обновление времени нашего сервера от контроллера домена. Выбор метода синхронизации времени зависит от того, как в дальнейшем будет использоваться наш сервер SUSE Linux.

    Настройка Kerberos

    Теперь нам нужно настроить Kerberos. В YaST выбираем Network Services > Kerberos Client. Мы должны получить результат, показанный на рис. 7.

    Сейчас не будем подробно останавливаться на “Advanced Settings” — там устанавливаются различные параметры, как клиента Kerberos, так и методов аутентификации в системе. Пока лучше этот пункт не трогать.

    Настройка LDAP

    Настала пора конфигурировать LDAP. Как уже упоминалось ранее, необходимости в этом для работы Samba нет, поскольку в составе Samba есть своя реализация LDAP. Но мы все-таки покажем, как настраивать LDAP и какие его возможности в дальнейшем мы сможем использовать.
    Нашим сервером LDAP является контроллер домена (рис. 8).

    Имеется несколько режимов работы LDAP. Фраза “Do Not Use LDAP” говорит о том, что LDAP настроен, но не используется при работе системы. “Use LDAP but Disable Login” не использует LDAP при аутентификации в системе. А при выборе “Use LDAP” для входа в систему (Оконный менеджер, ssh и другие сервисы) может быть использован сервер LDAP (то есть контроллер домена). Применение LDAP для входа в систему в нашем случае не самый лучший вариант — функции нашего сервера (файловое хранилище) не требуют такого способа авторизации. Но все будет зависеть от того, как будет использоваться сервер.
    После того, как мы указали сервер LDAP, можно и перезагрузить машину, чтобы убедиться в корректности работы. После перезагрузки опять вызовем YaST и LDAP Client Configuration. Мы увидим, что адрес LDAP-сервера сохранился, и нажмем на кнопочку “Fetch DN”. В результате мы то, что показано на рис. 9 (конфигурация LDAP. Запрос данных).

    Мы получили от LDAP-сервера информацию о домене. Значит, все работает хорошо, и можно продолжить настройку LDAP. Выберем “Advanced Configuration” в LDAP Client configuration и увидим изображенное на рис. 10.

    На этом рисунке поля User Map, Password Map и Group Map уже заполнены. Можно отредактировать их вручную, а можно выбрать вкладку Administration Setting и ввести имя администратора (рис. 11).

    После ввода имени администратора и выбора других пунктов (например, Configure User Management Setting — просто только посмотреть) будет предложено ввести пароль администратора (рис. 12).

    Для чего это все нужно? А нужно это для того (повторимся: это не обязательно), чтобы наш сервер SUSE Linux мог получать различную информацию от контроллера домена. Вернемся обратно на вкладку Client Settings и нажмем кнопку Browse возле User Map. Результат будет как на рис. 13 (Получение информации от LDAP-сервера.).

    Мы получили от контроллера домена информацию об объектах, хранящихся в базе данных LDAP о пользователях, и теперь мы можем ее использовать; например, для служб электронной почты на Linux.
    Кроме LDAP Client, через YaST можно запустить и LDAP Browser для просмотра более подробной информации, предоставляемой контроллером домена — например, подобный показанному на рис. 14.

    Для соединения с контроллером домена LDAP Browser запрашивает пароль пользователя (рис. 15).


    Настройка Samba

    Теперь настала пора переходить к настройке Samba.
    В YaST выбираем раздел Network Services и пункт Samba Server. Сначала будет предложено выбрать метод запуска Samba (Manual или During Boot). (См. рис. 16.)

    При выборе пункта During Boot сервер Samba запускается во время старта системы, при Manual необходимо запускать Samba вручную. Следует заметить, что режим During Boot может быть установлен при инсталляции пакетов Samba, и тогда вопроса выбора не возникает. Теперь нужно указать имя домена Windows (рис. 17).

    Samba может работать и как контроллер домена NT4. Следующим окном (рис. 18) будет предложено выбрать, будет ли Samba контроллером домена или нет. И если будет, то первичным или вторичным контроллером?

    В нашем случае мы выбираем Not a Domain Controller. Как контроллер домена NT4, Samba хорошо работает с операционными системами Windows XP/2000/2003, но при работе с Windows 7 в режиме AD будут возникать некоторые сложности. Работа Samba как контроллера домена — это предмет отдельной дискуссии. Некоторая информация о работе контроллера домена на Samba с клиентами Windows 7 представлена здесь
    Теперь нужно указать разделяемые ресурсы (Shared folders) на сервере Samba (рис. 19).

    Как видим, сейчас у нас таковых нет, а имеющийся ресурс netlogon имеет статус Disabled. При установке Samba может быть установлен файл конфигурации из дистрибутива, где уже указаны разделяемые ресурсы. Если нам необходимо добавить еще ресурсы (папки), то выбираем пункт Add, и нам будет предложено ввести параметры нового разделяемого ресурса (рис. 20).

    Теперь список разделяемых ресурсов на сервере выглядит как на рис. 21.

    На вкладке Shares можно указать режимы доступа к разделяемым каталогам. Можно разрешить пользователям предоставлять доступ к домашним каталогам и разрешить гостевой доступ.
    Теперь настала пора ввести некоторые идентификационные параметры на вкладке Identity (рис. 22).

    Здесь мы видим уже имя домена LAB. Желательно указать имя Netbios и, возможно, уточнить некоторые параметры, нажав на кнопку Advanced Settings.
    Можно включить поддержку WINS, которая разрешает имена NetBIOS в IP-адреса. Подробнее про WINS можно прочитать здесь.
    Также необходимо ввести параметры LDAP на вкладке LDAP Settings (рис. 23).

    Параметры LDAP Password Backend и LDAP Idmap Backend будут выбраны автоматически, Samba сама определит имя LDAP-сервера. Нам останется только ввести уникальное имя (DN — от Distinguished Name) администратора и его пароль. Но тут может возникнуть проблема. Дело в том, что при указании доменного имени (см. рис. 1), оканчивающегося на .local, SUSE Linux подключает службу mDNS. И если mDNS не находит имени сервера, то будет возникать ошибка. Одним способом выхода из этой ситуации является ручное редактирование файла nsswitch.conf, либо указание IP-адреса сервера LDAP. Подробнее про mDNS можно прочитать на сайте.
    Для проверки корректности работы нажмем Test Connection и увидим, что все в порядке (рис. 24).

    Как видим, все получилось. Теперь можно нажать всюду OK, конфигурация сервера будет сохранена. Чтобы убедиться в нормальной работе нашего сервера, можно и перезагрузить машину. Следует отметить, что после нажатия OK может быть предложено подключиться к домену Windows. Мы не рекомендуем делать это из окна Samba Server. Лучше будет вызвать в разделе Network Services YaST пункт Windows Domain Membership (рис. 25). При использовании этого пункта предлагается более полная диагностика возникающих проблем. Кроме того, настройка с использованием Windows Domain Membership предлагает больше вариантов настройки.

    В окне Windows Domain Membership можно указать ряд параметров. В нижней части можно уточнить настройки NTP, разрешить пользователям предоставлять свои каталоги для общего доступа и разрешить гостевой доступ к серверу, так же как и при настройке разделяемых каталогов Samba.
    Гораздо более интересные опции указываются в верхней части окна. Отметив Use SMB Information for Linux Authentication, мы включаем аутентификацию пользователей SUSE Linux в домене Windows. При указании этой опции пользователи при доступе к графической оболочке, к командной строке и к другим службам должны указывать доменные имена и пароли. Следует с осторожностью устанавливать эту опцию, поскольку не все оконные менеджеры дисплея (например, KDM и XDM), представленные в дистрибутиве SUSE Linux, способны поддержать аутентификацию через домен Windows. Мы оставим эту опцию для дальнейшей дискуссии.
    Нажав OK, мы получим предложение включить наш сервер в домен Windows (рис. 26).

    Согласившись с предложением, выбираем Yes и получаем приглашение ввести пароль администратора рис. 27.

    Через некоторое время после ввода пароля мы должны получить подтверждение включения нашего сервера в домен и увидим измененное окно Windows domain membership (рис. 28).

    Как видим, изменилось имя домена (оно совпадает с Kerberos realm) и появилась кнопка Leave — отключение от домена. Это свидетельствует о корректности включения в домен.

    Проверка работоспособности

    При корректном включении в домен, на контроллере домена мы увидим наш сервер SUSE Linux (рис. 29).

    Можно сказать, что задача выполнена. Теперь можно работать с нашим новым сервером. В дальнейшем мы рассмотрим возможные проблемы, появляющиеся при включении SUSE Linux в домен, и способы их устранения.

    Некоторые общие проблемы и методы их устранения

    Для корректной работы Samba в домене Windows 2008 R2 очень важно, чтобы имена разрешались правильно. Это касается прямого и обратного разрешения имен, разрешения имени контроллера домена, служб Kerberos и служб LDAP. Одним из вариантов решения проблемы является указание IP-адресов при настройке Linux, а не имен, даже несмотря на то, что при установке Samba имена разрешаются корректно. Важно убедиться, что на вкладке Kerberos Client включен режим Use Kerberos. Очень важно использовать самую последнюю версию Samba и других пакетов.

    Заключение

    Работа выполнена на базе Информационно-вычислительного центра МЭИ.
    Мы будем рады вашим замечаниям и предложениям. У нас есть возможности собрать тестовую сеть и отладить на ней различные варианты и конфигурации систем для обеспечения их взаимодействия.
    Share post

    Similar posts

    Comments 15

      +3
      Зачем использовать зону local, чем не угодила зона например .lan? Было бы неплохо приложить конфиги, а не только скриншоты менюшек — это не unix-way, описание неплохое, но годится только для сюсы текущей версии.
        0
        не понимаю чем не угодила зона .nal почему .lan :)
          0
          Можно и так, зона .local зарезервирована за mDNS, не понимаю зачем создавать себе сложности а потом героически их преодолевать?
            0
            Ну может конкретно mDNS в такой ситуации работает плохо, не проверял, думаю как и все, но сам виндовый домен чувствует себя прекрасно на .local рядом с avahi, bonjour.
              0
              А чего не зона дот нет тогда? Может он и там себя чувствовать хорошо будет. А ничего что если в такой домен понадобится включить машинку на nix или osx, то без выпиливания сервисов она не увидит серверов. На тестовом стенде такое решение допустимо, в живой сети периодически будут всплывать грабли, вдруг кто-то прочитает это и решит, что так и надо делать.
                –1
                В общем сеть .local 50 виндовых плюс 50 линуксовых машин, полет нормальный у меня. мультикаст днс для функционирования домена не нужен, самба домен на .local не пробовал но и там вроде как netbios и dns используется а не mdns
                  0
                  И вам было не лень на 50 линуховых машинах убивать avahi или править nsswitch.conf? Я прекрасно знаю, что можно убрать NOTFOUND=return и наслаждаться, вопрос зачем намеренно нарушать RFC 3927? Опять же одно дело когда вы у себя в сети такое делаете, тут в крайнем случае админ пришедший после вас поматерится и совсем другое когда такой совет попадается в топике по настройке, который могут использовать как шаблон многие начинающие администраторы. Это как витуху обжимать не по EIA/TIA-568, работать будет, но любой понимающий человек сразу поймет что делал мудрый мастер.
                    0
                    avahi не убивал, в nsswitch.conf только winbind добавился после установки соответствующего пакета, все работает без notfound, что я делаю не так?) кто сказал что я эту сеть поднимал, этот домен уже работает со времен когда про линукс на компе никто и не слышал почти, работает — не трогай, золотое правило. А схема обжимки это стандарт, не надо путать теплое с мягким.
                    И еще:Microsoft uses .local as the recommended root of internal domains. Человек как видишь тоже раньше стандарты выполнял )
                      0
                      RFC вполне себе стандарт, несмотря на расшифровку аббревиатуры и хороший тон как минимум прислушиваться к нему. Из рекомендаций майкрософт процитирую: «However, the organization might use corp.microsoft.com to represent their Active Directory forest root domain name.» В том же документе майкрософт рекомендует делать поддомен от основного. В документации от майкрософт я встречал такое количество противоречивых рекомендаций, что не удивляюсь наличию данной. Системы от майкрософт могут продолжать работать, но мы тут говорим про гетерогенную среду и нельзя не учитывать особенности работы других ОС. Какое отношение winbind имеет к резольву имен для меня загадка или зачем про него написали?
        +1
        По-моему в консоле быстрее и проще конфиги писать, там делов то на 5 минут.
        Раз уж вы начали про взаимодействие с виндой, может поможете в решении вопроса — Терминальный сервер + перемещаемые профили на samba сервере = не работает. Сможете подсказать или не пробовали такой штуки?
          0
          Я прошу прощения за запоздалый ответ.
          А можно поподробнее о задаче с терминальным сервером и перемещаемыми профилями? Если нужно, мы всегда можем попробовать — база для этого есть.

          Уж если говорить про способ конфигурации — кому как удобнее. Ранее мы уже публиковали статьи о том, как включать Samba в домен с использованием командной строки и правкой конфигурационных файлов. Поскольку не все желают пользоваться командной строкой, появилась потребность в статьях с картинками.
            0
            Да задача проста: несколько терминальных серверов, пользователи могут бегать между ними, хочется иметь общий профиль, который терминалки будут подтягивать при логоне. Вот оно не работает, никак :(
              0
              Терминальный сервер на винде и перемещаемые профили на самбе? 90% проблем — права доступа.
          +2
          Зачем вы учите людей плохому и указываете IP-адрес в кач-ве LDAP-сервера?
            0
            статей как через керберос прикрутить самбу, ssh, squid к актив директори и так много, зачем было пложить еще одну, еще и в картинках, когда это решается установкой нужных пакетов в любом юникс дистрибутиве, правкой конфига кербероса, ввода машины в домен, настройки ntp сервера чтобы время не улетало, и прикручивание авторизации в console/ssh, сквида и самбы в качестве файлохранилища.

            Only users with full accounts can post comments. Log in, please.