Аппаратные средства и архитектура



Скачать 10.18 Mb.
Pdf просмотр
страница43/68
Дата22.11.2016
Размер10.18 Mb.
Просмотров7296
Скачиваний0
1   ...   39   40   41   42   43   44   45   46   ...   68
Миграция с NIS на LDAP
В этом разделе описывается материал по теме 305.2 экзамена на профессионала Linux высокого уровня (LPIC-3) 301. Эта тема обладает весом 1.
Из этого раздела вы узнаете, как:

Анализировать структуру NIS перед миграцией на LDAP

Анализировать структуру NIS перед интеграцией с LDAP

Автоматизировать миграцию из NIS на LDAP

Создавать шлюз с NIS на LDAP
Служба NIS является традиционным методом централизованной аутентификации
UNIX-машин; она просто настраивается и хорошо работает. Хотя аутентификация LDAP является более сложной, она имеет следующие преимущества по сравнению с NIS:

LDAP безопаснее, чем NIS, поскольку позволяет шифровать трафик и ограничивать доступ к базе данных.

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

LDAP поддерживает большее количество клиентов, чем NIS.
Вы можете полностью заменить NIS на LDAP или использовать их одновременно. В последнем случае LDAP будет являться каноническим источником данных, а сервер NIS будет использовать данные LDAP вместо локальных файлов. Этот метод хорошо подходит для долговременной миграции или для поддержки старых операционных систем, которые не смогут работать с LDAP.
Первый подход: миграция на LDAP
Основные действия при выполнении миграции с NIS на LDAP заключаются в следующем:
1. Определить, какие базы данных NIS необходимо заменить.
2. Загрузить данные NIS в LDAP.
3. Перенастроить клиенты на использование LDAP вместо NIS.
В промежуток времени между началом шага 2 и завершением шага 3 вы будете иметь две активные базы данных, к которым не выполнено подключений. Любые изменения, такие как добавление пользователя или изменения его пароля, должны производиться в обеих базах данных, иначе в ваших данных могут возникнуть противоречия. Вы можете "заморозить" все изменения или же воспользоваться стратегией интеграции, описанной в следующем разделе.

Анализ существующей структуры NIS
Перед тем как начать миграцию, вы должны определить, какие базы данных управляются службой NIS. Подключитесь к главному серверу NIS и просмотрите каталог базы данных. В большинстве операционных систем файлы хранятся в каталоге /var/yp/имя_домена.
Листинг 5. Определение баз данных, обслуживаемых NIS
# ls /var/yp/`domainname` group.bygid group.byname hosts.byaddr hosts.byname mail.aliases netid.byname passwd.byname passwdbyuid protocols.byname protocols.bynumber rpc.byname rpc.bynumber services.byname services.byservicename ypservers
В листинге 5 используется команда domainname для отображения имени домена. Когда команда заключена в обратные кавычки (`), результат ее выполнения вставляется в командную строку. За исключением файла ypservers, каждый файл в этом каталоге представляет собой базу данных NIS. Составьте список уникальных имен баз данных, чтобы определить, какие из них должны быть перемещены в LDAP. NIS хранит одни и те же данные с различными ключами поиска, такими как поиск по имени и поиск по идентификатору пользователя (UID), как, например, в случае с файлом паролей; в данном случае обе базы представляют собой базу данных паролей. Другие случаи могут быть неочевидными: например, mail.aliases - это таблица псевдонимов aliases. Если вы сомневаетесь, загляните в файл /var/yp/Makefile, чтобы определить источник базы данных.
После того как вы проверите сервер, вы можете захотеть проверить некоторые из ваших
NIS-клиентов, чтобы определить, какие таблицы сопоставлений они используют. Для этого ищите ключевое слово nis в файле /etc/nsswitch.conf. Вероятно, вы обнаружите, что ваш сервер хранит больше таблиц сопоставления по сравнению с используемыми.
Использование инструментов миграции
Самыми популярными инструментами для миграции данных NIS в LDAP являются инструменты, разработанные программистами компании PADL software – авторами pam_ldap, nss_ldap и шлюза NIS-LDAP, речь о котором пойдет позднее. С большой вероятностью эти инструменты включены в ваш дистрибутив; если же нет, то ссылки на них вы можете найти в разделе
Ресурсы
. Инструменты миграции от PADL могут получать данные из локальных файлов, NIS или NIS+ и загружать их на ваш сервер LDAP.
Перед началом использования инструментов PADL у вас должен быть работающий сервер
LDAP, не содержащий никаких данных. Все необходимые записи будут сгенерированы автоматически, а вы избежите дублирования записей.
Инструменты миграции состоят из набора shell- и perl-скриптов. В системах RedHat скрипты являются частью пакета openldap-servers, и их можно найти в каталоге

/usr/share/openldap/migration. Пользователи Debian также могут захотеть получить пакет migrationtools. Ищите файл под названием migrate_base.pl или загрузите последнюю версию с Web-сайта PADL.
Эти скрипты получают данные из различных источников, конвертируют их в LDIF-формат и затем добавляют их на ваш сервер. Данные добавляются с помощью команды ldapadd в онлайновом режиме, а также с помощью команды slapadd – в автономном режиме, поэтому в первом случае вам понадобятся административные учетные данные, а во втором случае вам придется остановить сервер LDAP.
Предварительно может быть полезно настроить некоторые переменные среды, задав имена базового домена (DN) дерева и учетной записи администратора (root DN). В листинге 6 показаны команды оболочки bash для подготовки к миграции домена ertw.com.
Листинг 6. Настройка переменных среды для подготовки к миграции в LDAP
export LDAP_BASEDN="dc=ertw,dc=com"
export LDAP_BINDDN="cn=root,dc=ertw,dc=com"
export LDAP_DEFAULT_MAIL_DOMAIN=ertw.com
Первая строка в листинге 6 – это отличительное имя базового объекта (base DN) дерева
LDAP, которое позже будет использоваться для генерации всех отличительных имен. Вторая строка – это имя административной учетной записи root (root DN). Пароль вам понадобится только в том случае, если вы используете онлайновый режим. Последняя строка задает имя домена по умолчанию для адресов электронной почты. Некоторые из утилит не будут запрашивать у вас эту информацию, поэтому, указав все необходимые сведения здесь, вы оградите себя от проблем, которые могут возникнуть позже.
Утилиты разделены на две категории. Названия файлов первой из них начинаются с migrate_all_. Во вторую категорию включены все оставшиеся файлы, имена которых начинаются на migrate_ и содержат название файла или базы данных. Скрипты, входящие в первую категорию, используются для сбора данных в единое целое, а скрипты из второй категории предназначены для преобразования данных из исходного формата в LDIF-формат.
У вас есть два варианта. Вы можете использовать один из скриптов migrate_all_, который автоматически соберет данные всех общих баз данных из указанного местоположения (NIS, файлы, NIS+m, и так далее), или же вы можете самостоятельно собрать только нужные вам данные и использовать отдельные скрипты для их преобразования в LDIF. Первый способ, если он работает, является более простым. В листинге 7 показано использование скрипта migrate_all_nis_online.sh для выполнения миграции всех данных из NIS в каталог LDAP в онлайновом режиме.
Листинг 7. Выполнение миграции данных с NIS на LDAP с использованием скрипта
migrate_all_nis_online.sh
[root@server1 migration]# ./migrate_all_nis_online.sh
Enter the NIS domain to import from (optional):
No such map networks.byaddr. Reason: Internal NIS error
Enter the hostname of your LDAP server [ldap]: localhost
Enter the credentials to bind with: mypassword
Do you wish to generate a DUAConfigProfile [yes|no]? no
Importing into dc=ertw,dc=com...

Creating naming context entries...
Migrating groups...
Migrating hosts...
Migrating networks...
Migrating users...
Migrating protocols...
Migrating rpcs...
Migrating services...
Migrating netgroups...
Migrating netgroups (by user)...
sh: /etc/netgroup: No such file or directory
Migrating netgroups (by host)...
sh: /etc/netgroup: No such file or directory adding new entry "dc=ertw,dc=com"
Importing into LDAP...
adding new entry "ou=Hosts,dc=ertw,dc=com"
..... output omitted ...
adding new entry "cn=rquotad,ou=Rpc,dc=ertw,dc=com"
adding new entry "cn=rquotad,ou=Rpc,dc=ertw,dc=com"
ldap_add: Already exists (68)
/usr/bin/ldapadd: returned non-zero exit status: saving failed LDIF to
/tmp/nis.ldif.X17515
Листинг 7 начинается с запуска скрипта migrate_all_nis_onlinesh, который собирает данные
NIS, преобразует их в LDIF-формат и затем использует команду ldapadd для импорта данных. Сначала скрипт запрашивает имя NIS-домена; вы можете нажать клавишу Enter, если используете в системе NIS-домен по умолчанию. Затем скрипт импортирует данные NIS
(в этой системе была возвращена некритическая ошибка, поскольку таблица networks не использовалась). Далее скрипт предлагает ввести информацию о сервере LDAP, такую как имя хоста и пароль (имя для привязки (bind DN) и имя базового объекта (base DN) получены из переменных среды, которые были указаны в листинге 6). Не следует соглашаться на выполнение импорта объекта
DUAConfigProfile, если у вас нет поддерживающей эту функцию схемы, что маловероятно.
Если на этом этапе вы начнете получать ошибки, сообщающие о неправильном синтаксисе отличительных имен, убедитесь, что вы импортировали файл nis.schema внутри slapd.conf.
Если ваша схема не содержит ошибок, будет выполнен импорт данных в ваш каталог LDAP.
Существует вероятность того, что выполнение скрипта закончится с ошибкой, подобной той, что показана в конце листинга 7. Из-за способа хранения данных в NIS вы можете получить задублированные записи в некоторых базах данных. Это нормально для NIS, но не для LDAP.
Ниже представлено несколько способов решения этой проблемы в зависимости от ваших задач:

Отредактируйте LDIF-файл (в данном случае /tmp/nis.ldif.X17515), чтобы удалить задублированные данные, а затем удалите вашу базу данных LDAP и импортируйте файл.

Укажите команде ldapadd игнорировать ошибки, используя для этого параметр -c: export LDAPADD="/usr/bin/ldapadd -c" (заметьте, что скрипт все равно сообщит об ошибке, но данные будут импортированы).

Отредактируйте скрипт migrate_all_nis_online.sh и установите переменные

ETC_SERVICES, ETC_PROTOCOLS и ETC_RPC равными /dev/null вместо использования временного файла. Это приведет к тому, что база данных будет исключена из обработки (обратите внимание на то, что переменные некоторых из скриптов migrate_all_ могут быть переопределены переменными среды, но не вариантом NIS).

Не запускайте скрипт migrate_all_nis_online.sh и выполните миграцию вручную.
Первые три способа говорят сами за себя и эффективны в тех случаях, когда вас устраивают результаты (такие как отсутствие в каталоге LDAP протоколов, RPC и служб, как в третьем случае). Четвертый способ требует некоторых разъяснений.
Если все, что вам нужно – это переместить в LDAP пользователей и группы, вы можете самостоятельно скопировать файлы и сгенерировать LDIF с помощью других скриптов, и использовать ypcat для извлечения данных из NIS. Этот процесс показан в листинге 8.
Листинг 8. Выполнение миграции пользователей и групп вручную
[root@server1 migration]# ypcat passwd > /tmp/passwd.tmp
[root@server1 migration]# ypcat group > /tmp/group.tmp
[root@server1 migration]# ./migrate_base.pl > /tmp/ldif
[root@server1 migration]# ./migrate_passwd.pl /tmp/passwd.tmp >> /tmp/ldif
[root@server1 migration]# ./migrate_group.pl /tmp/group.tmp >> /tmp/ldif
[root@server1 migration]# ldapadd -x -D "cn=root,dc=ertw,dc=com" \
-w "mypassword" -f /tmp/ldif adding new entry "dc=ertw,dc=com"
adding new entry "ou=Hosts,dc=ertw,dc=com"
..... дальнейший вывод опущен ...
В первых двух строках листинга 8 используется команда ypcat для выгрузки данных NIS в файлы, расположенные в каталоге /tmp. Следующие три строки генерируют LDIF. Команда migrate_base создает некоторые основные элементы дерева каталога, а следующие две строки преобразуют файлы password и group в LDIF-формат. Обратите внимание на использование оператора >>, благодаря чему, результирующий файл будет содержать вывод всех трех скриптов миграции. Наконец, происходит вызов команды ldapadd для импортирования данных.
Независимо от того, каким способом миграции вы воспользуетесь, сделайте несколько простых запросов, чтобы убедиться, что вы можете видеть все данные. Убедитесь, что вы можете видеть хэши паролей (для этого используйте учетную запись администратора root
DN, поскольку ваш список контроля доступа может не позволять просматривать пароли).
На этом этапе все данные NIS находятся в каталоге LDAP. До тех пор, пока будут использоваться ваши NIS-клиенты, все изменения в NIS должны реплицироваться в LDAP и наоборот.
Перемещение клиентов и проверка результатов
Перенастройка клиентов – довольно простая задача, заключающаяся в настройке NSS и PAM на клиенте. Об этом детально рассказывалось в предыдущем разделе
. Вкратце, вы указываете в файле /etc/ldap.conf информацию о вашем сервере и редактируете файл/etc/nsswitch.conf, заменяя в нем nis на ldap. Если вы настраиваете PAM, вам понадобится отредактировать соответствующие файлы в директории /etc/pam.d и добавить в них ссылки на модуль pam_ldap.so.
На каждом клиентском компьютере войдите в систему под учетной записью обычного
пользователя и выполните команду getent для баз данных, которые вы переместили в
LDAP.
Второй подход: интеграция с LDAP
Второй подход основан на совместном использовании NIS и LDAP. Это может оказаться полезным, если у вас имеются клиенты, которые не понимают LDAP (не имеют собственного модуля LDAP или не поддерживают PAM), или если вы хотите осуществлять переход на
LDAP в течение длительного срока. Основные действия в случае совместного использования
NIS/LDAP почти такие же, что и в случае перехода от NIS к LDAP:
1. Определить, какие базы данных NIS используются.
2. Загрузить данные NIS в LDAP.
3. Заменить ваши серверы NIS на ypldapd.
4. Перенастроить клиенты на использование LDAP.
Для клиентов, которые будут продолжать использовать NIS, не требуется никаких изменений, поскольку ypldapd является полнофункциональным сервером NIS. Единственное отличие между ним и стандартным сервером ypserv, входящим в состав вашей операционной системы, заключается в том, что ypldapd получает данные из каталога LDAP, а не из локальных файлов.
Первые два шага аналогичны тем, что были описаны в первом случае, поэтому начнем с шага
3.
Замена серверов NIS на ypldapd
ypldapd представляет собой демон сервера NIS, использующий получения данных LDAP, а не файлы баз данных из каталога /var/yp. Это коммерческий программный продукт от компании PADL, но вы можете получить 30-дневную пробную лицензию, связавшись с PADL по электронной почте (обратитесь к разделу
Ресурсы
). Установить ypldapd достаточно просто:
1. Распакуйте tar-архив в каталог /opt/ypldapd.
2. Скопируйте лицензию в файл /opt/ypldapd/etc/padlock.ldif.
3. Отредактируйте конфигурационный файл /opt/ypldapd/etc/ypldapd.conf.
4. Остановите существующий сервер NIS.
5. Запустите ypldapd.
Сначала выполните команду mkdir -p /opt/ypldapd от имени пользователя root, чтобы создать каталог ypldapd (а также каталог /opt, если он не существует). Перейдите в этот каталог (
cd /opt/ypldapd) и распакуйте tar-файл дистрибутива ypldapd с помощью команды tar -xzf /tmp/ypldapd_linux-i386.tar.gz. В результате файлы ypldapd будут помещены в соответствующий каталог.
Вам будет предоставлена лицензия, которую вы поместите в файл
/opt/ypldapd/etc/padlock.ldif. Если вы получили ее по электронной почте, убедитесь, что ваш почтовый клиент не разрывает длинные строки: ключ должен содержать четыре строки, состоящих из пар атрибут:значение.
Конфигурационный файл ypldapd должен располагаться в каталоге
/opt/ypldapd/etc/ypldapd.conf. В этом каталоге вы обнаружите файл ypldapd.conf.sample, который вы можете скопировать и использовать как основу. Как и в случае с другими утилитами, с которыми вы имели дело до сих пор, вам потребуется указать информацию о вашем сервере LDAP. В листинге 9 показан пример файла ypldapd.conf.
Листинг 9. Пример файла ypldapd.conf

# Имя NIS-домена ypdomain ertw
# Сервер LDAP и отличительное имя базового объекта (base DN)
ldaphost localhost basedn dc=ertw,dc=com
# Учетные данные… Пользователь должен иметь разрешение на чтение атрибута userPassword binddn cn=ypldapd,dc=ertw,dc=com bindcred mypassword
# Сопоставление баз данных NIS с отличительными именами DN (относительно basedn)
# Если вы использовали инструменты миграции, у вас не должно возникнуть
# необходимости что-либо менять namingcontexts namingcontexts.conf
# Должен ли ypldapd кэшировать данные?
caching on
# Время жизни кэша в минутах cache_dump_interval 15
# Должен ли пароль быть скрыт?
hide_passwords off
# Сколько серверов ypldapd могут работать одновременно?
maxchildren 5
Когда ваш файл ypldapd.conf будет готов, вы можете остановить все экземпляры ypserv и выполнить команду sbin/ypldapd, которая запустит ypldapd в фоновом процессе.
Перемещение клиентов и проверка результатов
Для проверки вашего нового сервера NIS выполните команду ypwhich, которая покажет, к какому серверу NIS вы привязаны. Если вы получите ошибку, убедитесь, что не запущены никакие другие экземпляры ypserv, и что выполняется только один демон ypldapd. После этого попытайтесь получить таблицу сопоставления, выполнив команду ypcat passwd
(при условии, что на сервере также запущен и клиент).
Клиенты, которые будут продолжать использовать NIS, должны также уметь выполнять на новом сервере команды ypwhich и ypcat. Команды для клиентов, которые полностью перейдут на использование LDAP, приведены в разделе о миграции.
Интеграция LDAP и служб UNIX
В этом разделе описывается материал по теме 305.3 экзамена на профессионала Linux высокого уровня (LPIC-3) 301. Эта тема обладает весом 1.
Из этого раздела вы узнаете, как:

Интегрировать SSH и LDAP

Интегрировать FTP и LDAP

Интегрировать HTTP и LDAP

Интегрировать FreeRADIUS и LDAP

Интегрировать службы печати и LDAP
Большинство приложений будут корректно работать с LDAP, если вы настроили NSS и PAM.
Некоторым приложениям необходимо указать на использование PAM или обеспечить дополнительный функционал для правильного доступа к LDAP. В этом разделе мы сосредоточимся на рассмотрении распространенных служб UNIX, а также того, каким образом эти службы поддерживают интеграцию с LDAP.
Интеграция SSH и LDAP
OpenSSH интегрируется с LDAP через PAM, если дистрибутив был скомпилирован с поддержкой необходимого функционала. Запустите команду ldd /usr/sbin/sshd |
grep pam, чтобы проверить, были ли выполнена компоновка с поддержкой совместно используемых библиотек PAM. Если нет, необходимо перекомпилировать sshd с параметром
--with-pam.
Для использования PAM убедитесь, что у вас имеется конфигурационный PAM-файл с именем /etc/pam.d/sshd. В листинге 10 показан пример PAM-файла, использующего стек system-auth.
Листинг 10. Пример файла /etc/pam.d/system-auth
auth required pam_stack.so service=system-auth account required pam_stack.so service=system-auth password required pam_stack.so service=system-auth session required pam_stack.so service=system-auth
Когда ваш конфигурационный PAM-файл будет готов, вы можете настроить sshd для работы с PAM. В файле /etc/ssh/sshd_config добавьте строку
UsePAM yes и перезапустите sshd.
Интеграция FTP и LDAP
Существует множество демонов FTP, и неясно, какие из них фигурируют в экзамене LPIC 3.
Простейшим методом интеграции является метод, основанный на использовании интеграции
NSS. Когда FTP-сервер выполняет проверку пароля, функционал NSS использует LDAP.
Как правило, современные FTP-серверы поддерживают PAM. В этом случае вы создаете ваш конфигурационный PAM-файл в каталоге /etc/pam.d. Обычно этот файл называется ftp, но в зависимости от конкретной программы и от дистрибутива он может называться иначе.
Например, RedHat указывает демону vsftpd использовать файл /etc/pam.d/vsftpd вместо файла по умолчанию /etc/pam.d/ftp.
Как только демон ftp находит свой конфигурационный PAM-файл, он обрабатывает его так же, как и любой другой PAM-клиент. Конфигурации, приведенной в листинге 10, достаточно для запуска демона.Также можно использовать параметры pam_listfile.so item=user sense=deny file=/etc/ftpusers onerr=succeed и pam_shells на стадии auth, чтобы ограничить круг пользователей, которые могут подключаться, и доступные оболочки, наподобие того, как это делали старые FTP-серверы.
Интеграция HTTP и LDAP
В состав Web-сервера Apache входят модули, выполняющие базовую HTTP-аутентификацию с использованием хранилища LDAP вместо традиционного файлового хранилища htpasswd. Этот функционал реализуется через модули mod_authnz_ldap и mod_ldap.
Первый модуль предоставляет механизмы для аутентификации Web-пользователя с использованием данных LDAP; второй модуль, mod_ldap, предоставляет интерфейс доступа к LDAP для модуля mod_authnz_ldap (или для всех будущих модулей на основе
LDAP), включая объединение и кэширование подключений.
Все инструкции в этом разделе относятся к Apache версии 2.2. Если вы используете Apache
2.0, вместо модуля mod_authnz_ldap используется модуль mod_auth_ldap.
Конфигурации этих двух модулей одинаковы.
Оба модуля – mod_ldap и mod_authnz_ldap являются частью дистрибутива Apache.
Если вы компилируете Web-сервер вручную, необходимо указать параметры
--enable-authnz-ldap --enable-ldap при выполнении команды configure. Если вы используете версию Apache из своего дистрибутива, установите соответствующий модуль
(в дистрибутивах Red Hat модули являются частью базового пакета httpd).

Когда пользователь выполняет запрос к защищенному ресурсу, Apache возвращает код ошибки 401 (unauthorized). В этот момент Web-обозреватель должен предложить пользователю ввести имя и пароль. После этого обозреватель выполняет повторный запрос, содержащий полученную информацию, зашифрованную в заголовке
Authorization. Если имя пользователя и пароль принимаются Web-сервером, пользователь получает доступ к странице, в противном случае сервер снова возвращает код ошибки 401.
Когда Apache настроен на проверку паролей, хранящихся в LDAP, он сначала привязывается к серверу, используя заранее определенную учетную запись, и ищет полученное отличительное имя DN пользователя. Затем сервер выполняет повторную привязку в качестве этого пользователя, используя полученный пароль. Если сервер успешно привязывается к серверу с использованием учетных данных этого пользователя, аутентификация считается успешной.
После аутентификации пользователя сервер может выполнять дополнительные задачи, такие как проверка имени DN или атрибута, или результатов прохождения пользователем поискового фильтра. Если настроена какая-либо из таких проверок, то она должна быть успешно пройдена для того, чтобы авторизация также считалась успешной.
Настройка модуля mod_authnz_ldap аналогична стандартному методу аутентификации с использованием текстовых файлов. В листинге 11 показан простейший пример настройки
LDAP-аутентификации без использования авторизации.
Листинг 11. Конфигурация Web-сервера Apache для выполнения
LDAP-аутентификации
LoadModule ldap_module modules/mod_ldap.so
LoadModule authnz_ldap_module modules/mod_authnz_ldap.so

AuthType basic
AuthName ProtectedByLDAP
AuthBasicProvider ldap
AuthLDAPUrl ldap://192.168.1138/ou=People,dc=ertw,dc=com?uid
# Anon bind for first phase
#AuthLDAPBindDN
#AuthLDAPBindPassword
AuthzLDAPAuthoritative off require valid-user

Первые две строки листинга 11 загружают требуемые модули на Web-сервер. Оставшаяся часть конфигурации заключена в контейнер
Location, что означает, что данная конфигурация применяется только к запросам, начинающимся с
/protected. Сначала объявляется тип аутентификации (basic) и ее имя (
ProtectedByLDAP). Это имя отображается пользователю в Web-браузере. Строка
AuthBasicProvider указывает
Apache на то, что аутентификация осуществляется посредством LDAP.
Листинг 11 продолжает строка
AuthLDAPUrl, которая предоставляет Apache сведения о сервере LDAP. Аргумент этой строки имеет следующий вид: ldap://host:port/basedn?attribute?scope?filter. Параметры host и port указывают на сервер LDAP, а параметр basedn является именем базового объекта (base DN), с которого выполняется начальный поиск. Параметр attribute указывает на атрибут,
поиск которого будет выполняться наряду с именем пользователя во время начального поиска
(по умолчанию uid). Параметр scope имеет значение one или sub, определяющий соответствующий уровень поиска. Параметр filter является необязательным фильтром, который будет связан логической операцией "И" с условиями поиска заданной комбинации пользователь/атрибут.
Строки
AuthLDAPBindDN и AuthLDAPBindPassword в листинге 11 закомментированы, вследствие чего выполняется анонимная привязка. При желании вы можете указать здесь учетные данные пользователя. В любом случае пользователь, выполняющий начальную привязку, должен иметь разрешение на чтение атрибута, указанного в команде
AuthLDAPUrl.
Последние две строки отключают авторизацию, разрешая доступ любому проверенному пользователю. Строка
AuthzLDAPAuthoritative off означает, что впоследствии модуль может разрешать доступ даже в тех случаях, если LDAP отклоняет авторизацию (но не аутентификацию). Строка require valid-user получена из другого модуля, поэтому здесь она необходима. Вместо этих двух строк вы можете использовать строки, относящиеся к LDAP, например, выполняющих проверку принадлежности к группе или LDAP-атрибута. В листинге 12 показана измененная часть конфигурации из листинга 11, разрешающая доступ только тем пользователям, чья учетная запись содержит атрибут/значение ou=Engineering.



Поделитесь с Вашими друзьями:
1   ...   39   40   41   42   43   44   45   46   ...   68


База данных защищена авторским правом ©nethash.ru 2019
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал