FreeBSD в домене Microsoft Windows::Журнал СА 3.2005
www.samag.ru
Льготная подписка для студентов      
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
О журнале
Журнал «БИТ»
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Вакансии
Контакты
   

Jobsora

ЭКСПЕРТНАЯ СЕССИЯ 2019


  Опросы

Какие курсы вы бы выбрали для себя?  

Очные
Онлайновые
Платные
Бесплатные
Я и так все знаю

 Читать далее...

1001 и 1 книга  
28.05.2019г.
Просмотров: 1826
Комментарии: 2
Анализ вредоносных программ

 Читать далее...

28.05.2019г.
Просмотров: 1887
Комментарии: 1
Микросервисы и контейнеры Docker

 Читать далее...

28.05.2019г.
Просмотров: 1446
Комментарии: 0
Django 2 в примерах

 Читать далее...

28.05.2019г.
Просмотров: 1066
Комментарии: 0
Введение в анализ алгоритмов

 Читать далее...

27.03.2019г.
Просмотров: 1636
Комментарии: 1
Arduino Uno и Raspberry Pi 3: от схемотехники к интернету вещей

 Читать далее...

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

 FreeBSD в домене Microsoft Windows

Архив номеров / 2005 / Выпуск №3 (28) / 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

uid=1001(user1) gid=999(user1) groups=999(user1), 0(wheel), 20(staff), 69(network), 70(pgsql)

Программа id вызывает системную функцию getuid() для получения информации о пользователе, логин которого задан в командной строке. Порядок получения информации функцией getuid() во FreeBSD версий 4.х и 5.х приведен на рисунке.

Рисунок 1

Getuid() обращается к единственному источнику информации – локальной базе пользователей – файлу master.passwd для получения данных и выдает ответ, показанный выше. Теперь мы вводим команду id в системе, которая подключена к домену Microsoft Windows надлежащим образом:

> id user1

uid=15020(user1) gid=15001(Domain Users) groups=15001(Domain Users), 15011(Consultant users), 15014(LaserJet 1100 users), 15017(Production Users)

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 для обеспечения возможности работать с доменом Microsoft Windows.
  • Настройке PAM для обеспечения работоспособности различных сервисов. Мы рассмотрим только несколько наиболее часто используемых сервисов: login, kdm, ftp, ssh и xlock. При необходимости прочие сервисы могут быть настроены по образцу.

Настройка 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 выполняет это действие автоматически. Стандартное решение мне неизвестно, нестандартных же способов есть несколько:

  • Завести локального пользователя «_dummy» и вручную копировать домашний каталог всем создаваемым сетевым пользователям с последующим изменением владельца файлов.
  • Использовать возможность PAM session. Данный элемент настроек PAM обычно используется для занесения записей о начале сессии в файлы utmp/wtmp.

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».

На что еще следует обратить внимание:

  • Samba по умолчанию собирается с winbindd, поэтому во время сборки пакета не отключайте эту опцию!
  • По умолчанию файлы динамических библиотек nss_win- bind.so, pam_winbind.so, nss_wins.so и pam_smbpass.so (если его сборка была запрошена опцией PAM_ SMBPASS) помещаются в каталог /usr/local/lib. Если расположение каталогов меняется, необходимо убедиться, что каталог, в котором размещены данные файлы, входит в LDCONFIG_PATH.
  • Берегите базу IDMAP, после того как были розданы права на локальные файлы (допустим, создан профиль KDE, загружены документы, и т. д.). База IDMAP содержит соответствие между учетной записью домена и локальным UID/GID, которые будут вписываться в права на файл, как владелец и группа владельцев. Если база IDMAP была случайно утеряна, то при следующем обращении она будет создана заново, но соответствие между учетной записью и UID будет нарушено (первый пользователь, о котором была запрошена информация, получает UID = idmap uid, второй = idmap uid + 1 и т. д.) и можно обнаружить, что ваш домашний каталог принадлежит другому пользователю. База IDMAP содержится в двух файлах – /var/db/samba/winbind_groups.tdb и /var/db/samba/winbind_idmap.tdb.

Настройка 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

id: user2: no such user

при условии того, что пользователь user2 точно существует, значит, что-то настроено неправильно. Некоторые случаи, которые могут привести к такой ситуации, рассмотрены в разделе «Возможные ошибки».

Настройка PAM

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

> ls -l

total 1468

drwx------   3 shelton  Domain Users    1024 19 Dec 14:27 Desktop/

drwx------  18 shelton  Domain Users    3584 13 Feb 22:54 Mail/

drwxr-xr-x   2 shelton  Domain Users    1024 14 Jan  2002 RFC/

drwx------  10 shelton  Domain Users    1024 11 Feb 14:49 documents/

Пользователи 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 довольно-таки запутанная и терминологически неустоявшаяся область, поэтому настоятельно рекомендуется ознакомиться с какой-нибудь документацией по PAM, перед тем как пытаться в нем что-то самостоятельно изменить.
  • Обязательно сохраните копию каталога /etc/pam.d до того, как начнете вносить в него изменения! (Этот совет в неизменном виде кочует из одной статьи по PAM в другую потому что авторы, как правило, на своей шкуре убедились в его правильности).
  • Для внесения изменений в конфигурацию не нужно ни перегружать систему, ни перезапускать какие-либо сервисы – файл конфигурации сервиса считывается с диска в момент запроса к данному сервису, поэтому всё время, пока идут эксперименты с PAM, держите открытой как минимум одну консоль с правами root для внесения изменений, если что-то вдруг пойдет не так. Одно неверное движение – и можно уже не попасть в систему иначе как в однопользовательском режиме.

Настройка регистрации с консоли

Первое, что необходимо настроить, – это возможность зайти на компьютер с консоли. Конфигурационный файл 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, если помещение сообщений в этот файл настроено) появляется сообщение:

Feb  7 18:06:31 sentry kernel: Feb  7 18:06:31 sentry pam_winbind[23340]: user "shelton" granted access

Если пароль указан неверно или указано неверное имя пользователя, pam_winbind выдает соответствующие сообщения:

Feb 12 19:52:03 sentry kernel: Feb 12 19:52:03 sentry pam_winbind[55953]: request failed: No such user, PAM error was 13, NT error was NT_STATUS_NO_SUCH_USER

Feb 14 09:04:16 sentry kernel: Feb 14 09:04:16 sentry pam_winbind[43263]: request failed: Wrong Password, PAM error was 9, NT error was NT_STATUS_WRONG_PASSWORD

Feb 14 09:04:16 sentry kernel: Feb 14 09:04:16 sentry pam_winbind[43263]: user `shelton" denied access (incorrect password or invalid membership)

Настройка 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 не требует перезагрузки каких-либо демонов, поэтому проверить работоспособность конфигурации можно немедленно:

Connected to localhost.granch.ru.

220 Private FTP server by some porgrammer from Granch Ltd.

Name (localhost:shelton): shelton

331 Password required for shelton.

Password: ********

230 User shelton logged in.

Remote system type is UNIX.

Using binary mode to transfer files.

ftp>

При этом на консоли отображается сообщение 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

id: user2: no such user

следует проверить следующие вещи:

  • winbindd запущен (несмотря на всю тривиальность данного совета);
  • winbindd настроен правильно (параметры template shell, template homedir, idmap uid, idmap gid не имеют значений по умолчанию!);
  • команды wbinfo -p и wbinfo -t выдают успешные результаты (подробнее см. man wbinfo);
  • компьютер входит в домен;
  • доступен как минимум один контроллер домена, если указано password server = * или компьютер, указанный как сервер паролей в параметре password server;
  • каталог, в котором находится файл nss_winbind.so присутствует в переменной LDCONFIG_PATH (в особенности если это нестандартный каталог);
  • отсутствие сообщений об ошибках в файлах log.smbd, log.nmbd и log.winbindd, а также на консоли (например, файл nss_wins.so, предназначенный для поиска компьютеров по NetBIOS-имени, запустить не удалось из-за постоянной непонятной ошибки).

Ошибки PAM

Ошибки PAM диагностировать значительно труднее, потому что практически отсутствуют средства их обнаружения. Для диагностирования работы цепочек можно использовать модуль pam_echo, который выводит на экран передаваемые ему параметры (а также значения макроподстановок. Что можно получить через макросы, указано в man pam_echo).

С чем могут быть связаны ошибки PAМ:

  • каталог с файлом pam_winbind.so отсутствует в переменной LDCONFIG_PATH;
  • неверные условия для какого-либо модуля из цепочки;
  • неверное построение цепочки.

Необходимо точное понимание того, как условия required, requisute, sufficient и прочие воздействуют на цепочку. Неверное построение цепочки может привести к тому, что доступ не будет предоставлен при правильных условиях или будет предоставлен при неверных условиях.

Заключение

Данная статья рассматривает как на одну небольшую ступеньку приблизить ваш компьютер к «FreeBSD Desktop». Исключение необходимости создания локального юзера для работы за компьютером, входящим в домен Microsoft Windows – маленький, но полезный шаг в этом направлении.

Литература:

  1. http://www.freebsd.org/doc/en_US.ISO8859-1/articles/pam/article.html – Pluggable Authentication Modules by Dag-Erling Smorgrav, 2003 г.
  2. http://www.onlamp.com/pub/a/bsd/2003/02/06/FreeBSD_Basics.html – PAM by Dru Lavinge, 2003 г.
  3. The Offifical Samba-3 HOWTO and reference guide. Jelmer R. Vernooij, John H. Terpstra, Gerald (Jerry) Carter, 2004 г.
  4. Samba-3 by example. John H. Terpstra, 2004 г.
  5. SSH Secure Shell for Server version 3.2.9 Administrators Guide. SSH Communications Secuirty Corp., 2003 г.
  6. man pam_echo, man pam_group, man pam.conf, man smb.conf, man pam_winbind, man sshd.conf.

Комментарии отсутствуют

Добавить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru