 |
|
|
|
FreeBSD в домене Microsoft Windows
FreeBSD в домене Microsoft Windows Постановка задачи Предположим, имеется некоторое количество компьютеров, объединенных в локальную сеть и включенных в один Microsoft-based домен с контроллером домена на базе Windows 2000 Server. Как известно, в такой конфигурации нет необходимости заводить пользователей на каждом из компьютеров – достаточно создать пользователя в домене и можно с его учетной записью регистрироваться и работать на любом компьютере домена, если на то не установлено специальных ограничений. Теперь предположим, что в этот домен (например, MYDOMAIN) необходимо добавить рабочую станцию под управлением FreeBSD. Полноценное взаимодействие с членами Microsoft-based домена FreeBSD выполняет с помощью пакета Samba. Можно ли обойтись без создания локальных пользователей на FreeBSD и в момент авторизации действовать так же, как рабочая станция Microsoft Windows, – запрашивать список пользователей с контроллера домена? До недавнего времени ответ был однозначен: «Нельзя». Несмотря на наличие в системе winbindd, который позволяет получать информацию о пользователях домена, не было способов интегрировать доменных пользователей в систему и работать с ними так, как если бы они были локальными (хотя новая Samba 3.x предоставляет такую возможность). Но с выходом FreeBSD 5.x все изменилось в лучшую сторону. Итак, задача: настроить систему таким образом, чтобы можно было регистрироваться в системе, а также заходить по ftp, ssh, kdm и использовать xlockmore но при этом не создавать локального пользователя. Полигон: рабочая станция под управлением FreeBSD 5.3-RELEASE с установленной Samba 3.0.10, контроллер домена под управлением Windows 2000 Server. В сети Microsoft Network рабочая станция называется MYSTATION, контроллер домена – MYPDC. Новые возможности Благодаря чему поставленная задача стала решаемой? Решение задачи базируется на двух краеугольных камнях. Во-первых, во FreeBSD 5.х наконец-то появилась поддержка NSS (Name Service Switching), благодаря чему теперь возможно перенаправлять запросы программ, запрашивающих информацию о пользователе, группе, компьютере и т. д. Допустим, мы вводим команду id (выдать информацию о пользователе) в системе, не входящей в домен Microsoft Windows: > id user1
Программа id вызывает системную функцию getuid() для получения информации о пользователе, логин которого задан в командной строке. Порядок получения информации функцией getuid() во FreeBSD версий 4.х и 5.х приведен на рисунке.
Getuid() обращается к единственному источнику информации – локальной базе пользователей – файлу master.passwd для получения данных и выдает ответ, показанный выше. Теперь мы вводим команду id в системе, которая подключена к домену Microsoft Windows надлежащим образом: > id user1
Getuid() обращается к файлу nsswitch.conf, получает из него список источников информации и последовательно обращаясь к каждому, опрашивает их на предмет получения данных. И точно так же будет вести себя любая другая программа, которой потребуется получить информацию о поль-зователе или, например, проверить пароль пользователя. Во-вторых, это PAM (Pluggable Authentication Mechanism) – чрезвычайно мощный и столь же гибкий механизм, позволяющий реализовывать практически любые механизмы аутентификации пользователей любыми путями. Конечно, реализация PAM была и в 4.x. Но только в 5.x появилась возможность использовать его для целей аутентификации из домена Microsoft. Файл /etc/pam.conf в FreeBSD 5.x был заменен на каталог /etc/pam.d, в котором размещается по одному файлу на каждый сервис с именем, совпадающим с названием сервиса. Таким образом, настройка FreeBSD для аутентификации из домена Microsoft Windows сводится к:
Настройка Samba и NSS Так же как театр начинается с вешалки, так и представление FreeBSD, как и любой другой UNIX-системы в сети Micro-soft Windows, начинается с настройки пакета Samba. Об этом написано достаточно как на английском, так и на русском. С моей точки зрения лучшей является документация, созданная самими авторами пакета: «Using Samba», «Official Samba-3 HOWTO and reference Guide», «Samba-3 by Example». Мы рассмотрим только настройки winbindd, необходимые для получения информации из домена Microsoft Windows. Предполагается, что рабочая станция уже является членом домена. template homedir = /usr/home/%U Этот параметр определяет «домашний каталог» сетевого пользователя. Winbindd для каждого пользователя, отсутствующего в локальной базе, создает запись, по формату совпадающую с форматом записей файла master.passwd. Для заполнения полей, которые принципиально отсутствуют в домене Microsoft Windows, winbindd использует этот и подобные ему другие параметры. Макрос %U, как это принято в пакете Samba, обозначает имя пользователя. Каталог должен существовать, пользователь должен иметь на него необходимые права. При создании локальных пользователей все эти действия выполняет команда adduser. Как обеспечить наличие домашнего каталога для сетевого пользователя? Microsoft Windows выполняет это действие автоматически. Стандартное решение мне неизвестно, нестандартных же способов есть несколько:
template shell = /bin/tcsh Это второй параметр, который используется winbindd для заполнения записи о сетевом пользователе. Если локальная работа пользователей с данного компьютера не планируется, значением данного параметра можно выставить любую неинтерактивную программу, обычно это /sbin/nologin. dmap gid = 15000-30000 idmap uid = 15000-30000 Значения этих параметров очень важны для работы winbindd. Они задают диапазоны идентификаторов пользователей и групп, выделяемых для сетевых пользователей. В указанных диапазонах не должно существовать локальных пользователей или пользователей YP/NIS. winbind use default domain = true Этот параметр определяет, как winbindd будет реагировать на имя пользователя, не содержащее домена. Если параметр указан, то winbindd будет подставлять workgroup= из smb.conf в качестве имени домена. Значение этого параметра практически не влияет на работу в сети Microsoft Windows, зато значительно облегчает работу по протоколам ftp, ssh, электронной почты и т. д., потому что не будет требоваться указание домена (user1 вместо MYDOMAINuser1). winbind separator = + Этот параметр задает разделитель между доменом и именем пользователя. Значением по умолчанию является «», но рекомендуется изменять параметр на что-нибудь другое, особенно, если планируется использование запросов к winbindd в скриптах. Символ «» воспринимается командной оболочкой как служебный и обязательно должен быть «экранирован», то есть отмечен таким образом, чтобы командная оболочка воспринимала его как обычный символ. При этом «экранирование» может проводиться неоднократно и определить нужное число символов становится весьма нетривиальной задачей. Samba-3 HOWTO рекомендует устанавливать еще два параметра: winbind enum users = yes winbind enum groups = yes По умолчанию эти значения уже установлены в «yes». Если база пользователей большая, рекомендуется отключить перенумерацию, то есть установить значения в «no». На что еще следует обратить внимание:
Настройка NSS выполняется правкой файла настройки nsswitch.conf. В него следует добавить или изменить следующие строчки: group: files winbind passwd: files winbind Более подробную информацию о формате файла nsswitch.conf и его возможностях можно получить из man nsswitch.conf и главы 21 Samba 3 HOWTO «Winbind: use of Domain accounts». Как проверить, правильно ли все настроено? Пример правильного вывода команды id был приведен выше. Если вместо этого появляется что-то типа: >id user2
при условии того, что пользователь user2 точно существует, значит, что-то настроено неправильно. Некоторые случаи, которые могут привести к такой ситуации, рассмотрены в разделе «Возможные ошибки». Настройка PAM Итак, теперь мы можем получить информацию о пользователях домена и использовать их имена точно так же, как имена локальных пользователей и групп, например, для раздачи прав: > ls -l
Пользователи Windows сразу узнают группу Domain Users – стандартную группу Microsoft Windows домена. Но это только еще половина дела. Регистрироваться с сетевой учетной записью мы все еще не можем, потому что службы аутентификации компьютера ничего не знают ни о сети Microsoft, ни об NSS. Службы аутентификации используют PAM и для решения второй части задачи следует создать необходимые конфигурационные файлы. Что такое PAM «...Pluggable Authentication Modules (PAM) – это набор API, который позволяет системным администраторам добавлять методы аутентификации простым подключением новых PAM-модулей, и модифицировать политики аутентификации простым редактированием конфигурационных файлов...» – так описан PAM в руководстве пользователя FreeBSD. PAM был разработан в Sun Microsystems в 1995 г. и с тех пор не претерпел больших изменений. FreeBSD 5.х использует спецификацию OpenPAM (в то время как FreeBSD 4.х использовала Linux-PAM), но для его изучения годится любая доступная документация. Все системные службы по умолчанию используют PAM – регистрируетесь ли вы на консоли, заходите ли на компьютер по ftp или ssh – соответствующая программа (login, ftp, sshd) считывает оглавление каталога /etc/pam.d, находит файл с именем, совпадающим с именем сервиса и получает из него информацию о том, какие модули и в каком порядке следует использовать для аутентификации пользователя и как обрабатывать их ответы. Перед тем как вносить какие-либо изменения в содержимое каталога /etc/pam.d, необходимо отметить следующие моменты:
Настройка регистрации с консоли Первое, что необходимо настроить, – это возможность зайти на компьютер с консоли. Конфигурационный файл PAM для регистрации на консоли уже существует. Он разбит на две части – файлы /etc/pam.d/login и /etc/pam.d/system. Файл /etc/pam.d/login нас не интересует, потому что содержит только стандартные строки и вызов файла /etc/pam.d/system. В файл /etc/pam.d/system вносим следующие изменения (в секцию auth): auth sufficient pam_unix.so no_warn try_first_pass nullok auth required pam_winbind.so use_first_pass Что нам это дает? Первая строка указывает PAM на необходимость использования модуля pam_unix, который выполняет аутентификацию по обычному файлу /etc/master.passwd. Дополнительные флаги указывают на то, что нужно запросить пароль у пользователя и что ввод пустой строки допустим. Условие suffcient вызовет прекращение проверки в случае успешной аутентификации. Таким образом, если пользователь присутствует в файле /etc/master.passwd (например, root), дальнейшая проверка по базе пользователей домена не выполняется. Вторая строка определяет использование модуля pam_winbind, который выполняет аутентификацию по базе домена Microsoft Windows. Флаг параметров указывает на то, что нужно использовать пароль, введенный по запросу предыдущего модуля, а не спрашивать его еще раз. Условие required устанавливает состояние «успешно, если следующие успешны». Поскольку следующих модулей нет, результат аутентификации будет определяться модулем pam_winbind. В случае ввода правильного пароля предоставляется доступ в систему и на консоли (а также в файле /var/log/console, если помещение сообщений в этот файл настроено) появляется сообщение:
Если пароль указан неверно или указано неверное имя пользователя, pam_winbind выдает соответствующие сообщения:
Настройка KDM Если компьютер используется как рабочая станция, то второй по важности будет возможность запустить графическую оболочку. В крайнем случае, конечно, можно воспользоваться «дедовским» методом и прямо из консольного обработчика команд запустить startx, прописав в .xinitrc «exec startkde» последней строчкой. Поэтому мы копируем файл /etc/pam.d/xdm (стандартный) в /etc/rc.d/kdm и вносим в него изменения, аналогичные описанным выше. После внесения изменений секция auth-файла /etc/pam.d/kdm должна выглядеть так: # auth auth required pam_nologin.so no_warn auth sufficient pam_unix.so no_warn try_first_pass nullok auth required pam_winbind.so use_first_pass Логика работы аутентификаторов будет в точности совпадать с логикой работы, описанной в предыдущем разделе. Настройка SSH При настройке SSH я позволил себе немножко схитрить. Не стал настраивать PAM для SSH, а вместо этого воспользовался возможностью SSH-аутентификации по публичному ключу. Поскольку SSH использует собственный перечень методов аутентификации, в котором метод publickey идет до метода password, проверка доступа с использованием PAM в таком случае не используется. Порядок настройки аутентификации по публичному ключу изложен в любой документации по SSH, а также в статье «Копирование файлов в автоматическом режиме с множества компьютеров через SSH», опубликованной в журнале №12, 2004 г. Если же использовать методы аутентификации, основанные на PAM, то необходимо создать файл /etc/pam.d/ssh2 (можно скопировать стандартный файл, например, xdm), в который вписать секцию auth приведенную выше, последовательность вызова модулей проверки доступа. Естественно, SSH должен быть собран с поддержкой PAM. Кроме того, конфигурационный файл сервера должен включать следующие строчки: AllowedAuthentications keyboard-interactive AuthKbdInt.Optional pam а конфигурационный файл клиента: AllowedAuthentications keyboard-interactive Настройка FTP В качестве FTP-сервера я использую ProFTPd из порта ftp/proftpd. Поддержка PAM в нем включена по умолчанию. Для ее использования нужно добавить в конфигурационный файл сервера proftpd.conf строчку: AuthPAM on Для включения сервиса proftpd создать файл /etc/pam.d/proftpd (можно скопировать стандартный файл ftp), доработать его так, как описано в разделе «Настройка регистрации с консоли». PAM не требует перезагрузки каких-либо демонов, поэтому проверить работоспособность конфигурации можно немедленно:
При этом на консоли отображается сообщение pam_ winbind о предоставлении доступа, приводимое выше, а в файле /var/log/ftpd – регистрация обычного ftp-сеанса. Настройка программы xlockmore Последним рассмотренным примером будет широко известная программа блокировки экрана xlockmore, выводящая при этом различные заставки. Xlockmore содержит около 50 различных заставок, в том числе трехмерных. При запуске блокируются клавиатура и экран, и выводится заставка во время неактивности и пояснительный текст при нажатии любой клавиши. (Внизу отображается содержимое файла .signature, если он присутствует в домашнем каталоге). Для разблокировки экрана следует ввести пароль, который программа проверяет либо по локальной базе пользователей, либо с использованием PAM. Xlockmore по умолчанию не использует PAM. Для включения его использования необходимо дописать в Makefile порта в строчку CONFIGURE_ARGS ключ --enable-pam и пересобрать программу. При этом следует иметь в виду, что ключи --enable-pam и --with-xlock-group почему-то являются взаимоисключающими – при их одновременном разрешении сборка программы завершается с ошибкой. Для использования PAM следует создать файл /etc/pam.d/xlock (можно скопировать стандартный файл xdm) и изменить его, как показано в разделе «Настройка регистрации с консоли». Следует учитывать то, что программа пропускает только нажатие клавиши переключения раскладок, при этом факт переключения раскладки нигде не отображается, все остальные (в том числе Enter, ESC и пр.) – интерпретируются как часть пароля! Дополнительное ограничение Теперь мы можем регистрироваться в системе с доменной учетной записью. Но ведь теперь это же могут делать и все пользователи домена! Такая свобода нам вовсе ни к чему, поэтому настроим дополнительное ограничение – возможность использования некоторого сервиса только членам определенной локальной группы. В этом нам опять поможет PAM. Существует стандартный модуль pam_group, который решает именно такую задачу, – аутентификация успешна, только если пользователь входит в некую локальную группу. Если его включить в цепочку аутентификаторов, задача должна быть решена. На практике все оказалось не так-то просто. Модуль почему-то упорно отказывался работать, несмотря на явную правильность задания параметра. После некоторого исследования был создан патч для модуля, после наложения которого все начинает работать, как ожидалось. Патч приведен ниже: --- pam_group.c.old Tue Dec 14 19:38:56 2004 +++ pam_group.c Tue Dec 14 19:38:56 2004 @@ -70,7 +70,7 @@ return (PAM_IGNORE); /* get applicant */ - if (pam_get_item(pamh, PAM_RUSER, &ruser) != PAM_SUCCESS + if (pam_get_item(pamh, PAM_USER, &ruser) != PAM_SUCCESS || ruser == NULL || (pwd = getpwnam(ruser)) == NULL) return (PAM_AUTH_ERR); Итоговая логика работы аутентификаторов такова (на примере файла для сервиса kdm): # auth auth required pam_nologin.so no_warn auth sufficient pam_unix.so no_warn try_first_pass nullok auth required pam_group.so group=ntstaff auth required pam_winbind.so use_first_pass Если существует файл /var/run/nologin (это проверяется модулем pam_nologin), то доступ будет запрещен, независимо от результата работы прочих модулей (required). Если pam_nologin разрешает доступ, то устанавливается состояние «разрешить доступ, если не было запретов от других модулей». Если pam_unix разрешает доступ (это означает, что пользователь существует в локальной базе пользователей), то обработка цепочки прекращается, доступ будет предоставлен. Иначе результат pam_unix игнорируется (sufficient). Если пользователь присутствует в локальной группе ntstaff, pam_group разрешает доступ, и состояние «разрешить доступ, если не было запретов от других модулей» сохраняется. Иначе же доступ будет запрещен, независимо от результата работы прочих модулей (required). Если pam_winbind разрешает доступ и состояние «разрешить доступ, если не было запретов от других модулей» сохранилось, то доступ будет предоставлен, в противном случае доступ предоставлен не будет. Иначе говоря, если присутствуют модули с условием required, то результат их работы обьединяется по «и» – доступ будет предоставлен, только если все модули предоставили доступ. Возможные ошибки Ошибки Winbindd Если настройка winbindd была выполнена, но команда id user2 не выдает информацию о группах, в которые входит пользователь, а выдает что-то типа: >id user2
следует проверить следующие вещи:
Ошибки PAM Ошибки PAM диагностировать значительно труднее, потому что практически отсутствуют средства их обнаружения. Для диагностирования работы цепочек можно использовать модуль pam_echo, который выводит на экран передаваемые ему параметры (а также значения макроподстановок. Что можно получить через макросы, указано в man pam_echo). С чем могут быть связаны ошибки PAМ:
Необходимо точное понимание того, как условия required, requisute, sufficient и прочие воздействуют на цепочку. Неверное построение цепочки может привести к тому, что доступ не будет предоставлен при правильных условиях или будет предоставлен при неверных условиях. Заключение Данная статья рассматривает как на одну небольшую ступеньку приблизить ваш компьютер к «FreeBSD Desktop». Исключение необходимости создания локального юзера для работы за компьютером, входящим в домен Microsoft Windows – маленький, но полезный шаг в этом направлении. Литература:
|
РАШИД АЧИЛОВ
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
