Глава 7. Включение в домен серверов и клиентов

7.1.1. Условия задачи

7.2.1. Технические аспекты
7.2.2. Политические аспекты

7.3.1. NT4/Домен на Samba с сервером на Samba, являющимся членом этого домена — использование NSS LDAP
7.3.2. NT4/Домен на Samba с сервером на Samba, являющимся членом этого домена: использование NSS и winbind
7.3.3. NT4/Домен на Samba с сервером на Samba, являющимся членом этого домена без поддержки NSS
7.3.4. Домен Active Directory с сервером на Samba, являющимся членом этого домена

7.3.4.1. IDMAP_RID c Winbind
7.3.4.2. Хранение IDMAP в LDAP, используя Winbind
7.3.4.3. IDMAP и NSS, использующие LDAP из ADS с расширением схемы RFC2307bis

7.3.5. Членом домена является клиент UNIX/Linux

7.3.5.1. UNIX/Linux клиент член домена NT4
7.3.5.2. UNIX/Linux клиент член домена ADS

7.3.6. Основные моменты изученного

Наиболее часто обсуждаемые вопросы о Samba за последние два года касаются управления доменом и проблем печати. В результате последнего обзора, проведенного Open Magazine было выяснено, что из 97% случаев использования Samba под файловые и принт-серверы в 68% пакет используется для управления доменом. Обратитесь к сайту http://www.open-mag.com/cgi-bin/opencgi/surveys/survey.cgi?survey_name=samba для получения текущей информации. Результаты на 14 января 2004 года показаны на рисунке 7.1..

Рисунок 7.1. Обзор Open Magazine использования Samba

Пока существует интерес к управлению доменом, предоставлению доступа к файлам и принтерам, будут функции, которые востребованы у пакета Samba. До тех пор эта книга сможет осветить очень много аспектов применения Samba. Эта часть напрямую касается важной информации по добавлению серверов Samba в сеть Windows, не зависимо от существующих на данный момент технологий. Давайте же вернемся к нашим старым добрым друзьям из компании Abmas.
(к началу страницы)

7.1. Введение

Стэн уверенно планирует продолжить расширение, в то время как Кристина получает удовольствие от надежно работающей известной сетевой среды (что не противоречит законам эволюции :), прим.перев.). Самое время развернуть больше серверов и рабочих станций на Linux. Самое время рассмотреть будущие потребности и пройти через огонь их осуществления.
(к началу страницы)

7.1.1. Условия задачи

7.2. Обсуждение и анализ

Вы увидите пошаговые внедрения разнообразных инструментов, которые помогут в использовании авторизации. Также вы получите рабочие примеры решений по аутентификации как в среде UNIX, так и в среде Windows.
(к началу страницы)

7.2.1. Технические аспекты

Есть несколько фактов, которые мы должны принять во внимание, когда встает вопрос об интеграции клиентов и серверов UNIX/Linux в среду Windows:

• контроллер домена (PDC или BDC) всегда является авторитетным для учетных записей домена. Это значит, что BDC должен (или даже обязан) быть доступен для разрешения тех же значений UID и GID учетных записей, что и PDC;

• член домена может быть авторитетным для локальный учетных записей, но никогда для учетных записей домена. Если пользователь имеет доступ к серверу члену домена, и в то же время учетная запись пользователя не известна локально, сервер член домена должен авторизовать этого пользователя из того домена, в котором находится учетная запись пользователя. Затем его ID должен быть присоединен (map) к паре UID/GID, которая может быть использована локально. Этим процессом управляет winbindd;

• Когда Samba запущена на сервере члене домена, она может авторизовать пользователей из нескольких источников:
  - выполнения системных вызовов getpwnam() или getgrnam(). На системах, поддерживающих это, в данном случае используются возможности диспетчера разрешения имен NSS, (name service switch) для согласованного разрешения имен согласно конфигурационному файлу /etc/nsswitch.conf. NSS может быть настроен на использование LDAP, winbind, NIS или локальных файлов.
  - выполнения посредством NSS прямого LDAP-поиска (где был настроен бэкенд passdb LDAP). Это требует использования утилиты PADL nss_ldap (или ее эквивалента).
  - прямого опроса winbindd. winbindd соединяется с контроллером домена, чтобы попытаться авторизовать пользователей или группы. В этом случае происходит получение сетевого идентификатора безопасности Windows (SID) для соответствующей учетной записи, затем назначается локальный UID или GID из доступного диапазона ID и создается запись в файлах winbindd winbindd_idmap.tdb и winbindd_cache.tdb.

  Если параметр idmap backend = ldap:ldap://myserver.domain был задан и сервер LDAP был сконфигурирован, чтобы иметь контейнер, в котором могут храниться записи IDMAP, все члены домена могут совместно использовать информацию о всех существующих присоединениях (mapping) (то есть всех назначенных на данный момент соответствиях учетных записей Windows и UNIX).

  Независимо от того, как сконфигурирован файл smb.conf, winbind создает и кэширует локальную базу данных присоединений (соответствий, связей) ID (ID mapping database). Для этого используются файлы winbindd_idmap.tdb и winbindd_cache.tdb.

  Какой будет выбран метод для разрешения зависит от того, как сконфигурирована Samba в файле smb.conf. Некоторые конфигурационные опции скорее не так очевидны для случайного пользователя.

• Если вы хотите сделать возможным использование учетных записей (пользователей и/или групп ) локально средствами NSS (т.е. способными к использованию разрешения), этого можно добиться параметром winbind trusted domains only = Yes в файле smb.conf. Этот параметр применяется на контроллерах домена и серверах членах домена.

Если информация об учетных записях вашей сети находится в хранилище LDAP, вы должны использовать это прежде каких-либо альтернативных методов. Это значит, что если есть физическая возможность использовать утилиту nss_ldap для разрешения UID'ов/GID'ов учетных записей UNIX посредством LDAP, это будет предпочтительнее, потому что это даст наиболее просто контролируемый метод для безошибочного определения идентификаторов пользователей и групп в пределах всей сети.

В ситуации, когда учетные записи UNIX содержаться на самом сервере члене домена, есть только один эффективный путь по их использованию, это включение в файл smb.conf параметра winbind trusted domains only = Yes. Это вынудит Samba (smbd) выполнять системный вызов getpwnam(), который затем сможет управляться через настройки файла /etc/nsswitch.conf.

Winbind может использоваться для создания работы в режиме сервера члена домена. В этом режиме winbindd настроен для автоматического определения UID'ов и GID'ов из числового диапазона, заданного в файле smb.conf. Определение осуществляется для всех учетных записей, которые связаны с этим сервером членом домена, как внутри его собственного домена, так и в доменах, с которыми установлены доверительные отношения.

Если информация не сохранена в бэкенде LDAP, каждый член домена поддерживает свою уникальную базу данных присоединений. Это значит, что почти бесспорным является тот факт, что пользователь, имеющий доступ к двум серверам членам домена не имеет того же самого UID/GID на обоих серверах, в тоже время это прозрачно для пользователя сети Windows. Данные хранятся в файлах winbindd_idmap.tdb и winbindd_cache.tdb.

Использование бэкенда LDAP для использования средств Winbind IDMAP позволяет централизованно хранить соответствие (mapping) SID'ов домена Windows UID'ам и GID'ам. Результатом этого является согласованное соответствие (mapping) во всем пространстве сконфигурированных серверов членов домена. Это решает одну из главных проблем сетевых администраторов, которые нуждаются в копировании файлов между разными файловыми серверами сети.
(к началу страницы)

7.2.2. Политические аспекты

LDAP это наиболее подходящее решение для гетерогенных сред. Если вы нуждаетесь в криптографии, добавьте Kerberos. Причина для выбора LDAP и Kerberos состоит в их гетерогенности. Решения Windows для задач этого типа не являются гетерогенными. Это основа — и это не религия или политика. Это также не говорит о том, что вы не можете использовать Windows Active Directory в гетерогенных средах — это может быть сделано, просто потребуются коммерческие, платные продукты. Но это совсем не то, для чего был разработан Active Directory.

Ряд давних приверженцев UNIX недавно прокомментировали в ряде сообщений, что Samba Team это первая группа по разработке конкретного приложения, которая практически принуждает системных администраторов использовать LDAP. Нужно упомянуть, что мы противились этому столько, сколько могли. Однако факт остается фактом, в конце концов LDAP показал себя как наиболее предпочтительный бэкенд по управлению авторизацией для Samba. Мы рекомендуем LDAP как решение, способное полностью удовлетворить ваши потребности в службе Каталога.
(к началу страницы)

7.3. Включение в домен

Фактически, серверы члены домена и рабочие станции члены домена это очень разные объекты, но в терминах данной технологии они вместе используют сходную по своей сути инфраструктуру. Исходя их этого, мы будет отталкиваться от того, что серверы и рабочие станции идентичны. В противном случае многие пользователи утверждали бы, что рабочая станция (клиент) это лишь устройство, посредством которого пользователь создает документы и файлы, которые хранятся на сервере. Рабочая станция часто позиционируется как вспомогательный компонент, тогда как сервер воспринимается как ключевая деталь бизнеса.

Мы можем взглянуть на это с другой стороны. Если рабочая станция выйдет из строя, пострадает только один пользователь, однако в случае выхода из строя сервера сотни пользователей не смогут работать. Сервисы, которые предоставляет рабочая станция, ориентированы на создание документов и файлов; сервер же обеспечивает хранение информации и ориентирован на распределенную работу.

Почему это важно? Для начала нам стоит понять, какие компоненты операционной системы и ее окружения должны быть настроены. Также необходимо узнать, какие существуют зависимости между различными сервисами, которые будут использоваться. В частности, важно определить действие каждой критически важной части процесса аутентификации, процесса входа в систему, как осуществляется авторизация пользователя, а также как данные процессы применяется внутри операционной системы и приложений (подобных Samba), которые зависят от них (процессов), либо могут способствовать им.

Таким образом, в этой главе мы покажем внедрение этой технологии. Это сделано в контексте того, что должна быть обеспечена потребность в определенном виде обслуживания.
(к началу страницы)

7.3.1. NT4/Домен на Samba с сервером на Samba, являющимся членом этого домена — использование NSS LDAP

Если ваша инсталляция доступна только с клиентов, которые являются членами вашего собственного домена и все учетные записи пользователей в настоящее время находятся в локальном passdb бэкенде, нет необходимости запускать winbindd. Локальный passdb бэкенд может находится в smbpasswd, tdbsam, или в ldapsam.

Возможно использование локального passdb бэкенда с любым подходящим средством разрешения POSIX-информации об учетных записях пользователей и групп. POSIX-информация обычно доступна при использовании системного вызова getpwnam(). В системах, где используется NSS, актуальная информация по учетным записям POSIX может быть предоставлена из:

• файлов /etc/passwd или /etc/group;

• разрешения посредством NSS. В системах, где используется NSS обычно есть возможность разрешать ID'ы посредством различных методов. Обычно они включают files, compat, db, ldap, nis, nisplus, hesiod. В случае корректной установки, Samba добавляет к этому списку возоможности winbindd. Возможности LDAP часто представлены утилитой nss_ldap от PADL.

Рисунок 7.2. демонстрирует взаимосвязь Samba и системных компонентов, вовлеченных в процесс авторизации, в которых Samba используется внутри сети как сервер, являющийся членом домена, в свою очередь управляемого Samba. Из этого рисунка видно, что Samba будет осуществлять прямой просмотр основанного на LDAP passwd бэкенда ldapsam, чтобы получить аутентифицирующую и авторизирующую пользователя информацию.

Рисунок 7.2. Домен на Samba: сервер на Samba является членом данного домена

Информация IDMAP так хранится в LDAP, что может быть общедоступна всем серверам членам домена и каждый пользователь имеет согласованный UID и GID в пределах всей базы LDAP. Возможности IDMAP будут использоваться для всех внешних (т.е. не имеющих тех же самых SID, которые имеют члены домена) доменов. Настройка NSS будет гарантировать, что все процессы UNIX получат согласованные UID/GID.

Инструкции, которые здесь представлены, применяются к среде Samba, показанной в Главе 5, «Делаем пользователей довольными» и Главе 6, «Распределенная сеть на 2000 пользователей». Если ваша сеть не имеет дополнительного (slave) сервера LDAP (т.е. как показано в Главе 5, «Делаем пользователей довольными») измените эталонный сервер LDAP с lapdc на massive.

Настройка авторизации, основанной на nss_ldap:

1. Создайте файл smb.conf такого содержания, как показано в примере 7.3.1. и поместите его в папку /etc/samba/.

2. Настройте файл, который будет использоваться утилитой nss_ldap, чтобы находить сервер LDAP и связываться с ним. Этот файл будет называться ldap.conf. Если в вашей реализации будет применена утилита nss_ldap это будет соответствовать тому, что предлагают для использования авторы PADL, он будет находится в папке /etc. В некоторых системах данный файл по умолчанию находится в папке /etc/openldap, но как бы то ни было, этот файл предназначен для использования инструментами OpenLDAP и на самом деле он не должен использоваться утилитами nss_ldap до тех пор, пока его содержимое и структура обеспечивает выполнение определенных задач, делающих возможным разрешение ID пользователей и групп посредством NSS. Измените содержимое этого файла, который присутствует в вашей ОС на то, которое показано в примере 7.3.3.. Определите верное расположение этого файла, сведения об этом вы можете получить от использующейся библиотеки:

root# strings /lib/libnss_ldap* | grep ldap.conf
/etc/ldap.conf

3. Настройте управляющий файл NSS так, чтобы он стал похож на пример 7.3.4..

4. Перед продолжением конфигурирования Samba, проверьте возможность NSS осуществлять авторизацию посредством LDAP:

root#  getent passwd
...
root:x:0:512:Netbios Domain Administrator:/root:/bin/false
nobody:x:999:514:nobody:/dev/null:/bin/false
bobj:x:1000:513:Robert Jordan:/home/bobj:/bin/bash
stans:x:1001:513:Stanley Soroka:/home/stans:/bin/bash
chrisr:x:1002:513:Christine Roberson:/home/chrisr:/bin/bash
maryv:x:1003:513:Mary Vortexis:/home/maryv:/bin/bash
jht:x:1004:513:John H Terpstra:/home/jht:/bin/bash
bldg1$:x:1006:553:bldg1$:/dev/null:/bin/false
temptation$:x:1009:553:temptation$:/dev/null:/bin/false
vaioboss$:x:1005:553:vaioboss$:/dev/null:/bin/false
fran$:x:1008:553:fran$:/dev/null:/bin/false
josephj:x:1007:513:Joseph James:/home/josephj:/bin/bash

Вы должны обратить внимание на то, где располагаются домашние каталоги пользователей. Во-первых, удостоверьтесь, что домашние каталоги существуют на сервере члене домена, в противном случае не будет доступа к личному общему ресурсу (домашнему каталогу, подключаемому как сетевой диск). Домашние каталоги могут быть примонтированы с контроллера домена с использованием NFS или подобным средством. Во-вторых, отсутствие имени домена в пути к домашнему каталогу указывает на то, что авторизация не будет сделана посредством winbind.

root#  getent group
...
Domain Admins:x:512:root,jht
Domain Users:x:513:bobj,stans,chrisr,maryv,jht,josephj
Domain Guests:x:514:
Accounts:x:1000:
Finances:x:1001:
PIOps:x:1002:
sammy:x:4321:

Приведенный выше вывод показывает, что все работает так, как и должно. Обратите внимание, что в базе данных LDAP членство пользователей в первичной (primary) и вторичной (secondary) группе идентично. Нет необходмости в назначении членства во вторичной группе (т.е. добавлении в базу данных группы), если пользователь уже является членом посредством членства в базе данных паролей первичной группы. Фактически, при использовании winbind делать это нежелательно, потому что результатом является удвоение группового членства и это в некоторых ситуациях может стать причиной проблем с winbind. Предполагается, что эти ограничения winbind будут устранены после выхода Samba-3.0.20.

5. Каталог LDAP должен иметь объект-контейнер для данных IDMAP. Есть несколько способов, чтобы проверить, имеет ли возможность ваша база данных LDAP получать информацию IDMAP. Одним из простейших будет следующая команда:

root# slapcat | grep -i idmap
dn: ou=Idmap,dc=abmas,dc=biz
ou: idmap

Если выполнение этой команды не возвратит записи IDMAP, вы должны будете создать эталонный LDIF-файл (см. пример 7.3.2.). Вы можете добавить требующиеся записи следующей командой:

root#  ldapadd -x -D "cn=Manager,dc=abmas,dc=biz" \
		-w not24get < /etc/openldap/idmap.LDIF

6. Samba автоматически заполнит контейнер Каталога LDAP, когда это потребуется. Чтобы позволить Samba доступ на запись в Каталог LDAP, необходимо установить пароль администратора LDAP в файл secrets.tdb как показано ниже:

root#  smbpasswd -w not24get 

7. Система готова к включению в домен, выполните следующее:

root#  net rpc join -U root%not24get
Joined domain MEGANET2

Это свидетельствует о том, что включение в домен прошел успешно.

Ошибка при вводе в домен может быть вызвана целым рядом причин. Наиболее часто встречающиеся перечислены ниже:

• нарушения разрешения имен NetBIOS по соответствующим IP адресам;

• некорректное имя пользователя либо пароль;

• режимом ограничения анонимности в NT4 (NT4 restrict anonymous) установлено не допускать анонимных подключений.

root#  net rpc join -S 'pdc-name' -U administrator%password -d 5

Примечание: используйте учетную запись root в UNIX/Linux и Samba, а в Windows NT4/200X учетную запись Administrator. Если причина сбоя связана с ошибкой NT_SESSION_SETUP*, либо сообщение об ошибке сообщает: NT_STATUS_ACCESS_DENIED сразу же проверьте установки в реестре Windows, которые управляют настройками restrict anonymous. Установите значение этого параметра в 0, чтобы могли поддерживаться анонимные подключения, затем попробуйте снова. Если возможно (более того, рекомендуется), проверьте возможность подключения к NT4 PDC/BDC такой командой:

root#  net rpc info -S 'pdc-name' -U Administrator%not24get
Domain Name: MEGANET2
Domain SID: S-1-5-21-422319763-4138913805-7168186429
Sequence number: 1519909596
Num users: 7003
Num domain groups: 821
Num local groups: 8

root#  net rpc testjoin -S 'pdc-name' -U Administrator%not24get
Join to 'MEGANET2' is OK

Если по какой-либо причине будет получен отклик, который представлен ниже, самое время начинать отладку:

NT_STATUS_ACCESS_DENIED
Join to 'MEGANET2' failed.5

8. Не достаточно только осуществить ввод в домен; теперь вы должны настроить права и привилегии, по которым winbindd сможет взаимодействовать с серверами домена. Выполните следующую команду, чтобы установить необходимые права:

root# wbinfo --set-auth-user=Administrator%not24get

Теперь наша конфигурация готова, чтобы получать информацию о пользователях и группах домена на Samba.

9. Сейчас вы можете запустить Samba обычным способом, и ваш сервер член домена на Samba готов для использования. Не забудьте настроить требующиеся общие ресурсы.
(к началу страницы)

7.3.2. NT4/Домен на Samba с сервером на Samba, являющимся членом этого домена: использование NSS и winbind

• на системе не установлена поддержка LDAP (клиент);

• смягчение обстоятельств, при которых возникает нужда использовать LDAP;

• домен на Samba должен быть членом домена Windows NT4, или домена на Samba.

Конфигурирование авторизации, основанной на Winbind:

1. Создайте файл smb.conf с содержанием, которое показано в примере 7.3.5.

2. Отредактируйте файл /etc/nsswitch.conf так, чтобы он имел записи, показанные в примере 7.3.4..

3. Система готова для включения в домен. Выполните следующую команду:

net rpc join -U root%not2g4et
Joined domain MEGANET2.

Это означает, что введение в домен прошло успешно.

4. Проверьте winbind, используя утилиту wbinfo:

root#  wbinfo -u
MEGANET2+root
MEGANET2+nobody
MEGANET2+jht
MEGANET2+maryv
MEGANET2+billr
MEGANET2+jelliott
MEGANET2+dbrady
MEGANET2+joeg
MEGANET2+balap

Это говорит о том, что пользователи домена корректно просматриваются.

root#  wbinfo -g
MEGANET2+Domain Admins
MEGANET2+Domain Users
MEGANET2+Domain Guests
MEGANET2+Accounts
MEGANET2+Finances
MEGANET2+PIOps

Это показывает, что корректно может быть получен список групп домена.

5. Следующим шагом будет проверено, что NSS также может корректно получить эту информацию из winbind.

root#  getent passwd
...
MEGANET2+root:x:10000:10001:NetBIOS Domain Admin:
                      /home/MEGANET2/root:/bin/bash
MEGANET2+nobody:x:10001:10001:nobody:
                      /home/MEGANET2/nobody:/bin/bash
MEGANET2+jht:x:10002:10001:John H Terpstra:
                      /home/MEGANET2/jht:/bin/bash
MEGANET2+maryv:x:10003:10001:Mary Vortexis:
                      /home/MEGANET2/maryv:/bin/bash
MEGANET2+billr:x:10004:10001:William Randalph:
                      /home/MEGANET2/billr:/bin/bash
MEGANET2+jelliott:x:10005:10001:John G Elliott:
                      /home/MEGANET2/jelliott:/bin/bash
MEGANET2+dbrady:x:10006:10001:Darren Brady:
                      /home/MEGANET2/dbrady:/bin/bash
MEGANET2+joeg:x:10007:10001:Joe Green:
                      /home/MEGANET2/joeg:/bin/bash
MEGANET2+balap:x:10008:10001:Bala Pillay:
                      /home/MEGANET2/balap:/bin/bash

Информация об учетных записях пользователей была корректно получена. Эта информация была объединена с шаблонной информацией winbind, настроенной в файле smb.conf.

root# # getent group
...
MEGANET2+Domain Admins:x:10000:MEGANET2+root,MEGANET2+jht
MEGANET2+Domain Users:x:10001:MEGANET2+jht,MEGANET2+maryv,\
        MEGANET2+billr,MEGANET2+jelliott,MEGANET2+dbrady,\
        MEGANET2+joeg,MEGANET2+balap
MEGANET2+Domain Guests:x:10002:MEGANET2+nobody
MEGANET2+Accounts:x:10003:
MEGANET2+Finances:x:10004:
MEGANET2+PIOps:x:10005:

6. Сервер на Samba домена Windows NT4 готов к использованию.
(к началу страницы)

7.3.3. NT4/Домен на Samba с сервером на Samba, являющимся членом этого домена без поддержки NSS

При выполнении следующих шагов Samba может быть развернута с поддержкой локальных учетных записей. В этой конфигурации Samba сделана сервером членом домена. Все входящие соединения на сервер Samba будут являться основанием для просмотра входящего имени пользователя. Если учетная запись найдена, она используется. Если учетная запись не найдена, она будет автоматически создана на локальном компьютере, таким образом она сможет использоваться для всей операций по контролю за доступом.

Настройка использования только локальных учетных записей:

1. Создайте файл smb.conf, содержимое которого показано в примере 7.3.6.

2. Система готова для включения в домен. Выполните следующую команду:

net rpc join -U root%not2g4et
Joined domain MEGANET2.

Это означает, что введение в домен прошло успешно.

3. Удостоверьтесь, что все три демона Samba запущены - smbd, nmbd, и winbindd.

4.Сервер на Samba домена Windows NT4 готов к использованию.
(к началу страницы)

7.3.4. Домен Active Directory с сервером на Samba, являющимся членом этого домена

Рисунок 7.3. показывает как Samba-3 взаимодействует с компонентами Microsoft Active Directory. Нужно отметить, что если сервисы Microsoft Windows для UNIX (Microsoft Windows Services for UNIX – SFU) были установлены и корректно настроены, становиться возможным использовать клиент LDAP для авторизации также, как может быть сделано с Samba-3, если используется бэкенд LDAP passwd. Инструмент UNIX, в котором вы нуждаетесь в случае LDAP для UNIX/Linux это nss_ldap от PADL Software. Сравнивая с использованием winbind и Kerberos, использование авторизации опирающейся на LDAP, является менее безопасным. В свете того факта, что это решение требует установки дополнительного программного обеспечения на контроллеры домена под Windows 200X ADS, а также больших издержек по управлению, привлекательным для большинства клиентов ADS на Samba-3 будет тот вариант, где будет использоваться winbind.

Рисунок 7.3. Домен Active Directory: сервер Samba является членом этого домена

Не старайтесь использовать эту процедуру, если вы не на 100% удостоверились, что при сборке Samba-3 собраны и верно взаимодействуют все необходимые для этой задачи утилиты.

Учитывая значимость этого шага, сперва вы должны проверить что демон блока сообщений Samba-3 smbd (message block daemon (smbd)) имеет все необхдимые свойства.

Гипотетический домен, который вы используете в этом примере, предполагает, что лондонский офис Abmas решил взять на себя общее управление (некоторые скажут, что это - типичное поведение в корпоративном мире; кроме того, некоторые несоответствия и конфликты делаются для того, чтобы жизнь была интересней). Домен на Windows Server 2003 c ADS называется london.abmas.biz, а имя сервера W2K3S. В области AD это контроллер домена под именем w2k3s.london.abmas.biz, в номенклатуре NetBIOS имя домена LONDON, а имя сервера W2K3S.

Включение сервера Samba в домен Windows с AD:

1. Перед тем, как вы попытаетесь использовать Samba-3, для полной уверенности вам следует узнать, есть ли в вашем распоряжении поддержка Kerberos и LDAP, выполните следующую команду:

root#  cd /usr/sbin
root#  smbd -b | grep KRB
   HAVE_KRB5_H
   HAVE_ADDR_TYPE_IN_KRB5_ADDRESS
   HAVE_KRB5
   HAVE_KRB5_AUTH_CON_SETKEY
   HAVE_KRB5_GET_DEFAULT_IN_TKT_ETYPES
   HAVE_KRB5_GET_PW_SALT
   HAVE_KRB5_KEYBLOCK_KEYVALUE
   HAVE_KRB5_KEYTAB_ENTRY_KEYBLOCK
   HAVE_KRB5_MK_REQ_EXTENDED
   HAVE_KRB5_PRINCIPAL_GET_COMP_STRING
   HAVE_KRB5_SET_DEFAULT_IN_TKT_ETYPES
   HAVE_KRB5_STRING_TO_KEY
   HAVE_KRB5_STRING_TO_KEY_SALT
   HAVE_LIBKRB5

Этот вывод был получен на SUSE Linux и показывает, что Samba была собрана с библиотеками Heimdal Kerberos. Ниже представлен обычный вывод для систем Red Hat Linux, в которые входят библиотеки MIT Kerberos:

root#  cd /usr/sbin
root#  smbd -b | grep KRB
   HAVE_KRB5_H
   HAVE_ADDRTYPE_IN_KRB5_ADDRESS
   HAVE_KRB5
   HAVE_KRB5_AUTH_CON_SETUSERUSERKEY
   HAVE_KRB5_ENCRYPT_DATA
   HAVE_KRB5_FREE_DATA_CONTENTS
   HAVE_KRB5_FREE_KTYPES
   HAVE_KRB5_GET_PERMITTED_ENCTYPES
   HAVE_KRB5_KEYTAB_ENTRY_KEY
   HAVE_KRB5_LOCATE_KDC
   HAVE_KRB5_MK_REQ_EXTENDED
   HAVE_KRB5_PRINCIPAL2SALT
   HAVE_KRB5_PRINC_COMPONENT
   HAVE_KRB5_SET_DEFAULT_TGS_KTYPES
   HAVE_KRB5_SET_REAL_TIME
   HAVE_KRB5_STRING_TO_KEY
   HAVE_KRB5_TKT_ENC_PART2
   HAVE_KRB5_USE_ENCTYPE
   HAVE_LIBGSSAPI_KRB5
   HAVE_LIBKRB5

Выполните следующую команду, чтобы проверить, включена ли при сборке в вашу Samba поддержка LDAP:

root#  smbd -b | grep LDAP
massive:/usr/sbin # smbd -b | grep LDAP
   HAVE_LDAP_H
   HAVE_LDAP
   HAVE_LDAP_DOMAIN2HOSTLIST
   HAVE_LDAP_INIT
   HAVE_LDAP_INITIALIZE
   HAVE_LDAP_SET_REBIND_PROC
   HAVE_LIBLDAP
   LDAP_SET_REBIND_PROC_ARGS

Это выглядит многообещающе; smbd был собран с поддержкой Kerberos и LDAP. Вы испытываете облегчение от того, что в этом отношении вам не о чем беспокоится.

2. Следующим шагом мы должны выяснить, какая используется версия библиотек Kerberos. Чтобы позволить Samba-3 взаимодействовать с Windows 2003 Active Directory, необходима версия MIT Kerberos версии 1.3.1. или более поздней, а в случае Heimdal Kerberos версии 0.6 плюс дополнительные патчи. Вы можете определить версию библиотек MIT Kerberos (для Red Hat Linux) так:

root#  rpm -q krb5

На SUSE Linux выполните следующую команду:

root#  rpm -q heimdal

Пожалуйста, заметьте, что rpm-пакеты, предоставляемые командой разработчиков Samba известны как рабочие и были проверены. Пакеты для Red Hat Linux могут быть получены на ftp Samba, пакеты для SUSE Linux могут быть получены с сайта Sernet в Германии.

С этого момента вы можете быть полностью уверены, что ваша Samba собрана с включением всей необходимой функциональности. Теперь вы можете настроить Samba и NSS.

3. Создайте файл smb.conf, содержимое которого показано в примере 7.3.7.

4. Создайте или отредактируйте управляющий файл NSS, чтобы его содержимое было таким, как в примере 7.3.4..

5. Удалите файл /etc/samba/secrets.tdb, если он существует. Разумеется, вы сделали резервную копию этого файла, не так ли?

6. Удалите все файлы *.tdb, в которых кэширована информация Samba. Конечно, вы сделали резервные копии старых файлов. Вы также удаляете все файлы, чтобы гарантировать, что ничего не будет мешать вашей новой конфигурации. Выполните следующее (пример для SUSE Linux):

root#  rm /var/lib/samba/*tdb

7. Проверьте ваш файл smb.conf утилитой testparm (как вы делали это раньше). Устраните все ошибки перед продолжением. Команда, которую вы выполните для этого, будет такой:

root#  testparm -s | less

Сейчас вы довольны тем, что ваш сервер Samba готов для включения в домен с AD, двигаемся дальше.

8. Теперь самое время для проведения двойного контроля всего еще раз, и после того, как такая проверка будет сделана, выполните следующую команду:

root#  net ads join -UAdministrator%not24get
Using short domain name -- LONDON
Joined 'FRAN' to realm 'LONDON.ABMAS.BIZ'

Вы благополучно сделали ваш сервер Samba-3 членом домена с ADS с использованием протоколов Kerberos.

Если вы не получили данного сообщения, ничего не увидели, это означает, что при включении в домен произошла ошибка. Вы можете использовать ethereal для определения ее причины. В общем случае ошибки включения в домен включают:

• Неполное или ошибочное разрешение имен DNS;

• Запрещающие или ограничивающие настройки безопасности на контроллере домена Windows 200x ADS, препятствующие работе необходимых протоколов взаимодействия;

• Некорректные настройки в файле smb.conf;

• Отсутствие поддержки необходимых протоколов Kerberos, так как имеющиеся в использовании версии MIT Kerberos (или Heimdal) на дату своего выхода не имели необходимой функциональности.

9. Если в вашей системе установлен tdbdump (что не обязательно), вы можете просмотреть содержимое файла /etc/samba/secrets.tdb:

root#  tdbdump secrets.tdb
{
key = "SECRETS/SID/LONDON"
data = "\01\04\00\00\00\00\00\05\15\00\00\00\EBw\86\F1\ED\BD\
   F6{\5C6\E5W\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\
   00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\
   00\00\00\00\00\00\00\00"
}
{
key = "SECRETS/MACHINE_PASSWORD/LONDON"
data = "le3Q5FPnN5.ueC\00"
}
{
key = "SECRETS/MACHINE_SEC_CHANNEL_TYPE/LONDON"
data = "\02\00\00\00"
}
{
key = "SECRETS/MACHINE_LAST_CHANGE_TIME/LONDON"
data = "E\89\F6?"
}

Данный вывод приводится для того, чтобы показать скептикам, что этот процесс действительно работает.

10. Сейчас самое время запустить Samba обычным способом (тем, каким вы пользовались на протяжении всей этой книги).

11. А теперь пришла пора проверить, что все работает как нужно. Сначала проверьте, что winbind может получить список пользователей и групп от контроллера домена ADS. Выполните такую команду:

root#  wbinfo -u
LONDON+Administrator
LONDON+Guest
LONDON+SUPPORT_388945a0
LONDON+krbtgt
LONDON+jht

Хорошо, список пользователей был получен. Теперь подобным образом поступите для учетных записей групп:

root#  wbinfo -g
LONDON+Domain Computers
LONDON+Domain Controllers
LONDON+Schema Admins
LONDON+Enterprise Admins
LONDON+Domain Admins
LONDON+Domain Users
LONDON+Domain Guests
LONDON+Group Policy Creator Owners
LONDON+DnsUpdateРrоxy

Прекрасно, все работает как и хотелось.

12. Сейчас повторите это для NSS, чтобы проверить, что авторизация функционирует, как требуется:

root#  getent passwd
...
LONDON+Administrator:x:10000:10000:Administrator:
             /home/LONDON/administrator:/bin/bash
LONDON+Guest:x:10001:10001:Guest:
             /home/LONDON/guest:/bin/bash
LONDON+SUPPORT_388945a0:x:10002:10000:SUPPORT_388945a0:
             /home/LONDON/support_388945a0:/bin/bash
LONDON+krbtgt:x:10003:10000:krbtgt:
             /home/LONDON/krbtgt:/bin/bash
LONDON+jht:x:10004:10000:John H. Terpstra:
             /home/LONDON/jht:/bin/bash

Хорошо, учетные записи пользователей ADS разрешаются. Теперь проверьте разрешение групп:

root#  getent group
...
LONDON+Domain Computers:x:10002:
LONDON+Domain Controllers:x:10003:
LONDON+Schema Admins:x:10004:LONDON+Administrator
LONDON+Enterprise Admins:x:10005:LONDON+Administrator
LONDON+Domain Admins:x:10006:LONDON+jht,LONDON+Administrator
LONDON+Domain Users:x:10000:
LONDON+Domain Guests:x:10001:
LONDON+Group Policy Creator Owners:x:10007:LONDON+Administrator
LONDON+DnsUpdateРrоху:x:10008:

Это очень приятно, все работает, как и задумано.

13. Сейчас вы можете осуществить финальную проверку того, что взаимодействие между winbind Samba-3 и сервером Active Directory использует протоколы Kerberos, выполните следующую команду:

root#  net ads info
LDAP server: 192.168.2.123
LDAP server name: w2k3s
Realm: LONDON.ABMAS.BIZ
Bind Path: dc=LONDON,dc=ABMAS,dc=BIZ
LDAP port: 389
Server time: Sat, 03 Jan 2004 02:44:44 GMT
KDC server: 192.168.2.123
Server time offset: 2

Заметьте, что протоколы Kerberos чувствительны ко времени. Вы должны синхронизировать все время, используя протокол времени сети NTP (network time protocol – NTP). В любом случае, вывод, полученный нами, подтверждает, что все системы работают.

14. Есть еще одно действие, которое вы хотите сделать только потому, что вы недоверчивый параноик, выполните такую команду:

root#  net ads status -UAdministrator%not24get
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
objectClass: computer
cn: fran
distinguishedName: CN=fran,CN=Computers,DC=london,DC=abmas,DC=biz
instanceType: 4
whenCreated: 20040103092006.0Z
whenChanged: 20040103092006.0Z
uSNCreated: 28713
uSNChanged: 28717
name: fran
objectGUID: 58f89519-c467-49b9-acb0-f099d73696e
userAccountControl: 69632
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 0
lastLogoff: 0
lastLogon: 127175965783327936
localPolicyFlags: 0
pwdLastSet: 127175952062598496
primaryGroupID: 515
objectSid: S-1-5-21-4052121579-2079768045-1474639452-1109
accountExpires: 9223372036854775807
logonCount: 13
sAMAccountName: fran$
sAMAccountType: 805306369
operatingSystem: Samba
operatingSystemVersion: 3.0.20-SUSE
dNSHostName: fran
userPrincipalName: HOST/fran@LONDON.ABMAS.BIZ
servicePrincipalName: CIFS/fran.london.abmas.biz
servicePrincipalName: CIFS/fran
servicePrincipalName: HOST/fran.london.abmas.biz
servicePrincipalName: HOST/fran
objectCategory: CN=Computer,CN=Schema,CN=Configuration,
                              DC=london,DC=abmas,DC=biz
isCriticalSystemObject: FALSE
-------------- Security Descriptor (revision: 1, type: 0x8c14)
owner SID: S-1-5-21-4052121579-2079768045-1474639452-512
group SID: S-1-5-21-4052121579-2079768045-1474639452-513
------- (system) ACL (revision: 4, size: 120, number of ACEs: 2)
------- ACE (type: 0x07, flags: 0x5a, size: 0x38, 
               mask: 0x20, object flags: 0x3)
access SID:  S-1-1-0
access type: AUDIT OBJECT
Permissions:
        [Write All Properties]
------- ACE (type: 0x07, flags: 0x5a, size: 0x38, 
               mask: 0x20, object flags: 0x3)
access SID:  S-1-1-0
access type: AUDIT OBJECT
Permissions:
        [Write All Properties]
------- (user) ACL (revision: 4, size: 1944, number of ACEs: 40)
------- ACE (type: 0x00, flags: 0x00, size: 0x24, mask: 0xf01ff)
access SID:  S-1-5-21-4052121579-2079768045-1474639452-512
access type: ALLOWED
Permissions: [Full Control]
------- ACE (type: 0x00, flags: 0x00, size: 0x18, mask: 0xf01ff)
access SID:  S-1-5-32-548
...
------- ACE (type: 0x05, flags: 0x12, size: 0x38, 
                mask: 0x10, object flags: 0x3)
access SID:  S-1-5-9
access type: ALLOWED OBJECT
Permissions:
        [Read All Properties]
-------------- End Of Security Descriptor

И вот теперь вы имеете окончательное доказательство того, что ваш сервер Samba-3 с именем FRAN является членом домена на ADS и может взаимодействовать с контроллерами домена ADS.

Ваш сервер Samba-3 член домена на ADS готов к использованию. В течение данного урока вы, может быть, спрашивали себя, а что внутри файлов winbindd_cache.tdb и winbindd_idmap.tdb? Так как вас заинтересовал этот вопрос, сделайте следующее:

root#  tdbdump /var/lib/samba/winbindd_idmap.tdb
{
key = "S-1-5-21-4052121579-2079768045-1474639452-501\00"
data = "UID 10001\00"
}
{
key = "UID 10005\00"
data = "S-1-5-21-4052121579-2079768045-1474639452-1111\00"
}
{
key = "GID 10004\00"
data = "S-1-5-21-4052121579-2079768045-1474639452-518\00"
}
{
key = "S-1-5-21-4052121579-2079768045-1474639452-502\00"
data = "UID 10003\00"
}
...

root#  tdbdump /var/lib/samba/winbindd_cache.tdb
{
key = "UL/LONDON"
data = "\00\00\00\00bp\00\00\06\00\00\00\0DAdministrator\0D
   Administrator-S-1-5-21-4052121579-2079768045-1474639452-500-
   S-1-5-21-4052121579-2079768045-1474639452-513\05Guest\05
   Guest-S-1-5-21-4052121579-2079768045-1474639452-501-
   S-1-5-21-4052121579-2079768045-1474639452-514\10
   SUPPORT_388945a0\10SUPPORT_388945a0.
   S-1-5-21-4052121579-2079768045-1474639452-1001-
   S-1-5-21-4052121579-2079768045-1474639452-513\06krbtgt\06
   krbtgt-S-1-5-21-4052121579-2079768045-1474639452-502-
   S-1-5-21-4052121579-2079768045-1474639452-513\03jht\10
   John H. Terpstra.S-1-5-21-4052121579-2079768045-1474639452-1110-
   S-1-5-21-4052121579-2079768045-1474639452-513"
}
{
key = "GM/S-1-5-21-4052121579-2079768045-1474639452-512"
data = "\00\00\00\00bp\00\00\02\00\00\00.
   S-1-5-21-4052121579-2079768045-1474639452-1110\03
   jht\01\00\00\00-S-1-5-21-4052121579-2079768045-1474639452-500\0D
   Administrator\01\00\00\00"
}
{
key = "SN/S-1-5-21-4052121579-2079768045-1474639452-513"
data = "\00\00\00\00xp\00\00\02\00\00\00\0CDomain Users"
}
{
key = "GM/S-1-5-21-4052121579-2079768045-1474639452-518"
data = "\00\00\00\00bp\00\00\01\00\00\00-
   S-1-5-21-4052121579-2079768045-1474639452-500\0D
   Administrator\01\00\00\00"
}
{
key = "SEQNUM/LONDON\00"
data = "xp\00\00C\92\F6?"
}
{
key = "U/S-1-5-21-4052121579-2079768045-1474639452-1110"
data = "\00\00\00\00xp\00\00\03jht\10John H. Terpstra.
   S-1-5-21-4052121579-2079768045-1474639452-1110-
   S-1-5-21-4052121579-2079768045-1474639452-513"
}
{
key = "NS/S-1-5-21-4052121579-2079768045-1474639452-502"
data = "\00\00\00\00bp\00\00-
   S-1-5-21-4052121579-2079768045-1474639452-502"
}
{
key = "SN/S-1-5-21-4052121579-2079768045-1474639452-1001"
data = "\00\00\00\00bp\00\00\01\00\00\00\10SUPPORT_388945a0"
}
{
key = "SN/S-1-5-21-4052121579-2079768045-1474639452-500"
data = "\00\00\00\00bp\00\00\01\00\00\00\0DAdministrator"
}
{
key = "U/S-1-5-21-4052121579-2079768045-1474639452-502"
data = "\00\00\00\00bp\00\00\06krbtgt\06krbtgt-
   S-1-5-21-4052121579-2079768045-1474639452-502-
   S-1-5-21-4052121579-2079768045-1474639452-513"
}
....

Теперь все ясно. Ваше любопытство, так же как и ваша команда, были удовлетворены.
(к началу страницы)

7.3.4.1. IDMAP_RID c Winbind

Альтернативных методов присоединения SID к UID/GID можно добиться при использовании idmap_rid плагина. Этот плагин использует RID пользовательского SID, чтобы получить UID и GID, добавляя RID к основному заданному значению. Эта утилита требует, чтобы был задан параметр allow trusted domains = No, так как он не совместим с мультидоменной средой. Также должны быть описаны диапазоны idmap uid и idmap gid.

Возможности idmap_rid могут использоваться как в доменах в стиле NT4/Samba, так и с Active Directory. Чтобы применить их в домене NT4, не используйте параметр realm. В дополнение этот метод использует процесс net rpc join, чтобы осуществить включение в домен.

Содержимое файла smb.conf для среды домена ADS показано в примере 7.3.8..

В большом домене, где много пользователей необходимо запретить нумерацию пользователей и групп. Например, в среде, где в Active Directory есть 22000 пользователей, разрешение пользователей и групп, основанное на winbind, остается недоступным почти 12 минут после первого запуска winbind. Отключение же нумерации приводит к мгновенному отклику. Отключение нумерации пользователей и групп означает также то, что не будет возможности просматривать список пользователей и групп используя команды getent passwd и getent group. Но будет возможно просмотреть отдельных пользователей, как показано ниже.

Использование этого инструмента требует настройки NSS согласно тому, как используется winbind. Отредактируйте файл /etc/nsswitch.conf:

...
passwd: files winbind
shadow: files winbind
group:  files winbind
...
hosts:  files wins
...

Следующая процедура может быть использована для применения возможностей idmap_rid:

1. Создайте или отредактируйте файл smb.conf до вышеупомянутой конфигурации.

2. Отредактируйте файл /etc/nsswitch.conf, как показано выше.

3. Выполните:

root#  net ads join -UAdministrator%password
Using short domain name -- KPAK
Joined 'BIGJOE' to realm 'CORP.KPAK.COM'

При возникновении ошибки включения в домен, можно попробовать провести такую проверку:

root#  net ads testjoin
BIGJOE$@'s password:
[2004/11/05 16:53:03, 0] utils/net_ads.c:ads_startup(186)
  ads_connect: No results returned
Join to domain is not valid

Сообщение об ошибке может отличатся от приведенного, так как зависит от конкретной неисправности. Увеличьте log level до 10, повторите проверку, а затем изучите лог-файл, чтобы определить происхождение ошибки.

4. Запустите демоны nmbd, winbind, и smbd именно в приведенном порядке.

5. Проверьте работоспособность данной конфигурации, выполнив следующее:

root#  getent passwd administrator
administrator:x:1000:1013:Administrator:/home/BE/administrator:/bin/bash

7.3.4.2. Хранение IDMAP в LDAP, используя Winbind

Содержимое файла smb.conf приведено в примере 7.3.9..

Если используется домен стиля NT4/Samba, то не используется параметр realm, а командой для включения в домен является команда net rpc join. Упомянутый выше пример также показывает дополнительную технологию создания отчета об ошибках, которая детально описана в главе «Reporting Bugs» в «The Official Samba-3 HOWTO and Reference Guide, Second Edition» (TOSHARG2).

Если вами используется MIT kerberos (версии 1.3.4 или более поздней), отредактируйте файл /etc/krb5.conf, чтобы он принял такой вид:

[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 default_realm = SNOWSHOW.COM
 dns_lookup_realm = false
 dns_lookup_kdc = true

[appdefaults]
 pam = {
   debug = false
   ticket_lifetime = 36000
   renew_lifetime = 36000
   forwardable = true
   krb4_convert = false
 }

Если вы используете Heimdal kerberos, то либо сделайте файл /etc/krb5.conf пустым, либо наполните его таким содержимым:

[libdefaults]
        default_realm = SNOWSHOW.COM
        clockskew = 300

[realms]
        SNOWSHOW.COM = {
                kdc = ADSDC.SHOWSHOW.COM
        }

[domain_realm]
        .snowshow.com = SNOWSHOW.COM

Отредактируйте управляющий файл NSS /etc/nsswitch.conf так, чтобы в нем были такие записи:

...
passwd: files ldap
shadow: files ldap
group:  files ldap
...
hosts:  files wins
...

Для данного решения вам потребуется инстумент nss_ldap от PADL. Отредактируйте файл /etc/ldap.conf так, чтобы в нем присутствовала необходимая информация. Ниже дан пример рабочего файла:

host    192.168.2.1
base    dc=snowshow,dc=com
binddn  cn=Manager,dc=snowshow,dc=com
bindpw  not24get

pam_password exop

nss_base_passwd ou=People,dc=snowshow,dc=com?one
nss_base_shadow ou=People,dc=snowshow,dc=com?one
nss_base_group  ou=Groups,dc=snowshow,dc=com?one
ssl     no

Шаги для достижения рабочей конфигурации:

1. Создайте или отредактируйте файл smb.conf до вышеупомянутой конфигурации.

2. Создайте файл /etc/krb5.conf и заполните его содержимым, в зависимости от используемых вами библиотек kerberos.

3. Отредактируйте файл /etc/nsswitch.conf, как показано выше.

4. Загрузите, соберите и установите инструмент nss_ldap от PADL. Настройте файл /etc/ldap.conf как показано выше.

5. Настройте сервер LDAP и инициализируйте каталог с записями верхнего уровня (directory with the top-level entries), требующиеся IDMAP, как показано в LDIF-файле:

dn: dc=snowshow,dc=com
objectClass: dcObject
objectClass: organization
dc: snowshow
o: The Greatest Snow Show in Singapore.
description: Posix and Samba LDAP Identity Database

dn: cn=Manager,dc=snowshow,dc=com
objectClass: organizationalRole
cn: Manager
description: Directory Manager

dn: ou=Idmap,dc=snowshow,dc=com
objectClass: organizationalUnit
ou: idmap

6. Включите сервер Samba в домен ADS:

root#  net ads testjoin
Using short domain name -- SNOWSHOW
Joined 'GOODELF' to realm 'SNOWSHOW.COM'

7. Сохраните пароль доступа к серверу LDAP в файле secrets.tdb:

root#  smbpasswd -w not24get

8. Запустите демоны nmbd, winbind, и smbd именно в приведенном порядке.

Проведите диагностические процедуры, приведенные ранее, чтобы определить успешно ли был сервер введен в домен, либо возникли какие-то ошибки. Имейте ввиду, часто при ошибках нет никаких откликов, просто предлагается консоль для ввода следующей команды без индикации причин сбоя.
(к началу страницы)

7.3.4.3. IDMAP и NSS, использующие LDAP из ADS с расширением схемы RFC2307bis

Содержимое файла smb.conf для данного метода показано в примере 7.3.10..

Сервер Samba должен быть введен в домен обычным способом. Также необходимо собрать и установить инструмент nss_ldap от PADL, при сборке удостоверьтесь, что заданы такие параметры:

./configure --enable-rfc2307bis --enable-schema-mapping
make install

Также вам потребутется файл /etc/nsswitch.conf такого содержания:

...
passwd: files ldap
shadow: files ldap
group:  files ldap
...
hosts:  files wins
...

Должен быть сконфигурирован файл /etc/ldap.conf. Обратитесь к документации PADL и исходным кодам к nss_ldap для получения информации по этому поводу.

Следующий шаг включает подготовку схемы ADS. Кратко об этом рассказано ниже.

IDMAP, Active Directory, и MS сервисы для UNIX 3.5

Сервис Microsoft Windows для UNIX версии 3.5 (Microsoft Windows Service for UNIX version 3.5) доступен для свободной загрузки на сайте Microsoft, вы должны загрузить этот инструмент и установить его, следуя инструкциям.

IDMAP, Active Directory, и AD4UNIX

Инструкции по получению и установке AD4UNIX вы можете найти на сайте Geekcomix.
(к началу страницы)

7.3.5. Членом домена является клиент UNIX/Linux

Возможность использования одинаковых прав и привилегий пользователя во всех системах сети обычно подразумевает применение SSO (SSO - single sign-on, «принцип одной подписи», система, обеспечивающая аутентификацию пользователя один раз). Системы SSO поставляются большим числом производителей и включают целый диапазон технологий, среди которых:

• единая рrоxy-авторизация (рrоxy sign-on);

• интегрированная инициализация Каталога (federated directory provisioning);

• решения для сервера метаКаталога (metadirectory server solutions);

• системы идентификации подмены (replacement authentication systems).

• Samba winbind (СПО). В Samba-3.0.20 внедрено законченное обновление для Winbind, которое теперь предоставляет широчайший уровень масштабируемости в больших средах ADS;

• PAM и LDAP инструменты от PADL (СПО);

• идентификационные сервисы Vintela (коммерческое ПО);

• Centrify DirectControl (коммерческое ПО). Данный коммерческий продукт от Centrify позволяет UNIX/Linux системам использовать сервисы безопасности Active Directory, групповых политик и другие сервисы Каталога. Также сюда включено централизованное присоединение ID (centralized ID mapping), которое позволяет качественно взаимодействовать Samba, DirectControl и Active Directory.

Вы должны принять во внимание, что позволение распределенного входа в системы (SSO) возможно при использовании инструментов PAM и NSS, основанных на взаимодействии с LDAP, а также возможности хранения учетных записей пользователей и групп в Каталоге LDAP. Это даст возможность входа в систему пользователям UNIX/Linux, в то время как пользователи Windows получат свою поддержку «одноразовой идентификации» посредством Samba-3 (sign-on support via Samba-3).

С другой стороны, если бэкенд аутентификации и авторизации должен предоставляться домену в стиле Windows NT4 или домену Active Directory, в котором не установлены сервисы Microsoft Windows для UNIX (Microsoft Windows Services for UNIX), winbind это ваш лучший друг. Ниже будет дано специальное руководство для этих ситуаций.

Чтобы разрешить пользователям осуществлять вход на рабочие станции под управлением UNIX/Linux, используя права сети Windows, вы должны настроить авторизацию (NSS) и PAM. Это значит, что основные шаги включают в себя вышеприведенный план, а также дополнительно настройку PAM. Учитывая, что большинству рабочих станций обычно не требуется функция по предоставлению принт- и файловых сервисов группам пользователей, настройка общих ресурсов и принтеров, как правило, менее важна. Часто секции с описанием общих ресурсов можно просто удалить из файла smb.conf. В конечном итоге это решение принимает администратор.
(к началу страницы)

7.3.5.1. UNIX/Linux клиент член домена NT4

1. Проделайте шаги, описанные в разделе 7.3.2. NT4/Домен на Samba с сервером на Samba, являющимся членом этого домена: использование NSS и winbind, также проведите тестирование работоспособности и убедитесь, что все нормально.

2. Определите, что отвечает и обслуживает вход пользователей. В Red Hat Linux, если предопределено, что пользователю будет дан доступ ко всем сервисам, скорее всего это простой конфигурационный файл /etc/pam.d/system-auth, содержимое которого показано в примере 7.3.13.

3. Обязательно сделайте резервные копии всех конфигурационных файлов PAM перед внесением изменений.Если вы повредите конфигурацию PAM, вполне возможно, что вам потребуется восстанавливать работоспособность Linux с загрузочных реанимационных дисков. Можно также нарушить возможность входа в систему, если конфигурационные файлы PAM настроены некорректно. Весь каталог /etc/pam.d с содержимым должен быть зарезервирован и сохранен в безопасном месте.

4. Если вам требуется только поддержка консольного входа, отредактируйте файл /etc/pam.d/login как показано в примере 7.3.11..

5. Для предоставления входа в систему в графическом режиме, вы должны отредактировать файлы gdm и xdm из каталога /etc/pam.d (пример 7.3.12.).

6. Редактируйте только один файла за раз. Внимательно проверяйте измерения перед перезагрузкой.
(к началу страницы)

7.3.5.2. UNIX/Linux клиент член домена ADS

1. Проделайте шаги, описанные в разделе 7.3.4. Домен Active Directory с сервером на Samba, являющимся членом этого домена, также проведите тестирование работоспособности и убедитесь, что все нормально.

2. Определите, что отвечает и обслуживает вход пользователей. В Red Hat Linux, если предопределено, что пользователю будет дан доступ ко всем сервисам, скорее всего это простой конфигурационный файл /etc/pam.d/system-auth, содержимое которого показано в примере 7.3.13..

3. Обязательно сделайте резервные копии всех конфигурационных файлов PAM перед внесением изменений.Если вы повредите конфигурацию PAM, вполне возможно, что вам потребуется восстанавливать работоспособность Linux с загрузочных реанимационных дисков. Можно также нарушить возможность входа в систему, если конфигурационные файлы PAM настроены некорректно. Весь каталог /etc/pam.d с содержимым должен быть зарезервирован и сохранен в безопасном месте.

4. Если вам требуется только поддержка консольного входа, отредактируйте файл /etc/pam.d/login как показано в примере 7.3.11..

5. Для предоставления входа в систему в графическом режиме, вы должны отредактировать файлы gdm и xdm из каталога /etc/pam.d (пример 7.3.12.).

6. Редактируйте только один файла за раз. Внимательно проверяйте измерения перед перезагрузкой.
(к началу страницы)

7.3.6. Основные моменты изученного

Основные моменты данной главы:

• Контроллеры домена всегда авторитетны для домена;

• Члены домена могут иметь локальные учетные записи и могут авторизовать учетные записи пользователей домена. Авторизация учетных записей пользователей домена должна присоединяться (map) к локальным UID/GID. Такие локальные UID/GID должны храниться в LDAP. Таким путем можно предоставить доступ к данным IDMAP во всем пространстве компьютеров членов домена;

• Авторизация пользователей и групп компьютеров членов домена может быть внедрено с использованием прямых сервисов LDAP или использованием winbind;

• На системах UNIX/Linux с включенным NSS/PAM, NSS отвечает за управление авторизацией, а PAM за аутентификацию при входе в систему (имя пользователя и пароль).

Пример 7.3.1. Файл smb.conf, сервер на Samba является членом домена на Samba, использующего LDAP

# Global parameters 
 
[global]

unix charset = LOCALE 
workgroup = MEGANET2 
security = DOMAIN 
username map = /etc/samba/smbusers 
log level = 10 
syslog = 0 
log file = /var/log/samba/%m 
max log size = 50 
smb ports = 139 
name resolve order = wins bcast hosts 
printcap name = CUPS 
wins server = 192.168.2.1 
ldap suffix = dc=abmas,dc=biz 
ldap machine suffix = ou=People 
ldap user suffix = ou=People 
ldap group suffix = ou=Groups 
ldap idmap suffix = ou=Idmap 
ldap admin dn = cn=Manager,dc=abmas,dc=biz 
idmap backend = ldap:ldap://lapdc.abmas.biz 
idmap uid = 10000-20000 
idmap gid = 10000-20000 
winbind trusted domains only = Yes 
printer admin = root 
printing = cups 
 
[homes] 
comment = Home Directories 
valid users = %S 
read only = No 
browseable = No 
 
[printers] 
comment = SMB Print Spool 
path = /var/spool/samba 
guest ok = Yes 
printable = Yes 
browseable = No 
 
[print$] 
comment = Printer Drivers 
path = /var/lib/samba/drivers 
admin users = root, Administrator 
write list = root

Пример 7.3.2. Файл /etc/openldap/idmap.LDIF, загрузочный LDIF IDMAP файл для добавления информации

dn: ou=Idmap,dc=abmas,dc=biz
objectClass: organizationalUnit
ou: idmap
structuralObjectClass: organizationalUnit

Пример 7.3.3. Файл /etc/ldap.conf, конфигурационный файл для поддержки NSS LDAP

URI     ldap://massive.abmas.biz ldap://massive.abmas.biz:636
host    192.168.2.1
base    dc=abmas,dc=biz
binddn  cn=Manager,dc=abmas,dc=biz
bindpw  not24get

pam_password exop

nss_base_passwd ou=People,dc=abmas,dc=biz?one
nss_base_shadow ou=People,dc=abmas,dc=biz?one
nss_base_group  ou=Groups,dc=abmas,dc=biz?one
ssl     no

Пример 7.3.4. Файл /etc/nsswitch.conf, NSS использует LDAP для авторизации

passwd:         files ldap
shadow:         files ldap
group:          files ldap

hosts:          files dns wins
networks:       files dns

services:       files
protocols:      files
rpc:            files
ethers:         files
netmasks:       files
netgroup:       files
publickey:      files

bootparams:     files
automount:      files
aliases:        files

Пример 7.3.5. Файл smb.conf, использование winbind сервером членом домена на Samba в домене NT4

# Global parameters

[global]
unix charset = LOCALE
workgroup = MEGANET2
security = DOMAIN
username map = /etc/samba/smbusers
log level = 1
syslog = 0
log file = /var/log/samba/%m
max log size = 0
smb ports = 139
name resolve order = wins bcast hosts
printcap name = CUPS
wins server = 192.168.2.1
idmap uid = 10000-20000
idmap gid = 10000-20000
template primary group = "Domain Users"
template shell = /bin/bash
winbind separator = +
printer admin = root
hosts allow = 192.168.2., 192.168.3., 127.
printing = cups

[homes]
comment = Home Directories
valid users = %S
read only = No
browseable = No

[printers]
comment = SMB Print Spool
path = /var/spool/samba
guest ok = Yes
printable = Yes
browseable = No

[print$]
comment = Printer Drivers
path = /var/lib/samba/drivers
admin users = root, Administrator
write list = root

Пример 7.3.6. Файл smb.conf, использование локальных учетных записей сервером членом домена на Samba в домене NT4

# Global parameters

[global]
unix charset = LOCALE
workgroup = MEGANET3
netbios name = BSDBOX
security = DOMAIN
username map = /etc/samba/smbusers
log level = 1
syslog = 0
add user script = /usr/sbin/useradd -m '%u'
add machine script = /usr/sbin/useradd -M '%u'
add group script = /usr/sbin/groupadd '%g'
log file = /var/log/samba/%m
max log size = 0
smb ports = 139
name resolve order = wins bcast hosts
printcap name = CUPS
wins server = 192.168.2.1
printer admin = root
hosts allow = 192.168.2., 192.168.3., 127.
printing = cups

[homes]
comment = Home Directories
valid users = %S
read only = No
browseable = No

[printers]
comment = SMB Print Spool
path = /var/spool/samba
guest ok = Yes
printable = Yes
browseable = No

[print$]
comment = Printer Drivers
path = /var/lib/samba/drivers
admin users = root, Administrator
write list = root

Пример 7.3.7. Файл smb.confсервера Samba для реализации членства в Active Directory

# Global parameters

[global]
unix charset = LOCALE
workgroup = LONDON
realm = LONDON.ABMAS.BIZ
server string = Samba 3.0.20
security = ADS
username map = /etc/samba/smbusers
log level = 1
syslog = 0
log file = /var/log/samba/%m
max log size = 50
printcap name = CUPS
ldap ssl = no
idmap uid = 10000-20000
idmap gid = 10000-20000
template primary group = "Domain Users"
template shell = /bin/bash
winbind separator = +
printing = cups

[homes]
comment = Home Directories
valid users = %S
read only = No
browseable = No

[printers]
comment = SMB Print Spool
path = /var/spool/samba
guest ok = Yes
printable = Yes
browseable = No

[print$]
comment = Printer Drivers
path = /var/lib/samba/drivers
admin users = root, Administrator
write list = root

Пример 7.3.8. Файл smb.conf, в котором используется idmap_rid

# Global parameters

[global]
workgroup = KPAK
netbios name = BIGJOE
realm = CORP.KPAK.COM
server string = Office Server
security = ADS
allow trusted domains = No
idmap backend = idmap_rid:KPAK=500-100000000
idmap uid = 500-100000000
idmap gid = 500-100000000
template shell = /bin/bash
winbind use default domain = Yes
winbind enum users = No
winbind enum groups = No
winbind nested groups = Yes
printer admin = "KPAK\Domain Admins"

Пример 7.3.9. Типичный файл smb.conf для домена в стиле Active Directory

# Global parameters

[global]
workgroup = SNOWSHOW
netbios name = GOODELF
realm = SNOWSHOW.COM
server string = Samba Server
security = ADS
log level = 1 ads:10 auth:10 sam:10 rpc:10
ldap admin dn = cn=Manager,dc=SNOWSHOW,dc=COM
ldap idmap suffix = ou=Idmap
ldap suffix = dc=SNOWSHOW,dc=COM
idmap backend = ldap:ldap://ldap.snowshow.com
idmap uid = 150000-550000
idmap gid = 150000-550000
template shell = /bin/bash
winbind use default domain = Yes

Пример 7.3.10. Файл smb.conf, применяющийся для обеспечения авторизации при членстве в ADS с использованием RFC2307bis

# Global parameters

[global]
workgroup = BUBBAH
netbios name = MADMAX
realm = BUBBAH.COM
server string = Samba Server
security = ADS
idmap uid = 150000-550000
idmap gid = 150000-550000
template shell = /bin/bash
winbind use default domain = Yes
winbind trusted domains only = Yes
winbind nested groups = Yes

Пример 7.3.11. SUSE: модуль сетевого входа PAM использующий Winbind

# /etc/pam.d/login

#%PAM-1.0
auth sufficient pam_unix2.so    nullok
auth sufficient pam_winbind.so use_first_pass use_authtok
auth required   pam_securetty.so
auth required   pam_nologin.so
auth required   pam_env.so
auth required   pam_mail.so
account sufficient      pam_unix2.so
account sufficient      pam_winbind.so user_first_pass use_authtok
password required       pam_pwcheck.so  nullok
password sufficient     pam_unix2.so    nullok use_first_pass use_authtok
password sufficient     pam_winbind.so  use_first_pass use_authtok
session sufficient      pam_unix2.so    none
session sufficient      pam_winbind.so  use_first_pass use_authtok
session required        pam_limits.so

Пример 7.3.12. SUSE: модуль xdm PAM использующий Winbind

# /etc/pam.d/gdm (/etc/pam.d/xdm)

#%PAM-1.0
auth     sufficient     pam_unix2.so     nullok
auth     sufficient     pam_winbind.so   use_first_pass use_authtok
account  sufficient     pam_unix2.so
account  sufficient     pam_winbind.so   use_first_pass use_authtok
password sufficient     pam_unix2.so
password sufficient     pam_winbind.so   use_first_pass use_authtok
session  sufficient     pam_unix2.so
session  sufficient     pam_winbind.so   use_first_pass use_authtok
session  required       pam_dev perm.so
session  required       pam_resmgr.so

Пример 7.3.13. Red Hat 9: системный идентификационный файл PAM: модуль /etc/pam.d/system-auth, использующий Winbind

#%PAM-1.0
auth        required      /lib/security/$ISA/pam_env.so
auth        sufficient    /lib/security/$ISA/pam_unix.so likeauth nullok
auth        sufficient    /lib/security/$ISA/pam_winbind.so use_first_pass
auth        required      /lib/security/$ISA/pam_deny.so

account     required      /lib/security/$ISA/pam_unix.so
account     sufficient    /lib/security/$ISA/pam_winbind.so use_first_pass

password    required      /lib/security/$ISA/pam_cracklib.so retry=3 type=
# Note: The above line is complete. There is nothing following the '='
password    sufficient    /lib/security/$ISA/pam_unix.so \
                                             nullok use_authtok md5 shadow
password    sufficient    /lib/security/$ISA/pam_winbind.so use_first_pass
password    required      /lib/security/$ISA/pam_deny.so

session     required      /lib/security/$ISA/pam_limits.so
session     sufficient    /lib/security/$ISA/pam_unix.so
session     sufficient    /lib/security/$ISA/pam_winbind.so use_first_pass

(к началу страницы)

7.4. Вопросы и ответы

1. Мы используем NIS для всех учетных записей UNIX. Для чего нам winbind?
2. Нашим IT-менеджерам не нравится LDAP, они смотрят в сторону Microsoft Active Directory, что лучше?
3. Мы хотим развернуть один PDC на Samba, четыре BDC на Samba, и 10 серверов Samba. Возможно ли использование NIS вместо LDAP?
4. Вы советуете, чтобы пользователи не осуществляли вход (имеется ввиду локальный, прим.перев.) на сервер член домена. Если это так, почему?
5. Мы хотим убедиться, что только пользователи нашего собственного домена, а также из домена с доверительными отношениями могут пользоваться сервером Samba. В файле smb.conf на всех серверах у нас включен параметр winbind trusted domains only. Сейчас мы обнаружили, что пользователи из домена, с которым у нас установлено доверие, не могут получить доступ к нашим серверам, а пользователи клиентов Windows, которые не являются членами домена как раз имеют доступ на эти сервера. Это какая-то ошибка Samba?
6. Каковы выгоды от использования LDAP для моих серверов членов домена?
7. Действительно ли для Samba+LDAP необходима работа DNS? Если это так, что я должен добавить в конфигурацию DNS?
8. Наш домен под управлением Windows 2003 Server с Active Directory, который запущен с отключенным NetBIOS? Мы можем использовать Samba-3 в такой конфигурации?
9. Когда я пытаюсь выполнить команду net ads join, я не получаю никакого вывода. Ничего не работает, я думаю тут какая-то ошибка. Затем я делаю команду net rpc join и все прекрасно работает. Что тут в правильно, а что нет?
10. В чем основное преимущество использования сервера приложений?

1. Мы используем NIS для всех учетных записей UNIX. Для чего нам winbind?

- Вы можете использовать NIS для ваших учетных записей UNIX. NIS не хранит шифрованные пароли Windows, которые должны сохраняться в одном из возможных passdb бэкендов. Ваш выбор ограничен бэкендами smbpasswd или tdbsam. Winbind необходим, чтобы обрабатывать разрешение SID'ов из доверенных доменов по их локальным значениям UID/GID.

На сервере члене домена, фактически, присоединение (map) пользователей домена Windows и локальных пользователей, которые хранятся в базе данных NIS устанавливается параметром winbind trusted domains only. Это позволяет направить поиск учетных записей пользователей и групп через семейство системных вызовов getpwnam().

На клиенте с включенным NIS (on NIS-enabled client) это заставляет осуществлять разрешение пользователей и групп посредством NIS.

Как правило, хорошей идеей является запустить winbind на всех серверах Samba.

2. Нашим IT-менеджерам не нравится LDAP, они смотрят в сторону Microsoft Active Directory, что лучше?

- Microsoft Active Directory это сервер LDAP сложным образом завязанный на Kerberos. Большинство IT-менеджеров, возражающих против LDAP делают это потому, что сервер LDAP очень часто поставляется как исходный инструмент, который должен быть настроен и для которого администратор должен создать схему, создать утилиты администрирования и продумать возможности резервирования и восстановления, которые бы вписывались в общую структуру сети. Серверы LDAP в общем случае кажутся высоко затратными и рискованными средствами.

По сравнению с этим Microsoft Active Directory представляется как легко устанавливаемый и настраиваемый продукт, поставляемый со всеми необходимыми утилитами для развертывания и управления Каталогом. На предприятиях, испытывающих недостаток в технически компетентных специалистах, Active Directory представляется хорошим выбором. На предприятиях, которые имеют компетентных сотрудников, чтобы хорошо справляться с Active Directory, неплохой альтернативой является LDAP. Истинная проблема в том, какой тип решения нужен предприятию. Если менеджмент желает остановиться на альтернативных решениях, нужно взглянуть на дополнительные возможности этого решения, с другой стороны, если менеджмент хочет просто работающее решение, остановитесь на Microsoft Active Directory.

3. Мы хотим развернуть один PDC на Samba, четыре BDC на Samba, и 10 серверов Samba. Возможно ли использование NIS вместо LDAP?

- Да, можно использовать NIS вместо LDAP, но могут возникнуть проблемы с хранением корректно синхронизированных шифрованный паролей Windows (SMB) в пространстве сети. Рабочие станции Windows периодически изменяют их пароль безопасности учетной записи членства в домене (пароль рабочей станции, состоящей в домене, прим.перев.). Вы можете как-то сохранять изменения, которые синхронизируют удаленные BDC на PDC?

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

4. Вы советуете, чтобы пользователи не осуществляли вход (имеется ввиду локальный, прим.перев.) на сервер член домена. Если это так, почему?

- Многие администраторы UNIX высмеивают модель, которую индустрия персональных компьютеров приняла как стандарт с самого начала появления Novell NetWare. Старая концепция необходимости держать пользователей подальше от принт- и файл-серверов была результатом опасений относительно безопасности и целостности данных. Это была простая и в целом эффективная мера — держать пользователей вдалеке от серверов, за исключением подключения сетевых дисков.

Администраторы UNIX совершенно правы, когда утверждают, что серверы и рабочие станции UNIX одинаковы в отношении установленного программного обеспечения. Они правы, когда говорят, что в правильно защищенной среде безопасно хранить файлы в системе, у которой сотни пользователей. Но все администраторы UNIX должны хорошо взвесить решение, позволять или нет вход пользователю на систему UNIX которая, в основном является принт- или файл-сервером, всегда существует риск элементарных ошибок пользователя. Только в этом случае каждый может произвести оценку лучшей стратегии и выбрать определенную политику на предприятии, которая лучше всего защитит потребности пользователя, как и самого предприятия.

Из опыта можно посоветовать свести входы в важные системы к минимуму, а по возможности исключить их. Но все же это не должно быть принято как нерушимое правило.

5. Мы хотим убедиться, что только пользователи нашего собственного домена, а также из домена с доверительными отношениями могут пользоваться сервером Samba. В файле smb.conf на всех серверах у нас включен параметр winbind trusted domains only. Сейчас мы обнаружили, что пользователи из домена, с которым у нас установлено доверие, не могут получить доступ к нашим серверам, а пользователи клиентов Windows, которые не являются членами домена как раз имеют доступ на эти сервера. Это какая-то ошибка Samba?

- man-страницы говорят о параметре winbind trusted domains only следующее: «этот параметр предназначен для того, чтобы позволить серверам Samba, которые являются членами домена, управляемого Samba, использовать учетные записи UNIX, распространяемые через NIS, rsync или LDAP как UID'ы для пользователей winbindd в компьютерах первичного домена (hosts primary domain). Следовательно, пользователь SAMBA\user1 будет присоединен (mapped) к учетной записи user1 в файле /etc/passwd вместо выделения нового UID для него или для нее». Это четко намекает на то, что вы пытаетесь использовать этот параметр не по назначению.

Гораздо лучшим решением будет использование параметра valid users для описания строго оговаривания пользователей и групп домена, которым будет позволен доступ к общему ресурсу. Например, вы можете установить следующий параметр:

[demoshare]
	path = /export/demodata
	valid users = @"Domain Users", @"OTHERDOMAIN\Domain Users"

6. Каковы выгоды от использования LDAP для моих серверов членов домена?

- Основной эффект от использования LDAP в том, что UID всех пользователей и GID всех групп глобально согласованны на контроллерах домена, а также на серверах членах домена. Это значит, что можно копировать/реплицировать файлы во всем пространстве серверов без потери индентичности.

Когда используется авторизация учетных записей посредством winbind, даже когда бэкенд IDMAP хранится в LDAP, UID/GID на серверах членах домена согласованы, но отличаются от ID, которые пользователи/группы имеют на контроллерах домена. Winbind распределил UID/GID, которые хранятся в LDAP (или локально) и будут находится в числовом диапазоне, заданном в параметрах idmap uid/gid файла smb.conf. На контроллерах домена, UID/GID берется из значений POSIX, заданных в Каталоге LDAP как часть информации учетной записи POSIX.

7. Действительно ли для Samba+LDAP необходима работа DNS? Если это так, что я должен добавить в конфигурацию DNS?

- Samba зависит от корректного функционирования разрешения имен компьютеров по их IP адресам. Samba не делает прямой опрос DNS, а скорее производит пересылку всех вызовов имен-к-адресам (name-to-address calls) через функциональные вызовы getXXXbyXXX(). Конфигурация записи hosts в файле NSS /etc/nsswitch.conf определяет основной применяемый процесс разрешения. Если запись hosts вашего управляющего файла NSS выглядит так:

hosts: files dns wins

это значит, что при определении имени компьютера сначала будет сделана попытка обратиться к файлу /etc/hosts. Если разрешение не удастся, будет осуществлен с помощью DNS, если и на этот раз разрешение потерпит неудачу, последует обращение к WINS.

Дополнительный поиск при помощи WINS имеет смысл, только если NetBIOS поверх TCP/IP включен на всех клиентах Windows. Там, где NetBIOS поверх TCP/IP отключен, для разрешения имен предпочтительнее использовать технологию DNS. Обычно это имеет смысл в тех случаях, когда Samba является клиентом Active Directory, где использование NetBIOS было отключено. В этом случае Windows 200x авторегистрирует все записи указателей (locator records), которые требуются его собственному DNS серверу или серверам.

8. Наш домен под управлением Windows 2003 Server с Active Directory, который запущен с отключенным NetBIOS? Мы можем использовать Samba-3 в такой конфигурации?

- Да.

9. Когда я пытаюсь выполнить команду net ads join, я не получаю никакого вывода. Ничего не работает, я думаю тут какая-то ошибка. Затем я делаю команду net rpc join и все прекрасно работает. Что тут в правильно, а что нет?

- Нет, это не порядок. Это значит, что ваш клиент Samba-3 был включен в домен ADS, но Samba-3 не будет использовать аутентификацию, основанную на Kerberos.
(к началу страницы)